Hacker News new | past | comments | ask | show | jobs | submit login
Why People Think PHP Sucks (2014) (audero.it)
31 points by acqbu on Nov 27, 2022 | hide | past | favorite | 67 comments



It's not just people in general who think PHP sucks, but the original creator himself. Some of his quotes are a goldmine (if this was addressed in the article apologies, it is receiving the HN hug of death right now):

https://en.wikiquote.org/wiki/Rasmus_Lerdorf

"PHP is about as exciting as your toothbrush. You use it every day, it does the job, it is a simple tool, so what? Who would want to read about toothbrushes?"

"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."

"PHP 8 is significantly better because it contains a lot less of my code."


Wow, do people have this "joke" as an auto-reply?

To put this quote in context, over the last decade, a lot of legacy PHP features were deprecated and removed. Some in the community were opposed, and wanted Rasmus Ledorf to ape Linus Torvalds and reject the changes. His comment here was him explicitly saying he wasn't precious about the original design, and welcomed the changes.

The most annoying thing about PHP criticisms is people wheeling out these hackneyed old articles and quotes that don't say anything at all.


Yes, people have this as their autoreply. There are real, obviously-wrong things about PHP that the PHP community rejected and stated as "Design Requirements". Things like `mysql_real_escape_string` and `T_PAAMAYIM_NEKUDOTAYIM` are real warts that are easy to talk about and research; Many people decided "This language merits no further discussion" from those alone and they're not wrong. PHP had great documentation... in the comments of their docsite. The fact that the comments were not integrated into the documentation and marked as resolved was a real detriment. Important caveats and ways to shoot yourself in the foot (including major security risks and features!) were only documented through comments that could fall off the frontpage at any moment.

PHP is a joke language. It's most major usage is a joke company. Making jokes about it is apt.


Yawn. For a joke, it's generated a huge amount of value for the world, so I'll laugh and carry on using it.

EDIT:

Including your PHP WordPress blog. Curious.


In the software world, being widespread is pretty obviously not compelling evidence that something doesn't deserve harsh criticism. The sarcasm is bad, too.


"PHP is a joke." "PHP is widespread."

It's good to see humorous developers love spreading jokes.


It is perhaps evidence that the subjective "it sucks" opinion is meaningless. Code is not art. Commercial usage means a lot.

And if someone calls PHP a joke, but then personally chooses it for themselves, there is certainly some inconsistency there.


Maybe once PHP finally becomes a language of the past you will be one of the few holdouts pulling in $300-$400k per year or more for working on a legacy code base, like COBOL programmers for banks. Nothing wrong with that mindset if you actually enjoy working with it and can stand being on the constant butt end of PHP jokes.


Curious what backend stack you use?


I also remember my time at Yahoo! where he repeatedly expressed his disdain of frameworks on the internal mailing lists. Yahoo! heavily relied on PHP but did not have a web development framework. Rasmus's intent for each developer was to start from scratch every single time. Result was a much steeper learning curve, significantly lower efficiency, and plethora of security issues that a framework would typically mitigate behind the scenes. By the time Yahoo! adopted Symfony (~2009), it was way too late in my opinion.


Meh. Whatevs.

I use PHP, whenever I write server code. My main bailiwick is native Apple software (Swift, usually UIKit/WatchKit/AppKit).

PHP works great. Very fast, easy to provision, and has a massive stdlib, with lots of industry best practices, built in.

That said, I don't like writing in the language, and try to keep my incursions into the backend, as brief as possible (I just wrote a new server, to replace one written in Python/Django that had fallen down -took me about two weeks).

I am quite sure that there's a ton of folks that are far better on the server end, than I am (even in PHP). I don't care. They aren't stepping up to the bat for me, so I have to do it, myself.

But PHP has always delivered, and delivery is important to me. I knew a manager, once, that said "Shipping is the most important feature of the product!".


Agreed, I landed on a stack that just works and I've been rinsing and repeating ever since. Laravel, InertiaJS, Tailwind, DigitalOcean, Ploi. I've shipped several projects, have a starter template that I've used to build entire very complex financial systems to simple couple page apps. Made my millions and furthered my career. Not to mention how automated I have stuff setup to handle dependency and package upgrades [1], everything logged to appropriate slack channels [2]. My main income nowadays is just maintenance and that is almost no work. Love php [3].

[1] - https://news.ycombinator.com/item?id=33613037

[2] - https://news.ycombinator.com/item?id=22345150#22345721

[3] - https://levels.io/how-i-build-my-minimum-viable-products/


I don't know if it originates here. But, I first saw it on this page[1]. A great blog about Netscape browser release and product engineering in general.

> Shipping is a feature. A really important feature. Your product must have it.

