Stack Overflow: Defend PHP - convince me it isn't horrible
stackoverflow.com
stackoverflow.com
I love PHP and have used it for years since moving away from asp.net and agree with some of the posters arguments as a theoretical principle, but as day-to-day PHP developer I also say so what. Naming and parameter inconsistencies? Yes, my libraries have that too and I can at least learn the PHP ones with some experiernce. I don't know any asp.net developer that doesn't have to use some kind of tool to help them find where System.Obscure.FoundItOnline.Function exists in the monster .net namespace system. It allows me to be productive and allows me to be the gatekeeper of how well or poorly I implement things. This is a crucial point of the constant argument about poor PHP logic/presentation support for me, I can happily write mixed and messy code for a £500 job or I can write some clever system that implements caching and output buffer manipulation and have a great template system.
There are far too many people spending far too much time thinking that academic level programming considerations are applicable in every detail to every day programming practices of web developers.
- PHP has inconsistent naming of built-in and library functions. - C has types like int, size_t, jmp_buf and FILE
- PHP performance is abysmal without caching - MRI Ruby is pretty slow too
- Functions are case insensitive - Lisp anyone?
etc etc
The whole meme of PHP warts seems more like an exercise in confirmation bias than objective analysis.
Well, there's one -- Java-style OO. But incidentally, Java is almost impossible to use for the same reason.
>> Well, there's one -- Java-style OO. But incidentally, Java is almost impossible to use for the same reason.
Tiobe begs to differ :)
PHP encourages (practically requires) a coupling of processing with presentation. Yes, you can write PHP that doesn't do so, but it's actually easier to write code in the incorrect (from a sound design perspective) manner.
The ideal web application is the one that best fits the unique characteristics of the data being manipulated. When exploring how a web app should work, you should be thinking at all levels: view, controller, model. A framework that forces you to separate all three from the start is a bad framework. It pushes you toward generic data manipulation forms and reports. If those generic tools are the best ones for the data model being manipulated, why involve a programmer at all?
We would have much more interesting and varied web applications out there if the prevailing "wisdom" of MVC would die.
And separating those aspects programmatically makes it easier to think about them, not to mention program the ideas that occur to you when thinking about them separately.
> If those generic tools are the best ones for the data model being manipulated, why involve a programmer at all?
If intertwining essentially unrelated ideas is the best way to write programs, why use high level languages at all?
MVC--just like garbage collection, just data abstraction, just like most other high level languages features--is about modularity and separation of concerns.
> We would have much more interesting and varied web applications out there if the prevailing "wisdom" of MVC would die.
How do you reconcile this with the fact that there occurred a veritable explosion of various interesting web applications when MVC was (re)discovered by the webdev crowd?
EDIT: HN discussion: http://news.ycombinator.com/item?id=444615
The problem with paradigms (such as MVC, ORM, and OOP) is that no one paradigm is perfectly suited for all problems, but people tend to forget that.
(Why do they forget? Because there are advantages to picking one set of paradigms and focusing on them to the exclusion of all others: It focuses your toolkit development and your documentation and makes the story of your platform easier to tell. Thus, we have systems like Rails, where everything from Hello, World on up requires at least passing knowledge of MVC and objects, and the whole system is designed around the assumption that you are building an MVC web app, using an ORM with a certain standard layout, placing files in standard locations, et cetera.)
Unfortunately, there is one very important class of problem that most frameworks are ill-suited for: Very, very simple programs. Programs like the ones you write when you're new. Like a one-field "sign up for my mailing list" application, or a "guess the number between 1 and 100" application like the one I rewrote dozens of times in my Applesoft-BASIC-tinged youth.
PHP offers the new programmer the simplest thing that could possibly work. You edit your HTML file, sprinkle a line of PHP into it, and save it with a .php extension, and (assuming your $5/month web host set up Apache correctly) lo, you have a web application!
But you won't get any distance into (e.g.) Rails before the books and the docs insist on sending you to school, instead of straightforwardly doing what you want. "We know you want to write a one-page app", say the docs, "but first we'd like to give you a miniature degree in software development. We want to teach you about installing software on a Unix system, and using the command line, and what objects are, and what an ORM is, and what MVC is and why you should care".
Or, perhaps, you will use a walkthrough to generate your Hello, World. You will either use the scaffolding -- e.g. type some mystical incantations that seem to have nothing to do with HTML, or Ruby, or the web, and that have to be done on the command line and preferably not in Windows -- or you will edit multiple files in multiple places to set up your tiny view, and your tiny controller. Then you have Hello, World. To go any farther will require some more training. Budget a day or two to read the book. Maybe buy another book.
Heroku has gone to heroic efforts to remove some of these stumbling blocks, but there's only so much they can do. Rails is a professional tool for professionals. Like emacs, it takes time and determination to learn. And, like emacs, you're not likely to be motivated to learn it until you have cut your teeth on the equivalent of Notepad. But, in web development, the equivalent of Notepad is PHP. None of the other frameworks bother with such silly stuff.
I'm convinced that the big strength of PHP is that new people can pick it up fast. And this strength just builds on itself, all the way up to systems like Drupal. Not only because new PHP programmers gradually become experienced PHP programmers via a steady ramp, but because even an extremely advanced and complex PHP program has many edges -- like the templates -- which inexperienced programmers will want to be able to edit. And they can, because PHP is evolved to be simple and straightforward.
If you choose mod_perl, mod_python, JSP, or most of the classic environments you need a sysadmin to take care of the web server... It's going to crash from time to time, run out of memory, and otherwise make trouble for you.
PHP's mode of integration with the prefork Apache web server is almost trouble-free... It's such a big difference that there could be a "blub" factor here... People who program in other environments often have a really hard time believing that a large fraction of the sysadmin activities that they are doing just don't need to be done if you're running PHP. (You can go five years and never "kick Tomcat", something that some shops have to do every 5 hours).
That said, scaling comes to play here. For a small company or for a company that's doing a number of small projects, the cost of system administration that comes with other programming environment matters a lot more than it does for a big company. It's not such a big factor for a company like Facebook.
On the other hand, PHP forces people into a "shared nothing" model that scales well and ~eliminates~ a wide range of concurrency-related problems that are endemic to thread-based backend apps. For instance, quite often I've seen a race condition in an ASP.NET app and had everybody on the team swear up and down that there's no shared state, then I spend a few hours looking at the app and there's a static variable that nobody knew was there.
Another strength of PHP is that it has a very complete library that's largely correct. The PHP team is much more honest about what works and what doesn't work than a lot of others (PHP and Python have the same problem with threads, for the same reason -- PHP says "don't use them", Python says "jump in the water is fine".) If you program in some weird-o language like Haskell you'll probably have to write your own urldecode function and you'll probably be so busy thinking about higher-order functions you won't pay attention to details... Like making it work right. (Perl has a broken urldecode function in CPAN FOREVER)
Don't get me wrong, there's plenty to hate about PHP; but try to get some real work done in environment X and you'll find plenty to hate too.
The fact of the matter is PHP is ugly and that's really it. I can live with ugly because I know it and it does everything I've ever asked it to.
Frankly, it's no different than me switching from English because it has quirks.
It goes both ways: he has tried to do certain things with PHP and made his life miserable; you've done certain things with PHP that made your life easier.
Telling each other which is which will let the one know what to avoid and the other one what's he doing wrong.
Anyway, it's about time we started thinking and being more mature than 'my language is better than yours'. Which is why I hate all similar postings and articles which aim to enlighten me On the Amazing Features Of Language X (or the opposite).
Now that I'm a PHP developer, the response I give when people ask me why I use PHP and not a "real language" is the same one I would give if someone asked me why I speak English. There are more people who speak my language. If I travel to a remote fishing village in China, chances are I can find one person who speaks English. Try to find someone who speaks Italian. When I'm working on a web project, I know that if I write it in PHP I can find hundreds of developers to hire at a reasonable price versus hunting around for Ruby developers (who cost double).
At my day job, we run 200 websites, and 194 of them are written in PHP (1 is Java, 2 are .NET, 1 Ruby, 2 Coldfusion). When the company buys sites, the first step is converting them to PHP (if they aren't already), just so future maintenance is easy and cheap.
foobar() == FOOBAR() $foobar != $fooBar
It they would've simply changed it over night, I'd have problems.
Use it yourself and keep using it for as long as you like it. When you stop liking it, stop using it.
That doubles as a recipe for learning any new thing.
Bill, hates PHP with the heat of a thousand suns.
Back in 04, I already felt some reservations against PHP, but that's what I knew best and that's what was most used for the web (Rails might have been around, but not really known - other ruby options were not quite there yet. Python I disliked and Java I. don't. touch.).
The application was written in PHP5, initially developed on some RC of 5.0.0 and I was careful to keep a clean style and not using deprecated code.
This lead to a quite clean application that I could really be proud of. And still: While it has suffered from sometimes not quite reasonable customer demands, it's still very good at what it's doing and while there might be some dead bodies rotting in the code, it's nowhere near daily WTF material (aside of some bugs we have a good laugh at and fix shamefully).
Still. I have some bad gripes with PHP that made me stop doing anything new in that language.
I can easily live with the usually quoted problems though:
- parameter order in library function? I don't care - my IDE lists them.
- Huge base library? I don't care as the stuff I don't need doesn't cost me anything but disk space and the stuff I do need, I'm glad is there.
- No namespaces? Yeah. Bit me a couple of times, but I can work around that - besides, with 5.3 we got namespaces, so this doesn't count any more
- Performance issues? It's fast enough for said application.
- Security? It's just as secure as any other language you can write insecure code in (i.e. all of them).
- Allows intermixing of layout and code? Sure, but you don't have to. If you have any sense what so ever, all requests go through a central /index.php and all other code is in some not-publicly accessible location and emits no html what so ever. All output is generated using any of the thousands of templating libraries.
What really disturbs me about PHP is its type conversion rules. 1 == '1' or even worse 'foobar' == 0, or '123n' == 123. This is cause for so many subtle bugs.
Just use === you tell me? Sure, but then you clutter your code with an insane amount of isset()'s and isint()'s and whatnot - the fact that the database library I'm using (pgsql) returns everything as strings doesn't help that cause either.
The other thing is the really clumsy syntax. Array literals, anonymous functions, closures (with explicit declaration of all variables of the outer scope you want access to), operators, even just the lack of named function parameters. The syntax is clumsy and all the elegant code you see even from JavaScript just gets bloated and unreadable once you port it to PHP.
These two issues made me do stuff in Ruby, Python(3) and lately a lot of Node.js, but the maintenance of that huge application remains to be the main part of my day-job and even though the two issues really bug me, it's still not painful enough to really be complaining (or, heaven forbid, port the thing to whatever-other-language-thats-currently-hip).
So in retrospect, while I'm as die-hard a PHP user as you can get with many, many lines of PHP under my belt and while I do find some of the stuff highly enjoyable (php's arrays that are also ordered hashes for example. Or the really easy and accessible web-server/HTTP integration), I also dislike it quite a bit to the point of being unwilling to start something new in PHP.
That may be true; I've only developed two half-serious projects in PHP a while back. But given the amount of XSS and injection vulnerabilities we're seeing daily, I think that something is wrong with those web development guys. PHP is admittedly a widely used tool and I can't help but wonder: "Could it be just the language? Is there a possibility things would be better if PHP was abandoned?". Of course things would improve if we educated all PHP developers on the security implications of whatever it is they're programming. But so many years of coding have shown it's infeasible (for any language).
Nope. Beginning coders write vulnerabilities until they're otherwise educated. In PHP these are SQL injection and XSS holes. In C they're buffer overflows.
Of course things would improve if we educated all PHP developers on the security implications of whatever it is they're programming. But so many years of coding have shown it's infeasible (for any language).
Education is feasible for any language. Some segment of the programming population will always remain uneducated -- laziness or apathy on their part -- but this doesn't mean education doesn't work.
Please. This isn't 1960 anymore. Code is not written by "scientists" exclusively anymore.
PHP had a filter extension that helps with this for ages, but it's not on by default and not widely used by the various projects which hope/need to still run on up to 10 years old versions of PHP.
We'll see how the common Rails user will react to all text injected into ERB being escaped by default. I'm sure this will cause rants like http://news.ycombinator.com/item?id=1162122 which was complaining that ruby 1.9's string handling became "so complicated".
"but... I just want to allow the user to type HTML and to display it - why do I have to go all these lengths to accomplish that?"
Weird cases like 'foobar' == 0 are extremely rare and 1 == '1' is actually what you want most of the time. I've learned to embrace the type-less nature and use casts when I absolutely want to ensure a particular type. I no longer even consider this a problem.
And the fact that when comparing integer to strings, PHP prefers to convert the string to compare instead of converting the number (which would be lossless)
In my opinion, you have to be doing a lot of other things incorrectly for this to be a real problem.
The only way to safely do that in PHP is, sadly, a regular expression.
is_int checks the type, so is_int('1234') is as false as is_int('123n') or is_int('abc')
is_numeric is too permissive as it allows floating point numbers or even hexadecimal values.
intval($foobar) == $foobar doesn't work due to intval('123n') == 123
intval($foobar) === $foobar naturally doesn't work because the types don't match.
The code in question is the receiving end of some machine generated communication that is supposed to closely follow a specification.
During validation if the spec says that it requires a base10 integer encoded in ASCII, then 0xFF isn't permissible just because is_numeric() says so.
function is_intval($value)
{
if (is_integer($value)) return true;
if (is_bool($value)) return true;
if (!is_numeric($value)) return false;
if (is_float($value) && floatval(intval($value)) == $value) return true;
if (is_string($value) && strval(intval($value)) == $value) return true;
return false;
} '0' == false
array('0' => 'x') == array(false => 'x')
' 0' == true
array(' 0' => 'x') != array(true => 'x')
> crafted and refined over many centuries to be nonsensical, maddening, and pointless[....] The punishment lay in knowing that you were putting all of that effort into letting a kind of intellectual poison infiltrate your brain to its very roots.
Your example highlights some weirdness in the type system, but that could would never exist in actual product.
I don't need to compete in a race to the bottom.
Do you consider yourself a purist or pragmatic? In the latter case, PHP may be worth dating for a while.
Thanks to PHP or in spite of PHP?
Seriously, I like the photographing analogy: "Wow, what a photo you have taken! You must have really good camera?"
A programming language is rarely the limiting factor. Skillful programmer may benefit from advanced language, but mostly it's about knowing your tools and the bigger concepts, regardless of the language. Try yourself and learn to master something you like most. (My current choice being Python.)
That's like asking someone to defend a religion. A waste of time and energy.
In a good programmer's hands, the results will be good, regardless of language or platform choice.
Sure, you can argue the finer points until you're blue in the face, but in the end, the only thing that should matter to your "customer" is that the solution satisfies his/her needs.
To me, Facebook seems like a pretty complicated piece of software. The concept isn't very complicated but there are so many features all over the place.
For example, I would rather build a Facebook-sized app in Rails than a PHP framework, especially with Rails 3's new features. There are some very capable PHP frameworks out there, but you'll still end up writing much larger models and a lot more code than if you were using Rails.
Then, when you realise it's a runaway success and all the investment starts piling on board, the last thing you want to do is stop and tread water for 6 months whilst you rewrite everything (introducing a whole new set of problems as you do), just to get back up to where you are now, before adding those new features.
So, arguably these sites are successful because of their ideas, and the fact that they use PHP is more likely a historical accident than a carefully considered decision, at least in terms of their codebase.
To put a positive spin on it, you could argue that their early choice of PHP is what allowed them to become successful by letting them get their ideas out, rather than the best technology for a internet top-100 site or whatever.
Using Ruby on Rails, .NET, or python won't magically give you great programming skills. If you are a poor developer in general, you will run into problems with all of these languages.
"So, arguably these sites are successful because of their ideas, and the fact that they use PHP is more likely a historical accident than a carefully considered decision, at least in terms of their codebase."
All sites are successful because of their ideas. Using language X is just a design choice. I carefully choose php for all of my projects because it's better than all of the alternatives. I know I'm not alone in my thinking.
"To put a positive spin on it, you could argue that their early choice of PHP is what allowed them to become successful by letting them get their ideas out, rather than the best technology for a internet top-100 site or whatever."
A positive spin? How about a bias spin against php. If this were the case, we would see many more sites using other languages because PHP is so terrible.
Here is an old article on why the guy from cdbaby.com switched from ruby back to php:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...
I often hear 'more practical', but rarely 'better', would you care to describe what features work better for you than what the alternatives offer?
Why "more practical"? There are a slew of other languages and frameworks out there that could be used.
PHP gives you the flexibility to create more complex projects without being pigeon-holed into one specific framework. I noticed this with some of the newer languages (and frameworks) such as RoR and Django. The higher the level you go, the more difficult it is to get around the built-in features that try to make it easier to develop an application. PHP is at the perfect level for me. Higher than say c, but lower than something like RoR.
Also, the c syntax makes it to move onto other languages.
It's also been around for 15 years, which means a plethora of support and examples. The language itself may have some issues (naming convention, Unicode support, non-standard namespace convention), but it can still be used to create solid applications that scale well (if you know what you are doing).
Since PHP has been around longer, people really need to come up with reasons NOT to use it (and why I should be using new language X). So far, I'm not convinced.
"PHP was out of the question. Facebook is stuck on that for legacy reasons, not because it's the best choice right now. Our main takeaway from that experience is that programming language choice is very important and is extremely costly to change."
From: http://www.quora.com/Why-did-Quora-choose-Python-for-its-dev...
My impression is that people who claim PHP has not cost them development time have simply never looked at alternatives that solve many of the problems.
Excluding the obvious issues caused by bugs that are a natural part of any programming language's development, security problems are not caused by the language chosen, but by the developers themselves.
Putting PHP in the "inadequate corner" or trying to convince oneself that it is lacking in features is just an easy excuse.
Do you object to the attractive nuisance doctrine?
If your statement were true, then by that measure making a program in assembly would be as safe as doing it in C#. Evidently, it is not. Languages make certain idioms easier or worse, and they have a culture of security or they do not, which is reflected in development methodologies, libraries, and code samples.
PHP fails massively in all those regards.
If the author does not think that PHP is suited for his/her needs then he/she should not use it. There is a plethora of programming languages out there - pick and choose.
The post has a disconnect between the title and the content. The author does not want to use PHP and tries to outline the flaws in the language from his/her own view. Sorry to disappoint, but I disagree with those points. I use PHP amongst other programming languages and I use it only when it suits my needs and the needs of my project. It is not perfect but then again nothing is.
Final thought for the article would be a paraphrase of its title as a reply:
Defend 'behaviour'. Convince me it isn't spelled horribly - correct spelling 'behavior'.
I think you get the point :)
Convince me: Why should I buy a Mac instead of a PC?
The genuinely curious would explain about their graphics needs or what-not, and Anthony would go from there.
I think of Anthony when I see questions like this. My response back to the OP is to ask Why should you use PHP? What's so special about your situation that you need it?
"I don't know. Why would you use a language other than PHP? Most people use PHP. What's so special about you that you need what another language has to offer?"
In your example, the PC is the inferior but nearly ubiquitous (and easier) choice. Isn't that the position PHP is in as well?
I may not particularly like PHP, but to deliver projects in reasonable time, you may have to leverage PHP