Hacker News Reader

Comment by otar | Hacker News Reader

It's not a surprise at all.

Firstly, PHP has always been around, WordPress based websites still have like 1/3 share of all existing websites.

Secondly, in the recent years it got a very mature language, got loads of improvements and performance optimizations. With PHP 8 being planned to be released by the end of this year, it will be another major step forward.

Thirdly, Laravel, Symfony and other open source stuff are awesome.

I think if PHP does a major comeback as a decent platform for development and somehow gets rid of the undeserved reputation, those PHP devs who stayed with PHP and didn't switch to RoR, Django, Node or other platforms will be winners, including me :)

View on HN

The bad rep is totally deserved. PHP, for most of its existence, has been a profoundly bad language per se. That doesn't mean nobody's ever built anything valuable on top of it, and I fully understand that (much like also-justifiably-maligned JavaScript) it's evolved quite a bit. But the points made in this mid-2012 article are absolutely spot-on in describing precisely why PHP absolutely earned its reputation: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Yes, but 2012 is 8 years in the past. Do you know what else is 8 years in the past? Well, not Reacts first release because that happened only in 2013. That's how long 8 years are in web terms.

At some point — and boy, are we long past that point — it feels old when gramps goes off about the woes of PHP4 because, oh, it feels like it's just been yesterday.

Most projects are from yesterday though. Maintaining or porting legacy php is the reality of most projects.

Php4 is not yesterday so much as last decade.

Most people talling about legacy php mean php5, which is much more sane than php4

This is why PHP deserves it's reputation. The state of the language is one thing, the state of the ecosystem surrounding the language is another.

Anecdotally speaking, the vast majority of PHP projects I've been exposed to have been horrific precisely because there's a laissez-faire or "get the job done at any cost" attitude to software development that's uniquely prevelant in these communities (this exists in all languages, but in my experience it's way worse and way more normalized within the PHP silo). The language improving will only be positive for new projects that are started today, or that have been maintained by dilligent and empathetic engineers. Often teams are not as united on this front as they should be.

I think using almost any other comparable language in 2020 (Python 3, Go, Typescript) is a better solution than starting a new project in PHP these days. I suspect the real reason many still reach for PHP first is because it is "easy" and PHP developers are ostensibly cheap and easy to replace. It's a false economy.

And next you‘re telling how terrible COBOL is? Seems like most/many banks are still running on cobol today...

I think just because something was bad before yesterday does not mean it cannot be used in good ways today or tomorrow. And I think everybody talking bad about PHP should not even think about JavaScript.

Todays PHP gets its job done in a really good way. It has very good frameworks, is amazingly fast and is easy to start with and quite easy to deploy. And it‘s absolutely not comparable to something that was many years ago. And I think too, PHP before something after PHP 5.5 was not „that good“ compared to C# or Java.

>The bad rep is totally deserved. PHP, for most of its existence, has been a profoundly bad language per se.

Javascript too, so what? In the end it's another tool with specific pros and benefits, and it got many things right (ease of deployment, no shared state, batteries included, etc).

JavaScript was a bad language though, if not just from it’s messy origins. There’s been a ton of work put into the language and lots of thought put into the ’good parts’ to use and expand upon.

I’d be interested in learning more about php’s evolution, and possibly even a follow-up to that article.

I have written both PHP and JS for a living since about 2005 (for my sins) and I can tell you PHP has gone through at least as much of an evolution as JS. Neither one feels anything like its 2005 ancestor.

Unlike JS, Google doesn't endlessly push PHP. Having written in both of them (and prefer neither) they're equivalent outside the marketing budget.

I started programming with PHP back in 2001, I think. I moved to C# when dotnet was released shortly after, but still have a personal website that's built with PHP, and a couple of years back I updated it (from something like PHP 4/5, I forget) to the latest version PHP. I was pleasantly surprised - it wouldn't be my first choice by a long shot, but I can see why others would choose it today. And there's always been a good community around it too.

I also started with JavaScript a long time back, maybe something like 1998-1999. I've always found it a most loathsome language, and the anaemic standard library a huge barrier. It's not entirely the language's fault, of course - being the language of the web was always going to mean glacial progress. Recently I worked on a vanilla ES6 project (since browser support is finally there), and at long last I wouldn't quite describe it as "loathsome" anymore! Still, it's a far cry from the nicities of Typescript, and the tiny standard library remains an issue.

Having seen both PHP and JavaScript evolve over around 2 decades, I'd probably argue that PHP has evolved more as a language than JavaScript has.

JavaScript even in 1996 was much saner language than PHP. Surely there were bad parts, but in JS you could just ignore them. In PHP on the other hand one had to build on top of bad parts since there was no good alternatives.

>In PHP on the other hand one had to build on top of bad parts since there was no good alternatives.

What exactly was so bad in PHP that you couldn't also ignore?

Someone posted an article above [1], but citing from it, there is a function called mysql_real_escape_string. Although early JS also has quite odd language choices, it follows a consistent philosophy. To me it boils down to LISP in C syntax with weak typing. Past PHP feels more like a collection of stuff. But I assume modern PHP can be a viable choice if used with a modern framework, linter etc.

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

PHP follows a consistent philosophy as well. The PHP functions are usually named after the C functions they wrap. And in fact: The MySQL C client library contains a function called mysql_real_escape_string.

see: https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-escape-str...

this code is blowing my mind -

$arg = 'T'; $vehicle = ( ( $arg == 'B' ) ? 'bus' : ( $arg == 'A' ) ? 'airplane' : ( $arg == 'T' ) ? 'train' : ( $arg == 'C' ) ? 'car' : ( $arg == 'H' ) ? 'horse' : 'feet' ); echo $vehicle;

can someone explain to me why it should print out 'horse'? (what the article above says)