[1] - https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog... edit - added more context


Joel Spolsky always has great stuff.

I get the feeling that a lot of HN folks don't like him, though, which puzzles me.

Same with Steve McConnell.


It's the age-old pragmatists vs dogmatists debate that exists in everything. Both groups are well-represented on HN.

Personally, I credit much of my career to advice from Spolsky and McConnell.


I was a sysadmin through the 2000s and was responsible for maintaining php installs across a fleet of ~700 shared web servers.

People thought php sucked back then because it was obviously trash.

TFA isn't even touching on any of the very real unmitigated embarrassing failures in the decade of php growth leading up to 2014.

At one point I rolled out a php cgi update that broke something like 10% of customer scripts which upon investigation was due to the scripts containing mismatched curly braces. Pre-update, they worked well enough for the customers to have the impression that nothing was wrong. Post-update, all the sudden the php interpreter noticed these scripts didn't even have correctly enclosed code blocks. There'd be an open curly brace with no closing brace, or vice versa. It was lots of jibberish, and earlier versions of php did not care and if the random results were consistent with expectations, you carried on.

The fact that there was a post-1.0 php interpreter in widespread production use silently accepting such syntactically incorrect code clearly demonstrated to those stuck responsible for keeping this stuff ~working, while rolling out seemingly endless urgent security fixes, that php was a raging dumpster fire pushed by a clown car.


Agreed. Also "magic quotes" and "register_globals". Nuff' said.


Speaking as someone who has used PHP for years, I find a lot of the criticism is from people who are merely recycling second-hand opinions, or haven't used it since both they and the language were very different. Other criticisms are true of pretty much all programming, hardly unique to PHP.

The criticisms I would say are both still true of PHP, and aren't true of all languages:

* The PSR-4 pattern of "one class per file" encourages a lot of files.

* There's no concept of a module, where classes and methods can be public within that module, but private outside of it. This makes it hard to expose an interface.

* It's pretty verbose, with lots of boilerplate, brackets, and semi-colons.

* Installing extensions makes it difficult to configure environments.

All that being said, PHP would still be my go-to language for doing a low-traffic application doing mostly CRUD. It's a stable and reliable language, performant for many use cases, with some fabulous frameworks and libraries.


> It's pretty verbose, with lots of boilerplate

We recently got constructor promotion which has been really nice https://stitcher.io/blog/constructor-promotion-in-php-8

> Installing extensions makes it difficult to configure environments.

At least the way I do it, required extensions are just 1 line in a Dockerfile.


Yes, that's been brilliant. Read-only properties too.

A typical PHP file now includes:

    <?php

    declare(strict_types=1);
 
    namespace App\Something;

    use App\Services\Bar;

    final class Foo 
    {
        public function __construct(private readonly Bar $bar) {}

        public function doSomething(): string
        {
            return $this->bar->baz();
        }
    }
And I end up with a lot of PHP files that look very simlar. I'd love some defaults here.

* strict types

* namespaces to be autocalculated (since PSR-4 means it has to be in that namespace anyway)

* private, final and readonly both default to true

* The opening PHP tag

* Relative namespace

* Plus all those brackets and words that duplicate information. If it has brackets, it's a function. An empty function body doesn't need curly brackets.

I recognise this is a backwards-compatbility thing, so it's not as easy as "just do it". But I'd love a PHP file that looked lke:

    class Bar
    {
        __construct(Services\Baz $baz)

        public doSomething(): string
        {
            return $this->baz->bar();
        }
    }
But again, this is me waxing lyrical. I still prefer PHP to Python, but I do like Python's expressiveness.


I remember this post from 2012 being when "everyone" decided it was enough.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/


As a PHP developer for years I like to defend „my“ language. While a few issues he mentioned are true, most of them are outdated or fall into the category „if you do really weird, unusual things you can expect PHP to behave that way, too“. Other languages may prevent such mistakes, but PHP probably doesn’t because it’s historically grown and - like everyone knows - it didn’t start with a totally thought-through architecture. The good thing is, that because PHP has such a long life in web development, you can usually find a lot of docs, libraries and help for probably every problem you’ll habe to solve.

If you use PHP in a clean way, you won’t get in touch with most of the quirks he mentioned.


PHP Sadness #1, "Unexpected T_PAAMAYIM_NEKUDOTAYIM" is still the best error message of all time. http://phpsadness.com/sad/1


If only all error messages were so easily searchable for documentation.

I had this error once in 2005. Found the solution quickly. Never had it again.


I was expecting to see this link somewhere here in the comments as soon as I saw the title :)


