Actually, I think the depreciation point is one of the better points. Yeah, sometimes clean up is necessary, but when a language is a moving target like that, it raises serious concerns about portability and long term maintenance.
But the PHP guys had told us about the deprecation of pass-by-reference years before it was deprecated. I think that's a really good argument for portability and long term maintenance.
It they would've simply changed it over night, I'd have problems.
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.
> When exploring how a web app should work, you should be thinking at all levels: view, controller, model.
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?
The explosion you speak of is sites making better use of JavaScript, a movement that took off with the launch of gmail in 2004. Paul Buchheit talks about the thinking and communication that created gmail. He doesn't mention MVC; he talks a lot about rapid prototyping. He shares some of his then-current thinking in the form of a single 600-line source file. Read the post: http://paulbuchheit.blogspot.com/2009/01/communicating-with-...
Let me take this in a slightly different direction.
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.
PHP is great if you need to get some small thing up and running yesterday. PHP is also great if an out of the box solution will almost fit the bill due to the fact that there are so many. Just take a box and do some small modifications, voila, done!
...or big thing running yesterday, right? Take Facebook for an example.
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.
He didn't say you _can't_ use PHP for such things, he said PHP is "great" for getting smaller sites built quickly. It's possible to build very large apps with PHP alone, if you like, but there are other solutions I think are preferable. Most of them weren't even available when Facebook was born.
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.
Rails would get you started on Facebook app quicker, but then you'd be forever fighting the framework to do things outside of it's core abilities. For something as large as Facebook, that will be all the time.
Somewhere I read a quote that went "if you take the top 100 most popular websites on the internet... 90 of them use PHP". I don't have the source and I don't know if it's still true.. but you can add Yahoo, WordPress, PhotoBucket, SourceForge, etc...
It's probably fair to say that all of these started out pretty small (and quite a lot time ago). If you're a one-man company with a great idea and possibly not a huge amount of programming experience, then PHP is a fair choice for prototyping your design and getting things off the ground.
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.
"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."
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:
"I often hear 'more practical', but rarely 'better'"
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.
Quora's decision to use python seems to support your theory:
"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."
PHP may be one weird concoction, that's for sure, but all of the arguments brought up by this guy - and this is the exact same boring song belched out whenever there's an argument of "PHP is a terrible language" - fall into the category of vanity, because no matter how one twists and turns these points they still really don't make the language itself terrible, and they don't make PHP one bit less capable, nor one bit less adequate for the supposed job.
What do you mean?? Do you have any idea of just how many programmer hours have been wasted by the absence of features, just how insecure so many web apps are due to the weird casting system and lack of safety-oriented features.
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.
Without going off on a limb, I'm guessing you're a not too experienced developer. You comment as if instead going for Perl, Ruby or ASP inherently makes an application safe, saves buttloads of manhours etc. And you're wrong. Gravely wrong.
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.
A well designed language or library can decrease the likelihood of specific bugs, and especially security problems. Imagine the existence of a library which made it easier to use SQL placeholders than to concatenate user input into a string. Imagine PHP without register globals.
Really? So the fact that you are unknowingly casting integers to strings and vice-versa does not lead to security vulnerabilities is just fiction? Being able to escape characters? Making prepared statements and having sane exception management?
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.
To be honest I don't think case insensitivity is really that much of an issue. Common Lisp is case insensitive as well and I have never had any problems with that.
I'm spending most of my time maintaining a web application consisting of around 150k lines of PHP code. We (well - initially, it was just me) began development back in 2004 but since then the application has grown constantly.
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.
It's just as secure as any other language you can write insecure code in (i.e. all of them).
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).
Is there a possibility things would be better if PHP was abandoned?
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.
You mean to tell me that in a world where anyone could take up on any programming language and start writing code on one's own, properly educating that someone is feasible?
Please. This isn't 1960 anymore. Code is not written by "scientists" exclusively anymore.
up until very recently, no templating language provided XSS protection by default. Rails sample code you see in the various tutorial for example still is full of <h1><%= title %></h1> which for all versions of rails < 3 is an open door for an XSS attack.
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?"
> 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.
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.
The '123n'==123 conversion is the cause for at least 8 very nasty bugs in validating user input in that application I was referring to.
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)
I never said it wasn't weird!! I just said that it's not really a practical problem in most cases. Perhaps you do have to be extra careful and I'm just so used to it that I don't give it a second thought.
From the documentation: "A key may be either an integer or a string" So your boolean true is converted to the integer 1 and your boolean false is converted to the integer 0. Dump those arrays and you'll see they don't contain boolean keys. Then it's just a simple matter of '0' == 0 and ' 0' != 1. It's all perfectly logical.
Yeah, I can stare at the docs and work out the consequences of the ridiculous design decisions they committed to (such as array keys using an equivalence relation while equals does not, and some but not all strings being true yet converting to zero). But for me it's just too blatantly wrong to keep a good grasp on, and the experience of trying to resembles the Book from Anathem:
> 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.
I don't bother keeping a good grasp on it. The less you try and reason about it, the more likely it works as intended. You can concoct lots of scenarios where the type system in PHP breaks down yet in the average well-designed code those sorts of problems are rare.
Your example highlights some weirdness in the type system, but that could would never exist in actual product.
These topics always just smell of "Now I'm a grown up programmer I'm going to tell the world how much I understand by slamming an easy target language".
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.
Yeah, but if we continue that logic and fill up that "etc etc" it would seem that the other languages have their own bad features and PHP combines them all.
That "all" is what I'm referring to when I mentioned confirmation bias. PHP programs don't segfault when you have a typo. You don't have macro expansion problems. It's not particularly verbose. Most languages have a ton of issues. Imho, the stuff in the PHP list is pretty minor compared to some of the warts in some other languages.
Yeah, the minor details of PHP don't really matter. It's the whole language and ecosystem when viewed as one that is really repulsive. It's also difficult to write good code, because there are no abstraction mechanisms.
Well, there's one -- Java-style OO. But incidentally, Java is almost impossible to use for the same reason.
I'm curious why you think the ecosystem contributes to the bad rep. If anything, I think that's one thing PHP has going for it. In general, yes, seasoned programmers who are new(ish) to PHP tend to have a bit of a NIH-based bias against the frameworks, but you gotta admit that other languages simply don't have the one-click-install-everything-you-will-never-need sort of thing that Fantastico or whatever gives you.
>> Well, there's one -- Java-style OO. But incidentally, Java is almost impossible to use for the same reason.
I think this is the wrong approach. The guy should try to convince me that PHP is bad. That PHP has never not did what I wanted it to do. That I need to invest time and switch to some other language because it's better for my needs and purposes, and the switch will quickly get me to a level of expertise that I have with PHP now.
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.
The guy should try to convince me that PHP is bad.
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).
I wish I could ignore PHP, but it's just so darn ubiquitous. Most webhosts priced within the means of "normal" people have PHP, while far superior (IMO) platforms like ASP.NET are the exception. Until webhosts can be convinced to support a wider range of platforms, I fear humanity will never be freed of the bonds of PHP.
From a programming language perspective, PHP is somewhat horrible (PHP 5.3 less so, but still). I guess nobody will deny that. But from practical perspective, PHP is very suitable tool for many tasks and has huge ecosystem behind it. Complex real-world websites and applications have been successfully built with PHP. Isn't that proof enough?
Do you consider yourself a purist or pragmatic? In the latter case, PHP may be worth dating for a while.
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.)
To answer to the topic of the post - why should I (or anyone else for that matter) bother trying to convince the author that PHP isn't horrible.
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'.
My friend Anthony Lewin and I were Macintosh salespeople back in the Dark Times when Jedi Master Jobs was in exile. People would walk in to the store and ask the same question:
Convince me: Why should I buy a Mac instead of a PC?
Anthony quickly learned not to feed the trolls. He would say "I don't know. Why would you buy a Mac instead of a PC? Most people buy PCs. What's so special about you that you need what a Mac has to offer?"
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?
Doesn't this fit more appropriately the other way around?
"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?
Drupal, Joomla, Wordpress, phpbb, vbulletin, invision power board::
Together they are 99% of online communities + personal websites. If you want to use any of them. Then it is php.
I may not particularly like PHP, but to deliver projects in reasonable time, you may have to leverage PHP
This debate reminds me a lot about another debate about language. When I studied English in college, I occasionally came across papers enumerating the weaknesses of the English language. It's terrible for writing poetry, because you can't rhyme like you can with Italian or seduce like you can with French. It's difficult to learn, because of irregularities in spelling and pronunciation.
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.
It's a little pointless to defend PHP to someone who thinks it's horrible.
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.
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.
php is a tool. it has its benefits and its drawbacks. you shouldn't have to "defend" the language itself, but you should be able to defend your choice of language. if you don't like a language, go use another one.
I'm wondering, as a fairly inexperience programmer with most of my time in PHP: is there any good reference for "How to start web development in ___ with previous experience only in PHP". I would love a tutorial that explained how to accomplish in another language all the things that PHP makes simple for newbies. I'd also be totally willing to help an experience person develop such a tutorial.
73 comments
[ 2.7 ms ] story [ 128 ms ] threadIt they would've simply changed it over night, I'd have problems.
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.
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.
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.
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.
> 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 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 :)
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).
Bill, hates PHP with the heat of a thousand suns.
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.)
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 :)
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 don't need to compete in a race to the bottom.
I may not particularly like PHP, but to deliver projects in reasonable time, you may have to leverage PHP
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.
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.
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.