on edit: oh I get it, the false of the ternary statement here is on the left so when $arg == 'T' the true does ( $arg == 'H' ) which is false, hence printing out horse.

Well there's no reason true has to come first, but it is a c-flavored language so sort of weird it doesn't.

In JavaScript you still have to deal with all the bad parts. That’s why we pretty much require monstrosities like babel, webpack and whatever other build tools you can imagine.

If you want PHP, you install php, and you’re done.

I haven't used PHP is a professional project for probably 10 years, aside from needing to poke around in Wordpress occasionally. When I see modern PHP, I barely recognize it.

> PHP, for most of its existence, has been a profoundly bad language per se.

PHP is 26 years old. PHP5.3 is 11 years old. PHP7.0 is 5 years old.

Where is your cut-off that make you claim "most of its existence"?

Most is 51%. If PHP was bad from 1994 to 2002, when "A Fractal of Bad Design" was written (18 years), and is OK now (assuming it got good immediately after that post was written 8 years ago), it has been bad for most of its existence by simple arithmetic.

Bad compared to what at the time?

What other tech compared to PHP at the time?

Java? Python?

The FA itself points readers to Python (with Flask, Pyramids, or Django), and also gives an offhand mention of Ruby + Rails and Perl + Catalyst. Java had also become a pretty reasonable language & environment by this time, and off-beat "let's build a better language on top of an existing runtime/ecosystem" languages like Clojure and F# were in full swing.

PHP was already very successful before Django or Rails even had their first release.

I remember trying to set up a Python Django web site for the first time around 2010 because Python seems like the better language and it was such a PITA compared to PHP's it-just-works nature.

"A Fractal of Bad Design" was written in 2012. (looks like a typo on your part, since your math checks out)

I avoid including anything less tha 20 years old in my stack, so it,s an advantage for me.

So what operating system do you use? Unix is 50. Windows is 35. Linux (even if it is Unix) is 30. I can't think of any commercially viable operating system that has been released in the past 20 years.

I think you must have misread "less than" as "more than" in the comment you replied to.

What does 'profoundly bad language' mean exactly?

When PHP was first released it was dramatically better than the alternatives for it's intended purpose.

There were plenty of things to complain about, but none of them stopped you from doing useful things with it. It was never slow or inefficient compared to other scripting languages, it didn't lack functionality.

Over the decades the most popular complaints have been addressed as the language has matured.

That it's remained in active development for 25 years with no signs of that changing in the future is one of it's biggest selling points.

I don't blame people for having issues with aspects of PHP based on their personal preferences and experiences, I get that, but that doesn't make it a 'bad' language.

There's nothing wrong with purist perspectives on what programming languages should be and how they should work. That contributes to better design.

But in the real world the questions are simpler: can this tool be used to develop applications quickly? Is it reasonably efficient at runtime (in this case in the context of scripting)? Can we easily find affordable developers in the future? Is there community support?

PHP checks the boxes that people building things want checked as well as any language and better than many. Unless I'm missing something, 'bad' here is more of a philosophical stance.

> When PHP was first released it was dramatically better than the alternatives for it's intended purpose.

I think that's going to depend to some degree on how you define that purpose. If it centers around having a low barrier to entry, then that's partly true, but some of the ways it achieved that involved making code written in it vulnerable to variable poisoning and SQL injection by default.

Did Perl or C protect you against this when PHP came out?

Well register_globals was a kind of uniquely php thing, but that's been gone for ages at this point. I generally agree though that lots of the hate for php is a bit over the top.

Auto-escaping every GET/POST input at input time was quite something. Also arrays being pass by value is a lot of fun to this day:

$a = [1]; $b = $a; $b[] = 3; var_export($a);

And that you could pass by ref at call time to any function. That was also quite unique.

CGI didn't have register_globals, so yes on that count. I'm sure the quality of database access libraries varied, which is still a better situation than having a broken escape function built in to the language.

Yes. Perl has had taint mode since 1994, and for setuid scripts for longer.

For SQL: On CPAN, the oldest release in 1995 of DBI does seem to support bind params.

https://metacpan.org/source/TIMB/DBI-0.64/DBI.pm

Thank you!

I honestly didn't know (not paying attention to web programming back then) and was wondering if PHP's craziness was standard back then.

I think Bjarne Stroustrup put it best.

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

The C++ Programming Language

https://www.goodreads.com/quotes/226225-there-are-only-two-k...

I mean there are some quite uncontroversial languages. For instance Python. What surprises me the most, C is segfaulter #1 but literally nobody complains about that because it works good enough and the code is elegant. I think it still holds the position of most beloved systems programming language