In the last years, PHP has been refactored in a lot of places. It‘s way faster and cleaner now. There are still some quirks, like the inconsistent function naming. But - like the article says - your IDE is helping. Also, PHP has a great doc. Just open php.net/{{function name}}. You can write really clean code at enterprise level in PHP now. PHP is not just WordPress. Still a lot of PHP developers don’t tend to write clean code. It’s often a mess even if the language would not prevent them to write clean, S.O.L.I.D. and performant code. I don’t know if this is the case for other programming languages, too, or if Bad code is just more often tolerated in the PHP world.


I've worked with teams writing PHP, Python, C++, Java and Go. Every engineer complained that all the code they didn't write was shit. In all other languages, the engineers are blamed. But in PHP, for some reason, it's the the language's fault.


That documentation bit is one of favorite parts of php. I'm sure modern IDEs have it all built in nowadays but when I was writing everything in notepad 20 years ago it was great!


I stopped writing PHP around 2014.

I don't know if this is still true, but the impression I got at the time was that PHP is constantly trying to catch up with more advanced languages. There was no case I could point to and say "PHP is the best choice for this".

If I want to write a highly concurrent distributed system I'll reach for Elixir/OTP. If I want high performance, I'll reach for C or Rust. If I'm working on a data science project, I'll reach for Python or R. When is PHP the language to go to?


When what you need is just to build a web product.


I think the general "web product building" space is even more competitive with tons of good choices.

You've got Ruby on Rails and Elixir/Phoenix which both have an enjoyable developer experience and a well designed language.

There's JavaScript & Node.js where the language is a bit of a mess but the ecosystem is huge. Plus the same language can be used on the frontend and backend.

Python is extremely popular with Django, FastAPI, and Flask.

C# is also extremely popular with ASP.NET Core, although I've never used it.


Did it catch-up with Python? Because last time I saw, it was clearly behind.

