Completely ignoring the main point of the blog post, I’d put the glass bottle in the shoe and use it to hammer the nail.
I’ve been reading a lot of PHP bashing blogs lately and they all share the same problem. The problem with blogs like this one and especially “PHP: A Fractal of Bad Design” is that people bashing PHP don’t actually know much about PHP (i.e. almost every statement on that fractal blog post is wrong, good explanation here: http://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.html ) It’s ironic how people can make sarcastic remarks like this ““well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!”” and yet they’re actually the same, just with another toolbox in another playground.
If anyone has a good explanation on why PHP is bad, without all the snobbyst remarks and assumptions, with actual proper knowledge and experience with the language he’s analysing, ideally from someone who works with it right now (no, hacking up PHP4 code in high school doesn’t count), please don’t hesitate to share it.
Lets put this another way. If every PHP dev and piece of software switched over to Python (or what ever other language you decide for force everyone to use), what would change? Would all of those devs suddenly become five times better (and by what measurement)? Would all of those apps suddenly be seven times faster and use 50% less memory? Would this stop every dev from ever having a SQL injection issue, or prevent all XSS?
There is plenty to groan and complain about in PHP, no doubt of that. But clearly that isn’t enough to stop it from being useful.
The notion that all would be fixed in the world if devs only used a “well” designed language just hasn’t held water. I think it is paste time to get over it already.
Godspeed Mr. Atwood. If you can succeed with your new venture the way you succeeded with Stackoverflow you will deserve some sort of award.
There seems to be a bad language or bad framework stockholm syndrome out there. “If you just got to know PHP like I have you’d see it differently.” “PHP is really doing what’s best for me.” “PHP really isn’t that bad once you get used to it.”
Of course you could replace PHP with a lot of languages and still be accurate.
1 Like
but to build compelling alternatives
Mixing code and content is awful, but compelling for someone who doesn’t know better. There is nothing else that provides the type of immediate gratification of something that “works” as PHP, and this is the most insidious characteristic of it. Any alternative’s barrier to entry is, like the rent, too damn high for most people (unfortunately).
As one of those many self taught programmers that do PHP, where can I foolow this exciting “awesome opensource alternative to PHP”-project?
Would be great to learn & and grow with this “new language” as it is beeing developed!
Jeff, could you at least tell us what the language is? I don’t see the point of keeping it a secret…?
PHP as a whole is terrible, I won’t deny it, but it’s still usable if you use a good framework that encapsulates some or most of the PHP awfulness behind its abstractions.
In this case you still have to deal with “pure PHP” from time to time but your “house” will not have a roof upside-down, consider it as constructing with cheap materials
Is this a price worth paying? May be, depending on what you’re trying to accomplish.
Anybody who think that the choice of programming language one uses makes any form of difference whatsoever is suffering from a severe delusional state which can only be cured via copious intakes of some form of alcohol and a smack about the head with a clue-by-four.
Language doesn’t matter in the slightest. If you magically converted all PHP code to some other language overnight, then would it make all those programs better programs? Would it make everybody a better programmer?
Answer to both of these is no, because the “program” is not the end-goal, it is only the means to get to the end-goal.
If I’m a user, then I don’t care about having a spreadsheet program, I care about getting my work done with spreadsheets more easily and quickly. I don’t care about the email program, I care about sending my emails easily and effectively. I don’t care about the web publishing tool, I care about publishing content on the web more efficiently.
Users don’t care about language. Only programmer-nerd types like us do. But we’re not paying the bills, we’re being paid by the users to develop software for them.
And this leads to the bottom line:
The tool that works best is the one that gets you paid fastest.
Now, that tool may be anything depending on circumstances, but for web publishing, well, you pointed it out yourself. It’s clearly PHP. It’s everywhere, it’s easy-to-use, it’s fast-as-hell to develop with… even if it does have many, many problems from a pure programmers perspective.
PHP is a language for getting things done rapidly, with not much in the way of advanced skills being absolutely required. Sure, you can develop highly advanced structures and systems in PHP (especially since PHP 5.3), but the base-entry level is still HTML+PHP=FTW. Novices can (and should, IMO) start with it.
If you want to develop a better alternative, then focusing on the language itself will doom you to failure. PHP succeeded because of its usefulness and utility, not because of abstract and non-marketable ideas like language-syntax-purity and so forth. Any alternative must be immediately useful and easy-to-work-with, and trying to make the language somehow better from a pure programmer’s perspective invariably makes a language harder-to-use, as far as I can tell.
PHP is rarely the bottleneck
The beast feature of php is the manual and the community. It’s awesome being able to find solutions very easily.
Trying to figure out how something works in MSDN for .Net is like sticking nails through your eyes. It’s like it was written by lawyers and marketers exclusively—just jargon and shameless promotion, but not much real information.
Of course, the difficulty in reliably searching for .net or c# is part of that.
The PHP manual with the user-notes is a dream come true. What can take a full day to research in the MSDN manual takes seconds on php.net.
THIS is what you have to duplicate to replace php. Make it easy to understand, RAPIDLY. You need a good manual, with user notes, that gets updated and a community of passionate people who like discussing trivial matters.
The language itself is secondary or even tertiary to it’s success. That doesn’t mean you can’t make it awesome, but an awesome language is not enough nor is it a necessary prerequisite.
The solution is not to pick another programming language and make it ubiquitous for web applications. Instead, improve the interface and packaging model for web applications. I Am Not a Fan of Java, but the one thing it has going for it is WAR. If you’ve ever tried out something like Jenkins, for example, it’s as easy to run as “java jenkins.war”. And if you already have a fancy web server, you just drop the file in a directory.
In my opinion, standardizing on an interface (like FastCGI) between the web server and the application, plus a mechanism for packaging and deploying a complete application with its dependencies, independent of the programming language, would go a long way toward making a world where you’re not forced to consider PHP.
The other side of the coin is accessibility to new developers, and that’s an area where each language/framework should be actively competing. Here again, redirecting some of the time and energy wasted on packaging and deploying to improving the learning curve would be a good thing.
The objective tone of this article is a bit off given the obvious author bias.
As some commenters have pointed out PHP has improved considerably in recent years; any new critique should be on the current stable version of the language, not how it was in 1999
No toolset comes even remotely close to what php was actually designed to do: generate HTML from simple data structures. That is the key point that everyone seems to miss in these PHP SUXORZ debates. If you are trying to write an image processing/manipulation library from scratch in PHP, you are doing it wrong. If you are trying to implement a new database engine from scratch in PHP, you are doing it wrong. If you are trying to ANYTHING in php besides manage user input from http requests, load stored data, and generate HTML from that data, you are doing it wrong. It might be a cool experiment to build a distributed map reduce engine in PHP, but there are many reasons it’s a bad idea, mainly that you don’t end up generating HTML directly from a completed map reduce job.
I do think that auditing the consistency of some of the more archaic functions/APIs is a good idea. I personally hate having to lookup which comes first in a explode() or a strstr() if I brain fart for some weird reason, but I don’t blame php because I am the one who forgot the order after using it over 1000 times. PHP plays nice with every almost every system available, I have never seen issues with other programs or tool sets not being able to run because php is installed in a box.
It’s time to become better programmers and pick the right tool for the task, not the “job”. If you get over the fact there is not a superior programming language for all things you need to do then you will start to get the right picture. Then you begin to understand that you need to broaden your porgramming horizons and constantly learn new things and new tools. Then you start heading to a point where you can weave the best tools together to create functional art where everyone else didn’t even bother to look because, well, PHP LOL!!
TL;DR: PHP will continue to not give a shit about “becoming a better language”, and everyone else can continue to mock it from their sky castles and unicorns. I will still use it to generate awesome HTML with minimal fuss and almost never worry about deployment issues.
I don’t really buy the “PHP is easier to deploy” argument anymore. I don’t know what the situation is in the Python world, but Phusion Passenger (a.k.a. “mod_ruby”) has been making Ruby deployment very easy for a few years now.
The real issue is that many people who do PHP development either don’t have the knowledge or the desire to configure a server, so they go with shared hosting options that already have PHP, Apache, and MySQL preconfigured. But if you gave a developer shell access to a new virtual or dedicated server, it’d take about the same amount of time to configure and deploy a PHP or Ruby app (I’ve made a living doing both).
The aforementioned lack of knowledge is unfortunately pervasive in other areas of the PHP community. In my experience, the average PHP developer doesn’t know much about UNIX/Linux, doesn’t know much about databases, doesn’t know much about separation of concerns, and either doesn’t know or doesn’t care much about best practices.
All those things are okay if you’re using PHP as a templating language, which was its original purpose. But I’ve maintained for a while now that if you’re serious about the craft of software development–about achieving excellence in your work–PHP just might be a career hazard. I’ve moved on in my professional life, and I no longer even accept side projects doing PHP.
For some people, life is too short to use inferior tools. For others, life is too short to worry about the tool. Both viewpoints are defensible, but I think we have to accept that the aspirations of these two groups are very different.
Seeing that photo, at first I thought that you are going to praise you new hammer that you just bought for $199, and elaborate on how it was worth that price…
Jeff, you may get it. Realize that there are many people out there who don’t, though. Lots of developers use PHP day-to-day and think its flaws are fine and dandy. Those are the people that really need to be reached.
This is the fault - or rather, the pitfall - of open source software. It’s due to the narrowed perspective of the designer. People who don’t have to expand their awareness to include the realities of others (because they have to - commercial software companies demand it, and ignore it at their peril) end up creating applications that fully satisfy just one person - themselves - for a while.
Brilliant software works for many people and is updated rapidly in response to user requests. Think WordPerfect for DOS in the mid-1990s. The company responded to user requests and incorporated the good ones quickly - you could buy an update disk for $15 every few months.
Then along came Microsoft with marketing power and a bad attitude and bad software…and we haven’t had a decent word-processing app since.
PHP’s epic fail is not in language design on implementation. There are FAR worse languages out there (anyone know ActionScript? and apparently AppleScript is comparably bad). No, PHP’s fail is that it managed to get to be ubiquitous. It is everywhere and there is copious legacy code which needs to be supported (and it is cheaper to support bad but working code than it is to rewrite from scratch). And, of course, because the legacy code is bad PHP, the new code also has to be in PHP to be compatible.
Personally, I prefer Python (or Lisp… I dream of a Lisp-1 world… sigh…), but so long as PHP is paying my bills, I will hold my nose and use it.