Plenty of people complain about Python - about the language itself (significant whitespace, dynamic typing and excessive complexity), about the implementation (slow and limited by the GIL) and about the ecosystem (e.g. https://xkcd.com/1987/).

Python 3 and unicode are some things people have complained about python for example.

Segfalter is a feature which prevents release of weak code by weak people. Granted such approach isn't suitable in enterprise where Java rules because any kitchen sink of staff thrown together in Java still runs somehow, yet in systems you must meet orders of magnitude higher threshold.

The python way of doing ‘classes’ is pretty hideous to me. Why a self argument on every function?

> Why a self argument on every function?

A self argument is on methods because then, from the inside, methods are identical to functions, rather than functions with additional implicit magic.

Also because it's a function member of the class with exactly that argument pattern; calling instance.method(...) is just syntax sugar for ClassOfInstance.method(instance, ...).

This also makes Python handling of unbound methods a lot cleaner than, say, Ruby.

Bad type coercion you can’t turn off with weird semantics. Powerful but confusing arrays/dictionaries. Inconsistently named stdlib functions with inconsistent parameters. Little to no support for threading or concurrency models outside of making event loops or running multiple processes. Memory management that allowed for leaky memory all the time. Lack of proper support for stand-alone daemon processes (you could make it work but it was clearly not the main way PHP was meant to be run). Lack of namespaces or modules with all variables being global.

This was PHP 5 and it sent me running for the hills (Python, ES6). I am sure PHP 8 is an improvement and I’ve worked with PHP versions past 5.3 but it left such a bad taste in my mouth that yes I will avoid it if I can. Fixing what shouldn’t have been broken may make this language almost as good as something like Python but why would I reach for PHP when better things exist unless that decision is not made by me?

Not sure what you mean about global variables. PHP 5 had the same scoping rules like it has now. You couldn't access global variables directly from anywhere but the toplevel execution context.

Right. So if file a.php has:

    <?php $MY_SOCKET_TIMEOUT = 5;

And file b.php has:

    <?php require(‘a.php’); $MY_SOCKET_TIMEOUT = 10;

That’s a problem. Same with every function and class name. Oh and requiring/including a file is not idempotent because it’s just string concatenation because they are not modules. None of that should be a part of a modern language. If they haven’t fixed that in PHP 8, then it’s still broken.

require_once has existed since PHP5 at least (when I started using it).

That’s a hack, not a solution. You still can’t import just class A out of A, B, and C that are all defined in the same file. And even if you require_once file x.php, you don’t have any guarantees that that file won’t require/include file y.php that you also intend to include. PHP files are treated as files, not modules and that’s fundamentally broken.

I guess you like modules. Someone else may like string inclusion, because it allows for some other forms of splitting the code that modules would not allow and fulfills the primary purpose of a PHP script, which is templating. Neither is fundamentally broken. You're just focusing on one aspect (organizing code), while ignoring the other.

Ah and there it is. PHP is fundamentally a templating system with a programming language built-in. Imagine using Handlebars.js to write your business logic.

I do think code organization is one of the primary jobs of a programming language/ecosystem. I want my tools to help me be better about that, not worse. Oh and given that most projects use a bunch of library code, I would very much prefer a system that has a consistent code organization pattern so I don’t have to guess how it all works. Take a look at the source code for something like WordPress or WooCommerce. These are mature projects. And yet it’s hard to shake the feeling that it’s all spaghetti inclusions.

But also there are many other issues with PHP that I mentioned in a prior comment. Here, if you’d like for a better read on the subject than I can produce: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

> I do think code organization is one of the primary jobs of a programming language/ecosystem. I want my tools to help me be better about that, not worse.

Isn’t splitting up all your classes into separate files considered to be a good thing?

Considering how huge we can make files in JS I’m sort of inclined to consider that a problem instead of a feature.

I think any project that started around PHP 4/5 will look like Wordpress. Looking at more recent projects (after PSR’s became a thing) would be more representative.

It is but when you use third party code, what guarantees do you have that it didn’t do something stupid like declare a variable like $TIMEOUT? Whether on purpose or by accident. And of course any class or function become global even if you run include/require inside the body of a function or a method.

Include inside the body of an anonymous function if you care about toplevel $TIMEOUT=123 overriding some global variable.

Anyway you don't have any guarantees in JS either, for example. Imported module can just redefine Date object prototype or any global via globalThis. If you don't trust the libraries to not make a mess, don't use them is the only real solution. And it will be completely silent as opposed to PHP failing loudly when you try to redefine constant or class or function.

Variables would stay inside the scope of your anonymous function. Functions and classes will become defined globally. Surprise!

Ah, I don’t think so. It’s a different way of thinking about it, but it’s hardly broken.

It’s only broken if you expect files to be modules and they’re not.

It’s just as (if not more) confusing if you go from PHP to JS and expect modules to work like files.

So... don't do that? You're correct, it's possible to write blisteringly awful code in PHP. Ditto every other programming language ever.

But PHP makes it way too easy and provides few ways to guard against it. Well technically now it does with namespaces but that’s still less than ideal. And my point is that they are just now starting to catch up to more sane languages.

There is an argument for judging programming languages based on the worst code possible within the language, due to the fact that with a wide enough ecosystem, you will regularly encounter lots of stuff in the median between that and your “just don’t do that” standard.

This is one of the reasons I love Go: the worst code possible in it is still pretty readable.

The worst code possible in PHP is scattered across thousands of files corresponding to individual routes, and isn’t indented at all.

> Little to no support for threading or concurrency models outside of making event loops or running multiple processes.

Having just started with programming, this is more feature than bug. It’s super easy to reason about PHP applications because the whole flow is linear from top to bottom.

It means bad design. It address claims like "PHP improved in last decade".

I've checked and feel misguided. "Fractal of bad design" is still applicable

    strpos ( string $haystack , mixed $needle [, int $offset = 0 ] ) : int
    str_replace ( mixed $search , mixed $replace , mixed $subject [, int &$count ] ) : mixed

It is not possible to use language without documentation, should name include underscore? Where to put string? I've switched to ruby, it is predictable.

Mixed baggage of C, Perl, Java influences, no design. PHP 4 had design, PHP 5 made it total mess.

Borne shell good in gluing UNIX tools, AWK good in simple columnar data, PHP good in one page scripts.

You've described PHP as "useful" language.

"What does 'profoundly bad language' mean exactly?"

My comment linked to a comprehensive answer to that question.

PHP isn’t exactly an elegant language, and I would argue that you need to be an pretty good developer to write safe PHP code. Still PHP is easy to get startet with, well documented, productive and impressively fast for a “bad” language.

If you know what you’re doing I don’t see any reason to not pick PHP.

This back and forth appears in every single thread about PHP on HN:

- PHP doesn't deserve its bad reputation!

- Well, it used to be pretty terrible...

- Ok, so first let's talk about the relativity about the definition of "terrible". The Oxford English dictionary defines [...]

And from there it goes nowhere.

It is true that PHP improved drastically over the past decade or so, it is also true that it used to be a garbage fire of a programing language and ecosystem.

For the PHP proponents in the comments: I think you'd save you a lot of trouble if you didn't try to dismiss the history of PHP and pretend that it was just unfair criticism from haters. It was warranted. You can't win this one.

But who cares? If PHP really is good now you're way better off arguing about that, because while you'll never manage to convince me that it was a good language in 2005, you might end up convincing me (and others) to give it a try in 2020.

2005 means PHP 5/5.1. It may suck in retrospect, but it was fine at the time, and there were a lot fewer choices. There are excellent reasons why it powered (and continues to) large swaths of the web.

I think a lot of the misunderstanding around PHP's past stems from its accessibility. But real software developers had no problems creating real software with it even then, and since then the ecosystem has become startlingly better.

> …you might end up convincing me (and others) to give it a try in 2020.

It's been in the TIBOE top 10 since it's debut in 2001. If you haven't tried it by now, it seems unlikely you ever will (and that's absolutely fine).