(Next time I try web CRUD, I'll try it in Haskell. It seems to have let the more traditional languages behind.)


you are missing the point, all the shared webhosts out there support PHP+Apache+mySQL iterations, nobody is deploying python on dedicated server just because they wanted small web app.


There are plenty of shared webhosts that let you run whatever language you want. Fly.io, Render.com, Heroku, etc. They all let me run my code on a fraction of a dedicated server with fully managed infrastructure for a few dollars a month.


Oh, I haven't heard that one since the 00's.


There are so many things today that can do that. Lot's of server rendered js apps are rocking in this space to.


Please, stop this nonsense. The reasons to hate or love PHP have nothing to do with old blog posts.

I'm open to discuss pros and cons but over the value it might bring, or not, to an organization and its natural limitations or features.


Currently writing a huge app backend using PHP, and finding it extremely enjoyable compared to Ruby or Python. There may be theoretically valid criticisms, but I haven't run into them in practice.


Site getting smashed by HN traffic but even so, I really doubt a 2014 article about PHP is relevant nowdays, it has changed a lot.


PHP 8 is one of the rare few popular languages that have Union/Sum types:

    private int|float $foo;
TypeScript and Python are others. There's really nothing that bad about PHP compared to other scripting languages. My biggest complaint was the inconsistency of naming/parameters of standard functions. I used the Yii Framework for a project and it was much better than expected and the caching and query optimization features were outstanding.


Nit: these are called "untagged" union types, as opposed to much more common "tagged" union types (aka algebraic data types or ADTs) where each variant is named and distinct from each other even when types are same. Untagged union types are uncommon mainly because it complicates a type checker for little reason, and most frequently found where types were added as an afterthought and the base language couldn't be changed. In the case of PHP though, it doesn't have structural typing (unlike TypeScript) and every variant should be nominal or primitive types, so this is of the least concern.


Many languages that don't have these (untagged) union types, usually also have an open issue discussing if/when they'll be added. I've hand several occasions to want to use them where the available nominal sealed/enum type of the language is insufficient. In these cases it didn't matter if the components of the union were nominal, only that the union type itself wasn't.


The language itself is whatever. As usual, though, it's the system built up around it. PHP is associated with shoddy craftsmanship and below-entry-level "webdev" shops shoving out slop, usually in the form of semi-customized CSMs like WordPress or Joomla (and which are generally really terrible quality) for local/regional mom-and-pops, or personal blogs/forumns, because that is what the bulk of the "80% of websites" is.

The fact that some big name companies use it doesn't change that perception (especially when one examines the claim more deeply and realizes their use of PHP is surface-level at best anyway).


Laravel has been great so far for me, I don't think js has any frameworks that are as good. Curious to know how django compares to laravel.


Laravel is way ahead of Django in terms of batteries included and developer experience. As a Django user, I’m jealous!


IME Laravel as a framework, ecosystem and community is wide as an ocean and deep as a puddle. Everything about it is a weak copy of something that's done better elsewhere.


Another ex-Django user here. Can confirm.


I‘m not sure if Laravel is a great benefit to the PHP ecosystem. It heavily relies on traits, magic active records (Eloquent) and global god-like objects with static methods („Factories“). For sure you can write clean, maintainable code in Laravel - but in my opinion it encourages to not do so. I think Laravel is nice for quickly bootstrapping a project just to see if some idea works out. But it’s probably not a framework that proves how clean and enterprise-ready PHP nowadays is.


I think this is only a concern from a code purist point of view.

In real life business the productivity, security, ecosystem and guarantees of a battle proven tool matters *a lot*.

Not sure what alternative you're proposing here and I don't think this is the case, but I've seen already too many times the "Django/Laravel/Rails are bad so let's write our own awesome framework" and let's not get started on how that goes 99.99% of the times because you can already imagine it.

Also:

> For sure you can write clean, maintainable code in Laravel

This (and the opposite) applies to every single language and framework. In my experience it is more an attribute of the developer than of the tool/language/framework.


The only valid criticism is the lack of strong typing.

The rest is minor crap which doesn't really affect you once you're at your second project. I have a plethora of similar small problems in python (even if it's arguably better designed) and I see people with little familiarity with JS facing a bunch of small problems.

I think most of it is due to the OSS nature of languages and the lack of care for developers' experience. Too many democratic committees circling around issues and the lack of a company making a sensible choice because it makes business sense. An attitude of leaving basic functionalities to the OSS community to maintain for free in perpetuity - or until the dependencies blow up and everybody need to fix them.

Personally I'd love to have a paid programming language with a single creator's viewpoint. Elm got close but then decided to sabotage third party contributions in a way that ruined developer experience.


> The only valid criticism is the lack of strong typing.

What? It at least much stronger typing than JS. Having a separate concatenation operator already helps a lot.

Or do you mean, like static typing? Here PHP has the best gradual typing story of all the dynamic backend languages.

TS is super complex and needs an additional compile step. Python type declarations are a lie and can not be trusted as they are not enforced in any way by the language and different type checker will give you different results.

PHP enforces types at runtime and static type checkers are fast and reliable. Dynamic productivity with static safety when needed.


The fractal of bad design article is always linked, but I'd suggest also taking a look at https://www.youtube.com/watch?v=i5E48THNRe4 (or https://www.slideshare.net/zerutreck/taking-php-seriously-ke... if you prefer slides to videos.) It's by one of the developer's of Facebook's PHP engine/variant (Hack), and it tries to nail down what does make PHP special, beyond all the obvious warts.

(FWIW, one thing Facebook did have in it's favor is that it got pretty disciplined about what parts of the language to use or not use early on (e.g. no extract), which IMO made a large difference compared to typical php codebases back then.)


"php" == 0

That evaluates to true if you're using PHP prior to v8.0.0. A good example of why you almost always want to use strict comparisons (===).


My first internship, i had to juggle between php 5.3 and php5.6 (with windows IIS, which at the time had real troubles handling versionning, especially the `crypt` functions. Hopefully its better now, but it did traumatize me).

Php7 (and especially 8) seems to be a nice language, but man, the php hate was really warranted at the time.


How much of this article is still valid?


I dont think much of it was ever valid.

You can't really blame a language for the fact that some people wrote bad code in it. By that metric all languages are bad.

The valid ones are mostly nitpicks. Some standard library functions have inconsistent naming/argument order/poorly designed/multiple functions that do the same thing. Hard to change for back compat reasons, but you can simply not use those functions.

The ternary operator being left associative is the only truely wtf php design choice on the list imo.


> You can't really blame a language for the fact that some people wrote bad code in it.

The inexistence of footguns or statically enforced good practices are things we would usually praise a language for. So why should PHP not take the blame for how easy it is, to write atrocious code?


That’s true in every dynamic scripting language.


they did fix that:

https://wiki.php.net/rfc/ternary_associativity

it now requires parenthesis, and will be transitioned to being right associative


One thing that gets left off is the per-request lifecycle. It makes requests easy to think about, but it makes RPC/SQL connection pooling a lot harder, and that's one of the first things you do when you care about performance.


Can you explain what you mean here a bit more? I worked on some large PHP sites (millions of users a month) and didn't really have any problems with these things, but maybe you're talking about a specific type of RPC?


One place I worked put all their services behind private ELB instances. They didn't use PHP, but if they did, they'd pay the cost of HTTP(S?) connection establishment for each service call because the connection couldn't be reused across multiple incoming requests. DB connections have the same issue.


I would add (in 2022) the bolt on support of UTF-8 via a separate set of API functions.


Dumping on PHP and Java is a good way to farm for cool kid points.


Getting resource forbidden






Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: