PHP Sucks, But It Doesn't Matter(codinghorror.com)
codinghorror.com
PHP Sucks, But It Doesn't Matter
http://www.codinghorror.com/blog/archives/001119.html
63 comments
There is one more reason PHP is popular, not mentioned often: PHP is an embedded language and is designed to work well with HTTP servers. When you first hear that, you say "ah, go embed any language, then write your mod_x for Apache, what's the problem with it?".
The problem is that it's not that simple. PHP is "embeddable" specifically for markup languages by design, and it was also designed with Apache's modularity in mind (I supppose).
Perhaps Perl could have been a good candidate too, but it missed the train by not shipping the embedding feature in default installations.
Python, or any language that depends on newlines, sucks for embedding in markups.
So, PHP wins the battle because it was created with HTML and HTTP in mind. Could have been better, much better, much-much-much better. Okay. But that doesn't matter for now :)
The problem is that it's not that simple. PHP is "embeddable" specifically for markup languages by design, and it was also designed with Apache's modularity in mind (I supppose).
Perhaps Perl could have been a good candidate too, but it missed the train by not shipping the embedding feature in default installations.
Python, or any language that depends on newlines, sucks for embedding in markups.
So, PHP wins the battle because it was created with HTML and HTTP in mind. Could have been better, much better, much-much-much better. Okay. But that doesn't matter for now :)
PHP is "embeddable" specifically for markup languages by design
Not it is not! No it is not! Sorry to yell, but you're touching on one of my biggest peeves. The syntax that embeds PHP in the SGML family of markup languages was simply tacked on to an arbitrary syntax that vaguely resembles C and Perl. It was never designed.
I wrote a language that actually was designed to embed dynamic strings in static strings. It doesn't get ugly the way PHP does when you embed static strings within dynamic code within your outer static markup. It doesn't look anything like PHP.
Not it is not! No it is not! Sorry to yell, but you're touching on one of my biggest peeves. The syntax that embeds PHP in the SGML family of markup languages was simply tacked on to an arbitrary syntax that vaguely resembles C and Perl. It was never designed.
I wrote a language that actually was designed to embed dynamic strings in static strings. It doesn't get ugly the way PHP does when you embed static strings within dynamic code within your outer static markup. It doesn't look anything like PHP.
Well, Bruce, perhaps
...The best way to think of BRL is as a Scheme interpreter with an alternative syntax for strings
is where you should look for reasons of BRL's unpopularity, I think.
Can you tell us please, what is really special about BRL other than it being "Scheme with square brackets"?
...The best way to think of BRL is as a Scheme interpreter with an alternative syntax for strings
is where you should look for reasons of BRL's unpopularity, I think.
Can you tell us please, what is really special about BRL other than it being "Scheme with square brackets"?
The define-input syntax makes form handling almost as easy as PHP with register_globals on, while at the same time being as secure as PHP with register_globals off -- the best of both worlds. It's arguably more secure because of how conveniently one can use validator functions.
The sql-repeat syntax with group-beginning? and group-ending? makes sophisticated use of result sets much more accessible than looking behind/ahead a row manually.
Hoisting a function definition you quickly made within a page out to a sitewide definition is fast and easy, so doing something quick-and-dirty doesn't lock you into dirt forever.
And don't underestimate those square brackets. They totally optimize the human "inner loop" of web development. They beat the tar out of <%, %>, and the mess of quotes, backslashes and dots that constantly trip up newbies.
The sql-repeat syntax with group-beginning? and group-ending? makes sophisticated use of result sets much more accessible than looking behind/ahead a row manually.
Hoisting a function definition you quickly made within a page out to a sitewide definition is fast and easy, so doing something quick-and-dirty doesn't lock you into dirt forever.
And don't underestimate those square brackets. They totally optimize the human "inner loop" of web development. They beat the tar out of <%, %>, and the mess of quotes, backslashes and dots that constantly trip up newbies.
I don't underestimate square brackets, in fact I liked them, but i think the main problem is that BRL is Scheme.
If Scheme is not popular among web programmers, there must be a reason behind it, more than one reason, maybe a hundred reasons. But it's a fact. So I think if you are going to bring Scheme/Lisp into the web development market, you (I mean, not you personally, but in general) have to bring 2-3 new killer features along with HTML embedding and the language itself.
I'll try to understand BRL better, but from what you say above, those things don't seem to be really killer features. Even square brackets thing isn't a killer, I think.
If Scheme is not popular among web programmers, there must be a reason behind it, more than one reason, maybe a hundred reasons. But it's a fact. So I think if you are going to bring Scheme/Lisp into the web development market, you (I mean, not you personally, but in general) have to bring 2-3 new killer features along with HTML embedding and the language itself.
I'll try to understand BRL better, but from what you say above, those things don't seem to be really killer features. Even square brackets thing isn't a killer, I think.
You should check out Mako, a templating system for Python. Embedding Python (or Python-like) code in HTML is not as bad as one might think.
> the main reason we still PHP used so much, is that a lot of sites were build before 2005
That's really it - look at the dates on the sites he mentions. Wikipedia - 2002. Digg - 2004. Wordpress - 2003. FaceBook - 2004. Flickr - 2004.
The big hits of 2005 were YouTube (Python), Reddit (Python), and Twitter (Rails). Then there haven't really been many big hits since then - the ones I can think of with the most publicity are Pownce (Django), FriendFeed (Python), Justin.TV (Python), maybe Kongregate (Rails). So around 2005 there was a big shift away from PHP and towards Python/Ruby solutions.
There was a similar shift around 2000-2002 from Perl to PHP - the big hits then were LiveJournal (1998, Perl), Del.icio.us (2002, Perl), Blogger (1999, dunno), HotOrNot (2000, dunno), Craigslist (1996, Perl), EBay (1996, Perl), and IMDB (1998 or so, Perl).
That's really it - look at the dates on the sites he mentions. Wikipedia - 2002. Digg - 2004. Wordpress - 2003. FaceBook - 2004. Flickr - 2004.
The big hits of 2005 were YouTube (Python), Reddit (Python), and Twitter (Rails). Then there haven't really been many big hits since then - the ones I can think of with the most publicity are Pownce (Django), FriendFeed (Python), Justin.TV (Python), maybe Kongregate (Rails). So around 2005 there was a big shift away from PHP and towards Python/Ruby solutions.
There was a similar shift around 2000-2002 from Perl to PHP - the big hits then were LiveJournal (1998, Perl), Del.icio.us (2002, Perl), Blogger (1999, dunno), HotOrNot (2000, dunno), Craigslist (1996, Perl), EBay (1996, Perl), and IMDB (1998 or so, Perl).
> php --it was quick and dirty and easy to get started
I think that's the key, right there. Sites go after quick and dirty solutions, then scale and perfect from there. It's that low barrier to entry that I think draws so many developers to PHP, in spite of its problems.
I think that's the key, right there. Sites go after quick and dirty solutions, then scale and perfect from there. It's that low barrier to entry that I think draws so many developers to PHP, in spite of its problems.
I also feel like asp was also super popular before php came around.
yes, until .net was released, then it was droped overnight by the developers (well, within a couple of years).
I used it, while in school (around 2001) and remember doing anything with databases was a real pain. PHP felt like a step up.
When coming from ASP PHP was just amazing.
Not that it doesn't suck, it just sucks so much less than ASP :p
And there are still ASP developers around, I just recently worked with a company that still writes all their stuff (websites for paying customers!) in ASP
Not that it doesn't suck, it just sucks so much less than ASP :p
And there are still ASP developers around, I just recently worked with a company that still writes all their stuff (websites for paying customers!) in ASP
"And there are still ASP developers around, I just recently worked with a company that still writes all their stuff (websites for paying customers!) in ASP"
The company I work for has about 4000 customers on an application using ASP / SQL Server 2000. If it works and it does what people want, they really don't care or know even what language it is in.
The company I work for has about 4000 customers on an application using ASP / SQL Server 2000. If it works and it does what people want, they really don't care or know even what language it is in.
PHP is VB6 for the web - quick and dirty. though now with some good frameworks, it's no longer as dirty if a PHP developer is smart enough to use them
Can you edit that to "there were four popular choices"?
I wrote BRL, the sensible choice for something quick, based on Scheme, well before 2005.
I wrote BRL, the sensible choice for something quick, based on Scheme, well before 2005.
No offense intended, but BRL does not appear to be a popular choice.
It may have existed, but so did other possibilities not mentioned too, the idea was to summarize what choices your average developer had.
I would also add that a lot of people chose PHP because they had been working in it since the late 90s and needed a big improvement in order to justify changing.
I would also add that a lot of people chose PHP because they had been working in it since the late 90s and needed a big improvement in order to justify changing.
Right, I'm saying it wasn't popular.
It isn't that people tried BRL and decided its superiority in speed of development, speed of execution, security and learnability weren't big enough. It's that people didn't try it.
It isn't that people tried BRL and decided its superiority in speed of development, speed of execution, security and learnability weren't big enough. It's that people didn't try it.
Tcl things have been around a long time too, like Rivet, which was faster than PHP, and utilized a much nicer language.
The effective question is Why did PHP win over Perl for LAMP hosting? Java and .Net might as well have been on another planet.
The answer is that mod_php was a lot easier for a hosting provider to set up for shared hosting than mod_perl. Still is. The target user for scalable Perl and Python frameworks still seems to be someone with root access.
The answer is that mod_php was a lot easier for a hosting provider to set up for shared hosting than mod_perl. Still is. The target user for scalable Perl and Python frameworks still seems to be someone with root access.
The Perl community was too unfocused on the web. Perl was, and is, a general-purpose language built as a replacement for sed, awk, and shell scripts and later retrofitted for the web. PHP was built for one task, which gives it a certain coherency that is a major strength, especially for newbs.
You learn to build a web page with embedded PHP on page three of most tutorials. I don't remember the Camel book covering that at all. If it does I didn't notice -- too busy slogging through the regexps and the hash syntax and the insane special characters and the bizarre function-declaration syntax. And I fear that, in Perl, there is no standard way to do it. There are probably 75 standards, which is helpful, but not very helpful.
If I visit any random web forum about PHP I am 97% likely to find a discussion of website development; if I visit a random Perl forum I'm just as likely to find sysadmins debating how to automate database backups, or a linguistics debate, or a game of Perl golf.
You learn to build a web page with embedded PHP on page three of most tutorials. I don't remember the Camel book covering that at all. If it does I didn't notice -- too busy slogging through the regexps and the hash syntax and the insane special characters and the bizarre function-declaration syntax. And I fear that, in Perl, there is no standard way to do it. There are probably 75 standards, which is helpful, but not very helpful.
If I visit any random web forum about PHP I am 97% likely to find a discussion of website development; if I visit a random Perl forum I'm just as likely to find sysadmins debating how to automate database backups, or a linguistics debate, or a game of Perl golf.
Totally. As a total newbie, I picked up a Perl book and got frustrated. Then picked up a PHP/MySQL book and built a few websites.
The biggest thing for me, at the time, was the ease of use of PHP/MySQL. I haven't touched Perl in nearly a decade, perhaps it got better, but even in 2000-2001 PHP made it very easy for a total newbie to build dynamic websites.
The biggest thing for me, at the time, was the ease of use of PHP/MySQL. I haven't touched Perl in nearly a decade, perhaps it got better, but even in 2000-2001 PHP made it very easy for a total newbie to build dynamic websites.
> The Perl community was too unfocused on the web.
That's a fairly ridiculous claim. Perl CGI had all the momentum. It had plenty of forums. I repeat: PHP won because as the internet grew and compile-at-run CGI was no longer sufficiently scalable mod_php was more viable than mod_perl or fastcgi.
That's a fairly ridiculous claim. Perl CGI had all the momentum. It had plenty of forums. I repeat: PHP won because as the internet grew and compile-at-run CGI was no longer sufficiently scalable mod_php was more viable than mod_perl or fastcgi.
I think that's a bit true but I also have to believe that from a syntax perspective PHP has always been easier to use. That and all the libraries are pretty much built into php. you never had to deal with CPAN - it was either built into PHP's core or you lived without it (generally).
Apropos, from http://www.joelonsoftware.com/articles/fog0000000006.html
"What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines. The code looks pretty good, it's object-oriented and robust, but you don't waste time using tools that are at a level lower than you need. I've spent years writing code for C++/MFC and years writing code in Visual Basic, and let me tell you, VB is just much, much more productive. Michael and I had a good laugh today when we discovered somebody selling a beta crash-reporting product at $5000 for three months that Michael implemented in CityDesk in two days. (And we actually implemented a good part of ours in C++/ATL). And I also guarantee you that our Visual Basic code in CityDesk looks a lot better than most of the code you find written in macho languages like C++, because we're good programmers, and we write comments, and our variable names are well-chosen, and we do things the simple way, not the clever way, and so forth."
"What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines. The code looks pretty good, it's object-oriented and robust, but you don't waste time using tools that are at a level lower than you need. I've spent years writing code for C++/MFC and years writing code in Visual Basic, and let me tell you, VB is just much, much more productive. Michael and I had a good laugh today when we discovered somebody selling a beta crash-reporting product at $5000 for three months that Michael implemented in CityDesk in two days. (And we actually implemented a good part of ours in C++/ATL). And I also guarantee you that our Visual Basic code in CityDesk looks a lot better than most of the code you find written in macho languages like C++, because we're good programmers, and we write comments, and our variable names are well-chosen, and we do things the simple way, not the clever way, and so forth."
Solving spaghetti PHP in spaghetti SQL in spaghetti HTML:
1. Learn how MVC works.
2. Write a basic MVC framework.
3. Zip it up, put it aside, and learn Symfony, CodeIgniter, etc.
(Writing your own framework is an incredibly good learning experience.)
Spaghetti code is solved (mostly) by structured organization, ORM, views that simply display data, and the separation of the MVC parts.
1. Learn how MVC works.
2. Write a basic MVC framework.
3. Zip it up, put it aside, and learn Symfony, CodeIgniter, etc.
(Writing your own framework is an incredibly good learning experience.)
Spaghetti code is solved (mostly) by structured organization, ORM, views that simply display data, and the separation of the MVC parts.
As a developer, I am frightened by PHP.
I assume that it is possible to write clean, maintainable, secure code in PHP. But if I sat down and tried to write a web app on my own in PHP, what are the odds that I would do it right--particularly w.r.t. security? If I look for tutorials and reference materials that teach secure PHP programming, how do I know which of these documents are written by people who actually know what they're talking about?
And after taking into account all the effort to learn and use good PHP practices, is PHP really more difficult than one of the Perl, Python, or Ruby frameworks?
I assume that it is possible to write clean, maintainable, secure code in PHP. But if I sat down and tried to write a web app on my own in PHP, what are the odds that I would do it right--particularly w.r.t. security? If I look for tutorials and reference materials that teach secure PHP programming, how do I know which of these documents are written by people who actually know what they're talking about?
And after taking into account all the effort to learn and use good PHP practices, is PHP really more difficult than one of the Perl, Python, or Ruby frameworks?
What makes Ruby, Python and Perl more secure than PHP? Frameworks? PHP has plenty of options there.
PHP is popular because of how easy it was to get started and how available it was in every dirt cheap shared hosting plan on the market. Sure, it's not the most elegant language and it does have plenty of issues but quite a few of these are solved with quality planning and the use of quality tools such as CodeIgnitor or CakePHP.
The low barriers to entry are what made PHP popular and the fact that you can code something robust and maintainable are allowing it to sustain.
PHP is popular because of how easy it was to get started and how available it was in every dirt cheap shared hosting plan on the market. Sure, it's not the most elegant language and it does have plenty of issues but quite a few of these are solved with quality planning and the use of quality tools such as CodeIgnitor or CakePHP.
The low barriers to entry are what made PHP popular and the fact that you can code something robust and maintainable are allowing it to sustain.
What makes Ruby, Python and Perl more secure than PHP?
The fact that those languages don't have "magic_quotes" or "globals_on"?
The fact that those languages don't have "magic_quotes" or "globals_on"?
For more than 3 year I've not seen "magic_quotes" or "globals_on" turned on anywhere. As far as I know in php6 there won't be globals option at all.
Neither have I. If you care one bit about security, that's the first thing you'll find out about PHP and as you said, they are being eliminated from the php.ini file in php6 and will need to explicitely turned on in your scripts.
[deleted]
An excellent statement, as far as it goes.
The question remains, though: for a given application X, to be developed now, what is a better alternative, and why?
The question remains, though: for a given application X, to be developed now, what is a better alternative, and why?
"PHP Sucks"
Anyone can say this (and usually does).
"But It Doesn't Matter"
Thank you. In any language war, this is the most important thing to say.
Anyone can say this (and usually does).
"But It Doesn't Matter"
Thank you. In any language war, this is the most important thing to say.
I don't buy the "it doesn't matter" part. A good language can effect your project's agility by an order of magnitude; and the gap widens exponentially after you've used it long enough to build up some custom libraries/tools.
Well, it doesn't really matter. If my competitors want to use inferior tools, that's fine with me.
Yeah, but when your partners are using inferior tools, you spend a lot of time waiting. OurDoings integrates with 9 other sites, so this means something to me.
Yeah well with OSS your competitors can end up contributing to the "inferior" platforms instead of to your "superior' platform. Apple/Darwin comes to mind
You're absolutely right. Very good point.
What I meant was that you could build almost anything with almost any language.
This != "it doesn't matter".
(I sometimes react this way because we often debate endlessly over language fine points that are really just personal preference.)
What I meant was that you could build almost anything with almost any language.
This != "it doesn't matter".
(I sometimes react this way because we often debate endlessly over language fine points that are really just personal preference.)
But of course it does matter. The "it doesn't matter" was specific to PHP because PHP has a good record of success.
This post to be honest is from someone who does not obviously use PHP on a day to day basis.
Why PHP? In the end the quote below summarizes its success,
-- begin quote -- In many ways, the IETF runs on the beliefs of its participants. One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". -- end quote --
From the "Tao of IETF" http://www.ietf.org/tao.html
Why PHP? In the end the quote below summarizes its success,
-- begin quote -- In many ways, the IETF runs on the beliefs of its participants. One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". -- end quote --
From the "Tao of IETF" http://www.ietf.org/tao.html
To me, it seems PHP is the Windows of web languages. In many respects it "sucks", can be clunky, and has little to no elegance from a formal perspective, but it's everywhere and everyone knows how to use it. Thence lies its success.
(however, if you're willing to give up lambda's, some of the PHP frameworks like Cake are only mildly unpleasant)
P.S. Also, the author is inaccurate, as many of those functions are only included in certain modules and rarely found in common PHP builds.
(however, if you're willing to give up lambda's, some of the PHP frameworks like Cake are only mildly unpleasant)
P.S. Also, the author is inaccurate, as many of those functions are only included in certain modules and rarely found in common PHP builds.
The python code in the book Programming Collective Intelligence is aesthetically poor, with unclear naming, bad spacing, errors and some ugly duplication. But it doesn't matter. The algorithms work, the concepts get taught, and you still get to build your own little pageranking search engine in a single chapter.
Same deal with PHP. It seems that PHP gets the job done. (I say this never having coded anything significant in PHP.)
Same deal with PHP. It seems that PHP gets the job done. (I say this never having coded anything significant in PHP.)
In the early days, I can still remember my perl scripts failing with the "Premature end of script header" error. If they would have patched perl to ignore the newline encoding, nobody would have used php. I can imaging lots of newbiews turned down perl because of this error.
Php really is a mess. 20 functions for sorting, settings in php.in (each php installation should react the same way as the other does), etc...
Php really is a mess. 20 functions for sorting, settings in php.in (each php installation should react the same way as the other does), etc...
Nothing to see here. Religious opinion. Move along.
I'm not keen on PHP, but in its defense it is much less headache inducing than perl or as tedious as the Java/.NET world
One thing many people seem to forget when discussing PHP is that if PHP vast library of built in functions doesn't do what you need, you don't have to live without, you can just write an extension, recompile, and you're in business. PHP allows you to write important logic in C, giving me yet another reason use it.
I once read "PHP takes 'Worse is better' to a new level." That about sums it up for me.
But It Doesn't Matter
It matters to me.
It matters to me.
the main issue is in developer, not in language.
This is the same philosophy that blames users for mistakes they make with bad user interfaces.
it's not the same... I've seen ugly code in python and cpp and really great code in php using smarty and cakephp.
What does not allow you to write good code in php5, using unit testing and MVC framework?
What does not allow you to write good code in php5, using unit testing and MVC framework?
Some pilots have crashed planes with good instrumentation. Some pilots have successfully flown planes with poor instrumentation. Nonetheless, instrumentation design is a very important issue to talk about.
Similarly, programmer skill may make a larger difference, but language design is a very important issue to talk about.
Similarly, programmer skill may make a larger difference, but language design is a very important issue to talk about.
Actually php5 gives almost everything that was missing. The only thing is that a lot of pilots used to work with poor instrumentation and don’t want to switch!
If php sucks then why there are so many successful products/services written on it?
If windows sucks, why are there so many successful...?
If Chinese writing is so hard to learn, then why are there so many...?
If religious explanations for the origin of everything sucks, why do so many...?
If Chinese writing is so hard to learn, then why are there so many...?
If religious explanations for the origin of everything sucks, why do so many...?
Do you believe this questions share the same answer?
Nope. I'm just demonstrating how easy it is to come up with questions that have this structure, but which do not necessarily have the answer, "Because, really, it's actually awesome!"
The funny thing is that I do believe that Chinese writing and Zen are awesome :)
Not by the "orthogonal and easy to learn" metric.
[deleted]
[deleted]
[deleted]
Java --all frameworks sucked at the time (I had to work on struts, it was painful).
.net --tied to MS world, and the first iterations sucked
php --it was quick and dirty and easy to get started
cgi,perl, python, C++ --required higher level of expertise, and they were hard
php, was the sensible choice for something quick, and the more "primitive" state of the web apps at the time, demanded less from the framework/language being used.
Right now there is much more choices, and Python (Django), and Ruby on Rails can be really quick to get started on, therefore php is loosing it's main advantage, yet Django and Ror are much more sophisticated and maintainable on the long run.
Even Java now has some nimbler frameworks (Wicket, Stripes etc.)
So, right now PHP is a very bad choice to do anything significant, as it lost its advantages over time, yet it is a mess to work with.
But, the main reason we still PHP used so much, is that a lot of sites were build before 2005, and a lot of web devs are used to it, so as a language it will keep its momentum, but at some point it will run out of steam.
It seems that even the newbies now prefer Ror over PHP.