PHP 5 wasn't fine at the time which is what the GP was saying. It was inconsistent and stupid and only carried on because it was the default option on shared hosting so everyone could easily throw up their b2^H^H Wordpress blog.

PHP would have been abandoned years ago if not for Wordpress' worse is better success story.

> PHP 5 wasn't fine at the time which is what the GP was saying.

"Fine" (as in "adequate") is not a high bar, and so is easily defensible. I get that it's fun to say that PHP was "stupid", but history shows that PHP's historic imperfections didn't prevent developers from building everything from web-scale apps (Facebook, Wikipedia, Flickr, Tumbler, etc.) to, yes, millions of blogs.

(Don't get me wrong, your favorite language seems nice too.)

Big websites used PHP in the distant past and have a handful of lines running today. PHP is eating the world!

Come on man, you're well aware none of those "web scale" companies are running major portions of their sites on PHP anymore. Well, you should be aware of that.

You can keep fighting for PHP if you want. Don't pretend that it's worse is better nature fifteen years ago somehow made it a good language or that it didn't have major failings.

I wrote a ton of PHP 3 through 5. It was easier to deploy on $10 shared hosting than Perl/CGI and more capable than SSI. That was about it in terms of its advantages at the time. It wasn't easier to write than Perl and in fact had more and less obvious footguns. It's database access was shaky at best and downright dangerous at worst.

The question today is why bother with PHP for greenfield development? It doesn't really offer anything unique or special. You can't really leverage your PHP skills anywhere but web development and really only a subset of that field. So good luck with that.

> It's database access was shaky at best and downright dangerous at worst.

Lol. It literally offers you ‘one’ function to access the database. Any insecurity is your own fault.

What I actually said was PHP 5 was "fine". To that I'll add the wildly controversial assertions that PHP 7 is "pretty good" and PHP 8 "looks nice".

I know that I'm supposed to have internalized that PHP Is Bad, but occasionally I have to do maintenance on a PHP project and I just can't find it within me to hate it.

> It was easier to deploy on $10 shared hosting than Perl/CGI and more capable than SSI.

Exactly. And for other folks who (unlike us) didn't use PHP at the time, the "Virtues of PHP" section of this Slack post that lists other notable reasons why people chose (and still might?) PHP: https://slack.engineering/taking-php-seriously/

is there any cli for scaffolding a site that includes auth, caching, sessions, queues, teams, profile, 2-factor, rbac (via policies), migrations, asset management via webpack with low-to-no config... (sure this is just for laravel, but that's a huge subset of users, just as django/rails are for python/ruby)

Even rails doesn't have auth baked in. For launching something fast, nothing beats prototyping in laravel. For more heavy work-loads you can offload services to go or rust for data intensive things, and still keep the majority of the code/api.

For new devs especially, community matters more than just about anything. While, wordpress is a clusterfuck of security issues, vulnerabilities, and bad practices the laravel community and (symfony which is more for enterprise apps) are generally top notch.

Show me how you can bootstrap a full SaaS app w/ all the same features as:

laravel new myapp --jet --teams

In ANY language without using some sort of cookiecutter template, or something that is custom-brewed.

History shows successful projects built no matter what. It does not mean they would be successful if started with same technology today.

Unfortunately programmers rarely decide language of the project. Usually it is a sales team. Projects impossible to migrate and we stuck. If language does not match either rewrite, split service/extension or use polyglot like GraalVM.

Maybe it was the default option on shared hosting because it was the only thing that could sort of reasonably work on shared hosting?

Most shared hosts also supported CGI with scripts/binaries in a set cgi-bin directory. A lot of them (that I ever saw) even had some preinstalled CGI scripts linked into the user account's cgi-bin.

What a lot of shared hosts did not support were things like mod_cgi or mod_rewrite that might let you make cleaner looking URLs. With PHP you just enable mod_php and add index.php to the DirectoryIndex directive and call it a day. Many hosts didn't allow overrides so you couldn't add a CGI handler to your DirectoryIndex unless you knew the server admins.

So like I said, PHP was the easiest to get running. It wasn't the only thing that worked or was supported but it made it simple to have URLs that looked "professional" with no access to a server's configuration and no ability to override defaults. So it worked well for cheap shared hosting.

I'm still annoyed I know this stuff almost twenty years after having to deal with it. People really wanted their brand new .com address to serve up their "dynamic" homepage with nothing hanging off the path. PHP was the worst is better way to make that happen.

Case in point, after coming to the conclusion that XML + XSLT wouldn't last for my web site, I went to search for something else, and wasn't that happy with my ISP alternatives (PHP + CGI/Perl).

However, after a couple of trials with other stacks, I ended up going with PHP, it does the job, was already on the ISP without me having the hassle of being a special snowflake, I was anyway the only one coding it and now get to enjoy a JIT compiler that Python and Ruby communities are still not fully embracing on their reference implementations.

And although I do mostly Java/.NET Web related projects, I do occasional PHP projects, because after I am done, I am sure that the customer is going to have an easy time finding someone else to take care of their issues, as I don't want to make a living out of it.

I don't know how it looked like in the US, but in several European countries the web was basically built in PHP. In 2005 the entire web market in my country was PHP with a few uncool Java enterprisey jobs here and there.

Being able to mix PHP and HTML code was brilliant and setting up PHP on a server was child's play compared to Java. Because state was stored in the DB and individual pages were ephemeral, we didn't have any issues with e.g. memory usage or performance. At that time I was already familiar with C, C++ and C# and I didn't find it worse to use PHP. It was a good match for the job.

But the web was also made of SQLi and reverse shells in 2005 as well.

Nobody should argue the utility of using php in 2005; just as nobody should argue that it wasn't also a superfund site of a language in 2005 as well.

In 2020 the number one OWASP security risk is injection and I don't think anyone's arguing that the current crop of languages are all crap.

Evaluating a language without judging what kind of projects it enables is nonsensical and leads to pointless language ivory tower discussions. I'm sure that also back then there were all sorts of awesome programming languages that nobody was using, but checked all the boxes that would make the average HN language enthusiast happy.

As a counterpoint, the number one cause of death in America in 1950 was heart disease. It’s also the number one cause of death today. We’ve still made a lot of progress in treating heart disease in the last 70 years

What kind of progress have we made since 2005 in preventing (not treating) SQL injection? I remember reading a book about PHP security that year where escaping strings and bound parameters were mentioned.

Just don't construct SQL queries by directly concatenating user input. It's easy to mess up or use the wrong escape function, so always use prepared statements anywhere you want to pass user defined data.

You can usually grep or even use static code analysis to help find where your existing code is using "tainted" data to construct a query.

Also, if you use an ORM, you'll generally be working at a high enough level where SQL injection is impossible (unless there's a bug or design flaw in the ORM); since you won't be directly dealing with text queries.

I don't disagree that the web was basically built on PHP in 2005, but in 2020 that isn't really the case anymore.

> The bad rep is totally deserved.

This sentence really got me thinking. "Deserved" is some sort of moralistic word, I'm not sure how it applies to a tool, unless it means to apply to the makers and/or users of the tool.

And I guess it makes some sense. A bad reputation is a sort of social communication utilizing shame and stigma. Maybe it causes people not to use PHP without having to pay the cost of really understanding why, which is likely only accessible with lots of experience and/or study.

This is basically by definition an inaccurate bias, of lacking nuance, but perhaps a net good. If PHP was such a poor tool for productivity and security then it was probably good if shame and stigma were helping people to use better tools without paying the cost themselves first.

But it's always very frustrating if you actually know what's bad and what's good about a thing, or even just know that it has both bad and good parts (even if you don't know precisely which is which), and you see a memetic belief held up as truth rather than acknowledged as a useful heuristic.

