I'd be willing to bet the Digg engineers were bored by this talk. Most of this isn't new and is already PHP best practice (minus the HipHop stuff, I suppose).
I saw him give the talk at the Confoo conference (formerly PHP Quebec that got renamed when Ruby + Python tracks were added) and I was bored as well.
You can pretty much boil his talk down to use a profiler and make sure you run as little lines of code as possible. (AKA: Extra indirection always adds extra cost which is why generic web dev frameworks are always slow)
The HipHop part of his talk isn't really useful because extremely few sites are resource constrained enough at the web server level for it to make sense to complicate your deployments that massively.
He made a good point about using HipHop for static analysis though. The weird code he found in WordPress via HipHop was a bit disconcerting considering how many copies of it are running.
The performance stuff was pretty boring. 30 minutes of talking to go from 9 to 34 reqs/s. My VPS provider can increase my resources by an order of magnitude in 1 minute.
You don't need to analyze WordPress via HipHop to determine that it is truly dangerous total crap written by morons, and given that, it's been apparent for a long time that it is disturbing how many copies of it are running.
If you take a look at any community of designers who consider themselves 'developers', its scary - most of them build on WordPress as a platform. Clearly this is somewhat like putting up a tent on the Deepwater Horizon drilling platform. I can't believe how terrible the innards of wordpress are. That said, the outtards work pretty well, somehow.
I really like his rant that starts at the ~62 minute mark and ends with this:
"PHP is just a damn tool.
It's just a hammer; it's boring.
It's not that interesting. I'm not that interested in it.
But I need a working tool to solve problems.
I'm really, really interested in problems.
The tool itself; if it works great. If it's broken I fix it.
But I don't spend my entire life fixing it.
PHP is damn ugly.
It'll always be ugly because we're not going to spend the time to sit
and make it pretty.
We're spending our time building actual solutions and fixing problems.
And the tool works. You can build really, really fast things with PHP.
And yes, it's not pretty. If you're a CS major or if all sort of for
the purity of coding; PHP is not for you. But then you're not probably
not interested in building things for end users."
I'm not much a fan of that sentiment. It's the same sentiment espoused by people who don't have time to design software properly, or test it, or do exception handling. The tool is an important part of solving problems, but having an elegant tool helps keep the tool itself from becoming a problem. There seems to be subtext in that rant which says "prettier languages are inferior because they're written by academic snobs who don't have any experience actually writing real software", which is just patently false.
Also, people who usually have that sentiment are not the same people who have to maintain the code. They're usually long gone by then. I have personally suffered many sleepless nights having to maintain projects like that.
I think it's healthy to avoid extremes. Neither a "whatever works" nor a "write everything in lisp because it's beautiful" sentiment. It's up to the good programmer to decide when to be a pragmatist and when to be a purist.
I hear you, but the way he expresses what he does has the net effect of making excuses for PHP and saying "Hey, it's okay that it's an entirely inconsistent language without fundamental features of other real languages because it's just a tool to solve a problem I had at one point, and I hack in new features as the problem-of-the-minute requires them". That's not a well-designed tool. That's a hammer glued to a screwdriver duct taped to a torque wrench welded onto a lawnmower. You can probably properly tension a timing belt with such a monster, but just because you can doesn't mean that it's the right (or most productive) tool.
I'm very productive in PHP; that doesn't change the fact that I discovered I could be more productive in other languages that didn't actively frustrate my development progress due to being well-designed.
I may not care, but I end up knowing every time I see one of those PHP/MySQL error traces in a website. Apparently one of their problems isn't proper exception handling.
No, it does, however, ensure that my errors don't randomly get dumped on the page, and that instead an exception is raised and a proper 500 page can be returned.
The end user doesn't directly care, but if you solve their problem in a hacky unmaintainable way, they'll care when it takes you days to do what should take hours, weeks to do what should take days.
No. I didn't say that. The language you write in doesn't matter nearly as much as your attitude about writing the software. If you don't design for maintainability and readability, then modifying the code later will take much longer.
This would only be valid if there weren't any other languages/platforms that can build fast solutions and also be appreciated by CS majors for not being a huge ugly mess of a language. Unfortunately for PHP, there are.
Well, PHP is obviously doing something right, or everyone else is doing something wrong since PHP still sits near the top of the heap in usage. I noticed this the other day:
PHP still has a lot of momentum behind it, but I think that momentum will fade (or PHP will dramatically change). You still frequently see "PHP" as a three letter acronym on job postings, even if the employer doesn't use PHP. "PHP" in those cases basically just means "we want someone who develops software for the web." Or it might mean "we still have some old nasty PHP code that you may have to peek into from time to time."
As for growth rate, I question any study on "programming language usage" because it's very hard to define what that even means. Still, I'm not surprised by their findings. We've all seen the explosion of Python—both with hobbyists and huge corporations. As for PHP still increasing, that could be attributed simply to the persistent increase in web usage in general. It doesn't necessarily mean PHP is "beating" Ruby.
Unfortunately, PHP is also fundamentally broken in a number of ways. Ways that you're likely not to find out until after it has pissed in your cornflakes.
He doesn't seem that interested in fixing those problems, either.
For well over a year I've been looking for that 'better hammer', but to tell you the truth I haven't found one yet.
I've built some non-trivial application in a number of environments just to see what the grass is like on the other side of the street. Each and every solution I tried has its own warts and requires you to work around a new set of issues.
PHP is a 'bad' programming language, it smells of band-aids all over. But for all the elegance and brevity of some of the other contenders there isn't a single one that is better on all fronts. So far. Still looking, still trying new stuff. If I find something that makes me really happy I'll feel so much better because the P*/Javascript/CSS/HTML/SQL hodge-podge that we call web applications feels like the absolute wrong way to develop software to me.
Rasmus has been repeating this line to everyone for years now: I actually feel pretty bad for him. He gets quite a bit of flak for the language, when it actually does exactly what it's meant to.
Everyone just likes to hate on it because it's not "proper" enough for the academics and doesn't make enough assumptions (ala RoR) for many of the practicalists (I know I'm making up a word).
No, this is not right. The problem with PHP is that you can't use PHP to fix PHP. If you encounter a problem, there is no way to write a library to fix it.
Perl, on the other hand, was designed with "academic" abstraction mechanisms that can be hooked to change the language. For years, this was a problem -- Perl 5's object system was more like an object system object system. Everyone built their own object system for every application, and then used that. This made a mess, and annoyed everyone, because everyone was doing OO in their own slightly-wrong way. Yuck.
Then someone decided, "hey, let's use this object system object system to write a real object system!", and Moose was born. Now most new Perl 5 apps all use the same object system, and everything works much better. OO modules compose. Objects can be shared. It's possible to write object databases that actually work. (Just look at the MooseX:: namespace on search.cpan. All of these modules fundamentally change how "object oriented programming" works for a particular class or group of classes, but they all compose together cleanly and don't have effect outside of a limited scope. Beautiful! And it makes writing reusable code easy!)
No changes to Perl were ever needed for this, and yet the object system is probably the most flexible and feature-rich of any major programming language.
If PHP had the ability to be changed by PHP programmers, then the massive community would have cleanly fixed all the problems already. The Perl community did it. The Ruby community did it. Even the Java community sort of did it. But since the attitude is that PHP is just a hack on a hack, and web apps should just be hacks, PHP remains a hack on a hack that's too difficult to use for complex projects.
If PHP had the ability to be changed by PHP programmers, then the massive community would have cleanly fixed all the problems already.
PHP's greatest strength is also its greatest weakness: it's very easy to pick up and start running code. Have you read the huge number of broken tutorials that tell newbie users how cool, for example, variable variables are? Can you imagine the new levels of abuse such a system would introduce? ;)
Can you imagine the new levels of abuse such a system would introduce?
Actually yes, it's called Rails.
But anyway, a system that can't be broken is also one that can't be fixed. PHP programmers switching to Rails did some weird stuff, but without that ability to do weird stuff, Rails wouldn't have even been possible.
"If you're a CS major or if all sort of for the purity of coding; PHP is not for you. But then you're not probably not interested in building things for end users."
So if I'm not willing to use a tool that will create a mess that is expensive to maintain then I probably don't care about end users? Fallacy detected.
No, I'm not assuming, I've experienced it first hand. The language is ridiculous. I'm not going to rehash the tons of reasons the language is not technically sound, if you wish to believe it's a suitable language then go ahead. When a better designed language actually focuses on this space the different in maintainability will become measurably clear.
PHP might create a mess that is expenesive to maintain for _you_. It might even create a mess for a lot of people, especially newbies. Likewise with Perl.
That doesn't mean that creating maintainable PHP software can't be done - it's actually been done many times. While I agree that languages can make a big difference in maintainability, please stop blaming a programming language for your own mistakes.
This statement is absolute nonsense. Why should a programmer hate himself so?
I want to have beautiful and powerful tools. The code you write using an elegant language might as well be ugly. This shouldn't stop you from enjoying the process and demanding the best tools to do an already difficult job.
He admits that PHP ain't pretty, but argues that it does the job and that's good enough. Yes, yes it is good enough. However, he also claims that its the way it should be if you are "interested in building software for the end user." No, it really shouldn't, and thankfully we have practical languages and successful projects that prove it.
Regarding his anecdote of the company porting a client's application from PHP to Rails: Maybe the fact that completely rewriting an application in Rails is preferable to maintaining their PHP application is telling.
I think it's fair to call HipHop a native compiler, since it can generate native executables. phc generates C code, which is admittedly lower-lever, but it's roughly the same idea.
I'm interested in how you'd like phc to be more evolved. I've had lots of ideas (I'm the author) but I'm curious what others would like. Thanks!
"I never taken any classes in computer science. I should have taken classes in computer science".
So it was never designed to be a state of the art language. Just a tool to get things done. From 1997 to 2001 I really enjoyed solving problems in PHP. But things have changed. I have learned more and now certainly prefer using Ruby.
From a security perspective, kind of... it's not like for a decade or so every other security hole was a buffer overrun (or underrun, as the case may be) or others of that ilk. That's not to say they don't serve a purpose, but it's pretty easy to see that higher level languages have eliminated an entire class of security concerns in our code (at obvious costs).
i suppose thats my point. languages are just tools. some languages are hammers, where you can accidentally hit your thumb. some languages are like an automatic electric hammer where its all safe, but its heavy and you have to keep it plugged into the wall.
Rasmus is a former colleague at Linuxcare, and as far as I'm concerned, is a really cool guy, and very worth talking with. His story is pretty interesting, too. That said, I've encountered too much ugly PHP code to really want much to do with the language these days.
Felt like I was watching an old school cracktro with the rainbow effect going on there (a DLP projector issue?).
Most of Rasmus's talk is the same as it was for years in regards to optimization. If you've seen one of his older presentations take a look at the slides directly (http://talks.php.net/show/digg/1) rather than watching the video.
61 comments
[ 14.0 ms ] story [ 268 ms ] threadYou can pretty much boil his talk down to use a profiler and make sure you run as little lines of code as possible. (AKA: Extra indirection always adds extra cost which is why generic web dev frameworks are always slow)
The HipHop part of his talk isn't really useful because extremely few sites are resource constrained enough at the web server level for it to make sense to complicate your deployments that massively.
The performance stuff was pretty boring. 30 minutes of talking to go from 9 to 34 reqs/s. My VPS provider can increase my resources by an order of magnitude in 1 minute.
If you take a look at any community of designers who consider themselves 'developers', its scary - most of them build on WordPress as a platform. Clearly this is somewhat like putting up a tent on the Deepwater Horizon drilling platform. I can't believe how terrible the innards of wordpress are. That said, the outtards work pretty well, somehow.
"PHP is just a damn tool. It's just a hammer; it's boring. It's not that interesting. I'm not that interested in it. But I need a working tool to solve problems. I'm really, really interested in problems. The tool itself; if it works great. If it's broken I fix it. But I don't spend my entire life fixing it. PHP is damn ugly. It'll always be ugly because we're not going to spend the time to sit and make it pretty. We're spending our time building actual solutions and fixing problems. And the tool works. You can build really, really fast things with PHP. And yes, it's not pretty. If you're a CS major or if all sort of for the purity of coding; PHP is not for you. But then you're not probably not interested in building things for end users."
Also, people who usually have that sentiment are not the same people who have to maintain the code. They're usually long gone by then. I have personally suffered many sleepless nights having to maintain projects like that.
I think it's healthy to avoid extremes. Neither a "whatever works" nor a "write everything in lisp because it's beautiful" sentiment. It's up to the good programmer to decide when to be a pragmatist and when to be a purist.
I'm very productive in PHP; that doesn't change the fact that I discovered I could be more productive in other languages that didn't actively frustrate my development progress due to being well-designed.
Programma hatas gon hate.
http://www.activestate.com/blog/2010/07/growth-dynamic-langu...
which shows PHP is used more than any other dynamic language and it is growing faster than Ruby, but not as fast as Python and Javascript.
As for growth rate, I question any study on "programming language usage" because it's very hard to define what that even means. Still, I'm not surprised by their findings. We've all seen the explosion of Python—both with hobbyists and huge corporations. As for PHP still increasing, that could be attributed simply to the persistent increase in web usage in general. It doesn't necessarily mean PHP is "beating" Ruby.
1) it is easy to get startet
2) it is supported by just about every single host ever
He doesn't seem that interested in fixing those problems, either.
I've built some non-trivial application in a number of environments just to see what the grass is like on the other side of the street. Each and every solution I tried has its own warts and requires you to work around a new set of issues.
PHP is a 'bad' programming language, it smells of band-aids all over. But for all the elegance and brevity of some of the other contenders there isn't a single one that is better on all fronts. So far. Still looking, still trying new stuff. If I find something that makes me really happy I'll feel so much better because the P*/Javascript/CSS/HTML/SQL hodge-podge that we call web applications feels like the absolute wrong way to develop software to me.
We're doing something terribly wrong.
The only downside is that it requires Jetty (or Tomcat) to be deployed, which means you can't use it on a shared host.
Everyone just likes to hate on it because it's not "proper" enough for the academics and doesn't make enough assumptions (ala RoR) for many of the practicalists (I know I'm making up a word).
Perl, on the other hand, was designed with "academic" abstraction mechanisms that can be hooked to change the language. For years, this was a problem -- Perl 5's object system was more like an object system object system. Everyone built their own object system for every application, and then used that. This made a mess, and annoyed everyone, because everyone was doing OO in their own slightly-wrong way. Yuck.
Then someone decided, "hey, let's use this object system object system to write a real object system!", and Moose was born. Now most new Perl 5 apps all use the same object system, and everything works much better. OO modules compose. Objects can be shared. It's possible to write object databases that actually work. (Just look at the MooseX:: namespace on search.cpan. All of these modules fundamentally change how "object oriented programming" works for a particular class or group of classes, but they all compose together cleanly and don't have effect outside of a limited scope. Beautiful! And it makes writing reusable code easy!)
No changes to Perl were ever needed for this, and yet the object system is probably the most flexible and feature-rich of any major programming language.
If PHP had the ability to be changed by PHP programmers, then the massive community would have cleanly fixed all the problems already. The Perl community did it. The Ruby community did it. Even the Java community sort of did it. But since the attitude is that PHP is just a hack on a hack, and web apps should just be hacks, PHP remains a hack on a hack that's too difficult to use for complex projects.
PHP's greatest strength is also its greatest weakness: it's very easy to pick up and start running code. Have you read the huge number of broken tutorials that tell newbie users how cool, for example, variable variables are? Can you imagine the new levels of abuse such a system would introduce? ;)
Actually yes, it's called Rails.
But anyway, a system that can't be broken is also one that can't be fixed. PHP programmers switching to Rails did some weird stuff, but without that ability to do weird stuff, Rails wouldn't have even been possible.
So if I'm not willing to use a tool that will create a mess that is expensive to maintain then I probably don't care about end users? Fallacy detected.
That doesn't mean that creating maintainable PHP software can't be done - it's actually been done many times. While I agree that languages can make a big difference in maintainability, please stop blaming a programming language for your own mistakes.
I want to have beautiful and powerful tools. The code you write using an elegant language might as well be ugly. This shouldn't stop you from enjoying the process and demanding the best tools to do an already difficult job.
He admits that PHP ain't pretty, but argues that it does the job and that's good enough. Yes, yes it is good enough. However, he also claims that its the way it should be if you are "interested in building software for the end user." No, it really shouldn't, and thankfully we have practical languages and successful projects that prove it.
Rasmus is eminently practical. Mucho respect to the man.
If I am not mistaken there are a couple of projects already working on that.
Also, it's supposedly REALLY difficult to build.
I was thinking more like PHC but more evolved.
I'm interested in how you'd like phc to be more evolved. I've had lots of ideas (I'm the author) but I'm curious what others would like. Thanks!
"I never taken any classes in computer science. I should have taken classes in computer science".
So it was never designed to be a state of the art language. Just a tool to get things done. From 1997 to 2001 I really enjoyed solving problems in PHP. But things have changed. I have learned more and now certainly prefer using Ruby.
PHP lacks any kind of design, it was just an rapidly evolved toolchan. ^_^
i suppose thats my point. languages are just tools. some languages are hammers, where you can accidentally hit your thumb. some languages are like an automatic electric hammer where its all safe, but its heavy and you have to keep it plugged into the wall.
Most of Rasmus's talk is the same as it was for years in regards to optimization. If you've seen one of his older presentations take a look at the slides directly (http://talks.php.net/show/digg/1) rather than watching the video.