Rasmus should win a Turing award for bringing an easy to use web-centric server language to regular people. He does not get nearly the attention he deserves.
Why? Php wasn't some new, amazing idea. There was perl at the time as well. Php took off mostly because of mod_php, but there was already cgi. There was also asp from Microsoft that had almost all the same properties as php e.g. inline code and markup, upload and refresh), but Windows only. Php was just a little simpler to configure on a Linux webserver than cgi, but at the expenses of using php -- we've been paying for the decision for what, 20years now.
As someone who works in php daiy, I despise the language. It's getting much better than php4, but it still is lacking.
Anything but a Turing award. Turing was a computer scientist who cared.
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf
I also don't think PHP deserves a Turing award, but the remark about abstract methods and protected properties is completely irrelevant - you can have an amazing language without these and crappy ones with them.
The point of the quote is not about abstract methods and properties, it's about not giving a shit, and being proud of it.
If you really didn't already know about Rasmus Lerdorf's anti-intellectual attitude (who admits to being "really, really bad" and a "terrible coder", but still thinks he's "better than you"), then here are some more quotes:
There are people who actually like programming. I don't understand why they like programming.
I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
I do care about memory leaks but I still don't find programming enjoyable.
I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.
I was really, really bad at writing parsers. I still am really bad at writing parsers.
I really don't like programming. I built this tool to program less so that I could just reuse code.
I actually hate programming, but I love solving problems.
For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :)
I think what's getting me is a really superficial notion of what 'solving problems' means.
It's a leaking ceiling, a bucket under the leak ostensibly 'fixes' your original problem of water spilling out onto the floor, but now you've got the problem that at some point, the bucket will fill up.
It's rare for most problems you face in the workplace for the difficult part to be actually solving the problem. It's solving it in a way that doesn't just create three other messes elsewhere, in a way that somebody else can come along and understand how the problem was solved and in a way that doesn't hamstring you in the future.
Some of these quotes are really baffling. I mean, he must be being facetious or something.
I think it's called self-deprecating humour. I don't know too much about this guy, but these quotes endear him to somebody like me who is learning as much JavaScript as I need to do the things I want to do, but didn't necessarily come from a CS background. He seems like he's questioning what is pragmatic by using a bit of hyperbole.
I think those quotes are not to be interpreted literally. It's very likely that there's some humor in them that's being lost in this context. What does he even mean by bad or good? Does he really hate programming or maybe he hates academic programming?
Additionally, the project has really moved on. Admittedly, there are people who still code in php 5.5 and don't use a framework, or roll their own, but their experience does not reflect on how pleasant php can be. Coding in php without using the ecosystem is like walking across town instead of driving.
You sound like you're trying to justify a Trump tweet. But there's a long well documented history and consistent pattern you're ignoring.
Do you consider PHP 5.3.7 "moving on"?
> 5.3.7 upgrade warning:
[22-Aug-2011]
Due to unfortunate issues with 5.3.7 (see bug#55439) users should postpone upgrading until 5.3.8 is released (expected in a few days).
No seriously, he's literally as careless as he claims to be, and his lack of giving a shit about things that are extremely important has caused actual serious security problems, like breaking crypt() by checking in sloppy buggy code that would have caused a unit test to fail, but without bothering to run the unit tests (because so many of them failed anyway, so who cares??), and then MAKING A RELEASE of PHP 5.3.7 with, OF ALL THINGS, a broken untested crypt()!
Do you think that's just his sense of humor, a self deprecating joke, breaking then releasing crypt() without testing, that's funny in some context? What context would that be? Do you just laugh and shrug it off with "Let Rasmus be Rasmus!"
>You can see the code coverage, test case failures, Valgrind reports and more for each branch.
>The crypt change did trigger a test to fail, we just went a bit too fast with the release and didn't notice the failure. This is mostly because we have too many test failures which is primarily caused by us adding tests for bug reports before actually fixing the bug. I still like the practice of adding test cases for bugs and then working towards making the tests pass, however for some of these non-critical bugs that are taking a while to change we should probably switch them to XFAIL (expected fail) so they don't clutter up the test failure output and thus making it harder to spot new failures like this crypt one.
Thomas Midgley (born 18 May 1889; died 2 November 1944), was an American inventor. His two most famous inventions are both now banned because they are dangerous for the world environment: the use of lead in petrol (gasoline) and the use of chlorofluorocarbons (CFCs) in refrigerators. Midgley was accidentally killed by something he was inventing.
Midgley's legacy has been scarred by the negative environmental impact of some of his innovations. His work led to the release of large quantities of lead into the atmosphere as a result of the large-scale combustion of leaded gasoline all over the world. High atmospheric lead levels have been linked with serious long-term health problems from childhood, including neurological impairment, and with increased levels of violence and criminality in cities.
Thomas Midgley Jr. died three decades before the ozone-depleting and greenhouse gas effects of CFCs in the atmosphere became widely known. Bill Bryson remarked that Midgley possessed "an instinct for the regrettable that was almost uncanny." J. R. McNeill, an environmental historian, opined that Midgley "had more impact on the atmosphere than any other single organism in Earth's history."
Indeed. I realize the guy I answered to was probably just trolling, but it was very effective. To suggest that Rasmus should get academic praise for PHP is highly insulting.
Countering the first with the third isn't very constructive, particularly as you note "I realize the guy I answered to was probably just trolling." It just further degrades the conversation.
Mark Karpelès's crappy PHP code full of gaping security holes lost many people a hell of a lot of money ($450 million), and earned him a year in prison.
That's a leap.. The year in prison was related to embezzling charges, not the collapse of Mt. Gox due to his "crappy PHP code full of gaping security holes".
I don't agree. PHP was a quick shot to grab market share from Perl and other web development languages used at the time. While Rasmus may have developed it in good faith to bring easy web site programming to the masses, PHP is the single piece of software standing out for countless DDoS attacks making life difficult for web site owners of PHP and non-PHP web sites alike, and driving folks to centralized services such as CloudFlare.
PHP's original use case is dynamic HTML generation from HTML/SGML processing instructions embedded in otherwise static HTML. That's useful, but PHP's lack of HTML-aware template expansion and escaping mechanisms was and is bordering on the criminal IMHO.
One of the key reasons why PHP remains so widespread in use is the ease of deployment. No other language can match it.
PHP is the only language with almost universal support among web hosts. It can run on basic shared hosting plans and on nearly every server. It can be deployed by simply uploading your code to a directory on your web host. Sure, it's a widely criticised language (even within the PHP community), but it still accounts for the vast majority of server side code (80% according to some sources).
What's baffling is why other languages and so many developers are blind to this problem of easy server install. They think it's a non-issue.
Prolific blogger and programmer, Jeff Attwood ranted about how he disliked PHP in one of his blog posts, but recognised that:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option."
To broaden choice, Attwood argues we should:
"build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible."
Having a ridiculously easy web app installation process for servers would unlock countless opportunities for developers to reach more users or customers. And it has, for many PHP open source projects and products.
Want your customers to self-install your software? Good luck getting them to do that easily with any language other than PHP.
It's a good barrier to entry. If in 2017 you can't figure out how to setup an ec2 instance and run a simple webserver in any language, then you don't need to be setting up software. It's not hard.
Not even that, but with services like heroku and app engine, upload-and-refresh style development isn't php or old asp or cgi on a shared host anymore.
But people do need to setup software and run their business. If your favourite language can't abstract away those setup details your language will be skipped by the masses who want to get things done and won't want to invest the time in the setup details.
It was easy to get setup and start programming in the 80s. That allowed you to spend time/energy on the complex logic you needed to write the program. Most programming is so much easier the level of math required is so much smaller and most websites are simple crud. Why are we making the setup process more difficult? Do we really need a gate keeper?
Not quite. Passenger makes Rails deployment easier, sure, but it's the fundamental nature of PHP not requiring an app server and just loading everything per request that's the real trick - I know FPM changes that, btw.
That's a fair point. "Why didn't it change? I updated the code." That's definitely a barrier when there's no distinction between development and production.
No it won't, unless you're doing something stupid in your app, such as using synchronous or CPU-heavy code. But putting nginx in front of it doesn't save you here either; you'd need a caching reverse proxy instead.
The only thing where nginx might help performance-wise here is static file access (of eg. static web assets such as CSS or static HTML).
The language developers were never really in a position to fix this problem.
After all, in 2002 (the date of that Q&A), you could already deploy Perl or Python scripts by "simply uploading code to a directory", if mod_perl or mod_python was installed by the hosting provider.
i agree the ease od deployment was key and it still is to large degree but it along brought a huge problem with it, security.
you have to realize php is also incredibly insecure as well. chmod 777 on install instructions? on a shared webhost server? this really was and maybe still is the "thing".
the nature of being able to upload a php file to server on the public docroot makes the language always prone to hacks. sure there have been improvements with things like mod_suexec and fpms but this now makes things that usedto be easy now hard, ie htaccess and rewrite rules.
How is a PHP "program" easier to distribute and run than one written in Go, Rust, or Haskell? For any of those three, you have a self-contained executable that you run. One scp to your server, one service restart, and you're running your new server. How could any distribution and deployment process be easier than that?
This in turn also helped software like WordPress and phpBB become significantly more popular than their alternatives. They may not have been better coded, nor more secure or feature rich, but setup was a complete walk in the park. At most, you needed to set up a database through CPanel or whatever you used, then upload some files and run an installer. At least, you just clicked a few buttons in the control panel to install the system there and then.
Meanwhile, recent attempts at fancier competitors (like Ghost and Discourse) have completely failed to capture the marketshare of their PHP based counterparts because they're just more difficult to set up for the non technical individual or company. Their creators put image (aka a more 'glamorous') tech stack above ease of use, and paid the price.
PHP's ease of deployment is basically why so many of the larger CMS systems of today got popular at all.
It runs everywhere because it's really old and popular. So you could just call it momentum. I for one would never choose technology based on momentum alone.
And you might get PHP running in almost all servers, but that says nothing about all your dependencies such as mail servers, message queues and the like. So the fact that it runs everywhere doesn't actually mean that much.
There's an analogy that describes PHP as a weird sort of toolbox. Everything's there, but they are all a little funky.
The hammer is a double sided claw hammer, the pliers don't have serrated edges. They will do a job, but perhaps not the job that you expected.
Eventually it leads to everyone using this weird little toolbox ends up with a weird sort of house that might collapse at any moment.
Things have moved on quite a bit since then. Certainly in PHP 7, you're able to give it the same treatment as a "proper" programming language and people do.
My view is though, it's a little too late. I don't think new people are coming into PHP because the barrier to entry has become higher than other languages.
It has become almost impossible to write a PHP application to do even the simplest task without getting bogged down in all sorts of over engineering and so called "design patterns".
We all know PHP will be around for a while longer.
Yet in 2017, I wouldn't recommend learning about PHP. Go learn something else.
> It has become almost impossible to write a PHP application to do even the simplest task without getting bogged down in all sorts of over engineering and so called "design patterns".
That's rubbish. There's nothing that stops you creating a single script to return a value based on stdin or get parameters.
Design pattern nerds exist in every language. PHP has them no better or worse.
Not parent but I have done this before. There was an old PHP code that utilise TCPDF to generate a very complex report. The main application is being rewritten (in JS), but the report is very complex and utilise many features of TCPDF that I cannot find in PDFKit or other nodejs pdf libraries. In the end, the PHP code that generate reports was wrapped to take JSON input from STDIN and output the resulting pdf to STDOUT.
I seriously doubt you actually use php and the ecosystem if you feel that way. As long as you pick a reasonable framework and leverage composer, php is fine. Yes, the standard library has some weird functions in it. Don't use them. If that's what upsets you about a language then you clearly have no idea what working with a competent team is like.
Don’t judge PHP by a 15-year-old interview with its creator. The internals have been completely rewritten by an incredibly talented team that continues to make improvements.
PHP is a delight to work with, but that does not suit the signalling and over engineering crowd. We must recognize there is a social phenomenon evolving where some people seem to like complexity.
That's why these developers are blind to ruby setup and dependency hell or nodejs insanity but magnify any self-perceived flaw in PHP without seeing the dissonance. This is a difficult act to pull off. This is so over the top and one sided it ceases to be useful.
Pandering to these criticisms will not work as they are not sincere and these developers are too caught up in how they are perceived to ever use PHP. Those who care for PHP should be concerned about attempts to pander to perceptions as this will destroy the accessibility and simplicity that makes PHP useful for everyone.
>I got tired of rewriting the same code over and over again, and also wanted to separate my business logic from my HTML layout.
> So I wrote a very simple tag parser that would parse through an HTML file looking for special markup tags and replace those special tags with the result of my business logic code written in C.
(emphasis my own)
I really like PHP, but I find it very interesting that Lerdorf doesn't consider PHP code itself as business logic, but more of a templating language for the web.
A lot of PHP's fundamental strengths and weaknesses make sense in that light.
It's interesting to see how much the concept of 'backend' and 'frontend' changed over these years:
> I personally use a combination of PHP and Perl for many of my projects: Perl mostly for back-end tasks, while I have PHP doing all the front-end work.
63 comments
[ 6.4 ms ] story [ 123 ms ] threadAs someone who works in php daiy, I despise the language. It's getting much better than php4, but it still is lacking.
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all." -Rasmus Lerdorf
https://en.wikipedia.org/wiki/Turing_machine
https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis
And php has both protected properties and abstract methods now
If you really didn't already know about Rasmus Lerdorf's anti-intellectual attitude (who admits to being "really, really bad" and a "terrible coder", but still thinks he's "better than you"), then here are some more quotes:
There are people who actually like programming. I don't understand why they like programming.
I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
I do care about memory leaks but I still don't find programming enjoyable.
I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.
I was really, really bad at writing parsers. I still am really bad at writing parsers.
I really don't like programming. I built this tool to program less so that I could just reuse code.
I actually hate programming, but I love solving problems.
For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :)
https://en.wikiquote.org/wiki/Rasmus_Lerdorf
It's a leaking ceiling, a bucket under the leak ostensibly 'fixes' your original problem of water spilling out onto the floor, but now you've got the problem that at some point, the bucket will fill up.
It's rare for most problems you face in the workplace for the difficult part to be actually solving the problem. It's solving it in a way that doesn't just create three other messes elsewhere, in a way that somebody else can come along and understand how the problem was solved and in a way that doesn't hamstring you in the future.
Some of these quotes are really baffling. I mean, he must be being facetious or something.
Jamie is facetious. Rasmus is just incompetent.
Additionally, the project has really moved on. Admittedly, there are people who still code in php 5.5 and don't use a framework, or roll their own, but their experience does not reflect on how pleasant php can be. Coding in php without using the ecosystem is like walking across town instead of driving.
Do you consider PHP 5.3.7 "moving on"?
> 5.3.7 upgrade warning: [22-Aug-2011] Due to unfortunate issues with 5.3.7 (see bug#55439) users should postpone upgrading until 5.3.8 is released (expected in a few days).
No seriously, he's literally as careless as he claims to be, and his lack of giving a shit about things that are extremely important has caused actual serious security problems, like breaking crypt() by checking in sloppy buggy code that would have caused a unit test to fail, but without bothering to run the unit tests (because so many of them failed anyway, so who cares??), and then MAKING A RELEASE of PHP 5.3.7 with, OF ALL THINGS, a broken untested crypt()!
http://i.imgur.com/cAvSr.jpg
Do you think that's just his sense of humor, a self deprecating joke, breaking then releasing crypt() without testing, that's funny in some context? What context would that be? Do you just laugh and shrug it off with "Let Rasmus be Rasmus!"
https://www.reddit.com/r/programming/comments/jsudd/you_see_...
>r314434 (rasmus): Make static analyzers happy
>r315218 (stas): Unbreak crypt() (fix bug #55439) # If you want to remove static analyser messages, be my guest, but please run unit tests after
http://svn.php.net/viewvc/php/php-src/trunk/ext/standard/php...
https://plus.google.com/113641248237520845183/posts/g68d9RvR...
>Rasmus Lerdorf
>+Lorenz H.-S. We do. See http://gcov.php.net
>You can see the code coverage, test case failures, Valgrind reports and more for each branch.
>The crypt change did trigger a test to fail, we just went a bit too fast with the release and didn't notice the failure. This is mostly because we have too many test failures which is primarily caused by us adding tests for bug reports before actually fixing the bug. I still like the practice of adding test cases for bugs and then working towards making the tests pass, however for some of these non-critical bugs that are taking a while to change we should probably switch them to XFAIL (expected fail) so they don't clutter up the test failure output and thus making it harder to spot new failures like this crypt one.
How about the Thomas Midgley award, for having "had more impact on the internet than any other single organism in Earth's history"?
https://simple.wikipedia.org/wiki/Thomas_Midgley
Thomas Midgley (born 18 May 1889; died 2 November 1944), was an American inventor. His two most famous inventions are both now banned because they are dangerous for the world environment: the use of lead in petrol (gasoline) and the use of chlorofluorocarbons (CFCs) in refrigerators. Midgley was accidentally killed by something he was inventing.
https://en.wikipedia.org/wiki/Thomas_Midgley_Jr.#Legacy
Midgley's legacy has been scarred by the negative environmental impact of some of his innovations. His work led to the release of large quantities of lead into the atmosphere as a result of the large-scale combustion of leaded gasoline all over the world. High atmospheric lead levels have been linked with serious long-term health problems from childhood, including neurological impairment, and with increased levels of violence and criminality in cities.
Thomas Midgley Jr. died three decades before the ozone-depleting and greenhouse gas effects of CFCs in the atmosphere became widely known. Bill Bryson remarked that Midgley possessed "an instinct for the regrettable that was almost uncanny." J. R. McNeill, an environmental historian, opined that Midgley "had more impact on the atmosphere than any other single organism in Earth's history."
ಠ_ಠ
https://web.archive.org/web/20100701145902/http://blog.magic...
https://en.wikipedia.org/wiki/Mark_Karpel%C3%A8s
- someone should receive an award
- someone has had a large impact
- someone should go to prison
Countering the first with the third isn't very constructive, particularly as you note "I realize the guy I answered to was probably just trolling." It just further degrades the conversation.
http://themerkle.com/mark-karpeles-twitter/
PHP's original use case is dynamic HTML generation from HTML/SGML processing instructions embedded in otherwise static HTML. That's useful, but PHP's lack of HTML-aware template expansion and escaping mechanisms was and is bordering on the criminal IMHO.
"I was really, really bad at writing parsers. I still am really bad at writing parsers." -Rasmus Lerdorf
PHP is the only language with almost universal support among web hosts. It can run on basic shared hosting plans and on nearly every server. It can be deployed by simply uploading your code to a directory on your web host. Sure, it's a widely criticised language (even within the PHP community), but it still accounts for the vast majority of server side code (80% according to some sources).
What's baffling is why other languages and so many developers are blind to this problem of easy server install. They think it's a non-issue.
Prolific blogger and programmer, Jeff Attwood ranted about how he disliked PHP in one of his blog posts, but recognised that:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option."
To broaden choice, Attwood argues we should:
"build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible."
That was written in 2012. (https://blog.codinghorror.com/the-php-singularity/).
It's 2017 and what's changed? Nothing.
Having a ridiculously easy web app installation process for servers would unlock countless opportunities for developers to reach more users or customers. And it has, for many PHP open source projects and products.
Want your customers to self-install your software? Good luck getting them to do that easily with any language other than PHP.
It was easy to get setup and start programming in the 80s. That allowed you to spend time/energy on the complex logic you needed to write the program. Most programming is so much easier the level of math required is so much smaller and most websites are simple crud. Why are we making the setup process more difficult? Do we really need a gate keeper?
It's not anymore, and hasn't been for awhile. Here's one example:
https://www.phusionpassenger.com/
This is not true. We got AWS Lambda and friends, which let you write PHP in any language.
Solutions based on Node.js can be stand-alone.
(Hyperbole that hopefully illustrates my point)
The only thing where nginx might help performance-wise here is static file access (of eg. static web assets such as CSS or static HTML).
After all, in 2002 (the date of that Q&A), you could already deploy Perl or Python scripts by "simply uploading code to a directory", if mod_perl or mod_python was installed by the hosting provider.
Coordination problems are difficult.
you have to realize php is also incredibly insecure as well. chmod 777 on install instructions? on a shared webhost server? this really was and maybe still is the "thing".
the nature of being able to upload a php file to server on the public docroot makes the language always prone to hacks. sure there have been improvements with things like mod_suexec and fpms but this now makes things that usedto be easy now hard, ie htaccess and rewrite rules.
Meanwhile, recent attempts at fancier competitors (like Ghost and Discourse) have completely failed to capture the marketshare of their PHP based counterparts because they're just more difficult to set up for the non technical individual or company. Their creators put image (aka a more 'glamorous') tech stack above ease of use, and paid the price.
PHP's ease of deployment is basically why so many of the larger CMS systems of today got popular at all.
And you might get PHP running in almost all servers, but that says nothing about all your dependencies such as mail servers, message queues and the like. So the fact that it runs everywhere doesn't actually mean that much.
The hammer is a double sided claw hammer, the pliers don't have serrated edges. They will do a job, but perhaps not the job that you expected.
Eventually it leads to everyone using this weird little toolbox ends up with a weird sort of house that might collapse at any moment.
Things have moved on quite a bit since then. Certainly in PHP 7, you're able to give it the same treatment as a "proper" programming language and people do.
My view is though, it's a little too late. I don't think new people are coming into PHP because the barrier to entry has become higher than other languages.
It has become almost impossible to write a PHP application to do even the simplest task without getting bogged down in all sorts of over engineering and so called "design patterns".
We all know PHP will be around for a while longer.
Yet in 2017, I wouldn't recommend learning about PHP. Go learn something else.
That's rubbish. There's nothing that stops you creating a single script to return a value based on stdin or get parameters.
Design pattern nerds exist in every language. PHP has them no better or worse.
Also, many of the demons from PHP4 (in use in 2002) have been excised, e.g. https://wiki.php.net/rfc/remove_php4_constructors
That's why these developers are blind to ruby setup and dependency hell or nodejs insanity but magnify any self-perceived flaw in PHP without seeing the dissonance. This is a difficult act to pull off. This is so over the top and one sided it ceases to be useful.
Pandering to these criticisms will not work as they are not sincere and these developers are too caught up in how they are perceived to ever use PHP. Those who care for PHP should be concerned about attempts to pander to perceptions as this will destroy the accessibility and simplicity that makes PHP useful for everyone.
> So I wrote a very simple tag parser that would parse through an HTML file looking for special markup tags and replace those special tags with the result of my business logic code written in C.
(emphasis my own)
I really like PHP, but I find it very interesting that Lerdorf doesn't consider PHP code itself as business logic, but more of a templating language for the web.
A lot of PHP's fundamental strengths and weaknesses make sense in that light.
> I personally use a combination of PHP and Perl for many of my projects: Perl mostly for back-end tasks, while I have PHP doing all the front-end work.