And while it feels dirty, maybe this shame and stigma also serves to influence the creators of the language and its ecosystem to make it better. I don't know. I hope there are better ways than shame and stigma but I'm just a d00d writing a post on a web forum.

What does seem clear to me, though, is if is a good tool NOW, as a result of years of work by the people who kept at it, then a bad reputation is no good anymore; no longer a positive force but a negative one.

I think in this case "deserved" was used in the same sense as "warranted," although I realize this doesn't change the main point you're making.

What you're getting at is that people can be influenced by factors other than objective truths. I admit that I am someone who tries to avoid making decisions based on word-of-mouth or "reputation," but you can't deny that only considering objective truths takes a lot of work.

Sometimes I just want to buy a keyboard, not read and apply "The 50 Tenets of Keyboard Comparison" to find the objectively best (for me) keyboard.

It makes sense how this attitude can bleed into decision-making as a whole, even for higher-impact decisions like programming language choice. So I wouldn't discredit (or lower the reputation of ;) ) too much the folks who don't always go by objective truth.

Is C undefined behavior and use after free "shame" or "stigma"?

JavaScript has bad parts and design (and big community that claims it is fine language), Perl has great design and small community (and everyone can bash it), PHP has horrible design flows and a big community that does not address issues from "Fractal of bad design" but claims language is fixed.

As experienced developer I know what good design is. This article saved a lot of novices from trapping into badly designed language as a first one.

At least some PHP proponents makes fools of themselves:

> This of course is coming, like usual, from someone who spent a significant portion of their life in academia and then moved to R&D and still has yet to make a dent in the world, or likely their student loans [1].

Words of true believer. PHP can't transition to not bad language because of such believers. Those who can see faults left. And what's left is echo chamber. There would be no break of backward compatibility. I've checked, from design perspective nothing changed.

All I see is community discarding critique without addressing it or even understanding it.

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

> PHP, for most of its existence, has been a profoundly bad language per se

I mean, people often say the same thing about C, C++ and Java. But these are also massively popular languages, so obviously they're doing _something_ right and the people complaining must be looking at the wrong metrics.

2board.net is written in php and it's one of the most popular sites on the world wide web.

Depends on how you used it. I ve barely noticed a change, in fact thats why i use it

> in this mid-2012 article

Don’t you think referencing something 8 years out of date, from when PHP 8 was PHP 5 may be a bit out of date?

"PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening."

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

> somehow gets rid of the undeserved reputation

That reputation is a competitive edge for companies and people who embrace PHP. They get shit done for the business and grow revenue while the rest of the tech community is rewriting basic tooling for the 50th time in Rust on a Kubernetes-powered back-end with a React front-end powered by a GraphQL API layer.

But the new stack is 12% faster!!!!*

*We didn't re-run benchmarks after fixing edge cases

I understand what you are trying to say but Kubernetes and React complement services written in PHP, the former can deploy and orchestrate them while the latter offers an option for SPA apps written in PHP. Also, Rust when written where it should be written, can enhance PHP services that require fast and secure components. But yes, trying to replace what PHP is good at (serving content) with Rust is not really the best thing to do.

