I used PHP again last year after almost a decade and it sucks less (a lot less!), but it still sucks.
Going from a language with a well organised stdlib with consistent syntax to php is not fun.
Sure, it has a lot of nice features now, and some of the footguns have been removed, but the core language is still there and it's still a mishmash with a bunch of hidden landmines.
> What do you mean you don't have every disjointed combination of needle, haystack memorized? ;p
This is one of the weakest, "not happening in reality" issue of PHP though. It's the most obvious, and the one who don't use php but glance at it point. But in the real world, any editor you use not only show it but also show a type error if you made a mistake, on top of that after a few hours you know which is which (yes strpos and in_array have an opposite haystack/needle, but each always use the same, once you use them more than 5 times you remember the same way you remember to check for 0 on strpos).
There are still flaws in the php world, but the one most commonly pointed out are always sounding funny to me because they're flaws if you show an exemple in a conversation but that you don't actually hit when coding.
Which is why it stops being an issue after, what, 2 days ? And most editor also have an autoswap feature for when you have a brain fart because since the language now had proper type hint there is no possibility to misplace a scalar and an array.
But you see other people just 'get it right' the first time every time without even having to use the language. They just 'know' everything up front, or... read it in a forum 8 years ago and it's perfectly crystalized. It's only the lowly PHP plebes who need an editor to help them get things right the first time. Syntax, method naming, parameter order, return values - these are 100% completely solved problems that never cause anyone ANY problems ever in any other language - this is 1100% a PHP-only problem. Can't you understand? The entire rest of the programming world is excellent except for PHP.
Yes... it's a bit /s, and perhaps is a bit much, but... this "my language has no defects!" attitude from everyone crapping on PHP is tiresome. I've been programming as a hobbyist since the 80s, and professionally since the early 90s. Nothing is perfect, everything has warts, the holy wars suck. I've been with PHP since early 96, and have worked in ASP, .NET, Python, Ruby, Java/JVM, Node/JS, and a couple other stacks. They all suck in more than a few ways.
For those of you who only ever work in one tech for years without needing to touch anything else... and get to perfect your parameter-order-fu down to a reflex... great. I'm routinely having to switch between different SQL and various server-side languages, and even then ... 'obvious' things like array/string handling have different syntaxes I have to jump between in a single day. (postgresql arrays are 1-based, not 0-based, IIRC). You know what? I deal with it and move on. IDEs/tools help. Memory helps. Nothing is perfect.
One somewhat famous hidden landmine is in_array('0010e2', ['1e3']);
And that will return true, because you forgot the third "strict" parameter. This is really something strict_types could/should have fixed, but it doesn't.
You can have code reviews and static analysers and all of that to catch this, but it's definitely a landmine. I've seen some pretty serious CVEs that were fixed just by adding that last parameter to some in_array() call.
But I didn't forget the third strict parameter, because I'm diligent in reading documentation and at my job.
Was that everything? You basically state there's a problem because you didn't use the function correctly and language didn't fall head over heels to stop you from doing silly things due to slopiness?
People forget this things all the time because people's brains don't work like Spock's brain. There are plenty of junior programmers around that will have to be taught this. It's a footgun. Is it manageable? Sure; I already said that. But that doesn't make it not a footgun. Anyone who says anything else is not serious.
Check this - if it's something important.. don't forget it and implement something called "function" that would pass the third parameter by default?
Anyone who is not capable of taking care of what you called footgun in a way where they automate - that person is not serious.
If there's a pretty huge problem - manage it. That's your job as programmer. If you're lazy, sloppy and prefer whining online over being proud of your work - there's no programming language that will take care of that for you.
No, it's not a function that causes it. It's the dev who is sloppy and causes issues. Would you blame the scalpel or brain surgeon for mishap while cutting important bits in the brain?
What kind of logic is this, to blame the tool because you have no clue how to use it?
That's a very good analogy because they had to stop using scalpels in brain surgery because the surgeons kept making mistakes.
Tools must be designed so that they're difficult to use incorrectly. That's why we have guards and interlocks on any tool more complicated than a shovel.
Function has 3 arguments. It's documented. Use cases are documented. You are trained. You ask for.. even more protection? From what? There's a limit to laziness, it takes more time to do this word-warrioring on HN than to learn how to use the function correctly and how to create a wrapper around it that serves as the protection you seek.
This really isn't that hard, we're not trying to travel to Mars.
Would you buy a car that explodes every time you start it unless you press the “don’t explode” button? And would you blame the people who get killed by this car for not reading the documentation?
You shouldn't trust him. He is sharing his experience with using the language.
I hate Rollercoasters, I hate surprises and strong emotions. So if you ask me how Disneyworld is, I'll tell you it sucked for me. But maybe you are onto that, so you shouldn't trust me.
Back yo PHP I've used it for super fast tiny dynamic websites, and it works wonders. I wouldn't do an online exchange with it though.
It's late Friday night so this what I really think of PHP: It is the purest form of web programming. You don't need a framework. Spin up a server and just start writing. Experiment. Do crazy things with it, like an art project. Every page is it's own world. Have fun with it. PHP is freedom.
There's nothing like being able to write backend code directly in HTML files, without even having to start a new server process. It's literally just a .php file executed and served to the user.
It starts as the ultimate anti-structure. Nothing, not even MVC. But then you can refactor parts out of it and start moving towards a structure. Very freeing if it's a small one-off page/project and you know what structure works for you.
(Of course, if you need a database and authentication and Scaling and so forth, that's when you start bringing in the heavy artillery (libraries and packages), or switch to a framework.)
I volunteered to help .netart artists in the early 2000's to get their code working. They were able to do some very creative things with PHP that I know they didn't have the coding skills to do otherwise. Like grabbing random images based on keyword searches from poems and creating montages with them. The industrial programmers would shudder in horror at the PHP code they wrote but it did the job. PHP is for the people. It'd be nice if the bureaucratic programmers would keep on making their proper factory factory singletons they learned at University without turning up their noses at PHP in their boxed world
I used PHP several years ago and are considering trying it again for my side hustles. You basically just push files to a folder and "forget about it"
It just keeps running and auto corrects any temporary load issues because of its stateless nature. I don't have to worry about memory leakage or processes that eventually become unresponsive and needs to be restarted. If the unlikely event that the PHP process crashes, it will just restart automatically and handle the next request as if nothing happened.
Its the ideal solution for side projects, and I am definitely going back now that I don't have time to maintain complicated infrastructure.
PHP was my generation's version of AWS stateless "lamda". Just place a file in the folder, and it will be executed on demand and clean up resources after the request has ended. A server could handle many different websites at the same time. That was basically how we could get cheap webhosting. They just put a bunch of Apache-instances behind a load balancer and used a shared network drive to read the files from
This is nothing to do with PHP the language. You can have an HTTP server and templating engine in any scripting language. It’s just the way that PHP is distributed is particularly easy. Someone could throw together a “PHPython” from existing components and get the same effect.
Yet, even with the actual deployment not being much different (just used Apache as an example here), there's still dependency management, which Python is often described to be pretty messy at, virtual environments or not. With PHP, most of the stuff you need for common use cases often is pre-installed and is just a matter of enabling some plugin in the config.
That said, I deploy most of my stuff in containers, so PHP, Python, Node, .NET, Java and others all become more alike when viewed from the outside.
Because it sucks! We tried it, it was bad, the Python community left it behind. Maybe if PHP left things that suck behind too then fewer people would say that PHP sucks.
The whole point of the parent comment was that it doesn't, at least when you want to be able to experiment and iterate quickly:
> It is the purest form of web programming. You don't need a framework. Spin up a server and just start writing. Experiment. Do crazy things with it, like an art project. Every page is it's own world. Have fun with it.
Why would that be a bad thing? Even when it comes to something like REPLs, everyone always touts being able to iterate more quickly as a good thing, don't they?
Edit: aside from the implications of an in process language runtime, that was discussed in another comment.
Why are you talking as if embedding server-side logic in HTML is necessary to experiment and iterate quickly? I can get up and running with a Python project in seconds and can iterate quickly with that.
“This is good because it enables you to iterate quickly” isn’t a good argument when you can iterate quickly regardless.
> Why are you talking as if embedding server-side logic in HTML is necessary to experiment and iterate quickly?
Necessary? Not quite.
But having those things be closer together leading to faster iteration? I'd argue that that's definitely true, same as how someone could skip out on writing a bunch of enterprise programming patterns, MVC or even tests, as well as use a language with a dynamic type system, or even write serverless functions. Not that any of that is very maintainable long term, but at the same time nobody would expect that from something that's very much like a REPL.
It's the same as how I like to have a clearly separated front end (typically a SPA) and a back end API (something RESTful) in most cases so that those technologies wouldn't be coupled and the API could be re-used as necessary, except that people who go for the various SSR and templating approaches typically code around me in circles, because they don't have to write as much API client code as I do.
> Because this method of deployment is not only unsafe but also doesn't scale.
How is a mainstream web server acting as a reverse proxy for an app server unsafe?
You get the benefits of one common approach to configuration, request logging (and possibly log shipping), rate limiting, compression, path rewriting and so on, while letting the app server handle the actual app and language runtime stuff (whether it's some Python app server, PHP, Java with Tomcat or whatever). You can even serve any static assets right there, alongside your API.
You can either include everything in a container, have separate containers for each process with overlay networking, or just have them run on the OS directly with only the web server binding to whatever ports you want to expose.
As for scaling, none of that prevents you from running anywhere between 1 or a million instances in parallel, with some load balancing (whether it's multiple servers or containers across a cluster). If it's really that bad, throw in HAProxy or something into the mix, alongside whatever cache solution tickles your fancy.
That's besides the point that I could provide a service to everyone in my country on a single rack (redundancy aside), not everyone even needs some mythical sky high scaling target.
> In the age of cloud, you just run your web application as its own server, a just have a proxy that fronts it.
Whether you use your own ingress (there's a lot of good ACME solutions out there) or something that your cloud provider gives you, using a server per app would in many cases be wasteful and there's a bunch of ways to increase the density, especially with the dynamic scheduling most container orchestrators could also give you.
mod_php runs in the same process as your http server, with the same rights. It's comically bad, especially in mutualized environments, and the reason why PHP is such a common target for hacks.
> mod_php runs in the same process as your http server, with the same rights.
mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.
Here's a very simple setup of two separate processes, with Supervisord (this is what runs in my self-contained dev container, but no reason why someone couldn't do something similar with systemd, or on a container cluster, with different users/permissions for each process):
> mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.
Or even simpler, just make your application listen to a particular port and implement a full HTTP server, and reverse proxy to that (or not) using whatever tech you fancy (Apache, nginx, Cloudflare, Cloudfront, ELB...)
This achieves the same thing while providing more control and layering standard protocols.
Oh but if your web server had PHP installed, it really was “easy” in a way that modern web programming is not. Yes, you could replicate it with Python, but actually you can’t, because no one has “thrown together” a PHPython. Nothing today can beat the feeling of being able to just drop a .php file in a directory and have an interactive, dynamic web page up and running
Exactly, I used to be much more productive when using PHP because I could simply write some code, put it in a folder and refresh the browser and it would work.
How do you go into production? You put the file in a folder on the Web server. It works everywhere the same.
The code writing part itself is very straightforward and there's nothing counterintuitive as long as you don't try to do something that it's not designed for.
>there's nothing counterintuitive as long as you don't try to do something that it's not designed for.
Maybe that's the key. Instead of trying to write programs with tools that are not made for this but are somehow bullied into doing it, just use the right tools.
For generating HTML based on a request and data in the database, PHP it is. Don't try to make a language made for DOM manipulation process data and generate HTML.
For Web UI, DOM + JS it is. Learn how browser works and write the JS that will modify the DOM as needed which will result in interactive UI. Don't stack abstraction.
> How do you go into production? You put the file in a folder on the Web server. It works everywhere the same.
Well, not really because you have this massive php.ini file with tons of settings and whatnot, and scripts not working due to that was always a common point of failure back when I was using PHP. Also: not having some extension, which are almost always in C and require server installation (which is quite different from many other languages, where the user can usually specify most or all of their dependencies).
Maybe all of this changed? I don't know. But PHP in general has been the most fickle and unreliable environments I've dealt with. Give me any random servers, and I find it very hard to tell if my PHP script will run.
Right but all that was handled with stuff like XAMPP or some server control panel because it was all straightforward and if you don't use control panel all you had to do was to edit some .ini file.
That's of course for singe server applications. However, because everything is straightforward and built for purpose and not trying to pretend being something else, more complex systems were still easy to setup and manage.
The joy of coding PHP usually died off with frameworks like Symfony where they built complex abstractions for the pleasure of the "Enterprise" projects with many moving parts.
That's all fine if you're the one in control of the servers, but in reality that's not always the case. And actually even if you're in control, it's just a huge bunch of moving parts that can (and do) fail.
I also have to say that php.ini is probably one reason PHP became so successful in the first place, by having things like safe_mode and such so it could be easily used on shared hosts with ease. All the $2/month shared hosts were offering PHP, not Perl or Python, because of this (and mod_php).
But other settings like that automatic $_GET/$_POST importing ... yeah, that was a lot more misguided. Even error_reporting really should never have been a system setting: always let the code handle these sort of things. And even safe_mode is mostly outdated and useless now, because no one is doing shared hosting any more.
Current cloud providers have very different execution environments; the typical shared webhost had one Apache process with mod_php and every account was just a different system account. What you needed as a hosting provider was a way of preventing file_get_contents("/home/someone-else/secret.txt"), which is what open_basedir gave you. And system(nefarious-stuff), which is what safe_mode gave you.
Today that sort of thing is very rare; you will run in a virtual machine or container, and have an execution environment all to yourself.
quite a lot of Wordpress setups run on sort of shared hostings to the date. Plesk and Cpanel are still a thing in this area. And Wordpress is still massive share of websites.
PHP-FPM which has options to specify system user per pool is basically how restrictions on file_get_contents are enforced.
Many other frameworks copied this approach from PHP.
For example, both ASP and ASP.NET can be developed using Notepad.exe directly on an IIS web server, and you can similarly test changes by simply refreshing your browser.
Personally I'm allergic to this style of development, the "banging on it with a rock until it starts moving" approach tends to result in poor outcomes over the long term.
I much prefer that a compiler go over the entire codebase and check everything when I hit the compile button.
Sadly, this bad habit from PHP still lingers in ASP.NET Core to this day, and causes me endless grief.
Just over the last couple of months, I have encountered the following:
- DEV, UAT, and PRD are out-of-sync with each other and the source code. When I asked the developers why that is, they said they make changes to individual files instead of "building the whole thing", because "that's faster". Okay, they saved the two minutes the pipeline takes to run, great. Now I have to spend a week disentangling the mess.
- I refactor something, hit build, it comes back with all green ticks, I deploy... and the site is broken with HTTP/500 a day later because these scripting-style frameworks don't build the page code until runtime.
- A security vulnerability code scanner was enabled, and it broke the build. Why? Because it actually builds the code, all of it! Except that these frameworks have two sets of page template files that contribute to the "final product": 1) the list of page templates registered with the build system or VS project file, and 2) the list of files physically in the Git repo. Some build steps consider only the former, the web server considers the latter. You can remove a page from a build system, and it'll remain working. It's like removing C code from Linux and still have it turn up in the kernel! That's nuts, and a security nightmare. Cough-xv-cough.
PS: It's possible for ASP.NET Core to be configured to both compile every page on publish and support hot-reload and automatically include every file in the build if it's physically in the folder structure. This really ought to be the default, but isn't... to pander to ex-PHP devs or something.
>I'm allergic to this style of development, the "banging on it with a rock until it starts moving" approach tends to result in poor outcomes over the long term.
I was sold on this too, that's why I left PHP for sexier stuff and never regained my productivity. As it turns out, most of the time I don't have a complete idea on what I'm doing but instead I have a direction and banging on it with a rock until it starts moving *in the right direction* is very productive because the design happens at the same time with the development.
My PHP code was complete "garbage" but it worked as expected and made me money and/or satisfaction of building things. Later I improved my coding skills and become much more aware of patterns and structures and found myself optimising the code instead of the product, destroying my productivity because as it turns out computers don't actually care or reward you for beautiful code. All that matter is, what that code is doing regarding the expectations of the humans who benefit from it.
I worked with PHP XX years ago, and we didn't have that problem. I think that once you have access to a machine, it will always be possible to make direct changes. It's just that PHP made it easier, and in some cases it was also acceptable that the prod environment was temporarily broken until the developer undid their changes. You would just mess up a single page (or route).
Example 1:
I developed internal tools on a single server. The way I would do it was to have a personal folder on the server that I could use for development. Then I would commit the files to CVS which was the used for "deployment" to the main "production" folder. This worked well for me.
Example 2:
We also had a customer facing website where this practice was not allowed. We had proper build pipelines that created RPM packages which was installed by hand on the production machines.
My point is that there were many ways of avoiding editing the files directly in "production", even back when PHP ruled the world.
“The problem didn’t happen to me” doesn’t mean the problem doesn’t occur. It’s like speeding.
PS: I saw a developer take out an 80K user enterprise because they tried to change the look and feel of a login page live on the prod server. They didn’t know any better because they were used to editing pages in live systems. That bad habit resulted in about a million dollars of lost work.
that shop could be using the latest academic language with full guarantee syntactic checks and perfect compiler and testing... you would still have the same problems.
Not an SQL injection, but I opened Google in a private browsing window, searched for “php mysql tutorial”, and it brought me to the W3Schools tutorial, which has multiple other vulnerabilities relating to how PHP just dumps its output into HTML unescaped without a second thought. At a glance, I see obvious XSS and open redirect vulnerabilities.
It’s the top hit for “PHP MySQL tutorial”. This is what PHP newbies are learning from.
The same tutorial with Django wouldn’t have the same problem because Django auto-escapes strings you dump into HTML. These vulnerabilities only exist in this tutorial because PHP treats its output as HTML by default not text, so you need to put in extra effort to be secure.
That are the top hit on Google for a common beginner query and contain multiple vulnerabilities caused by a flaw unique to the language?
And we aren’t talking about an article, we’re talking about a tutorial. There’s a very big difference between the two, why are you switching? Tutorials are obviously vastly more important to beginners.
Let me remind you of the context:
> > Mixing server side and front end code is bad news. I think following many PHP-MySql tutorials will result in SQL injection vulnerabilities. Not good.
> i think you'd have to go back at least a decade to find tutorials that bad
This is something that is harming people learning PHP today, not the distant past.
> The same tutorial with Django wouldn’t have the same problem because Django auto-escapes strings you dump into HTML. These vulnerabilities only exist in this tutorial because PHP treats its output as HTML by default not text, so you need to put in extra effort to be secure.
Python http.server isn't particularly secure by default.
I don't understand why you keep ruminating about Django, which is obviously irrelevant as a comparison. If you want to use Django as a point of comparison you'd need to compare with Laravel.
Laravel is how you learn web development with PHP. It's the Django equivalent.
You wrote something about how "people" do web development in Python, I don't see the relevance to your decrepit comparison.
Everyone that starts building computer network services is dangerous for about 5-10 years regardless of what tutorial material they initially come across. If not longer, since it takes a long time to internalise the protocols, client platforms, server platforms, relevant network layers, common threat vectors, and so on.
I still use php for random small scripting. Text processing, that sort of thing. Its great because you can iterate on the code on the command line and then if you want to use it again, slap some HTML around it and stick it on the server.
For the past few years I've been building a B2B SAAS. Naturally I've chosen my "get shit done" language PHP to do it. While the product itself is as boring as it gets, I've had stretches of good fun with it by building _everything_ myself.
Naturally the web frontend is written in PHP, so are the cronjobs, shell scripts, message queues, WebSocket server, client software, statistics and the server automation (think Ansible, but imperative). Sharing my own libraries between all these parts is extremely valuable. Owning the whole stack means I never have to deal with black boxes or fiddle with dependency management. The language just gets out of the way so you can solve your actual problems.
The fact that PHP is reasonably good at all these things is a big advantage. The performance is certainly good enough (never became a problem) and the long running server applications (e.g. the WebSocket servers) are rock solid.
Hell, in PHP 5 era and before, it even HAD to, PHP had been designed as "you get a brand new process every request" and so a lot of things with memory went wrong if you ran for too long.
This changed with PHP 7, some framework appeared to allow an event based system, and then PHP 8 (or a later minor update) added fibers to the core to support it more easily.
These day, event based php has several well supported frameworks, is stable and fast, and allows you to have the same codebase on your websocket or other event system as you use on the rest of your app (sharing libraries is super cool, using the same DTO on the sender and receiver also, etc ...)
Does it also run in the browser, so you can share type definitions and libraries and tools between client and server, and seamlessly perform isomorphic server side rendering?
If only there were a language that was as universally deployed and well supported and extremely optimized on both server AND client, and had all of the capabilities of PHP and many more...
Because today, using an anisomorphic language that can't run on both sides is like riding a bicycle with only one leg.
Oh I would agree but Javascript is anything BUT stable in its environnement and frameworks etc... Trying to update a one year old php code base with composer means no issue at the end in 99% of the time.
Oh don't worry, some day JavaScript will as stagnant as PHP, too. Just wait, time flies.
If it's a stable environment that runs old code you want, then if I had my way we'd all be programming interactive distributed network extensible web apps in PostScript instead of JavaScript, and that language has been stagnant for a much longer time than PHP has ever existed (13 years before PHP 1.0 was released in 1995), since you can still print and view all of your old PostScript documents from 1982, 42 years ago.
HyperMedia browser with embedded "applets" in PostScript:
It's definitely the only worthwhile or practical language for isomorphic web app development.
Of course you could choose to run a WASM PHP interpreter in the browser, but you be you.
Or you could petition all the browser vendors to support PHP directly. Get back to me on that when you've sorted it all out and resolved all the political and technological and economic issues, and also implemented a better framework than SvelteKit with it.
For me it's not what the language itself is like, but what's the average project I can end up working on. So PHP was magical when I was using it on my side projects, but as soon as I started commercial work on full blown projects with frameworks, it made me question my life choices. Lack of version control or test suites, editing files directly via FTP were common practices. Wordpress plugins that invited hackers to mess with your code. Maybe I was just too incompetent back then, but moving to Ruby saved me - for instance how much emphasis the community puts on writing testable code and testing it. Few years later I tried PHP again and it felt like Wild West compared to Ruby (that was 10 years ago). So while it may not suck anymore, it's not the case for all the legacy code out there.
This is awfully similar to how I feel about C# the language itself really feels like "improved Java" and making side projects was a joy. But, I realized that the vast majority of companies that use .NET are not tech first, meaning developers and software is a cost center, meaning there's little to no internal engineer culture or investment to the development department, and everyone just wants to "flip the burger and move on".
Well said! I once heard C# referred to as a “blue collar language”. Perhaps snarky, but it mirrors my experience.
There’s little in the way of fun in the ecosystem. Not a lot of true open source in the conventional sense, lots of Microsoft MVP consultant types with blogs promoting their services. Those websites look like time capsules from 2011. You won’t find many beautiful, “handcrafted” blogs on .NET topics. A perhaps bizarre metric, but it helped me well in gauging an ecosystem’s vibe (Rust, Go, Python and others pass that vibe check, for example).
Part of the problem - there's highly insufficient amount of bullying in the industry towards companies and decision makers that blindly pick Go as a language for e.g. yet another database or some other form of data-intensive application rather than C# which is what they actually should be choosing if they don't want to use Rust but still something that gives them performant and robust platform for systems programming.
Which is actually my main reason why I shill it here on HN - please, stop picking Go for the fun technical challenges. It's an exceedingly poor choice for that and you are making yourself a fool with it because you never looked at platform implementation details and capabilities to make an informed choice.
The "higher level managed Rust" you are looking for has always been C# even more so in the last couple of years due to proper low-level abstractions and performance it offers.
I actually find it amazing how much impact I can have coming back to PHP after half a decade of modern development practises at start-ups. I am introducing version control, CI/CD pipelines, testing, and am able to have real, tangible improvements as well as really help my fellow colleagues advance whereas working at a modern start-up is just infinite agile-scrum-waterfall meeting galore where years go by and I feel I achieved nothing.
This article focuses on added features, but although some of them may help, those features weren’t really the problem with PHP. I haven’t meaningfully used PHP since about 2010, but https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ generally rang true, and I get the impression that most of that is still valid (though some points have certainly been fixed).
It is hard to blame PHP for having been badly designed when... it wasn't "designed" to begin with. Rasmus Lerdorf had to following to say:
> 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.
some good usability points on method names, but the bulk is mostly complaints by someone clearly unable to understand webservers or security. complaining that error level hides errors from output is very amateur. also complaining about info missing from the manual in open source is silly. test the two failure cases and send a manual improvement patch, instead of being annoying and wasting more effort on a blog post
You’re looking at it too simply. These are complaints of an expert with broad experience across PHP and similar systems, who found a steady stream of problems wherever she looked. These are systemic issues. The foundations themselves are unsound, and that’s difficult to ever fix. I think the analogy is good to give a basic sense of all this. And then the remainder of the article was written in such specific and extensive detail deliberately to counter shallow dismissals like yours.
The main problem with PHP 5 was never the lack of features, but things like "there is no way I can get an error code from fopen()", and things like that. Can I now get EEXISTS and such out of fopen()? Looking at the docs it still just returns false and emits an uncatchable E_WARNING that can't be examined programmatically.
Having to write a bit more code because it doesn't have some feature is not ideal, but whatever. Not able to correctly race-free implement file access is a much bigger issue. I have some other gripes (which may or may not be fixed), but this was and remains my main one.
> Can I now get EEXISTS and such out of fopen()? Looking at the docs it still just returns false and emits an uncatchable E_WARNING that can't be examined programmatically.
Sure, the most straightforward way is to first use the "x" flag for write-only, and "x+" for read/write access.
$fp = fopen('file.txt', 'x+');
From the PHP docs:
"If the file already exists, the fopen() call will fail by returning false and generating an error of level E_WARNING. If the file does not exist, attempt to create it. This is equivalent to specifying O_EXCL|O_CREAT flags for the underlying open(2) system call."
And finally to convert E_WARNING errors to exceptions, use you can use set_error_handler() to throw an exception (and even write business logic to filter them): https://www.php.net/manual/en/language.exceptions.php
They're not unhandleable.
But if you want a single function that throws a specific exception when a file exists, specific to the behavior you want, I got you:
<?php
declare(strict_types=1);
namespace Argp242;
use function fopen as php_fopen;
function fopen(
string $filename,
string $mode,
bool $use_include_path = false,
$context = null
) {
if (file_exists($filename)) {
throw new \RuntimeException('E_EXISTS');
}
return php_fopen($filename, $mode, $use_include_path, $context);
}
To run this code from outside a namespace, simply:
There are tons of reasons an fopen() call can fail and sometimes you really want to know why; these pokemon exceptions don't give me that. And your code is racy as files can be created in-between the file_exists() and fopen() calls. Yes, this happens, and in some cases it's a security problem (which is why you need to use mkstemp and not mktemp in C).
The core of PHP is very close to the libc function it offers, and so you will do that in a similar way that you do that in C : call error_get_last(), which gives you the details of the last error.
This absolutely will happen, and most likely the other process is also PHP. The most obvious example is caching anything to a file. I don't hate PHP though, I just don't feel the need to convince myself it couldn't be improved.
A lot of PHP usage is inherently multi-process; 100 users accessing your PHP app are essentially 100 processes, often with a few of them running in parallel. Doing any sort of file i/o really does require thinking about these sort of things, and it's something I've run into.
And this is not exactly a huge ask, or a very obscure function call. You can kind of work around all of this if you're careful, but it's not exactly brilliant is it? Literally every other mainstream language can do this. This is really a "only in PHP" type of thing.
Just say "yeah, this is still a downside of PHP; hopefully it will get improve one day!" Fine. Fair enough. No language is perfect and I'm not here to bash PHP. I consider this to be a major pain point, but other people do other things and maybe it's less of an issue for them. Also fine. What I don't get are these contortionist tricks – I already knew how this would go when I posted it: first there would be the "but you can do this", and then when mentioned that's not really sufficient the "yes but you don't need that anyway".
We ran several quite popular (millions of monthly users) PHP websites for almost two decades and never ran into any issues of this nature, including a lot of local on-server file I/O. I don't recall doing anything specific or particularly advanced to deal with these issues, just some basic encapsulation was enough and it worked seamlessly.
If you change the behavior of fopen() by installing an error handler that throws an exception, won't that mess up library code that doesn't expect that behavior? Seems hacky and error prone to me. (Also the race condition others already mentioned!)
The old core of PHP is very close to the libc function it offers, and so you will do that in a similar way that you do that in C : call error_get_last(), which gives you the details of the last error.
How do I do "errno == EXISTS" like in C? This is bit I need. The issue for this was closed as essentially as wontfix: https://bugs.php.net/bug.php?id=49396
How do I test if this is EEXISTS and not, say, a full disk? Or too many symlinks? Or something else? Because last time I check it's not really possible, but maybe this has changed?
The problem is that you're trying to use PHP as if it's a different language.
If I have to deal with files, I'll create a class and I'll combine functions file_exists, is_file, is_writable, file_get_contents, file_put_contents (and new fsync) in conjunction with stream_context_create. I can even get the errors that OS spits out and test for what exactly went wrong, but you obviously ignored that and gave up. I can tell you used the language sporadically, not professionally.
You're taking a small, localized issue that arose, while your job as programmer is to get around idiosyncrasies in programming languages with the focus on achieving the end goal.
I've a list of terrible things that PHP does but I have one for JS/TypeScript/Go/Rust/<you name it>.
My job is to know these and achieve goals, not to criticize languages because file handling in it is not the same as in C++ and language didn't fire up 50 AWS instances to spam X.com with messages in hopes that I somehow notice them.
> I can even get the errors that OS spits out and test for what exactly went wrong
Coolio, so how do you do this?
I spent several years full-time working with PHP. I ran in to this several times. It's not a small issue. And my entire point is I can't work around it, because as near as I can tell, it just doesn't offer me the required primitives. That was certainly the case when I last looked at this, but that was a long time ago so maybe things changed?
Agreed and just to be clear, fopen() returns false if an error happens. If you don't check your return values, it's not on php, you're just not very good at your job.
One of the issues I have with "languages that don't suck anymore" is that, even after the language gets all the cool new features, you'll still end up having to use some libraries targeting old versions.
So you end up having to choose between stable libraries in the old style or experimental modern libraries.
While some features can be retrofitted to work with old code (e.g. Java 8's SAMs were smart a way for old libraries to support the new lambdas), in a lot of situations you'll have to wait years for the stable libraries to support the new features.
Having said that, it's nice to see PHP catching up. I haven't used it in a long time, but I like to check the changelog once in a while.
It really doesn't apply with PHP though. I mean that.
Nowaday you use composer so your versionning and compatibility is done for you, everything is made out of libraries instead of monolithic bloc, and no major libraries use anything below PHP 7.X
I don't think you can find any sort-of-major library that doesn't work on PHP 8, nor anything with any kind of serious usage that isn't working on PHP 7. That's sort of the point of PHP making sure backward compatibility remains.
And if you mean "but my code can't use the good stuff", actually nothing stops it, even the type system stictness is decided caller side, specifically to avoid the issue you mention.
> One of the issues I have with "languages that don't suck anymore" is that, even after the language gets all the cool new features, you'll still end up having to use some libraries targeting old versions
Can you name any PHP libraries that don't support the latest version, that you wanted to use, and held you back from upgrading?
The article would be a lot better with examples - PHP has (had?) a history of implementing good features in very un-ergonomic ways (classes/namespaces). It'd help to demonstrate that all these improvements aren't like that.
Latest code sample is at the bottom, covers a single specific use case (DTO) and it's still old as last update is november 2022.
PHP in general has managed to had great feature while cleaning up and keeping true to its mantra of "it should be simple and easy".
Modern PHP is super fun to use, and whether you like the verbosity and completeness of symfony, the "take a shortcut around the things you don't care so you can focus on your stuff" of laravel, the event based system of swoole or similar, the microframework like slim or just raw php, it's hard not to find a shoe that fit.
What's notably funny is how they managed to do that without breaking bc, and how that is perceived highly depend on who is reading. Take switch(). The original php version of it is rather terrible in what it does in term of "programming language correctness", but it worked and had its use. At the same time, a clean one that did what was needed was really wanted.
So instead of breaking every single software out there, making wordpress and company stuck on old version forever, they added a match(), which is a bit different and much cleaner. It's not really "the broken one and the good one", as their feature is different, but it's obvious that people who look for something bad will see that as terrible. In reality, you mostly don't use switch() in new code, but its behavior is fully described and documented.
PHP is awesome if you're a pragmatic engineer who just wants to get things done, and with things like Laravel Octane, it's also a decent solution for high performance applications now, something it historically wasn't good at. That said, if you only care about the elegance of your code, refer to it as "prose" and instead of making solutions prefer to wrangle ideologies, then PHP is most definitely not for you.
After having been in an abusive relationship for a while, and having liberated yourself from it, I imagine a lot of folks wouldn't go back, even if that other person has presumably improved their ways...
I recently had to work on a large php project with mixed all and new php; it’s very refreshing vs node/react etc. Enough to make me wonder about the choices I made in my work life.
I started with php when it was still a perl script and did it professionally for 10 years after that.
After 6 years of Clojure, I went back to PHP because it now has type safety and an amazing ecosystem of high quality libraries, allowing me to be very performant in my work. But then again, I was never in a abusive relationship because back when I did PHP, I didn't really know any better, so it was totally fine.
PHP has experienced a 400% performance increase between 5.6 and 7, and another 20% between 7 and 8. It's fast enough for most use cases, and if you need a specialized use case, use a specialized language."
Or you pay 5 Dollars a month for some good old shared hosting, upload you php files and be done with it. Save big money not even having to worry about all the DevOps stuff.
PHP is amazing for small and medium sized companies that just need to get stuff done.
Java is better than Javascript, I'm mystified. I have used Java and Javascript lambdas, the Java ones use 4 times the memory of the JS lambdas and are slower, to do the same thing.
If you want to be pedantic then multi-byte string !== UTF-8 support. ;)
Consider the intended purpose of the language and then consider whether the abstraction offered is appropriate. IMO in the case of PHP and UTF-8 it is not.
In my specific case it made my job harder than I would like on 2 projects I used PHP for, which is why I am complaining.
While proper description is linked already in neighbouring comment.
TLDR: in 2024 with PHP8 you still need mbstring extension and also you should be careful around UTF-8 if you do any text processing. In almost all other modern programming languages it's just works.
I don't think that's a pain. It's making explicit what should be explicit and the decoded string doesn't have an encoding attached (like in Ruby), it can't be in an unexpected format, it's always UTF-16. One can argue about weather UTF-16 is the best choice, but at least it's always that and always Unicode. No surprises.
They're UTF-16, and substr(), length, etc, work at the code unit level. Hence, the above isn't actually valid for all strings - any characters that are represented by codepoints between U+10000 and U+10FFFF require 2 code units [1]. For example U+10429 Deseret Small Letter Long E [2]
I think the proper way to do it is to have a string type and a byte-array type, like many other languages do it (not Ruby, that's a mess, too, if you ask me). The string type is always Unicode, can be any kind of UTF encoding in the background, that's an implementation detail. Sadly most languages still require you to know that detail.
It just happened to end up that way because Rasmus Lerdorf just doesn't give a shit. ¯\_(ツ)_/¯
And I've written and maintained lots of PHP code for decades, so I know from first hand experience what its problems are, and I'm not just complaining about something I've never used. And I keep receipts.
>"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
The point of the quote is not about abstract methods and properties, it's about a culture of 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." -Rasmus Lerdorf
>"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." -Rasmus Lerdorf
>"I do care about memory leaks but I still don't find programming enjoyable." -Rasmus Lerdorf
>"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." -Rasmus Lerdorf
>"I was really, really bad at writing parsers. I still am really bad at writing parsers." -Rasmus Lerdorf
>"I really don't like programming. I built this tool to program less so that I could just reuse code." -Rasmus Lerdorf
>"I actually hate programming, but I love solving problems." -Rasmus Lerdorf
>"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 :)" -Rasmus Lerdorf
And who remembers how careless, reckless, and blithe he was with the PHP 5.3.7 release he didn't bother to test because running tests was too much of a hassle because there were already so many test failures that wading through them all to see if there were any new ones was just too much to ask of him, the leader of the widely used project, in charge of cutting releases?
>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 (when he says that repeatedly, you should believe him!), and his lack of giving a shit about things like tests and encryption and security 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.
And don't even get me started about mysql_real_escape_string! It has the word "real" in it. I mean, come on, who would ever name a function "real", and why?
That implies the existence of a not-so-real mysql escape string function. Why didn't they simply FIX the gaping security hole in the not-so-real mysql escape string function, instead of maintaining one that was real that you should use, and one that was not so real that you should definitely not use, in the name of backwards compatibility?
Or were there actually people out there using the non-real mysql escape string function, and they didn't want to ruffle their feathers by forcing those people with code that had a security hole so big you could fly a space shuttle through to fix their gaping security holes?
The name of the function "mysql_real_escape_string" says all you need to know about the culture and carelessness and lack of security consciousness of the PHP community.
Melania Trump's "I REALLY DON'T CARE DO U?" nihilistic fashion statement sums up Rasmus Lerdorf's and the PHP community's attitude towards security, software quality, programming, standards, computer science, and unit tests.
I know it feels tired to dunk on things like this, but I feel like this is the “original sin” of PHP. Lerdorf built a language for himself, it appealed to other developers with this attitude, and eventually they became the people driving the language forward, propagating the problem into the future. Pretty much everything people dislike about PHP today can be traced back to this mentality.
> And don't even get me started about mysql_real_escape_string! It has the word "real" in it. I mean, come on, who would ever name a function "real", and why?
> [...]
> The name of the function "mysql_real_escape_string" says all you need to know about the culture and carelessness and lack of security consciousness of the PHP community.
The reasoning for this boils down to historic reasons and backwards compatibility. And the naming here isn't even PHP's fault at all, so maybe rethink your rant a bit!
Correctly escaping a bind variable string in MySQL depends on the connection's character set, since a few rarely-used character sets involve more complexity with escaping. But full support for character sets wasn't added to MySQL until version 4.1, released 20 years ago in 2004.
So prior to that, in the MySQL C client API, you could safely escape strings using the mysql_escape_string C function. But after connection-level character sets were added, this was no longer sufficient. And you can't change the function signature in a widely-used C library without breaking all prior users of the library. So the MySQL C client API introduced mysql_real_escape_string to solve this, which takes a connection pointer as its first parameter, and then deprecated the old mysql_escape_string at the same time.
So then PHP added their mysql_real_escape_string to match this, and deprecated the old mysql_escape_string, but did not remove it because it would break all old programs. And at the time two decades ago, this actually made sense! Many of those old programs were still using pre-4.1 MySQL (since 4.1 was still brand new), in which case the old mysql_escape_string was still perfectly secure, since connections didn't have character sets.
Today it's clear that both PHP and MySQL should have acted more aggressively to remove the deprecated connectionless mysql_escape_string shortly after this all happened. But from my memory, the industry's views on security vs backwards compatibility were quite different 20 years ago than they are today.
Thanks! I should add a disclaimer that I was writing it from memory, as a random programmer who started using PHP 4 and MySQL 3.23 in 2003, i.e. I wasn't a direct contributor to the language or database.
After further reflection, some of the fine details in my comment above may be off. I vaguely remember MySQL having a single server-wide (I believe?) configurable charset option before MySQL 4.1, so it's likely the MySQL C client library API gained mysql_real_escape_string earlier than 4.1.
Anyway though the broad point remains -- PHP didn't pick the "real_" naming, MySQL did; and the reason for MySQL's API there makes more sense in the historical context of expanding charset support, and needing a different C function signature to accept a connection arg.
And fwiw I do agree that "real" is a rather poor choice for this sort of API naming, but I assume the MySQL folks just went with that to avoid an excessively-long function name... also the developers of MySQL weren't native English speakers. Anyway, hindsight is 20/20 and all that.
I had the misfortune of having to use PHP again last year for six months, after not having used it in more than a decade. My opinion is that while it certainly has improved in some aspects, it still sucks very much.
I used to use PHP all the time. It really was revelatory when it came out.
This article is a little short on explanations or examples, though, so it’s hard to even really know what a lot of this is about, but it sounds mostly like syntax refinements and a few new language features. Which is great. Between that and the performance improvements, I’m glad to hear that PHP is still alive and well.
All that said, my memory of why PHP got such a bad rep was not so much the language itself, but the truly dangerous defaults, magically populated variables and more, that were so embedded into the usage of the language that for years, the maintainers were reluctant to make the necessary breaking changes to address the risks. Those issues drove far more people away—to the emerging frameworks like Rails and Django or all the way to Java or .NET—than the lack of named parameters or the need for the ‘array’ keyword.
It's the opposite: "professional" php sucks now, with all this overengineering and developers constantly trying to prove how PHP doesn't suck by adding new complexity. "Look, I've overengineered it to death! It's possible in PHP so now you can't say it sucks"
I've migrated code to PHP 8 last year. It is not as bad as it used to be but it is still a lot worse than most languages. Meanwhile it left behind its fortes as quick an dirty hack language, and traded it for being a very bad pseudo java.
I don't doubt that php will be with us for many years so any improvements are great.
Personally prefer to use a language like python that has depth of libraries and also useful for non web based apps.
The extension system allows you to interface with pretty much anything you could compile on the same machine. For quick development of wrappers or whatever, take a look at https://zephir-lang.com/en .
Every argument like this that just focuses on the language features and performance completely misses the point.
When I hear people expressing that PHP "sucks", that's mostly coupled to the ecosystem, not necessarily the language itself. Yes, the biggest warts in the language might be non-issues now if you write 100% of your code yourself, but the ecosystem is the same as it ever was.
PHPs utilitarianism is its biggest strength but also its biggest weakness when it comes to its libraries. Packagist is mostly a graveyard of libraries that people have coded up for their exact niche use-case 8 years ago (with no updates since), with little flexiblity beyond that (like you would see for libraries in other ecosystems).
The popular frameworks (mainly the CMSs, but also some of the MVC ones) suffer from a similar fate: Great if you want to hack something up quickly or do a small extension to it, but full of footguns and lacking in developer tooling.
In my few years of experience, the language is not too bad but the ecosystem, job market, and dare I say the self-considered experts who specialize in it, are difficult to tolerate for long. It's great the performance is improving, but there continue to be questionable design decisions in the language, as well as accepted standard practices and libraries.
> if you write 100% of your code yourself
The only way I was able to tolerate it is by carving out my own little world, and being very conservative with any external dependencies. Come to think of it, this approach has worked well for me with other languages but not to this extreme where I consider it a hostile environment.
The problem is that PHP still has no credible competition whatsoever in core use cases like "take an HTML document and replace static part with something fetched from a database", or "take multiple HTML documents and factor out a common structure that you might want to change everywhere at once later". Of course there exist solutions in "modern, well-designed languages" for these, but I will confidently take a challenge from any node.js, Elixir or Ruby developer on who can get it done faster.
Sophistry about how my solution won't scale to a million users per day or I should have used their framework from the start rather than having a bunch of HTML files won't matter to me nor the <10k people I expect on my website. In many cases, modern languages and frameworks drive adoption for themselves by tricking you into solving a problem that is not actually the problem you have, but they happen to be adapted to.
> Packagist is mostly a graveyard of libraries that people have coded up for their exact niche use-case 8 years ago (with no updates since), with little flexiblity beyond that (like you would see for libraries in other ecosystems).
Could you provide some examples? I wrote a lot of PHP libraries over the years, and while some are definitely stale because nobody uses them (and thus I have no incentive to keep the lights on), the only time I see dead packages, they're actually forks of other open source software that people contributed exactly one commit to (to change the package name).
Why is that a problem? I have always considered it as something of a feature. I guess at massive scale it might be a hassle but are there other reasons?
No matter what PHP project I worked on, it was always a mess. Unreadable mess of HTML, PHP and SQL all of them intermixed in one file. Instead of templates, there's a line of PHP, line of HTML, line of PHP again. Instead of using SQL placeholders, there's usually string interpolation. Lots of copy paste, I've seen a commercial PHP project, that was sold for around ~200 EUR, that had almost no functions: every repeating part of functionality was copy pasted 3-10 times.
All the PHP projects I've seen, eventually failed and had to be rewritten in another language. It was impossible to add new features and fix bugs in such a code. For example, if the original code uses copy paste instead of functions (and it is very often the case for PHP code), you'd have to fix every bug 3-5 times (most of the time, you fix it in one place and only after deployment realize, that the bug still manifests itself in 2-4 other places).
Yeah, maybe PHP is very easy to write and deploy, but this simplicity somehow makes bad programmer out of the person writing in PHP. I know, it's very subjective, but I had such a negative experience that I gave myself a promise to avoid PHP related jobs at all costs.
Also, maybe it was slightly more difficult to use other languages for web development 20 years ago. You'd have to use CGI, or set up some mod_python with all of its quirks, but those times are long gone. It's almost as easy now to develop/deploy Web apps in any other language.
I like it. I returned to PHP after nearly a decade and with Laravel I’m able to ship products really quickly.
Laravel’s collections fix my syntactic issues with PHP arrays.
My only complaint is that type checking is performed at runtime, so if you forget to mark a field as optional you get a type error even if you account for the nullref in your code.
I kept hearing these "PHP doesn't suck anymore" sentiments so in 2019, I started a new project in PHP. I read all the modern books, followed all the recent best practises, used all the sane configuration...
...and PHP still kinda sucked. Maybe it has improved between 2021 (when I last committed to that new project) and 2024, but I'm skeptical.
It was a huge disappointment to me because I really want PHP to be nice. PHP was the second language I learned for bigger projects after Perl, so some part of it still feels like home and evokes a beautiful naive feeling towards programming in me.
Alas, I'm unlikely to try it again in the next decade. I suspect it's slowly catching up to other languages, but at this rate I think more than a few years are needed until parity.
Me from 2013 when I've left PHP for Ruby would definitely be in awe. Today, not using Ruby for 5 years now, it's "meh". With the utmost respect to the effort of everyone involved.
It's a better language. Better performance, better typing, better syntax, and so on.
Build an application in Python, then as soon as it becomes pushed by load you're going to need a rewrite. A few small load balancers and virtual web servers doing PHP can handle tens of thousands of requests per second, the database is almost guaranteed to be the bottleneck.
Python is a (according to some) nicer bash, it's not a good alternative for implementing non-trivial systems and web services.
As a longtime PHP developer, my opinion differs from yours regarding PHP vs. Python syntax.
Python took some getting used to, but the more I used it the more strongly I began preferring its lack of things like curly braces, semicolons, even parenthesis in some cases. Because of that, python feels more concise, human-readable, and more efficient to write, than PHP.
I like both languages, and still rely on PHP for a lot of web work, but for data science or ML I do end up enjoying my time with python.
Sorry, I'm not keen on measuring excellence by polling web search engines. Is this how you choose what web pages to visit? You grab a top five from somewhere and only use those, except when you drop by here?
I'm more interested in your claim about "usable for any application". How come all those fancy ML types and learned academics refuse to use Python for the core computations they perform when they try to invent witchcrafts, instead opting for C, C++ and Fortran libraries?
Sometimes the algolians are called general-purpose programming languages, as opposed to SQL, functional programming languages, logic programming, and so on. Sometimes anything it's used as an opposite to domain-specific languages.
I’ve been hearing “Yes, PHP used to suck but it’s good now!” after every major release since v4. And even after minor releases during v5!
Yes, PHP 3 sucked, but PHP 4 is good now!
Yes, PHP 4 sucked, but PHP 5 is good now!
Yes, PHP 5.0 sucked, but PHP 5.3 is good now!
Yes, PHP 5.3 sucked, but PHP 5.5 is good now!
Let’s not talk about PHP 6!
Yes, PHP 5 sucked, but PHP 7 is good now!
Every so often I have to deal with some PHP code, and every time I see that, no, it’s still just the boy who cried wolf. It seems like PHP fans are all too happy to agree with the people saying PHP sucks… as long as it’s not the latest version. And suddenly they can see that version’s faults… as soon as a new version is released that they can tell people doesn’t suck. Maybe if PHP fans hadn’t spent the last two decades telling people PHP didn’t suck when it most obviously did, people would be more inclined to listen today.
People focus too much on syntax. I have worked with PHP professionally and I have to grant those folks that they got genuinely good libraries and frameworks. But coming from Java, I always found that you are ultimately boxed into a corner.
It surface seems productive and shiny and for 90% of use-cases you get the job done quickly. But for those other 10% you realize that at its center lies a rotten heart, wired together with duct tape. Syntax is not the problem. Horrendous stdlib and IO interop is what keeps it a mess.
Once you try to do anything more sophisticated you realize its many sharp angles which don't make sense. Such as call-by-reference only working 2 recursions deep. Silently failing when opening files which are too large. Arbitrary decisions and namings on stdlib. The hassle of debugging your program.
Or an ongoing struggle in my old company: Wanting to set up old PHP projects and realizing that your package manager doesn't have them anymore.
When it coems to running different PHP versions, modern PHP development has largely moved to using Docker (ddev, for example: https://ddev.com/) for that, and there's plenty Docker images for old PHP versions so it's a non-issue. I'd also imagine it be difficult to get many other outdated programming languages via a package manager.
There's now the PHP Foundation, which while relatively new in its formation, has significantly boosted PHP development and I'd recommend donating if improving the language is important to you.
Makes sense to use docker. I hope my old company is going with the time by now as well. The problem has always been supporting and updating old applications which you are still contractually obligated in supporting. Bringing them up to speed has always been a struggle. Both, programatically and economically.
> I'd recommend donating if improving the language is important to you.
> Such as call-by-reference only working 2 recursions deep.
Which smells like an anti-pattern to me. Blaming bad code on the language is one way to deal with it.
> Arbitrary decisions and namings on stdlib.
This is absolutely true and even more annoying I find that the ordering of stdlib arguments is inconsistent. Backwards-compatibility is one of the reasons this has not changed, I guess.
What I don't understand is, why people don't apply that same legitimate criticism to python. I recently had to do a project in python and was astounded by the amount of arbitrary namings and design choices.
I also agree that many php codebases, especially if not written in a good framework, are a hot mess.
That being said, the ecosystem if using decent frameworks with php 8+ versions very productive in terms of time vs results and a joy to work with.
> What I don't understand is, why people don't apply that same legitimate criticism to python. I recently had to do a project in python and was astounded by the amount of arbitrary namings and design choices.
I absolutely do. I appreciate the PHP community for having expertise in actually creating sane tools attempting to do a good job. But Python is just batshit crazy with some of the most wild bugs I have seen and no guardrails whatsoever.
Out of all the languages which got a type-system after the fact, PHP is the best one hands down. Runtime-validation of types + non-null by default keeps some of the bad stuff inside Pandora's box.
> Which smells like an anti-pattern to me. Blaming bad code on the language is one way to deal with it.
It was a simple recursive algorithm which we used to make some custom-highlighting on a few select words (much easier to understand than an equivalent iterative approach). But I wasted a good day until I saw that there was a technological limitation which made the algorithm fall apart, and not the logic itself. That's a quite offputting smell.
Of course I understand the economic choice behind PHP... finding PHP programmers is cheaper than going C# or Java. But having a good background in parallelism and having a good grasp on efficient CPU/JVM usage PHP doesn't provide anything unique. Everything it provides, I can achieve equally fast in other established languages, while posing an actual problem when technological limits are reached.
What I find most important recently is at least getting to do something, being busy sort of. After all, definitively, there will not be a language which satisfies everyone. So, your negativity might be the source of motivation keeping you up to do something involving... php. At least be busy developing, complaining not a good sport.
Then the whole "everything is output unless in the php tag" seems to be never used anymore.
I can't see why anyone would choose to start a new project in it.
No ROI for me. Got other stacks for the backend and ‘just ftp it’ realistically isn’t a deployment option anymore unless you’re a single man Wordpress shop or whatever.
Going from a language with a well organised stdlib with consistent syntax to php is not fun.
Sure, it has a lot of nice features now, and some of the footguns have been removed, but the core language is still there and it's still a mishmash with a bunch of hidden landmines.