Apologies! I think I might have a found an eager redirect on the server. I haven't been able to reproduce, but you're not the first to report it. I hope it's fixed now.
Easily one of the worst UI's I've seen since 2020.
Timing the initial in/exhales is tricky, because the circle contracts, not to its center, but to a nearly invisible (on my screen at least) smaller circle in the middle. No visible counters.
After a while, it just says "Hold". No indication that we're done. And I sit there, almost dying for 2 minutes before realizing, that it's done some kind of quiet-quitting routine on me.
Yes, apologies, the centre circle colour scheme was a terrible choice. I've changed it to something more visible. It looked like network errors were blocking the main thread so to speak, that shouldn't be an issue anymore.
I'm glad it's only the worse you have seen since 2020 though, I take that a little as a compliment because frontend design is not my strong point. This is just a fun little thing I made to help me relax before meetings etc.
I'm glad you're taking my feedback in stride. To be honest I regretted the harsh tone as soon as I hit submit. Can I blame it on oxygen deprivation? :)
Really great work, I liked the video, even had a good laugh. But I was surprised to learn that it would cost 1000$ to make something which is still... very clearly artificial.
1. That thing point out every weird thing you can do in PHP without pointing out that in reality one does not do such things.
2. You are could replace every instance of "php"!in that text with "Javascript" and it would be about equally true: some things more, some things less, but in general they are equally bad. Doesn't prevent people from making great things with both.
Almost anything ist noch longer true. PHP has a very strong backward compatibility. Migrating from one mayor release to another mostly is possible without touching your code. But you can also start new and work with very modern language features
This was about PHP 4/5 -- we are currently on PHP 8. I wouldn't even bother reading it, and some syntax there is not used in modern PHP.
PHP still has its warts -- like any language -- but with IDEs (which weren't around in 2012) and modern frameworks, you don't run into them very often.
60% true still. Most of the issues are in "wontfix" mode. I have seen this article so many times, and its still relevant, even a decade has passed. Make you wonder what the hell php devs are really doing?
Relevant in what way? Relevant as in they are factual or relevant to the day to day of a real PHP developer, because I can tell you the latter didn't hold up even when this was written.
> even a decade has passed
We got more optional typing and better error handling, and I'm still able to run the awful code I have written a decade ago.
Java is an almost 30 year old language and I can still do this:
Last time i looked PHP still had no generics, and the "typesystem" is mostly a joke. All the builtin functions still have no namespaces, and no forced types. PHP still coerces strings to ints and vice versa. PHP still has serious bugs with its (only) collection, the frankenstein ARRAY. IIRC doing a array_filter is still broken on PHP8 for key val arrays. PHP still had no unicode in 2023, im not sure how the latest version fixed this or not. IIRC you had to use the weird mb_real functions to get anything closely functional, and it was a mess.
> Last time i looked PHP still had no generics, and the "typesystem" is mostly a joke.
So is Python's yet the language is enjoying great success.
> All the builtin functions still have no namespaces, and no forced types.
And no PHP developer cares, because neither does C and yet it's doing just fine.
> PHP still coerces strings to ints and vice versa.
Which is great for beginners, because they don't need to worry about it, unlike me when I program in Rust and have to deal with 8+ number types.
> PHP still has serious bugs with its (only) collection, the frankenstein ARRAY.
So does JavaScript, yet it's not enough to stop the language.
> IIRC doing a array_filter is still broken on PHP8 for key val arrays.
There is some odd behavior if you try to do certain things in a functional style that is actually true.
> PHP still had no unicode in 2023, im not sure how the latest version fixed this or not. IIRC you had to use the weird mb_real functions to get anything closely functional, and it was a mess.
That can get annoying in some use cases, I have developed many international web apps in PHP, it rarely got in my way, but I do acknowledge that it's not great to not have Unicode by default, I suspect they are afraid to resolve this after seeing what happened with Python 3.
Yeah that's ugly, but it doesn't really matter. What is worse is inconsistencies when declaring class vars and constants... But you learn to live with it.
Luckily PHP pop has declined drastically since 2010. Its barely holding on as a top10 language. We can all hope it dies some day. We need better and faster software, realtime and unicode aware. We dont need more php.
Real numbers is hard to measure with PHP. This is because of the weird world of CMS systems (like wordpress). From all PHP code out there WordPress is most likely taking 80% of all the online deployments. So is it really PHP anymore? Its just a UI you click, drag and drop and customize. You dont even have to touch any code.
IF this is the measure, why not count PHP as C, as its written in C?
I stil argue that a single javascript library (jQuery) is MORE popular in 2025 than all PHP installations combined. Take that for scale. Now add all javascript (non compiled) and it trumps PHP by a factor of 100.
A lot of the points were bad even when this was written for example "A language must be consistent." is probably not true for any of the top 10 languages.
> PHP is inconsistent: strpos, str_rot13
I used PHP for two decades and the naming issues while being annoying didn't really bother me in real life, nobody would tell you not to use C because you have 10 bad implementations of the same string method with weird names.
> Side observation: I loooove Python. I will also happily talk your ear off complaining about it, if you really want me to. I don’t claim it’s perfect; I’ve just weighed its benefits against its problems and concluded it’s the best fit for things I want to do.
You should check out the moment you reach this paragraph because Python has similar and sometimes worse developer experience issues.
> There’s no clear design philosophy. Early PHP was inspired by Perl; the huge stdlib with “out” params is from C; the OO parts are designed like C++ and Java.
Exactly, the language has a lot of old cruft, just like most old languages, but that does not matter, what matters is how well you can use it to build something useful today.
> There is no threading support whatsoever.
Neither in JavaScript and nobody developing JavaScript is missing horrors of threads, if you need that level of performance, there are more suitable languages out there.
> In PHP, these functions return false. If you use FALSE as an index, or do much of anything with it except compare with ===, PHP will silently convert it to 0 for you.
Just like in JavaScript, yet people are still able to build big things.
> There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.
This is coming from someone who loves Python.
> PHP is dynamically-typed, so variables generally have no type… except references, which adorn function definitions, variable syntax, and assignment.
Not true anymore.
> Constructs
Full of nitpicks and statements that are wrong or don't mean anything.
> echo is a statement-y kind of thing, not a function.
This is a problem because?
> There’s redundant syntax for blocks: if (...): ... endif;, etc.
Because it used to be a templating language, don't use it or do use it, nobody will care either way.
> Error handling
It's configurable and you can configure it to meet your needs, moving on.
> PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all.
They do now.
> But you can’t require that an argument be an int or string or object or other “core” type, even though every builtin function uses this kind of typing, probably because int is not a thing in PHP.
You can now.
> The procedural parts of PHP are designed like C, but the objectional (ho ho) parts are designed like Java. I cannot overemphasize how jarring this is.
It's not, you read the docs, you get the job done.
> clone is an operator?!
What does it matter if it's an operator or a function that is in the standard library?
> There is no module system.
There is Composer and you get an experience similar to Java.
> There are thousands of functions in the global namespace.
And this will destroy my productivity because?
> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it. Even dev servers for Python toy frameworks don’t act like this.
Person writing this is not very experienced, because this hasn't been the norm for a long time.
> PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language.
Author doesn't know what they are talking about, you can use whatever webserver you want.
> Similarly, there is no easy way to “insulate” a PHP application and its dependencies from the rest of a system. Running two applications that require different versions of a library, or even PHP itself? Start by building a second copy of Apache.
This is coming from someone who likes Python which has the same problem.
> The “bunch of files” approach, besides making routing a huge pain in the ass, also means you have to carefully whitelist or blacklist what stuff is actually available, because your URL hierarchy is also your entire code tree. Configuration files and other “partials” need C-like guards to prevent them from being loaded directly. Version control noise (e.g., .svn) needs protecting. With mod_php, everything on your filesystem is a potential entry point; with an app server, there’s only one entry point, and only the URL controls whether it’s invoked.
You use a framework and all of these problems go away.
> You can’t seamlessly upgrade a bunch of files that run CGI-style, unless you want crashes and undefined behavior as users hit your site halfway through the upgrade.
Has this person heard about containers or symlinks?
> No template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program.
Twig, Smarty etc.
> No XSS filter. No, “remember to use htmlspecialchars” is not an XSS filter. This is.
Use a framework.
> No CSRF protection. You get to do it yourself.
That's what frameworks do in any language.
> No generic standard database API. Stuff like PDO has to wrap every individual database’s API to abstract the differences away.
PDO is the standard database API.
-------
As someone who actually used PHP to get real work done I find this article very nitpicky and get the impression that it's mainly taking potshots rather than looking at things that actually matter day to day.
Majority of what is in this article doesn't matter in real life, a lot of the things that do matter have been fixed, there are some legitimate points that do impact you and have not been fixed yet, but they are few and far between.
This article compares core PHP with a framework from some other language, which is unproductive because most of the time you should be using a framework but at the same time it's impressive that you can actually write real applications just by using the standard library, I would not recommend it though.
PHP is incredibly stable, scales horizontally by default and has amazing documentation. I have applications I have built 13+ years ago and I can still get them to work with minimal effort on the latest PHP. PHP has a very low barrier of entry which can be incredibly helpful.
Is PHP without flaws? Of course not, some of the syntax is quirky and it's full of legacy code.
I always recommend: pick the framework not the language, if the way the framework works suits you, then choose it, otherwise find another one that is better suited to your exact needs, if I were to have a beginner write something, a PHP-based framework would be a good entry point, because they can learn the basics without worrying about typing too much.
>> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it. Even dev servers for Python toy frameworks don’t act like this.
> Person writing this is not very experienced, because this hasn't been the norm for a long time.
I’m genuinely curious—what is the norm here now? I see a lot of PHP code, and 90% of it is just setting up the environment from the ground up, while only 10% is the real processing. The good side is being stateless, but the performance penalty is enormous. I still see a lot of file caching (please make this dir 777 for production) to mitigate some of it, but Redis has become remarkably visible over the last years.
Not being a PHP expert, I really need some best practices to point devs to.
Nobody runs PHP in CGI mode, either they go with libapache2_mod_php, where Apache itself does the work or PHP-FPM with Nginx.
Either way you are not going to pay for the PHP process startup cost.
PHP can also cache the interpretations of files so you avoid that cost as well.
And frameworks usually have their own usually file-based caching mechanism.
At the end of the day it's still going to have some costs compared to a single application server model, but for most web apps it's not going to matter, however it greatly simplifies the programming model.
Sure, it’s not pure CGI, just CGI on steroids. But frankly, it hasn’t gone too far. I’ve seen a lot of WordPress plugins with spaghetti code being called on every invoked endpoint. File caching is evil—many PHP devs love using the filesystem to store things, which is pretty nasty under K8s.
But it’s not the language itself, as I was advised. True asynchronous handlers are possible, which is promising.
> Sure, it’s not pure CGI, just CGI on steroids. But frankly, it hasn’t gone too far.
It doesn't need to go far, because it's selling point is that it's easy to learn and use.
The way I see PHP is not as a competitor to Java, .Net, NodeJS or Rust, instead I see it as a platform for non-advanced developers to be able to be able to create things and actually have the whole thing be cheap and sustainable.
> But it’s not the language itself, as I was advised. True asynchronous handlers are possible, which is promising.
The whole point of PHP is that it's single threaded, blocking and from the developer's point of view: your program starts at the request and terminates when the HTTP request is complete, this is what makes it simple to comprehend, if you want async, I would tell you to use something like Node instead.
> File caching is evil—many PHP devs love using the filesystem to store things, which is pretty nasty under K8s.
It's usually just an annoyance or just something you need to configure or just brute force it with a shared mount.
> I’ve seen a lot of WordPress plugins with spaghetti code being called on every invoked endpoint.
That's not really the problem of the language itself, the language doesn't force you to run anything on every request.
If you are concerned about request startup times (which is not the problem in most cases, cause db io is usually the bottleneck) you can look up the following swoole, octane, hyperf, frankenphp. Haven't used all of them in production but had good experience with swoole.
A lot of "Fractal of Bad Design" was more applicable when it was written in 2012. PHP has moved on since; there's a lot more emphasis on using OOP frameworks / libraries now. Particularly through Composer, which had only been released for a month when the essay was written (and, as such, which almost nobody was using yet).
From my experience, functional programmers come in two flavors. The ones who constantly nag others by telling them "everything you do is wrong", and "hey, come here, I want to show you something!". Unfortunately, the first camp is way more dominant than others.
Again, from the same article, there's observation "People who care about the craft are rare. Cherish the who cares, meet the rest at where they are". This is very true. The problem is, the people in the first camp can't cater to either group. First group has strong opinions and want a solid (not hostile, solid) discussion about how they can improve and how that tool works, and the second group doesn't care.
Also, every programmer has an understanding of the machine, and they program on top of that abstraction. For me, "C virtual machine", or the modern hardware is very easy to grasp. For every line of code, I can have an educated guess about how my code will run (e.g. how will the branch predictor will behave or got inadvertently poisoned), hence imperative languages and the primitive memory management is easy for me. For others who think more meta, functional paradigm is a natural think to construct in their brains. Not meeting them at where they are is again off-putting.
All in all, nobody wants to be constantly nagged to feel "stupid" about not understanding functional programming or how unelegant imperative is, and most of the functional programmers are doing this, even without knowing it.
Some of my friends who do functional programming are more reasonable people. Who sit down and look at some code or problem say "oh, this looks an interesting problem and interesting solution, can I show you how it's done in functional way", and we can go from there, and go a very long way from there.
I have never picked up Common LISP because of an academic who praised functional programming like it's the second coming of Christ. I still have the first chapter of the LISP book printed on my desk. I'll start it after 15 years, but now I don't have the time I want to spend on it.
Lastly, from an architecture/elegance perspective, I believe a good imperative program in C/C++/Go is somewhere between Bauhaus and Brutalist architecture depending on what domain you're targeting (lower the level, more Brutalism), and I find that naked nature of imperative code directly tapping into the hardware or the kernel efficiently very elegant and well-designed. For the same majority of functional programmers this is ugly and shall be got ridden with a flamethrower. Also, an imperative programming language is no lighter on PLT and mathematics which the same majority finds mouth wateringly elegant.
TL;DR: If the majority of functional programmers can be a bit less arrogant, meet in the middle and learn why we love what we love, we can build better languages, ecosystems, and a better world to live in, but no, functional elegant, imperative bad.
Robert Martin's Talk: "What Killed Smalltalk can Kill Ruby, Too": https://youtu.be/YX3iRjKj7C0 which notes a similar mechanic about Smalltalk.
My experience is the opposite, I've only met incredibly friendly and helpful people within the functional world.
Your description of a person who has to put down everyone else in other to raise himself up, is just person with such low self-esteem that it's become toxic. You'll find these people everywhere, it's not exclusive to FP.
I'm personally fairly rigid about implementing business logic as functionally as possible, but I also enjoy game development which is inherently stateful and never without some imperative parts. I do think FP has some advantages over Imperative programming in many instances, but the opposite is also true, and I'd never pretend to be smarter or better than someone like John Carmack, who's made his career almost exclusively in Imperative languages.
Maybe not "most functional programmers", though. Maybe "the functional programmers who post the most" or "post the most stridently" and therefore "the functional programmers that I encounter the most often in ways that let me know that they are functional programmers".
And "Have you considered that your position is lazy" isn't a reply likely to change hearts and minds. (It is also, itself, a pretty lazy reply, compared to the effort the GP put into their answer.)
How my position is lazy? By not learning Functional Programming? I openly said that I was driven away by these very people, because I don't want to be part of a community who belittles the outsiders the moment they talked.
I mean, most (not all) functional programmers I met (for the last 20 years, no less!) started to praise functional programming by bashing imperative programming languages and never asked me about what I like about programming, and why I was so adamant to stay away from functional paradigm.
When you start selling what you like as an omnipotent silver bullet without listening to what the other party is saying, or by calling the other party lazy and the root of the problem you drive away people from the thing you are selling,
like you're doing right now.
Extra points for you for doing this, even after I have politely said that I have left that beef behind and trying to find the time to learn functional programming, and PLT in depth. Chef's kiss, actually.
> How my position is lazy? By not learning Functional Programming?
No, your position is lazy by asserting that most people who do functional programming are arrogant. This is a nonsensical value judgement. You don't know most functional programmers.
I don't know whether or not you're skilled FP. I don't know you. But as is appropriate, I assumed that you do actually know what you're talking about.
> Typed languages are essential on teams with mixed experience levels
Essential, meaning 'cannot exist without', it's not. I've seen this work a number of places.
> Blind devotion to functional is dumb.
Managing/limiting state is always a worthwhile pursuit. I'd think he would agree since he seems to value simplicity
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.
That's like saying don't check if your cars tires still have any pattern left, the engine is more important. Until it isn't. Streamlining the smaller details allows the brain to focus on more important stuff, but the details matter and their value increases exponentially with the size of the project.
Regarding code style etc. I get where he's coming from as plenty of people made entire careers on pursuing the perfect linter configuration. They're a net negative in every project.
reply