"SPA apps written in PHP"

huh? that sounds like a contradiction in terms.

You can have a PHP server rendered page that can hold multiple SPAs written in React, imagine a portal like Liferay where each portlet is its own React app. Or imagine Steam shop that is using React for some of its components, like its new chat system which is a SPA integrated into Steam network.

* Yes, I should have said "integrated" in PHP instead of "written".

Definitely a weird thing given PHP’s heritage. Of course it’s totally possible to write JSON API endpoints in PHP.

I understand the sentiment, but historically there has been a lot more web-framework churn in PHP compared to other languages.

The “framework du jour” and the set of best practices have changed way more often in PHP than in any other language, perhaps as much as, or more than Javascript.

> I understand the sentiment, but historically there has been a lot more web-framework churn in PHP compared to other languages.

That has not been my experience. When I used to work with that tech stack, the major framework choice only ever had 3 options:

Zend Framework, Symfony and Laravel.

From what I hear Laravel is the industry leading and there's no sign of that changing.

Sure there are other less popular frameworks just like in other languages.

> The “framework du jour” and the set of best practices have changed way more often in PHP than in any other language, perhaps as much as, or more than Javascript.

PHP have had a published standard specification for framework and component interoperability for long time now:

https://www.php-fig.org/psr/

> That has not been my experience

Sure, but this is not about personal experience, but rather about history. Maybe it just happened before your time? Also, please read my reply in context.

Pretty much every other language that's similar in purpose and popularity is provenly more stable regarding framework popularity than PHP.

Sure it feels great to bash Rust and Kubernetes or whatever like the GP poster did, but PHP suffered from the same problems until very recently, whereas Python, Ruby, Java and C# among others did not.

Even Javascript has been historically more stable in the backend than PHP: it's been pretty much just Express from almost the beginning, and other contenders never reached much popularity.

PHP allows folks without a strong background to solve some simple business problems which, in general, is a good thing. But once the project exceeds a certain complexity threshold (which I admit many business problems never do), this approach hits a wall: things break and fixing it breaks more things and it is an uphill battle to move in the right direction. Adding a significant new capability -- forget it.

To make things worse, this cannot easily be fixed because the implementation is a hodge-podge of ideas and functions. You cannot find good architecture people who want to work in PHP to clean it. It cannot easily be re-architected because it captures a lot of business wisdom. And business people (rightly) suspect pitches for a new built-from-scratch solution: sure, it will be fast and maybe it will be reliable; but will it solve their problem? will employees need to be re-trained? etc.

That's not the languages fault, it's the incompetence of the people trying to use it.

Ah, “you’re holding it wrong.” Good languages make it easy to build and maintain robust, scalable, and secure solutions to problems.

Facebook ($750B), Slack ($15B), and Etsy ($15B) would beg to differ. But whatever, your arrogant, gatekeeping and elitist mentality is primarily a roadblock for your own career growth.

Wow, chill. I do not know what part of my post you reacted to, but to clarify, I do not mean that professional software engineers working on PHP are unskilled. What I meant was that PHP and its frameworks allow business person to solve simple problems without hiring a good software developer. Which is OK in many cases, but when this fails to work, it fails hard in a way that is both painful and difficult to quickly address.

You just reiterated it. Your view is that PHP is only used by non-educated simpletons and who are only capable of solving the most mundane of business problems. This sort of elitist attitude is really frustrating on a forum that's supposed to embody the "hacker" spirit, that is, building things and getting shit done without worrying about whether or not someone is going to come along and criticize the correctness of their code while blissfully ignoring their innovative idea, or the fact that it works, and the impact on the world. It's pure gatekeeping garbage.

This of course is coming, like usual, from someone who spent a significant portion of their life in academia and then moved to R&D and still has yet to make a dent in the world, or likely their student loans.

Mate, I will try one more time. (A implies B) does not mean (not A implies not B). Those are unrelated logical statements.

As an unrelated example, almost anyone can now do their own accurate temperature and blood pressure measurements, so the vast majority of temperature measurements is done by those with no medical training. This does not mean that nurses and doctors who do the same measurement (that a middle school student can do) are any less skilled in medicine, let alone "non-educated simpletons".

FWIW I've interpreted your posts in the same way as the other person. They come across as deliberately inflammatory.

"What I meant was that PHP and its frameworks allow business person to solve simple problems without hiring a good software developer..."

There seems to be an implication that an org using PHP has not also hired good software developers. Or that a good software developer would not use PHP.

My logic skills may be a bit rusty at this point, but I suspect that's what altdatathrow was reacting to.

That’s not how I read it.

My take of the GP was more that they believe the _strength_ of PHP is that businesses that don’t have an existing pool of SWE talent can start solving problems with more or less whoever they can get their hands on (I’m trying to be careful not to imply that the “whoever” here is a poor engineer - just that they might not necessarily need to be experts).

Then when those projects get traction and start to grow and an engineering org starts to grow and mature around it (with plenty of “good” engineers, whatever that means), the _weaknesses_ of PHP may come to the forefront, making maintaining & expanding the PHP project difficult.

Thank you, this is what I meant. I probably could have made my original post clearer.

Facebook didn’t make its money because of innovative PHP uses. And it based on this (somewhat old) discussion the quality of code at Facebook is universally terrible:

https://www.reddit.com/r/programming/comments/3r90iy/faceboo...

Which I am not blaming PHP for specifically, but rather that “you say PHP sucks but Facebook made a lot of money” is not an argument and is particularly dumb for Facebook specifically.

And the personal attacks are really not ok.

One could swap PHP for any possible language and your comment could still be true, because you're describing project management and software architecture failures.

It reads like you're talking about a specific project and trying to generalize?

PHP earned its reputation. Whether the reputation earned by previous versions is relevant to the current version is a different question.

