Is a language good because it has many features? My current thesis is that adding features to languages can open up new ways to encode entire classes of bugs, but adding features cannot remove buggy possibilities.
If you have a foot-gun in your arsenal and you add a new safe-gun, sure, technically that’s just one more way you can shoot yourself in the foot, but that’s missing the point of having a safe-gun.
Many features can be used as less bug prone alternatives to old constructs. E.g., match expression instead of a switch statement where you could forget the assignment or forget a break and get unintentional fall-through. Same way features like unique_ptr in C++ can help reduce bugs compared to using bare pointers.
Another thing worth mentioning is that PHP has also grown some good linters that keep you away from the unsafe footguns. I believe it’s gotten really good over the years.
I actually run all of these. Obviously no linter is perfect and you can still have bugs but if you’re passing all of these with strict types enabled, you’re not writing the bad amateur code that got PHP it’s reputation from the “bad old days”. PHP’s not perfect but it’s no more ridiculous than, say, JavaScript, which curiously doesn’t suffer from the same street cred problems.
…JavaScript, which curiously doesn’t suffer from the same street cred problems.
I see what you’re saying, but JS actually does kinda have serious street cred problems. I mean, there are a ton of people who basically view JS programmers as second-class or less “talented”. And JS as a language is constantly mocked. I think the difference is that JS just happens to be the built-in language for the most widely deployed application delivery mechanism of all time: the web browser.
It’s probably just taken verbatim from C. It’s funny because PHP seems to have taken some things from Perl, which curiously does not have this flaw (it does allow a fallthrough with the next keyword, so you get the best of both worlds).
Switch has been in PHP since at least version 3.0 which is from the 1990s. Match doesn’t replace switch in the language but it can replace switch in your own code, making it better.
I disagree. People saying this usually have C++ on their mind, but I’d say C++ is an unusual exception in a class of its own. Every other language I’ve seen evolving has got substantially better over time: Java, C#, PHP, JS, Rust. Apart from Rust, these are old languages, that kept adding features for decades, and still haven’t jumped the shark.
PHP has actually completely removed many of its worst footguns like magic quotes or include over HTTP, and established patterns/frameworks that keep people away from the bad parts. They haven’t removed issues like inconsistent naming of functions, because frankly that’s a cosmetic issue that doesn’t get in the way of writing software. It’s very objectionable to people who don’t use PHP. PHP users have higher-priority higher-impact wishes for the language, and PHP keeps addressing these.
or the infamous mysql API (that was replaced by mysqli)
edit: Also I like that the OOP vs functional interfaces keep existing. My old code just runs and I get the choice between OOP and functional stuff (and I can switch as I like)
I liked the original mysql api. Was the easiest to use with proper documentation back then. A footgun is good analogy. A gun can be used in a perfectly safe manner. Of course if you eyeball the barrel or have no regard for basic safety rules about it being loaded or where it is pointed to at any time, then yeah, things are going to go south sooner or later.
Likewise, the old functional mysql api was perfectly usable and I never felt any worry about being hacked through sql injection. If you are going to pass numbers as string parameters or rely on things like auto-escape, then just like in the gun example, things are not going to end well. But let’s all be honest, at the point it is expected to be hacked.
I haven’t been around the PHP community in any serious capacity for probably 17 years now, but “with proper documentation” was a double edged sword. The main php.net website was a fantastic documentation reference, except for the part where lots of people posted really terrible solutions to problems on the same page as the official documentation. As I grew as a developer, I learned where a lot of the footguns were, but starting out the easy path was to just grab the solution in the comments on the page and use it, with all of the accompanying downfalls.
Already back in the day, it baffled me that the site even had comments, let alone people relying on them.nI would never blindly trust anything in the comments.
There is only one way of modifying a language that works in practice: add new features. As one of my colleagues likes to say, you can’t take piss out of a swimming pool. Once a feature is in a language, you can’t remove it without breaking things. You can; however, follow this sequence:
Add new feature.
Recommend against using old feature.
Refactor your codebase to avoid the old feature.
Add static analysis checks to CI that you aren’t using the old feature.
Provide compiler options to make use of the old features a hard error.
At this point, the old feature technically exists in the language, but not in your codebase and not in new code. I’ve seen this sequence (1-4, at least) used a lot in C++, where unsafe things from C++98 were gradually refactored into modern C++ (C++11 and later), things like the C++ Core Guidelines were written to recommend against the older idioms, then integrated into static analysers and used in CI, so you the old usages gradually fade.
If you manage to get to step 5, then you can completely ignore the fact that the language still has the old warts.
I thought I was going crazy. Needed validation as no one would state the obvious.
None of these features is a game changer for PHP. And even less so is all the composer and laravel craze that pretty much boils down to a silly explosion of javaesque boilerplate code.
Heck, even the introduction of a new object model back in PHP 5 had marginal impact on the language at best.
PHP’s killer features were:
Place script in location to deploy and map a URL to it
Out of the box support MySQL. Easy to use alternatives were payed back then, and connecting to MySQL or PostgreSQL was a PITA in most languages.
A robust template engine. It still is among the best and most intuitive to use our there. Although alternatives exist for every language.
Affordable availability on shared hosting with proper performance. This blew the options out of the water, with alternatives coating up to three orders of magnitude more for a minimum setup.
These things are not killer features anymore. Writing a simple webapp with a Sinatra-like framework it’s easier than setting up PHP. The whole drop file to deploy only made sense in the days of expensive shared servers. It is counterproductive in the $3 vps era.
I would prefer if the language would:
Ship a robust production grade http server to use with the language instead of the whole mess it requires to be used via third party web servers
Even better. Drop the whole http request and response as default input/output. It makes no sense nowadays. It is just a cute reliq from past decades. Which is more a source of trouble than a nicety.
From what I remember from trying out this stuff at the time, the .htaccess boilerplate for mod_cgi was more hassle and harder to understand.
CGI got a rep for being slow. fork/exec on every request costs a little, starting a new Perl interpreter or whatever on every request cost a lot. (and CGI in C was a productivity disaster)
PHP had features like parsing query strings and form bodies for you right out of the box. No need to even write import cgi.
Overall the barrier to entry to start getting something interactive happening in PHP was much lower.
From what I remember the documentation you could find online was much more tutorial shaped for PHP than what you could find online for CGI.
PHP != mod_php
Sure now, but pm is discussing the past. PHP == mod_php was de facto true during the period of time in which PHP’s ubiquity was skyrocketing. Where pm above describes what PHP’s killer features “were”, this is the time period they are describing.
It also did it much worse. With CGI, the web browser would fork, setuid to the owner of the public_html directory, and then execve the script. This had some overhead. In contrast, mod_php would run the PHP interpreter in-process. This meant that it had read access to all of the files that the web server had access to. If you had database passwords in your PHP scripts, then you’d better make sure that you trust all of the other users on the system, because they can write a PHP script that reads files from your ~/public_html and sends them to the requesting client. A lot of PHP scripts had vulnerabilities that let them dump the contents of any file that the PHP interpreter could read and this became any file the web server could read when deployed with mod_php. I recall one system I was using being compromised because the web server could read the shadow password file, someone was able to dump it, and then they were able to do an offline attack (back then, passwords were hashed with MD5 and an MD5 rainbow table for a particular salt was something that was plausible to generate) and find the root password. They then had root access on the system.
This is part of where the PHP hate came from: ‘PHP is fast’ was the claim, and the small print was ‘as long as you don’t want any security’.
This is completely irrelevant to the onboarding experience.
It mattered for the people who had their database credentials stolen because mod_php gave everyone else on their shared host read access to the file containing them. You’re right that it didn’t seem to harm PHP adoption though.
Not to the same extent at all. CGI would spawn a process on the operative system per request. It was practically impossible to keep safe. PHP outsourced the request lifecycle out of the developer’s concern. And did so with a huge performance gain compared to CGI. While in theory you could to “the same” with CGI, in practice,.it was just not viable. When PHP4 arrived, CGi was already in a downwards spiral already, with most hosting providers disabling access to it.
While Microsoft and Sun microsystems followed PHP philosophy by offering ASP and JSP, which had their own share of popularity.
PHP is, by and large, mod_php and nowadays fpm. The manual introductory tutorial even assumes such usage. Had they packaged it early on as a regular programming language, with its primary default interpreter hooked up to standard streams, it might have been forgotten today. Although personally I think they should have made that switch long ago.
“Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.”
Yeah. I worked for a PHP shop a few jobs back, and one of the web devs responding to my carping about it said “Yeah but you see, the thing is, PHP isn’t for YOU or even US. It’s for EVERYONE, even non programmers”.
At the time I thought he was just defending it because I was tipping his sacred cow, but I do think there’s some truth in there.
Demand the PHP core team break backwards compatibility with the software that powers 80% of the Internet to satisfy your aesthetic opinions about APIs.
So just to be clear I realize I am absolutely being the Princess and the Pea with my API issues. PHP is clearly a tool that makes many MANY people around the world productive, and Wordpress and Drupal and their ilk power huge swaths of the internet.
That said, I don’t have to particularly enjoy working with the language even if I do appreciate its many and varied strengths :)
PHP got better, but JavaScript got amazing. I don’t think PHP will ever overtake JS as a language, so even though I think Laravel has some very cool ideas, I can’t imagine ever using it for a new project again.
WordPress is a very good way to make a site to hand off a site to semi-technical people who then mostly leave it alone for several years. If you are an actual web developer, it is a terrible experience.
make a site to hand off a site to semi-technical people who then mostly leave it alone for several years.
It was this week when a friend contacted me that their Wordpress site made unexpected redirects to some bitcoin or pharmacy scam sites. They had auto updates activated and ran the latest Wordpress version, which is 5.9.2, but still their website got infected with malware, likely through some plugin though. I tried to run their site locally using docker-compose but Wordpress just died without any logs, only an error screen. In short, I always think that PHP is okayish until I have to use it. Giving non-technical people a wordpress makes them to administrators, if they want or not. Instead, they would be better off with something like a headless CMS (Jamstack) where they don’t have to fear getting infiltrated with malware.
There’s not a lot that comes close to the delight of resurrecting someone’s crashed Wordpress site. The joys of having to wade through broken MySQL tables, getting a PHP setup that functions and digging through crash logs, yay!
The only thing worse than that is trying to resurrect a broken custom PHP project that uses a framework that hasn’t been updated in a gazillion years and got broken due to a long-overdue PHP upgrade by the hosting provider, which now breaks because the ancient framework doesn’t support modern PHP.
I got to rescue one of my favorite old comics from a botched PHP upgrade. :-) http://www.alessonislearned.com/ The site was borked so I emailed the creator and he gave me FTP access. I forget the details, but it was probably the PHP 7 MySQL thing.
Yes, I think essentially no one but WordPress developers should self-host WordPress. It’s just not worth it. They all get hacked. Use one of the professional WP hosts and make it their problem.
I’m not enough of a concurrency expert to debate your feelings around Python’s async and await, although I will say a tremendous amount of work is being done there and the community has embraced it with open arms.
There’s a whole new wave of ‘modern’ Python projects that are async and type aware out of box.
Again, NOT trying to harsh your JS buzz, just hoping for accuracy and transparency around where Python is at with this stuff.
In JS, it’s trivial to take a callback based API and convert it to a Promise API.
function promiseEventListener(el, action) {
return new Promise(resolve => {
el.addEventListener(action, resolve, {once: true})
});
}
// elsewhere; this will block until someone clicks on it
let event = await promiseEventListener(el, "click");
Doing the equivalent in Python is non-trivial because you have to find the event loop, hope there are no other threads screwing things up, workaround the fact that Python first implemented a failed yield based API before the async APIs, workaround the lack of anonymous callbacks in Python… Async in JavaScript is just a quality of life improvement that you can opt into whenever you feel like writing a 3 line adaptor. Async in Python is an entirely different paradigm that has bad APIs.
To be pedantic, you usually don’t need to be too worried about other threads screwing things up in the event loop. But that said you’re spot on. Concurrency in Python is a bit of an after-thought and something you very much have to opt-into. JS is effortlessly concurrent in a way that makes me jealous when I use Python.
Been thinking about this a bit, and I see where you’re coming from here.
One IMO interesting thing I’ll note and it MAY support your point WRT Python - what we’re seeing is a ton of library authors embracing async and abstracting away all those details, so users/developers don’t have to care.
Like, FastAPI is async, and all its dependencies are async, but all the developer knows is their API is crazy pants fast, because the abstractions IT offers are really good.
Also back to Javascript - I have kind of a hard time dis-associating any given programming language from the uses it can be put to. That may be a failure of imagination on my part.
I have kind of a hard time dis-associating any given programming language from the uses it can be put to.
Yeah, that’s kind of the silly thing about arguing about programming languages online. 99% of the time the choice of language is dictated either by a) the software that already exists at the company or b) the ecosystem that already exists in the world. There are usually some experimental things on the margin, but if you want to write something for domain X there will only be a handful of practical choices, maybe even only one or two.
I’ve been writing JavaScript for 25 years and, I don’t want to say I “hate” it but… where to start.
I don’t like the turtles-all-the-way-down thing going on with its objects, how almost none of your muscle memory is transferable for how objects vs classes work from almost all other OO languages, and just in general I find it very unpredictable. I find the execution model unpredictable, the scoping rules. No matter how many years go by my development method with it remains, write code and see what nuance of the language I either don’t know or forgot.
I’ve had this conversation with other developers and they say, well it’s not fair to project your expectations from other languages on JavaScript, which I agree. I’m not saying the way it works is objectively bad, just that for me personally, I’m writing JavaScript to get my work done. I’m not having fun learning a new paradigm where the concept of OO is flipped on its head. That’s just slowing me down.
Just a latest example, there’s some problem accessing this inside arrow functions. There’s some reason for that fine, but the bottom line is it’s not intuitive and that’s just 1 out of countless examples from over the years that I can’t remember.
JavaScript’s rules for this were confusing and bad, and the solution is the arrow function, which fixes them. Similarly, scoping was idiosyncratic (function wide and hoisted) and let fixed it. (Const is dumb though, lol.) Basically all of the problems with ES5 have a good solution in ES6+.
Been trying to feel the Javascript love of late and not succeeding very well outside of interactive in browser stuff where I can see it’s pretty expressive and fit to task.
Every feature listed in the article is a feature of that JS had first. JS also has a very good system for async (unlike Python). I don’t really like Node or JS on the backend, but as a language, it has gotten quite good.
If, one day, typescript is not something you have to bolt on top of existing frameworks (or use stuff like deno for in-runtime support), we can start talking about typescript as JS.
While my kneejerk is that these are are common place in the FP space (pattern matching, union types/enums, never, Void, shorthand lambdas, Ord (-1, 0, 1), actually remembering null values), I realize these are almost certainly borrowed verbatim from JavaScript/TypeScript, not Haskell/OCaml/etc.
Would it really “break the web” if PHP removed some of the sketchy parts of the language? It’s not like JS in the browser where you don’t have control over the version you’re running. Updating JS would break existing websites running old code. But pushing breaking changes in a version bump to PHP doesn’t have to break anything. It’s running on the backend and a lot of people are (or were at least) using old versions for WordPress anyway. Why don’t the just purge some of that stuff and make it actually nice.
Folks using those sketchy parts will just keep using older builds of PHP which keeps their applications sketchy but also locks them out of security updates. At least that’s been my experience developing with PHP in the past.
There is an almost constant push from a segment of the php internals community (i.e. the community of people that actually develop php itself) to improve things, make it stricter, remove old stuff.
In practically every case, the age old “but BC” is trotted out. Sometimes enough people think the improvement is worth it, and the vote passes. In some cases it doesn’t.
If you want to really scream “wtf” at your display, go read through the php internals mailing list messages arguing against recently passed RFC, that means accessing undeclared variables will be considered an error, not just a warning (and thus can’t just be silenced any more). You understood that correctly: in 2022 people are arguing in favour of the ability to deliberately attempting to access undeclared variables without an error.
I have mixed feelings about a lot of this. Being a user of both Lua and JavsScript I see a lot of issues PHP has handled in different ways.
In practically every case, the age old “but BC” is trotted out
In Lua, they allow, and liberally if needed break backwards compatibility. The language is better for it, BUT Lua is primarily an embedded language so users are free to use whatever version, official or not they want. JavaScript on the other hand still carries around stuff like string.bold because removing stuff like that could actually break unmodified code that has otherwise been running just fine on the web.
in 2022 people are arguing in favour of the ability to deliberately attempting to access undeclared variables without an error.
I’m not a huge user of PHP but I have to work with it from time to time. I would think because of the nature of stuff like includes, where code is basically inserted inline, you don’t always know what variables will be available at run-time. Sometimes, like Lua, it’s easier to just add null guards here and there or find other ways to protect your code against null values.
I mean, php isn’t a client-side language, there’s no reason a developer isn’t in control of the version of php they use, more now than ever.
When mod_php was “the way”, sure, it was harder to pick and choose versions on any kind of multiple use system (either shared hosting, or even multiple sites/projects on a single VM/server, but these days: php-fpm (i.e. a fastcgi daemon) is undoubtedly “the way”, and it’s trivial to have half a dozen different versions of php installed concurrently, and target a specific version per vhost / site. Furthermore, easier service management via systemd and/or system encapsulation via containers mean that running stuff which has very esoteric needs (i.e. needs mod_php, needs php5.4 or something else equally ancient) on an otherwise multi-use system is not rocket science.
The biggest difference is probably that php is generally exposed to the web as a server, which Lua can do obviously but it isn’t Lua’s raison d’etre, so running an older version that is potentially not receiving security updates is probably less critical.
So, until php 8.2, if run above you’ll either get stuff output, or a warning and then nothing, because an undefined variable is treated as null (and I deliberately misspelled the second one with a capital i instead of a lowercase L).
The argument isn’t about “should we allow for the concept of undefined variables”.. That exists in multiple ways:
the isset() language construct
the empty() language construct
the ?? null coalescing operator
The argument being made isn’t “an undefined variable is something we have to handle, this is the only way”.
The argument being made is “it’s too much work to explicitly check if a potentially undefined variable is defined before accessing it, and keeping the ‘default to null’ behaviour is more important than helping to solve a whole swathe of bugs caused by unexpectedly undefined variables (either due to logic issues, var name typos, etc).
One of the biggest benefits to me, is that it forces people to be explicit in their code now. Dealing with other people’s sloppy code is a nightmare, and even the best IDE can’t tell you what someone else’s intention was.
They did it with the PHP 3 => 4 transition, there was a massive breaking change in how objects were passed by reference (they used to be passed by value, if you can believe it). So they can do it again, perhaps over many releases by gradually deprecating (and replacing) and removing the old APIs. I think it’s more likely that they don’t really feel the sketchy parts are that sketchy.
Jeeze, so, haven’t really touched PHP since like 2003 so I don’t recall what the syntax for anything is, but just looking at the lambda syntax in that font, I couldn’t actually tell if that was =>, or ==>, or ->, or even -->. I had to look at the source to figure out what it actually was.
It was primarily the APIs, not the language, that led me to give up PHP in disgust a long time ago (c.2006.) A lot of the APIs were badly designed in the first place, like the core ones that just aped C; many had “clever” features like magic parameter values that triggered special behavior, and some had weird changes in semantics between PHP versions. This made the APIs bristle with footguns, in my experience.
PHP is bad for webpages because it’s not a suitable HTML templating language and it uses file based routing. A suitable templating language is safe by default. Even the cool new PHP things all end up using some other safer language for templating. File based routing can be okay if it’s smart routing, like there’s some parsing of route info, a la Next.js, but PHP file based routing is dumb URL → page and you need to use Apache or whatever to make the routing acceptable. I guess someone could fork PHP to fix those issues, but that would just be Laravel, no?
What PHP has going for it is that it is very easy to get something to production quickly. This is a very important quality, perhaps even the most important for many uses. Still, for most new users today my recommendation is to just make a static site and host it on Netlify so you can collect form inputs or use Airtable for forms.
FYI the templating URL you’re linking to is Symfony’s templating language framework, not something intended to be used as-is. The actual templating language symfony and Drupal use is Twig, which is escaped by default.
Most serious projects use PHP frameworks that do not use file-based routing, it’s there at the lower level but that’s not really part of your development experience. You define routes very similar to the way you would in e.g. popular JavaScript frameworks.
I guess I’m not understanding your point on how PHP’s native routing makes it bad for web pages. I’m guessing I disagree with you on something here but I’m not even sure what that is :) File-based routing is fine for very simple sites, and if you’re doing something more complex you have a framework that gives you more power. Isn’t this exactly the same as HTML+JS? Web servers use file-based routing too (unless you’re doing something fancy with JS) so it’s not really a weakness of PHP, that’s just how the web works.
No, you want to separate routes from controllers in any kind of practical system. It doesn’t have to be a regex (although those are nice to have), but eg it should be easy to do /page/:id. In PHP, to do that, you have to leave PHP, go to your web server, configure that to send pages to index.php but include the original URL as a query parameter or something, go back to PHP and add code to unpack the information from the router, then do the actual routing. None of that is impossible, but it’s not the easy path, and the easy path should include /page/:id because that’s a minimum for a dynamic web server. If you only need static routing, just use a static site generator.
you want to separate routes from controllers in any kind of practical system
I agree with you, and there is a case here that PHP could have some native routing support that would make the framework implementations of this simpler. But I would still say, the process you describe doesn’t really matter as a PHP dev because all of that is invisible and handled for you by any popular framework (routes and controllers are decoupled). Stuff like /page/:id I’m pretty sure I’ve been able to manage just through mod_rewrite e.g. /foo/id/3 gets matched to foo.php?id=3 – although forgive me if PHP did require something to make that work and I just forgot, I haven’t needed to set that up in a long time.
I’m surprised no one forked PHP and cleaned it up. You can’t beat PHP for web pages.
The idea of this comment, as I understand it, is not “the PHP ecosystem is good” or “there are strong PHP frameworks”. It’s “PHP the language is really nice and convenient for making a dynamic website, and if someone could just go back and fix all the weird naming issues with the standard library, it would be perfect.” I disagree with that. My disagreement isn’t that good frameworks can’t be written in PHP. Laravel is very cool! It’s that the core language and standard library, even if you went back and fixed the inconsistent naming stuff, aren’t good enough to make a dynamic website for two reasons: 1. the templating is unsafe and you need Twig or something to fix it and 2. you need non-file based routing, or at least dynamic file routing, and to do that in PHP, you need to coordinate some hand off with your webserver.
I think I understand the point better, thank you for clarifying.
To that I would still say though, “good” must at some point be relative. Every language (that I’m aware of anyway) when used for the web, is primarily used with a framework. At least for any non-trivial project, which is arguably the use case that matters the most.
By the standard and reasoning I’m taking away from this criticism, there are /no/ languages that are good at dynamic websites because if they were, none of them would need frameworks. Express.js and Django exist because JavaScript and Python aren’t perfect for web apps out of the box. In that sense this criticism of PHP seems tautological.
Go’s standard library has an adequate templating library and router. It’s very common to use it without a “framework” although you will probably end up using some kind of third party packages for things like databases and sessions. I don’t think it’s unreasonable to think that “a cleaned up PHP” would come with a decent router and templating language.
It would be cool if someone forked it to a very small binary with a very aggressive strip. With things like auto loading or even OOP support removed. Something that could be used to build quick and dirty web interfaces. Perhaps even in microcontrolers.
The template capabilities are still, IMO, the easiest to use of any template engine out there. Because they just use the language constructs the programmer already knows.
Is a language good because it has many features? My current thesis is that adding features to languages can open up new ways to encode entire classes of bugs, but adding features cannot remove buggy possibilities.
If you have a foot-gun in your arsenal and you add a new safe-gun, sure, technically that’s just one more way you can shoot yourself in the foot, but that’s missing the point of having a safe-gun.
Many features can be used as less bug prone alternatives to old constructs. E.g., match expression instead of a switch statement where you could forget the assignment or forget a break and get unintentional fall-through. Same way features like unique_ptr in C++ can help reduce bugs compared to using bare pointers.
Another thing worth mentioning is that PHP has also grown some good linters that keep you away from the unsafe footguns. I believe it’s gotten really good over the years.
Just to fill this out:
Psalm
PHPStan
EA Inspections Extended
Sonar
I actually run all of these. Obviously no linter is perfect and you can still have bugs but if you’re passing all of these with strict types enabled, you’re not writing the bad amateur code that got PHP it’s reputation from the “bad old days”. PHP’s not perfect but it’s no more ridiculous than, say, JavaScript, which curiously doesn’t suffer from the same street cred problems.
I see what you’re saying, but JS actually does kinda have serious street cred problems. I mean, there are a ton of people who basically view JS programmers as second-class or less “talented”. And JS as a language is constantly mocked. I think the difference is that JS just happens to be the built-in language for the most widely deployed application delivery mechanism of all time: the web browser.
It’s not as if match replaced switch; and why did it have default falkthrough to begin with, whilst match doesn’t?
It’s probably just taken verbatim from C. It’s funny because PHP seems to have taken some things from Perl, which curiously does not have this flaw (it does allow a fallthrough with the
nextkeyword, so you get the best of both worlds).Switch has been in PHP since at least version 3.0 which is from the 1990s. Match doesn’t replace switch in the language but it can replace switch in your own code, making it better.
I disagree. People saying this usually have C++ on their mind, but I’d say C++ is an unusual exception in a class of its own. Every other language I’ve seen evolving has got substantially better over time: Java, C#, PHP, JS, Rust. Apart from Rust, these are old languages, that kept adding features for decades, and still haven’t jumped the shark.
PHP has actually completely removed many of its worst footguns like magic quotes or include over HTTP, and established patterns/frameworks that keep people away from the bad parts. They haven’t removed issues like inconsistent naming of functions, because frankly that’s a cosmetic issue that doesn’t get in the way of writing software. It’s very objectionable to people who don’t use PHP. PHP users have higher-priority higher-impact wishes for the language, and PHP keeps addressing these.
or the infamous mysql API (that was replaced by mysqli)
edit: Also I like that the OOP vs functional interfaces keep existing. My old code just runs and I get the choice between OOP and functional stuff (and I can switch as I like)
I liked the original mysql api. Was the easiest to use with proper documentation back then. A footgun is good analogy. A gun can be used in a perfectly safe manner. Of course if you eyeball the barrel or have no regard for basic safety rules about it being loaded or where it is pointed to at any time, then yeah, things are going to go south sooner or later.
Likewise, the old functional mysql api was perfectly usable and I never felt any worry about being hacked through sql injection. If you are going to pass numbers as string parameters or rely on things like auto-escape, then just like in the gun example, things are not going to end well. But let’s all be honest, at the point it is expected to be hacked.
I haven’t been around the PHP community in any serious capacity for probably 17 years now, but “with proper documentation” was a double edged sword. The main php.net website was a fantastic documentation reference, except for the part where lots of people posted really terrible solutions to problems on the same page as the official documentation. As I grew as a developer, I learned where a lot of the footguns were, but starting out the easy path was to just grab the solution in the comments on the page and use it, with all of the accompanying downfalls.
Already back in the day, it baffled me that the site even had comments, let alone people relying on them.nI would never blindly trust anything in the comments.
There is only one way of modifying a language that works in practice: add new features. As one of my colleagues likes to say, you can’t take piss out of a swimming pool. Once a feature is in a language, you can’t remove it without breaking things. You can; however, follow this sequence:
At this point, the old feature technically exists in the language, but not in your codebase and not in new code. I’ve seen this sequence (1-4, at least) used a lot in C++, where unsafe things from C++98 were gradually refactored into modern C++ (C++11 and later), things like the C++ Core Guidelines were written to recommend against the older idioms, then integrated into static analysers and used in CI, so you the old usages gradually fade.
If you manage to get to step 5, then you can completely ignore the fact that the language still has the old warts.
I thought I was going crazy. Needed validation as no one would state the obvious.
None of these features is a game changer for PHP. And even less so is all the composer and laravel craze that pretty much boils down to a silly explosion of javaesque boilerplate code.
Heck, even the introduction of a new object model back in PHP 5 had marginal impact on the language at best.
PHP’s killer features were:
These things are not killer features anymore. Writing a simple webapp with a Sinatra-like framework it’s easier than setting up PHP. The whole drop file to deploy only made sense in the days of expensive shared servers. It is counterproductive in the $3 vps era.
I would prefer if the language would:
Ship a robust production grade http server to use with the language instead of the whole mess it requires to be used via third party web servers
Even better. Drop the whole http request and response as default input/output. It makes no sense nowadays. It is just a cute reliq from past decades. Which is more a source of trouble than a nicety.
Which was possible for years before PHP via CGI and is no longer possible for PHP in many setups. PHP != mod_php
mod_php did this better than CGI did at the time.
.htaccessboilerplate for mod_cgi was more hassle and harder to understand.import cgi.Overall the barrier to entry to start getting something interactive happening in PHP was much lower.
From what I remember the documentation you could find online was much more tutorial shaped for PHP than what you could find online for CGI.
Sure now, but pm is discussing the past. PHP == mod_php was de facto true during the period of time in which PHP’s ubiquity was skyrocketing. Where pm above describes what PHP’s killer features “were”, this is the time period they are describing.
It also did it much worse. With CGI, the web browser would fork, setuid to the owner of the
public_htmldirectory, and thenexecvethe script. This had some overhead. In contrast,mod_phpwould run the PHP interpreter in-process. This meant that it had read access to all of the files that the web server had access to. If you had database passwords in your PHP scripts, then you’d better make sure that you trust all of the other users on the system, because they can write a PHP script that reads files from your~/public_htmland sends them to the requesting client. A lot of PHP scripts had vulnerabilities that let them dump the contents of any file that the PHP interpreter could read and this became any file the web server could read when deployed withmod_php. I recall one system I was using being compromised because the web server could read the shadow password file, someone was able to dump it, and then they were able to do an offline attack (back then, passwords were hashed with MD5 and an MD5 rainbow table for a particular salt was something that was plausible to generate) and find the root password. They then had root access on the system.This is part of where the PHP hate came from: ‘PHP is fast’ was the claim, and the small print was ‘as long as you don’t want any security’.
This is completely irrelevant to the onboarding experience.
Either way, empirically, people didn’t actually care all that much about the fact that their php webhosts were getting broken into.
It mattered for the people who had their database credentials stolen because
mod_phpgave everyone else on their shared host read access to the file containing them. You’re right that it didn’t seem to harm PHP adoption though.Not to the same extent at all. CGI would spawn a process on the operative system per request. It was practically impossible to keep safe. PHP outsourced the request lifecycle out of the developer’s concern. And did so with a huge performance gain compared to CGI. While in theory you could to “the same” with CGI, in practice,.it was just not viable. When PHP4 arrived, CGi was already in a downwards spiral already, with most hosting providers disabling access to it. While Microsoft and Sun microsystems followed PHP philosophy by offering ASP and JSP, which had their own share of popularity.
PHP is, by and large, mod_php and nowadays fpm. The manual introductory tutorial even assumes such usage. Had they packaged it early on as a regular programming language, with its primary default interpreter hooked up to standard streams, it might have been forgotten today. Although personally I think they should have made that switch long ago.
“Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.”
https://schemers.org/Documents/Standards/R5RS/HTML/
I think it’s the same principle as with source code: you want as little as possible while keeping things readable and correct
These are all worthy and probably excellent enhancements - but they don’t address my core beef with PHP: The APIs.
The weird mix of pre OO big_long_namespaced_function_names() with some OO libraries make my skin crawl :)
(I’m looking at you, get_file_contents() :)
It’s
file_get_contents()btw 😊Details are important. Thanks for the correction.
On the up-side, this means I have succeeded in my goal of wiping PHP from my brain :)
I think it’s probably hopeless to fix that stuff because there’s so much legacy code that depends on it.
My core beef is the existence of the PHP configuration file, but same story there.
Yeah. I worked for a PHP shop a few jobs back, and one of the web devs responding to my carping about it said “Yeah but you see, the thing is, PHP isn’t for YOU or even US. It’s for EVERYONE, even non programmers”.
At the time I thought he was just defending it because I was tipping his sacred cow, but I do think there’s some truth in there.
There’s two ways to address this, as far as I’m aware.
So just to be clear I realize I am absolutely being the Princess and the Pea with my API issues. PHP is clearly a tool that makes many MANY people around the world productive, and Wordpress and Drupal and their ilk power huge swaths of the internet.
That said, I don’t have to particularly enjoy working with the language even if I do appreciate its many and varied strengths :)
PHP got better, but JavaScript got amazing. I don’t think PHP will ever overtake JS as a language, so even though I think Laravel has some very cool ideas, I can’t imagine ever using it for a new project again.
I think you may be overlooking Wordpress and similar solutions.
WordPress is a very good way to make a site to hand off a site to semi-technical people who then mostly leave it alone for several years. If you are an actual web developer, it is a terrible experience.
It was this week when a friend contacted me that their Wordpress site made unexpected redirects to some bitcoin or pharmacy scam sites. They had auto updates activated and ran the latest Wordpress version, which is 5.9.2, but still their website got infected with malware, likely through some plugin though. I tried to run their site locally using docker-compose but Wordpress just died without any logs, only an error screen. In short, I always think that PHP is okayish until I have to use it. Giving non-technical people a wordpress makes them to administrators, if they want or not. Instead, they would be better off with something like a headless CMS (Jamstack) where they don’t have to fear getting infiltrated with malware.
There’s not a lot that comes close to the delight of resurrecting someone’s crashed Wordpress site. The joys of having to wade through broken MySQL tables, getting a PHP setup that functions and digging through crash logs, yay!
The only thing worse than that is trying to resurrect a broken custom PHP project that uses a framework that hasn’t been updated in a gazillion years and got broken due to a long-overdue PHP upgrade by the hosting provider, which now breaks because the ancient framework doesn’t support modern PHP.
I got to rescue one of my favorite old comics from a botched PHP upgrade. :-) http://www.alessonislearned.com/ The site was borked so I emailed the creator and he gave me FTP access. I forget the details, but it was probably the PHP 7 MySQL thing.
Yes, I think essentially no one but WordPress developers should self-host WordPress. It’s just not worth it. They all get hacked. Use one of the professional WP hosts and make it their problem.
I’m not enough of a concurrency expert to debate your feelings around Python’s async and await, although I will say a tremendous amount of work is being done there and the community has embraced it with open arms.
There’s a whole new wave of ‘modern’ Python projects that are async and type aware out of box.
Again, NOT trying to harsh your JS buzz, just hoping for accuracy and transparency around where Python is at with this stuff.
In JS, it’s trivial to take a callback based API and convert it to a Promise API.
Doing the equivalent in Python is non-trivial because you have to find the event loop, hope there are no other threads screwing things up, workaround the fact that Python first implemented a failed yield based API before the async APIs, workaround the lack of anonymous callbacks in Python… Async in JavaScript is just a quality of life improvement that you can opt into whenever you feel like writing a 3 line adaptor. Async in Python is an entirely different paradigm that has bad APIs.
To be pedantic, you usually don’t need to be too worried about other threads screwing things up in the event loop. But that said you’re spot on. Concurrency in Python is a bit of an after-thought and something you very much have to opt-into. JS is effortlessly concurrent in a way that makes me jealous when I use Python.
Been thinking about this a bit, and I see where you’re coming from here.
One IMO interesting thing I’ll note and it MAY support your point WRT Python - what we’re seeing is a ton of library authors embracing async and abstracting away all those details, so users/developers don’t have to care.
Like, FastAPI is async, and all its dependencies are async, but all the developer knows is their API is crazy pants fast, because the abstractions IT offers are really good.
Also back to Javascript - I have kind of a hard time dis-associating any given programming language from the uses it can be put to. That may be a failure of imagination on my part.
Yeah, that’s kind of the silly thing about arguing about programming languages online. 99% of the time the choice of language is dictated either by a) the software that already exists at the company or b) the ecosystem that already exists in the world. There are usually some experimental things on the margin, but if you want to write something for domain X there will only be a handful of practical choices, maybe even only one or two.
I’ve been writing JavaScript for 25 years and, I don’t want to say I “hate” it but… where to start.
I don’t like the turtles-all-the-way-down thing going on with its objects, how almost none of your muscle memory is transferable for how objects vs classes work from almost all other OO languages, and just in general I find it very unpredictable. I find the execution model unpredictable, the scoping rules. No matter how many years go by my development method with it remains, write code and see what nuance of the language I either don’t know or forgot.
I’ve had this conversation with other developers and they say, well it’s not fair to project your expectations from other languages on JavaScript, which I agree. I’m not saying the way it works is objectively bad, just that for me personally, I’m writing JavaScript to get my work done. I’m not having fun learning a new paradigm where the concept of OO is flipped on its head. That’s just slowing me down.
Just a latest example, there’s some problem accessing
thisinside arrow functions. There’s some reason for that fine, but the bottom line is it’s not intuitive and that’s just 1 out of countless examples from over the years that I can’t remember.JavaScript’s rules for this were confusing and bad, and the solution is the arrow function, which fixes them. Similarly, scoping was idiosyncratic (function wide and hoisted) and let fixed it. (Const is dumb though, lol.) Basically all of the problems with ES5 have a good solution in ES6+.
Which changes do you find particularly amazing?
Been trying to feel the Javascript love of late and not succeeding very well outside of interactive in browser stuff where I can see it’s pretty expressive and fit to task.
Every feature listed in the article is a feature of that JS had first. JS also has a very good system for async (unlike Python). I don’t really like Node or JS on the backend, but as a language, it has gotten quite good.
I thought I was crazy, but I checked and it doesn’t look like all of these features are in js.
Specifically:
Matching and enums I’ve grown to especially miss (and if we’re making comparisons to python, python does have both).
Still definitely a lot of features I’ve missed have come to javascript, but idk if I’m ready to say amazing yet.
I am pretty sure TypeScript has most of those features, but yes, that is different than JS.
If, one day, typescript is not something you have to bolt on top of existing frameworks (or use stuff like deno for in-runtime support), we can start talking about typescript as JS.
Typescript has sum types, enums, and constructor parameters, but doesn’t have multiple catch, match expression, or spaceship.
While my kneejerk is that these are are common place in the FP space (pattern matching, union types/enums,
never,Void, shorthand lambdas,Ord(-1, 0, 1), actually rememberingnullvalues), I realize these are almost certainly borrowed verbatim from JavaScript/TypeScript, not Haskell/OCaml/etc.Would it really “break the web” if PHP removed some of the sketchy parts of the language? It’s not like JS in the browser where you don’t have control over the version you’re running. Updating JS would break existing websites running old code. But pushing breaking changes in a version bump to PHP doesn’t have to break anything. It’s running on the backend and a lot of people are (or were at least) using old versions for WordPress anyway. Why don’t the just purge some of that stuff and make it actually nice.
Folks using those sketchy parts will just keep using older builds of PHP which keeps their applications sketchy but also locks them out of security updates. At least that’s been my experience developing with PHP in the past.
There is an almost constant push from a segment of the php internals community (i.e. the community of people that actually develop php itself) to improve things, make it stricter, remove old stuff.
In practically every case, the age old “but BC” is trotted out. Sometimes enough people think the improvement is worth it, and the vote passes. In some cases it doesn’t.
If you want to really scream “wtf” at your display, go read through the php internals mailing list messages arguing against recently passed RFC, that means accessing undeclared variables will be considered an error, not just a warning (and thus can’t just be silenced any more). You understood that correctly: in 2022 people are arguing in favour of the ability to deliberately attempting to access undeclared variables without an error.
I have mixed feelings about a lot of this. Being a user of both Lua and JavsScript I see a lot of issues PHP has handled in different ways.
In Lua, they allow, and liberally if needed break backwards compatibility. The language is better for it, BUT Lua is primarily an embedded language so users are free to use whatever version, official or not they want. JavaScript on the other hand still carries around stuff like
string.boldbecause removing stuff like that could actually break unmodified code that has otherwise been running just fine on the web.I’m not a huge user of PHP but I have to work with it from time to time. I would think because of the nature of stuff like includes, where code is basically inserted inline, you don’t always know what variables will be available at run-time. Sometimes, like Lua, it’s easier to just add null guards here and there or find other ways to protect your code against null values.
I mean, php isn’t a client-side language, there’s no reason a developer isn’t in control of the version of php they use, more now than ever.
When
mod_phpwas “the way”, sure, it was harder to pick and choose versions on any kind of multiple use system (either shared hosting, or even multiple sites/projects on a single VM/server, but these days: php-fpm (i.e. a fastcgi daemon) is undoubtedly “the way”, and it’s trivial to have half a dozen different versions of php installed concurrently, and target a specific version per vhost / site. Furthermore, easier service management via systemd and/or system encapsulation via containers mean that running stuff which has very esoteric needs (i.e. needs mod_php, needs php5.4 or something else equally ancient) on an otherwise multi-use system is not rocket science.The biggest difference is probably that php is generally exposed to the web as a server, which Lua can do obviously but it isn’t Lua’s raison d’etre, so running an older version that is potentially not receiving security updates is probably less critical.
So let’s say you have two files: a.php
b.php
So, until php 8.2, if run above you’ll either get
stuffoutput, or a warning and then nothing, because an undefined variable is treated as null (and I deliberately misspelled the second one with a capitaliinstead of a lowercaseL).The argument isn’t about “should we allow for the concept of undefined variables”.. That exists in multiple ways:
The argument being made isn’t “an undefined variable is something we have to handle, this is the only way”.
The argument being made is “it’s too much work to explicitly check if a potentially undefined variable is defined before accessing it, and keeping the ‘default to null’ behaviour is more important than helping to solve a whole swathe of bugs caused by unexpectedly undefined variables (either due to logic issues, var name typos, etc).
One of the biggest benefits to me, is that it forces people to be explicit in their code now. Dealing with other people’s sloppy code is a nightmare, and even the best IDE can’t tell you what someone else’s intention was.
They did it with the PHP 3 => 4 transition, there was a massive breaking change in how objects were passed by reference (they used to be passed by value, if you can believe it). So they can do it again, perhaps over many releases by gradually deprecating (and replacing) and removing the old APIs. I think it’s more likely that they don’t really feel the sketchy parts are that sketchy.
Jeeze, so, haven’t really touched PHP since like 2003 so I don’t recall what the syntax for anything is, but just looking at the lambda syntax in that font, I couldn’t actually tell if that was
=>, or==>, or->, or even-->. I had to look at the source to figure out what it actually was.Ligatures. They’re awful.
It was primarily the APIs, not the language, that led me to give up PHP in disgust a long time ago (c.2006.) A lot of the APIs were badly designed in the first place, like the core ones that just aped C; many had “clever” features like magic parameter values that triggered special behavior, and some had weird changes in semantics between PHP versions. This made the APIs bristle with footguns, in my experience.
I’m surprised no one forked PHP and cleaned it up. You can’t beat PHP for web pages.
That happened! https://hacklang.org/
It seems like it’s mainly used at Facebook though …
PHP is bad for webpages because it’s not a suitable HTML templating language and it uses file based routing. A suitable templating language is safe by default. Even the cool new PHP things all end up using some other safer language for templating. File based routing can be okay if it’s smart routing, like there’s some parsing of route info, a la Next.js, but PHP file based routing is dumb URL → page and you need to use Apache or whatever to make the routing acceptable. I guess someone could fork PHP to fix those issues, but that would just be Laravel, no?
What PHP has going for it is that it is very easy to get something to production quickly. This is a very important quality, perhaps even the most important for many uses. Still, for most new users today my recommendation is to just make a static site and host it on Netlify so you can collect form inputs or use Airtable for forms.
In light of laravel and symfony I don’t think that is true at all.
Laravel has Blade, which is a superset of PHP because PHP is not a suitable templating language.
Symphony has https://github.com/symfony/templating which I guess is closer to pure PHP, but it sucks because you have to manually escape things.
FYI the templating URL you’re linking to is Symfony’s templating language framework, not something intended to be used as-is. The actual templating language symfony and Drupal use is Twig, which is escaped by default.
Thanks. I thought it was a mustache-like but Duck Duck Go failed me.
And laravel is totally fine for me, it’s not like people started inventing Mustache, jinja and frameworks like Vue,React etc out of fun.
Most serious projects use PHP frameworks that do not use file-based routing, it’s there at the lower level but that’s not really part of your development experience. You define routes very similar to the way you would in e.g. popular JavaScript frameworks.
That’s what I said.
I guess I’m not understanding your point on how PHP’s native routing makes it bad for web pages. I’m guessing I disagree with you on something here but I’m not even sure what that is :) File-based routing is fine for very simple sites, and if you’re doing something more complex you have a framework that gives you more power. Isn’t this exactly the same as HTML+JS? Web servers use file-based routing too (unless you’re doing something fancy with JS) so it’s not really a weakness of PHP, that’s just how the web works.
No, you want to separate routes from controllers in any kind of practical system. It doesn’t have to be a regex (although those are nice to have), but eg it should be easy to do /page/:id. In PHP, to do that, you have to leave PHP, go to your web server, configure that to send pages to index.php but include the original URL as a query parameter or something, go back to PHP and add code to unpack the information from the router, then do the actual routing. None of that is impossible, but it’s not the easy path, and the easy path should include /page/:id because that’s a minimum for a dynamic web server. If you only need static routing, just use a static site generator.
I agree with you, and there is a case here that PHP could have some native routing support that would make the framework implementations of this simpler. But I would still say, the process you describe doesn’t really matter as a PHP dev because all of that is invisible and handled for you by any popular framework (routes and controllers are decoupled). Stuff like /page/:id I’m pretty sure I’ve been able to manage just through mod_rewrite e.g. /foo/id/3 gets matched to foo.php?id=3 – although forgive me if PHP did require something to make that work and I just forgot, I haven’t needed to set that up in a long time.
Go back to the beginning:
The idea of this comment, as I understand it, is not “the PHP ecosystem is good” or “there are strong PHP frameworks”. It’s “PHP the language is really nice and convenient for making a dynamic website, and if someone could just go back and fix all the weird naming issues with the standard library, it would be perfect.” I disagree with that. My disagreement isn’t that good frameworks can’t be written in PHP. Laravel is very cool! It’s that the core language and standard library, even if you went back and fixed the inconsistent naming stuff, aren’t good enough to make a dynamic website for two reasons: 1. the templating is unsafe and you need Twig or something to fix it and 2. you need non-file based routing, or at least dynamic file routing, and to do that in PHP, you need to coordinate some hand off with your webserver.
I think I understand the point better, thank you for clarifying.
To that I would still say though, “good” must at some point be relative. Every language (that I’m aware of anyway) when used for the web, is primarily used with a framework. At least for any non-trivial project, which is arguably the use case that matters the most.
By the standard and reasoning I’m taking away from this criticism, there are /no/ languages that are good at dynamic websites because if they were, none of them would need frameworks. Express.js and Django exist because JavaScript and Python aren’t perfect for web apps out of the box. In that sense this criticism of PHP seems tautological.
Go’s standard library has an adequate templating library and router. It’s very common to use it without a “framework” although you will probably end up using some kind of third party packages for things like databases and sessions. I don’t think it’s unreasonable to think that “a cleaned up PHP” would come with a decent router and templating language.
How so? Most web frameworks have a templated language that is the same form as PHP (erb, etc).
Hm, what most web frameworks have server modules for Apache or nginx like php modules?
It would be cool if someone forked it to a very small binary with a very aggressive strip. With things like auto loading or even OOP support removed. Something that could be used to build quick and dirty web interfaces. Perhaps even in microcontrolers.
The template capabilities are still, IMO, the easiest to use of any template engine out there. Because they just use the language constructs the programmer already knows.