PHP Sucks, But It Doesn't Matter
codinghorror.com
codinghorror.com
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.
I wrote BRL, the sensible choice for something quick, based on Scheme, well before 2005.
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.
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.
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
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.
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.
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 :)
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.
...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 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.
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.
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.
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.
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.
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.
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).
"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."
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.
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?
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.
The fact that those languages don't have "magic_quotes" or "globals_on"?
The question remains, though: for a given application X, to be developed now, what is a better alternative, and why?
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.
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.)
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
(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.
Same deal with PHP. It seems that PHP gets the job done. (I say this never having coded anything significant in PHP.)
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...
It matters to me.
What does not allow you to write good code in php5, using unit testing and MVC framework?
Similarly, programmer skill may make a larger difference, but language design is a very important issue to talk about.
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...?