I'm going to assume it's a decent modern language now, but what's the argument for using it instead of another mature dynamic language like Ruby or Python?

I have no metrics on this but I was under the impression that due to the size of the PHP community the package ecosystem specifically for web is probably larger. The community itself being larger is of course another plus as it means you're able to get easier access to the knowledge of others.

Thirdly of course the shared hosting providers (by what I've seen in the past) usually support PHP almost always - this is not the case for either Ruby or Python.

Performance is also better than Ruby and Python. While providing comparable development experience / ease of use.

> While providing comparable development experience / ease of use.

I would argue with that.

Part of my job is writing a lot of PHP currently (Hack actually, but they are very similar). Sometimes it's OK, but sometimes early PHP design decision to make code always appear working correctly and avoid raising user-visible errors really make me wish I was coding in another language. One of latest examples: when converting string to floating point number, sometimes you get 0.0 in case of parsing error, sometimes part of string is ignored.

Yes, PHP has some warts, but so do ruby & javascript [1], python [2], and all other similar languages. The keyword to look for people explaining some of these warts is "wat" (popularized by the talk at [1] I think).

[1] https://www.destroyallsoftware.com/talks/wat

[2] https://github.com/cosmologicon/pywat

Yup, for web stuff you’re right. Python has a larger overall user base, but much of that usage is in non-web contexts, whereas PHP is pretty single-mindedly focussed on websites.

'larger' in terms of what? I don't know what you'd have to do 'specifically for web' that you'd find yourself writing python and thinking 'damn shame there's no package for this'; and JavaScript's must be way (overly) 'larger' (package count) than that.

I didn't even realize shared hosting providers still existed. I thought everything was virtualized and containerized. But indeed, sites like Gandi.net sell shared hosting.

> what's the argument for using it instead of another mature dynamic language like Ruby or Python?

A massive body of existing code that you can leverage.

I keep putting off picking up PHP, but when you look at the number of off-the-shelf easily-extensible solutions for CMSs, CRMs, and e-commerce platforms, there's no contest. PHP wins.

If anyone can point me at a Python e-commerce solution that will let you deliver an MVP in an afternoon, and your first original feature within a week, that would make my month.

It's not exactly a language choice at that point. That's like saying C++ is a good language because Excel exists.

It's an argument for a particular tech stack that may have PHP in it. Excel is a bad example because it's closed-source and does not put a developer building a solution on top of it on equal footing with its creators. Wordpress is probably the best example here; if it does 90% of what someone wants, it may be easier to add that 10% than to use a different solution.

I'd be surprised, however if there aren't solutions written in other languages that provide that same 90% in most cases. None of them are as famous, but that shouldn't hinder someone working as a consultant to help small businesses get online.

Excel enables even less technical people than Wordpress configurers. It provides 99.999999% of the solution, and the rest can be done with macros, pivot tables, etc. That's why it's a good example, I'd say.

Extending Excel is a reason to use VBA, not the C/C++/C# most of Excel itself is written in. Extending Wordpress is a reason to use PHP.

In both cases, the merits of the extension language are almost irrelevant; people use them because they're the extension language for a popular platform.

I'm not sure the number of those should be a consideration, as you probably only need one or two of each. The quality or fitness for a particular purpose does matter, and I'll confess to not being up-to-date enough about that kind of software to make a good case for any particular package. They certainly exist for Python, and I can recall using Satchmo and Django CMS some time ago. Those satisfied the MVP in an afternoon criterion for a developer already familiar with them.

Ok, how about the number that are actually production ready?

Django CMS looks nice from what I've seen, I'll give you that.

I hadn't encountered satchmo before. Their website seems to be down now, which is not encouraging.

> Those satisfied the MVP in an afternoon criterion for a developer already familiar with them.

Which is completely missing the point. I got WordPress up in under an hour on my first attempt. How many Python solutions can claim that kind of learning curve?

Not sure whats wrong with https://saleor.io/ or http://oscarcommerce.com/ or any number of other options from https://djangopackages.org/grids/g/ecommerce/

I hadn't encountered saleor.io, thanks.

Oscar, from what I've seen, is very difficult to get started with. The code and documentation are rather hostile to newcomers. I was left with the impression that the documentation is designed to funnel you into associated consulting services, rather than help you get started on your own. I would love to be wrong about that.

None if the other e-commerce solutions on Django packages seem to have a sizeable developer community around them. I would be hesitant to use them for anything business critical, unless I had the resources to maintain everything in house.

Unless I'm drastically mistaken, PHP is faster than both ruby and python. There's no consideration of what we call technical correctness, only business value, and on the whole that is a good thing.

Most web applications are not bottlenecked by the execution speed of their backend language.

> There's no consideration of what we call technical correctness, only business value, and on the whole that is a good thing.

That's called technical debt. Taking some on may not always be a bad decision, but if there's a short-term gain (and I'm skeptical PHP provides one), it may come at a cost of future development slowdowns, downtime, a full rewrite, or a data breach.

In the case of PHP (a language I've used as day job for the last decade on large enterprise projects and other stuff) the speed of PHP isn't its issue.

Building the world to throw it away on every request is..compounded by the sheer size of the stack between the PHP runtime and a response (laravel is a particular problem here out the box).

You can do sorts of interesting things to get around this but there is no free lunch, they add complexity (caching, shared state, connection pooling) or change the execution model in ways you don't expect.

For all that modern PHP isn't a bad language, it's not C# (my favourite pragmatic language) but it's also not as bad as 5 was and certainly not 4.

It's biggest 'issue' on a wide scale is the massive disparity in skill levels covered by "PHP programmer" and how hard that makes hiring.

My advice is if you are building a small system or one that is tightly constrained then Laravel isn't bad but if you are building a big system or one that will grow over time, go with Symfony, it's more work up front (though not a huge amount) but in every other way future you will thank you.

> Building the world to throw it away on every request is

"Shared nothing" architecture has positive benefits too.

Absolutely and I regard it as a good feature.

It's just the size of the world varies widely and sometimes 80ms to build a world is simply too much.

I'd vager Wordpress? Maybe Laravel? So not that different from choosing i.e. Ruby to do your business-focused monolith and get payed :)

PHP has been optimized to death so performance wise it’s excellent (same as javascript, it should not have become so fast, but the sheer amount of work done on it gives it an edge).

The other advantage over ruby (python too?) is the server models bootstrap and trash everything on each request, meaning way less weird memory issues and more predictable behavior.

Nowadays nobody’s gonna run a php server ad hoc, so it will be wrapped in a container anyway, but IMO it’s still easier to manage than ruby/puma.

Last but not least, it’s very subjective but I think php has better enterprisy trade-offs than ruby: you’re not free to rewrite the whole language but have a decent degree of freedom in writing code with few boilerplate. Ruby gives way more freedom which is not always an advantage depending on the work culture.

I say that having left php for ruby.

Composer, Packagist, and PHPUnit are all excellent too.

If I must work with a bad language, I'd rather choose Javascript over PHP any day.

Actually, I often choose PHP over JS, because it has a lot more included in the basic runtime. The stuff I'd have to manage the dependencies for personally in JS, I have access to right away in PHP. Things like email message header formatting/quoting, PDO/database access, curl (easy to underestimate curl, but it supports much more protocols than just HTTP), XML parsing, DOM, CSV parsing, .... A ton of small things that add up in the end to an easier experience, when throwing together some quick project. And all these functions are standard, documented, dependable (all of these are there since 2006 or so, when I started using PHP, at the very least), and don't involve having to pull anything from an internet over npm that can be abandoned at any time by the uploader.

> Thirdly, Laravel, Symfony and other open source stuff are awesome.

I think PHPs biggest feather in its cap is Composer.

I can't even line a single script without it now. It really changed the usefulness of the language for me by many times.

Composer has changed my life as well, so incredibly powerful.

I love the patches package that can be combined with it, allows me to patch contrib modules or Drupal core in a controlled and transparent manner. This alone has changed my developer life.

I don't really see how PHP catching up to improvements that were made in other ecosystems suddenly makes it a better choice than it's competitor though. What is it actually better at? And as a developer, why should I bother with it when it probably has the lowest average salaries of any web technology AND isn't going to help me get shit done faster than several other tools that pay above average?

I’m not a PHP programmer but I used to be. It’s hard to overstate the simplicity of the deployment model. Your competitors will spend tens of thousands of person-hours chasing their tails around Docker, Kubernetes, AWS, Ansible/Puppet/Chef, etc. while you spend 15 seconds FTPing your source code around. LAMP stack achieved the “serverless” dream before many of today’s engineers were even born.

> Your competitors will spend tens of thousands of person-hours chasing their tails around Docker, Kubernetes

There are people who use all that stuff to deploy PHP-based apps too, though. One doesn't preclude the other.

Also ad hoc in-production debugging/observability is kinda easy. ssh to your server, add a log statement to code. Done.

I can't do that with a node app by default without restarting it, killing all connections, etc.

how is that any easier than dropping a fat jar or a binary on a server? its not like building those is difficult

Analogous to the ‘serverless’ platforms, there are many companies selling shared PHP hosting, so you can just upload your code and expect it to work without worrying about security updates, service management, configuring TLS, etc.

A fat jar dropped on a server doesn’t just run. You need something else to run the process, restart it if it crashes, manage log output, etc.

PHP is served as soon as it’s dropped into a DocumentRoot.

As a maintainer of small Wordpress and PHP forum installations I tried to use PHP for system administration scripts to avoid extra dependencies. It worked at the end surprisingly good, but only after I wrote quite a few lines of glue code to get sane behavior from PHP.

The biggest surprise was that on Linux one cannot call an external process directly. At least with PHP 7.0 one always has to use an intermediate shell and one has to use extra functions to escape strings safely.

So yes, PHP works, but defaults are insane and to make things secure and robust one has to use extra libraries.

https://www.php.net/manual/en/function.pcntl-exec.php

Choosing a language isn't like trading. You don't win by sticking to one. You rather lose by not knowing the strong points of each without trying any others.

Undeserved? Not really. Tell me another programming language that needed 3 tries to introduce a MySQL escape function. The future is Elixir/Phoenix or maybe also Python/Django. But probably not the pile of unmaintainable Code PHP leads to.

> The future is ... Python/Django

I don't normally do a 'ha ha' sort of post on things like this but... 'ha ha'. WTF?

That's a future with one hell of a long past that has not even begun to take over a small subset of mindshare. Python/Django is not 'the future' for anyone except current Django/Python devs.

How’s the Django job market these days?

>Thirdly, Laravel, Symfony and other open source stuff are awesome.

Most people talk about PHP the language but not its surrounding ecosystem. Yes The language run time went through lots of improvement, proper JIT landing in PHP8. But That is like talking about Ruby on Web Development without talking about Rails. ( Like it or not Rails easily represent 80%+ of Ruby's Web usage )

Laravel took everything that is good on Rails and its surrounding Ecosystem, ( Auth, SearchKick etc ) and packed it together. And the productivity I saw from those using it as a whole were amazing.

There are also a lot less ideology with Laravel. And try to provide decent usage in all usage scenario. Compare to Rails which is more of an DHH / Basecamp's framework.

I mean if Elixir and Phoenix LiveView dont pick up some mainstream usage I did imagine PHP with LiveWire will be making a come back.

I sometimes wonder if anyone had made something like CooffeScript, or Scala or some other language that runs on PHP run time with some sane syntax ( Excluding Hack )

For me the real php gem has always been Slim.

Reply on news.ycombinator.com