How would they fix it anyway? It was never really designed, it just evolved as a slow accretion of features using whatever syntax was convenient in the parser codebase over a couple of decades.
The author makes a good point that people like me who ditched PHP in the mid-2000s should probably stop complaining about it since we don't really know the current state of affairs.
The problem is when we have languages like Ruby, Clojure, Scala, Haskell, or even plain old Javascript ala Node, why would I waste another thought on PHP? PHP was created to make very simple dynamic web pages, and I would still use it for that in the way that I still write bash scripts for simple shell operations to avoid a higher level dependency like Ruby or Perl. I'll use PHP for small stuff, but I see no benefit towards putting any real engineering effort into a PHP project.
I'd argue that PHP came out of the gate with some pretty powerful properties, too.
They hit a sweet spot of
* Being there at the right time (none of the "good" languages in your book was around or usable for web dev at the time of PHP4 and PHP5 came out)
* Being easy to learn - giving beginners quick rewards.
* Being powerful enough to do quite a bit more than "simple web pages", as you say. This enabled people to "graduate" from "simple web pages" to "web apps".
In fact, most of the web was built in PHP (Wikipedia, Facebook, Wordpress runs on 50% of all webpages or so, Drupal is incredibly popular, Magento runs loads of webshops, and on and on). This has not happened merely by accident.
I feel it's a bit wrongheaded to suggest otherwise.
* Being dead easy to deploy on almost any webhost (Drop files, hit them with their url, be done - almost no other language delivers this even today)
In all i feel PHP has moved the web forward tremendously.
In time, itself has evolved as well. It may not have evolved as fast as one would want.
"Being there at the right time" is pretty much the only redeeming quality it has, and it's not so much a quality of the language, is it?
"Easy to learn" is not the same as giving beginners quick rewards. Being easy to learn, in reality, would probably result in things like Wordpress not having more holes than a swiss cheese.
"Powerful enough" -- most web frameworks are. Saying that it didn't happen by accident of course depends on how you define accident. Personally I think the only thing PHP has got going for it is the timing and next point:
"Dead easy to deploy" again isn't a property of the language. Saying that "almost no language delivers this" about something that's really up to the service you're using to host your website isn't fair, in that it actually has nothing to do with the language.
I must say that I wholeheartedly agree with your closing statements, though.
Well that's why I said "even" Javascript. Brendan Eich actually pulled off a small miracle by embedding incredibly powerful functional and prototypal paradigms in JS. It's not perfect, and there are plenty of warts, but JS came out of the gate with a powerful core that PHP took decades to add in a Frankenstein manner.
Enough with the "JavaScript is a functional language" myth, please. Merely having first-class functions does not make a language a functional programming language.
JavaScript does not promote the use of pure functions, referential transparency, and the minimization of state.
JavaScript does not encourage the use of recursion.
JavaScript has an atrociously broken type system, rather than a robust and theoretically sound one.
JavaScript does not offer pattern matching and other functionality offered by modern functional languages.
In fact, JavaScript goes out of its way to promote a very imperative, non-functional style of software development, even when efforts are made to try to use it in a functional way.
And JavaScript's prototype-based OO is anything but powerful. In practice, it's nearly useless. That's why we see so many JavaScript developers try to fake a class-like OO system using it, since class-based OO does offer what they need and want. But due to the incapability of JavaScript's prototype-based approach, these hacks end up being incompatible maintenance headaches.
JavaScript does not have a "powerful core". It has a rotten core, just like PHP, and it has evolved in a broken manner, just like PHP.
JavaScript's design is clearly much more coherent than PHP's. Whereas PHP's developers have added features haphazardly over several years, the JavaScript language hasn't changed much since its initial design in 1995. Warts aside, having a (barely) complete initial design that was done by one person over a short time and has since been mostly left alone is an advantage. And JavaScript is flexible enough that library and framework developers have been able to explore several different approaches while the language remains frozen. Therefore, it's quite misguided to lump JavaScript in with PHP in terms of language design.
It's certainly not accurate to categorize JS as a functional language, but it is flexible enough that one can program in a more or less functional style; and unlike PHP, it always has been.
Also, I've read several of your anti-JS diatribes, and I feel compelled to ask this: What drives you to denigrate JavaScript, and programmers who willingly choose to use it, wherever you can? Do you feel the need to show your superiority by bashing the languages that many programmers use to produce useful applications despite their lack of expertise? Can we not accept that all mainstream languages have warts, and that in many cases, practicality may dictate that we use a language that doesn't please us aesthetically but is nevertheless useful?
A bad programming language that remains bad for nearly two decades isn't really any better, in my opinion, than a bad language that undergoes some change that may have mixed results in the end.
JavaScript is bad. PHP is bad. They're both bad in many of the same ways, and they're bad in different ways. None of this changes the inherent fact that they're both bad programming languages.
Of course all programming languages have "warts". Very few, however, have as many horrible and inexcusable "warts" as JavaScript and PHP do.
As an industry and as a community, we can do better than JavaScript and PHP. In fact, we have already done better in the past (sometimes many years ago), many times over.
So, yes, I will speak out against programming languages that are inherently broken and inferior, and even extremely harmful, whenever I get the chance. It's the right thing to do.
This is not about my ego, or about my "superiority", or about me at all. This is about doing things properly, as an industry and as an entire community of programmers and software developers. JavaScript and PHP are very clearly not acceptable programming languages to use, even if a lot of people make the mistake of doing so.
I take issue with your recurring assertion that JavaScript is bad. Not just that it isn't to your liking, but that it's objectively bad, something that the software development community ought to avoid. JavaScript's bad parts have been discussed to death, so I won't rehash them; it's enough to point out that programmers can easily get used to avoiding or working around them. What's more important is that there are good things about JS which make it very desirable as a cross-platform, general-purpose programming language. Specifically:
1. JS is the native language of the Web platform. Because of its ubiquity, the likes of which Java, Flash, and Silverlight never achieved, the Web platform is an attractive deployment target for many apps.
2. Because of JS's role in the Web platform, it has the support of every major player in personal computing, specifically, Apple, Google, and Microsoft. Languages like Python, Ruby, and Lua have nowhere near that level of corporate backing.
3. Yet no single company owns JavaScript, so there is no patent trap as with Java or .NET. Nor is there any threat of vendor lock-in.
4. Because of the strong corporate backing and the fact that most Web browsers are now based on open-source engines, there are mature, open-source, non-copyleft implementations of JavaScript for all major desktop and mobile platforms. (The "non-copyleft" bit is in contrast with, say, Mono, whose license enables Xamarin to charge a premium for use in iOS, Android, and Mac apps.)
5. Because JavaScript is the native language of the Web platform, full-stack Web application developers basically know it to some extent, regardless of what language they prefer on the back-end. So many programmers know JavaScript, making it an attractive choice for a software company wanting to hire more programmers, or an open-source project looking for contributors.
6. Because of the competition among browser developers in recent years, all of the major JS implementations are now very fast.
7. Unlike C and C++, which are AFAIK the only languages that match or exceed JS's ubiquity, JS guarantees memory safety. This eliminate a whole class of bugs that many programmers are not equipped to deal with or prevent. These bugs often turn into security holes.
So these qualities, largely political and business-related but important nonetheless, make JS very attractive to anyone wanting to choose a mainstream, high-level, general-purpose programming language for cross-platform application development. In light of this, how can you say that JS is objectively bad?
Don't set me up as straw man for your anti-JS rant. I never said JavaScript was a functional language, and I never said it was a great language. I just said it is better conceived than PHP, no more, no less.
Support for higher-order functions is obviously a minimal requirement of a "functional programming language". But functional programming extends far, far beyond that.
It also embodies a philosophy emphasizing the purity of such functions. It encourages the use of recursion for iteration. It encourages the use of robust type systems. It encourages the use of pattern matching. It discourages the use of many imperative approaches.
Although they may offer some form of higher-order functions these days, I don't consider languages like JavaScript, C#, C++, Ruby or PHP to be "functional programming languages". They're imperative languages that just happen to have added the most basic of functionality expected from functional programming languages. They don't truly encourage, and only partially enable, the writing of software using a functional approach.
I wouldn't say so. It's far, far closer to a functional programming language than JavaScript is, for instance. But it's clearly nowhere near what Haskell or Standard ML are, either.
Maybe "semi-functional" would be a good term for it and Scheme. It has some of the important elements of functional programming, but not all of them.
You would have to break it to fix it. Backwards compatibility kills you unless you never make bad decisions. Some languages manage this, eg Lua that has a (long slow) cycle of deprecate, remove on features.
What you say is very true. PHP is in the same boat that JavaScript is in. Their very severe, yet very inherent, language flaws just cannot be covered up with one library or framework after another.
The only real option is to give up backward compatibility, to then throw out every broken language feature, and to then reimplement them properly. Unfortunately for those two languages, that would involve an awful lot of stuff getting thrown out and reimplemented, which is very likely why it hasn't happened yet.
Given how much core functionality needs to be reworked in both cases, I don't think they can really be saved. There are numerous other better languages out there, and it's easier just to use them instead of trying to salvage PHP or JavaScript.
For example they have now deprecated the dreaded mysql_, pgsql_ interfaces (including mysql_now_escape_the_string_for_real() and the like ;) for accessing the database in favor of PDO.
They will be removed in the future.
Lots of projects still use those.
Just 1 example of PHP dropping backwards compatibility.
It's not quite so bad as you make it out to be.
Deprecation of those awful vendor specific DB extensions is a good start, no doubt. But those are library functions, rather than language features.
Another thing to consider is that PHP developers have a track record of deprecating certain functionality, then a few releases later changing their minds and no longer deprecating it. Some examples of this include is_a, and var in property declarations.
Given how it's still relatively common to see PHP 4.x installations in use today, 10 or more years after they were first released in some cases, merely deprecating some of the broken functionality now won't help much. We'll still see deprecated features in use in 2020, if not well beyond then.
The broken functionality needs to be stripped out completely within a reasonable time frame (well under a year), not merely deprecated and left around for years, if it even stays deprecated. But this involves the PHP community acting responsibly, and going along with these changes for their own good. I don't think we can expect that level of responsibility out of them, unfortunately.
I agree about the need to really strip out the bad stuff, not just deprecating.
Wrt removal of language features:
They seem to be in the process of cleaning up some there as well.
For example in 5.4 they removed safe mode, register globals, magic quotes (and those were really awful).
see: http://php.net/releases/5_4_0.php
I also agree that there is a lot of bad stuff still around.
Look at how slow Python 3 adoption has been. I don't think completely breaking backwards compatibility is a quick thing. The Python folks expected 5 years for Python 3 to become the default version because of the dramatic changes.
I've worked on a number of software systems at several different organizations that have very effectively used Python 3 for years now. I think that Python 3 has been adopted perfectly fine by many other people and organizations, too.
We're just not overly vocal about using it, because it has worked for us with so little pain and so little effort in many cases. It really wasn't much different going from 2.7 to 3.0 or 3.1 than it was going from 2.6 to 2.7, for example.
I strongly disagree, php 5 has introduced a lot of fixes, performance improvements and many nice and great new features.
I'm a big fan of python and I think that very intelligent people are behind its architecture, but honestly most of the money I made through the past years came from php websites that I can build really fast.
I have eventually used python (fabric) to automate creating php websites.
Not so fast. PHP evolved a lot as a language, maybe it will never be enough to fix its ancestry, but namespaces, closures, generators, ~~typed~~ expressions (you can finally slice a function call returning an array without unnecessary variables) and some literals. It's still not 1958-worthy to me, but they do evolve.
It is evolved indeed, but is there any language designer / guru who ever come close to exploring its good parts (like Douglas Crockford did with Javascript)? I don't think so...
Well, first I think it's irrelevant with what we were saying. Secondly, I doubt there will ever be such a document toward PHP, since it wasn't conceived with a linguistic background (Rasmus Lerdorf wanted a pragmatic dynamic layer on top of C code without resorting to perl). There's no special abstraction principle in PHP, as opposed to prototyping, which (after a quick wikicheck) is not a core abstraction in mainstream languages and could benefit from a book explaining how to think in it. PHP is more and more aiming toward mainstream class based OOP, and everything has been said about it but I can be wrong.
A fixed php would be a different language. The differences between Python 2.x and 3.0 would be minor compared to what would need to be fixed in php... and look how well that migration has worked out for python.
The language remains as bad as it was 7 years ago, and they seem to be woefully unwilling to actually fix it.