25 Years of PHP | Hacker News Reader

25 Years of PHP

jetbrains.com

454 pointsbrendt_gd412 comments

I wrote a lot of PHP from 1999-2008. First as a hobby, then professionally. From 20 LOC guestbooks to payment gateways used to process millions in payments. It wasn't until recently that I was sure I'd written more code in any other language than PHP. These days I'll occasionally poke around with it or patch a bug, but that's about it.

Is it a perfect language? No. But which language is? (I can hear the Lisp crowd grumbling.) It's fast. The only ceremony you need to write executable code is the <?php tag. It has a very rich standard library -- even if some of the function names make me want to stab people.

My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?

PHP has taken a lot of flack over the years. Mostly from people who never really worked with it. A lot of the criticism really should have been aimed at certain PHP developers, rather than the language or the community at large. PHP's low entry barrier is a blessing, it's how a lot of developers were introduced to programming. It's also a curse, because a lot of very inexperienced programmers managed to become prolific at getting code out there, code which was ugly, bug infested and a security nightmare. But it's not fair to attack a language over its inexperienced users.

While I agree that PHP does have pros as well as cons, I find it disconcerting that I've read MANY assertions here on HN, that PHP detractors just haven't used it very much or are mostly complaining about things like bad standard library function names.

I've used PHP in earnest. It and JavaScript are tied for worst programming languages I've used. JavaScript gets more of a "pass" from me because I'm just not a dynamic-typing fan and I'll admit that it might be less awful for someone who enjoys/prefers Python or Ruby or whatever.

PHP, on the other hand, is basically just worse-Java. And Java isn't a great language, either. The built-in PHP array is a constant source of frustration. Keys are sometimes strings, sometimes ints. And you don't always know which it is! This makes working with the array_* functions cumbersome at best. The fact that you can't typehint everywhere also sucks. No generics sucks. No threads sucks. No (real) async sucks. Globals suck (including different language behavior based on a config file on your machine...........).

It's just not a strong language. And I'm super-tired of hearing "it's not the tool, it's the user." There is such a thing as a shitty tool. And just because some human somewhere CAN write working code in Brainfuck, does NOT mean that anybody SHOULD. I'm similarly tired of "all languages have warts". Do I even need to actually explain the fallacy there?

On the other hand, I agree 100% that PHP's deployment story is awesome! But is that because PHP did anything useful, or because Apache and Nginx support PHP out of the box?

Just like I tell people that buy cordless drills at Harbor Freight, "sometimes it IS the tool". Does that mean you can't build fast, meaningful, cool things with it? Of course you can. But, the deeper you get, the more problems you'll have to solve with weird esoteric knowledge. I'll agree with all of your points on horribly inconsistent and broken language features.

I get that people that have grown up with the language, or folks who have used it full time for years, don't see these blemishes as that big of a deal. But to newcomers, or folks from other languages, it's an affront. I hate to pile on an old, worn out issue but, as a language designer/implementer, the moment you start working on `mysql_real_escape_string()`, a huge warning bell should have gone off! I'm fine if people want to question my competence in writing code. It happens all the time on HN. I've been at it for 20 years... so some rando telling me that I don't know what I'm doing is pretty common. What we find in PHP though is quite a bit of tribal/tacit knowledge. And it's wrong to blame the user.

I mean, who uses mysql_real_escape_string when you have PDO and bindings ?

PHP isn’t perfect. As OP said, no language is, and any competent software engineer uses the parts of the language that work well for them, and just ignores the things that don’t work for them. I don’t believe for a second that the abuse the language has suffered over the years has anything to do with mysql_real_escape_string, it’s more to do with crappy code. You can write crappy code in any language, and it’s more a reflection of the programmer than the programming language IMHO.

Part of PHP’s problem is that it’s so easy to use. Any C programmer can pick up the basics pretty easily, hack together something that scratches an itch, and move on. Later someone will criticize the quick hack and say “you didn’t use mysql_real_escape_string so that code has a SQL vulnerability. Don’t use PHP”. In reality, there are mechanisms for preventing SQL injection and they just weren’t used. Is that a failing of the language ? Partly, perhaps, for providing the unsafe way of doing things, but a lot of blame also lies with the coder.

I’ll admit to a soft spot for PHP - I was putting database-driven websites on the web when that wasn’t much of a thing (back in 1981, if foggy memory recalls true). I wrote the asset management system that was used by Lucasfilm on Star Wars, by Manix on the Matrix, by various post-production houses in Soho, etc. etc. - all in PHP. We had video-streaming from remote locations before RealNetworks were mainstream. All because of PHP.

I also used PHP to write a content management system for the RiskWaters Group - around 100 magazines in the CMS, with forums, mailmerge, access-rights per page or per view-count or per time-period, with back-end admin pages, with macros the editors could use, etc. etc.

Used properly and judiciously, PHP is a powerful tool. It comes with a few areas that ought to be marked ‘here be dragons’, but frankly so do most languages.

These days, I mostly use PHP for shell-scripting (it comes installed as standard on my Mac), nothing so grandiose as the halcyon days of yore, but I still have PHP to thank for getting the job I’ve had for the last 15 years, in R&D at Apple (“these are the guys that Lucas was talking about”, said the VP who bought my small company).

I’ll finish with a line from a song “Baby, life’s what you make it, celebrate it”. That applies to PHP as well.

You're using the two super-fallacious arguments I refer to in my original reply:

1. You can write bad code in any language.

2. All languages have warts.

My response to #1: Here is a rock. Please use it, with some nails, to hang a bunch of pictures on your walls. Don't complain about your tool because it's entirely possible to use it successfully at this task. Or, less sarcastically, why use a tool that encourages bad results when you can use a tool that nudges you toward better results?

My response to #2: Would you rather have one wart, or 100 warts?

> I mean, who uses mysql_real_escape_string when you have PDO and bindings ?

You've made my point. A person with tribal knowledge probably would NOT. Any new user coming from reading an older blog post or perhaps a PHP book would have no idea that that "older approach" is out of date.

Furthermore, the more precise point I was trying to make there was as a language designer, how on earth would you be okay implementing something like that? (Remove my example of `mysql_read_escape_string()` and insert any of the more WTF features of PHP.

Lastly, see my comment about being able to build meaningful, fast, cool things with PHP. I never want to tear down anyone's hard work. (Rasmus/Zeev/etc included).

1981? The title of the article is "25 Years of PHP", which checks out because PHP appeared in 1995, and this is 2020, and 2020-1995=25, but 1981 was 39 years ago. The ARPANET was using NCP with 8 bit host IDs in 1981, and nobody was listening for the HTTP protocol on port 80 back then, and homosocketuality was still prohibited.

https://news.ycombinator.com/item?id=14178993

>The act of trying to connect an even socket to another even socket, or an odd socket to another odd socket, was considered a "peculiar error" called "homosocketuality", which was strictly forbidden by internet protocols, and mandatory "heterosocketuality" was called the "Anita Bryant feature" [2].

https://www.saildart.org/allow/IMPSER.DOC%5bSS,SYS%5d

>Illegal gender in RFC, host hhh/iii, link 0

>The host is trying to engage us in homosocketuality. Since this is against the laws of God and ARPA, we naturally refuse to consent to it.

> Used properly and judiciously, PHP is a powerful tool.

What is a 'powerful' programming language?

And I think you've hit the nail on the head here. People who defend PHP as "not that bad" are probably people who have used it for so long that they just work around its insanity by muscle memory.

It is NOT okay that `foreach` leaves an allocated reference to the loop-local value.

And probably people who haven't used anything else, so they have no frame of reference to compare it to, which they would need to realize how terribly and unnecessarily bad it actually is.

I dont agree with you at all.

Why are you building arrays with mixed key types?

Why do you want type hints?

Why do you need generics in a dynamically typed language?

Php has pthreads. They just arent needed that often.

Async is being worked on You didnt mention it but immutable types are also being worked on.

Everything people complain about php over tends to actually make its way into the language eventually.

I dont know when you tried php, but I dont really think it was in earnest. It sounds like you had problems keeping your types straight.

I agree its not super natural to deal with the php type system but once you learn it its pretty simple to keep things in order.

I see most messes arise when people mix types, mutate variables carelessly, or otherwise over leverage things they shouldnt (e.g. globals)

But these are hygiene problems, and all languages have these.

Ive seen garbage java, ive seen hairballed rust, ive seen pretty much any c, ive seen wanky golang and ive seen babel-typescri-rea-tsx

The only thing that really annoys me about php these days is the dollar signs.

That and the frameworks are all trash.

I am reminded of 2 things while reading your comment:

1. The meme where someone sits in a burning house or room and says "It's fine.".

2. "Sweet lemons". That is the sort of psychological "strategy" that is often applied and that seems to be used here: Things are bad, so lets talk them good. It all sounds like "Oh come on, it's not so bad!", but that is not the point. The point is, that compared with more developed languages, things are objectively worse with PHP and no one should have to deal with its issues.

There are issues in programming languages, which cannot be fixed, except for making far fetching design changes to the language itself, unless you include the required tools inside the language, for modifying the language itself. Those are called macros usually, and I am not talking about C preprocessor macros.

To fix a lot of the issues PHP would have to change to a degree, where it is no longer PHP and it does not include the required tools for changing the language itself. It requires a commitee, which is apparently unwillig to fix the language, or is so slow at it, that we still have PHP in its current form after "25 years of PHP".

I think one important thing is the overall impact of bad decisions in language design, implementation & stdlib.

As a Clojure developer, I see plenty of things that might be better in PHP in language design (making existing syntax more powerful instead of adding more syntax), implementation (make sure there are no memory leaks for example), stdlib (make one big incompatible release and make sure all functions have consistent naming & parameters & return values).

But today, in the age of PHP 7, frameworks and thousands of libraries, short requests that make memleaks insignificant, I think PHP is an awesome productive language. A language purist who loves elegance (like me) would not take a fancy of PHP, but the same goes for Go, C, C++, Lua and in some way also Vala, D. These languages are just highly practical hammers. Nothing to love, nothing to play with. But boy, these hammers are highly productive and in the right hands and appropriate situation, they are very hard to outcompete.

For some people, using PHP can be the best solution (Do you know C-like languages? Are libs you need in composer? For such a person PHP might be a way to get the result fast).

That's why Hack was created by FB

> Why are you building arrays with mixed key types?

It happens on accident. All keys are converted to ints if they can be. So if you read a file that is called "123", it'll suddenly become an int key whereas all the rest will be strings. That's absolutely insane.

> Why do you want type hints?

The same reason anybody does. It is a contract and it makes your code more well-documented, more robust, and more correct. There's a reason that PHP has typehints and the consensus in all major, current, PHP projects is that they are good.

> Php has pthreads. They just arent needed that often.

Pthreads is garbage. Always has been. Never worked on servers. Is deprecated, finally: https://github.com/krakjoe/pthreads/issues/929 https://www.php.net/manual/en/intro.pthreads.php

> Async is being worked on You didnt mention it but immutable types are also being worked on.

PHP will be less awful when they're done. It's still awful today. I don't revel in PHP being bad. If it's good some day, I'll be happy.

> Everything people complain about php over tends to actually make its way into the language eventually.

25 years. 25 years and the language still sucks. Just use Java (or better yet, Kotlin).

> I dont know when you tried php, but I dont really think it was in earnest. It sounds like you had problems keeping your types straight.

I've been doing PHP dev for years now. Of course I had trouble keeping my types straight. PHP turns everything into a string whenever it can. Except sometimes it turns strings into ints for some unholy reason. Also, the type system (like Java's) sucks. It's not expressive at all and I can't even return a collection of a single type without resorting to language extensions.

> I agree its not super natural to deal with the php type system but once you learn it its pretty simple to keep things in order.

Not being natural is not the same thing as being broken. And being able to remember all of the gotchas doesn't make it simple.

> I see most messes arise when people mix types, mutate variables carelessly, or otherwise over leverage things they shouldnt (e.g. globals)

Agreed. So how do we avoid mutation? Use `clone`? Nope. It's shallow and everything is mutable by default. Overload `__clone()` on every class you write? Okay, but you better hope that your classes don't have fields that DON'T implement deep cloning...

> But these are hygiene problems, and all languages have these.

Bull. No language is perfect. But tell me, what's worse: 1 issue or 1,000 issues? Come on.

> Ive seen garbage java, ive seen hairballed rust, ive seen pretty much any c, ive seen wanky golang and ive seen babel-typescri-rea-tsx

See above. This is the most bottom-of-the-barrel excuse I keep reading over and over. PHP ENCOURAGES garbage code. Rust does not. Not even in the same ballpark. Not even playing the same GAME.

> The only thing that really annoys me about php these days is the dollar signs.

lol

“I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act.”

— Ken Pier, Xerox PARC, Preface to The Unix Haters Handbook

https://web.mit.edu/~simsong/www/ugh.pdf

Hey ragnese, thanks for your posts.

Re; the mixed int/string key issue with filenames being the key - what issue did you witness having a mixed combo of types for the key cause?

Or was it just that the types were mixed and this was unnecessarily confusing?

Thanks

all your arguments can be true or false. depending on the use case and the position you look from, a language can be defined good or bad. there is no objective answer. from a commercial point of view php is for example one of the best languages ever. from a technical perspective maybe not so much. please accept different realities. don't get stuck in your own.

I agree with everything you say here about PHP the language, having programmed in it myself (though not as long as you). It’s a big pile of terrible warts with hidden gotchas everywhere.

I think it’s important to distinguish between a language, and its environment and ecosystem. That’s where PHP shines. I wouldn’t choose PHP for my own projects, but with the tooling and frameworks available I actually don’t mind working on it for money.

No sir PHP is nothing like java ! PHP while not perfect gets out of your way and lets you code. Sure it's not perfect but start with one file and one tag , upload to server and you have have something.

Java: the amount of files and java-knowledge and xml files crap one has to go through... No thanks.. PHP might not be perfect ! But it's NOTHING like java.

First of all, I was talking about the language. Not the dev-ops. The language semantics are almost exactly Java.

Also, if you're talking about a single-file project, you can do that in Java, too, using plain old javac. It's not quite as simple as dropping a file on a server (but it's really damn close- first run javac, THEN plop the file on the server).

But you're fooling yourself if you think you don't have to do any setup to get a publicly facing PHP app to work. If you don't configure your Apache or Nginx or fiddle with your .htaccess junk, then you're not actually doing anything. So it's not fair to complain about "xml files crap" for Java and not discuss the equivalent for PHP, which is fiddling with php.ini and installing php_mod and configuring that in your Apache or whatever.

I am currently working on a Kotlin backend project and I haven't touched any XML. I've done plenty of Java/Kotlin and PHP.

Java has gotten much better on the xml front.

A lot of the tooling can abstract you from the brunt of it.

Have you ever played around with Kotlin?

Never say never my friend, as someone who has used PHP in the past I prefer Java by far. The streams concept/interface they have in Java is really cool.

I've built a lot of servers... and PHP support isn't "out of the box". It's just such a low cost of investment, that admins install it without much of a fuss... Until you start asking for additional support.

> PHP, on the other hand, is basically just worse-Java

It’s much more like C than Java. And Java was in its infancy when PHP came out so it makes sense that it’s inspired more by C than Java.

Incorrect. Old PHP was more like C. If you see a modern, best practices, PHP code base today, it reads like Java 7 did in 2011.

Whats old is new again.

Laravel et al read like java. Nobody wants that crap anymore. Everyones moving codebases back to more procedural styles with a good dose of functional leanings towards immutable values.

PHP is way less verbose. I wouldn't say it really looks like Java, maybe more like C++.

> Keys are sometimes strings, sometimes ints. And you don't always know which it is!

Could you give an example? Because I've never had any issues with it and find it very predictable.

> The fact that you can't typehint everywhere also sucks.

Type-hinting is being implemented and is already available in most places. But why you'd expect that in a dynamically typed language is beyond me.

> No generics sucks.

Again, dynamic language.

> No threads sucks.

pthreads has been considered stable since early 2014: https://pecl.php.net/package/pthreads

> Globals suck

Are you talking about "register_globals" which had its default setting changed to "off" 18 years ago and was completely removed 8 years ago: https://www.php.net/manual/en/security.globals.php ?

> But is that because PHP did anything useful, or because Apache and Nginx support PHP out of the box?

Do they? Last I checked you had to install and enable support for PHP just like anything else. Unless you're talking about bundles like MAMP, but then it doesn't really make much sense.

You may claim that you've used PHP in earnest, but I honestly find that a little hard to believe when seeing these claims. And I don't mean that I expect you to understand all the little edge-cases of type-coercion, but if you'd really needed threads I'm sure you'd have stumbled upon pthreads, and if you've been using globals, then you've been following some oooooold guides.

Your response is almost exactly the same as waheoo's. Please see my reply to his for everything you asked here.

Yeah, I noticed after I'd missed your reply there the first time around. Sorry.

I'm still confused about the array keys though. I'm not sure I understand the example you gave in your other comment.

And I'm also curious which Apache and Nginx has PHP installed and enabled by default.

You might be interested in this study I found. There might be more, but this was the first one:

https://www.i-programmer.info/news/98-languages/11184-which-...

"The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits."

People who demand a dynamic language needs to add strict typing and once it does, demand that it now add generics need to stay the fuck away from dynamic languages.

For sure. But let's be clear- I'm not "demanding" anything. I don't want PHP to change, I don't want to use PHP at all. I don't like dynamic languages.

BUT. Today's "best practices" for PHP are to use typehints everywhere. And there are language changes in the works to add MORE typing to PHP.

> I don't want to use PHP at all. I don't like dynamic languages.

Okay, so don't? I think individual languages are better when they don't add every feature under the sun that happens to be popular in the moment. PHP doesn't need threads and it sure as hell doesn't need async. PHP multiprocessing works the old way just fine (fork).

> Today's "best practices" for PHP are to use typehints everywhere.

Yeah, and it's a result of people constantly bitching about PHP lacking features. It's really annoying because it gives credence to complaints like this, I really wish they would have just replied to the strict-types demands with "No, fuck off, this is a dynamic language."

If you must use PHP, I would strongly suggest you use it the way it was intended and stop trying to shoehorn other language features and paradigms into it, you will be much happier. If we simply treat PHP as a dynamically typed C, everything is so much easier.

> Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE.

To clarify, comments never affect running code in PHP, ever.

What's often done however is that tools like ORMs, or web frameworks offer a 'compile' step that parses these annotations (just like it's common in Java) and dumps a PHP file that maps things in the annotations into actual PHP code.

For example, you can use it in Symfony to wire routes to handling functions in controller classes; or in Doctrine to help the mapper wire Entity classes to database tables.

If you don't like the idea of preprocessing annotations, you can totally not use them and configure everything using external YAML/XML files.

Yeah I worded that poorly, but once I went full on caps I decided to leave it, ahem :/.

I get the idea of a compile step, and that's totally fine. But these annotations are commented out. It's very icky to be using them for anything other than documentation -- which is what comments are for, after all.

Java's annotations are a bit different. Sure, the compiler does things with them -- the runtime does, too --, but they're syntactically part of the language. In PHP, they're kinda of not. Not yet, anyway.

Is a heftier compile step totally fine?

The biggest difference between PHP and Java in my mind is that you start Java and pay the compile cost on server start, in PHP you pay the compile cost on every request, frameworks and language features increasingly hide this future cost in caches but caches are one of the two hardest things in computing and often act like pushing things under the carpet, why optimise the compile? It's under the carpet

As we move closer and closer to Java's model, we get further and further away from that quick PHP feedback loop of, make a change press f5 see the changes immediately and quickly

Which puts us further and further away from the kind of ideals that Bret Victor mentioned in his very good talk inventing on principle: https://youtu.be/PUv66718DII which to quote: "Creators need an immediate connection to what they're creating."

Inevitably this is coming and is already here but we should recognise what we've lost

Meanwhile with something like NextJS/TypeScript/React you can just enjoy instant reloads without ever caring about F5 again

The more languages the better IMHO though

To be fair, I've been working in PHP for nearly 20 years and I've been able to avoid annotations almost entirely, except for that one time I used Doctrine and then threw it in the trash.

It absolutely shouldn't, but it _can_: https://www.php.net/manual/en/reflectionclass.getdoccomment..... Zend has/had support for parsing this value as well.

I distinctly remember writing a project in PHP that allowed users to create custom reports and flows based on values returned from the data models, and for whatever reason we decided to use PHPDoc tags to determine what routines would be exposed to the public for use in these tools. We of course eventually updated this to use DB definitions instead because it was an asinine idea to need to parse a bundle of models and other files every time you needed to pull in definitions.

Every time there's a story about PHP there's a comment like yours, and then in reply there's a comment like mine:

Yes it's perfectly fine to use PHP if it's a productive environment for you. Of course it's possible to write good software with it. Of course a skilled developer will manage to do great things with sub-standard tools. Many extremely popular websites were and even still are powered by PHP, that's undeniable.

But that doesn't mean that we should absolve PHP of all its many, many design errors over the years. There were for a long time many fundamental issues with PHP as a language that didn't exist with its peers. The language was not so much designed as it was cobbled together by amateurs starting from a half-backed templating engine.

I'm not saying that to hate on PHP, I just believe that it's important to learn from your mistakes if you don't want to end up reproducing them. It's important to acknowledge the many failings of PHP even if many of them are now ancient history.

This revisionist stance that there was never anything really wrong with PHP and it's just Lispers who hated on the language because it was popular and beginner-friendly and they didn't know what they were talking about is simply, factually, provably untrue.

> This revisionist stance that there was never anything really wrong with PHP

This strikes me as a strawman. PHP spent years being a generally loathed language for reasons that at this point aren't really worth reiterating.

But, in an analog to Javascript, it has made progress, grown up and become a better language. One of the best? Like Javascript, no. But serviceable at worst.

I stopped earnest work in PHP ~ 5.7. I dabbled with HHVM, but eventually moved most backend/server code to Go and moved on with my life. But PHP 7+ has been a big step up, at least from my current vantage point.

>This strikes me as a strawman. PHP spent years being a generally loathed language for reasons that at this point aren't really worth reiterating.

This story is called "25 years of PHP" and the parent starts their comment with "I wrote a lot of PHP from 1999-2008". In this context I think it's fair to remind people of the many... controversial choices the PHP developers have made (or, maybe more accurately, stumbled upon) especially early in its history.

I certainly hope that most of these earlier flaws have been addressed, and I'm willing to believe that modern PHP can be a much better language to work with but that doesn't mean that we can say that criticism wasn't ever warranted. Lest we forget this is a language that once shipped a function called "mysql_real_escape_string" and saw nothing wrong with that and a tertiary statement whose precedence works backwards from any other language with a similar construct.

Really, though, who denies the language has a very bad reputation? A lot of these decisions were questionable, but explainable, like mysql_real_escape_string coming from the MySQL C code itself.[1] that doesn't excuse it, but it explains it.

[1] https://dev.mysql.com/doc/refman/8.0/en/mysql-real-escape-st...

Javascript has made progress too. While far from perfect and I think PHP's journey started at a worse point has has gone further JS certainly is a lot better now and the major failings of JS are of it's ecosystem and not the language itself.

I also think that both JS and PHP get a lot of flak for maintaining backwards compat as far back as they do. You can run a lot of webapps (frontend and backend) from 10-20 years back in modern PHP and browsers which is pretty amazing. I'd like them to have a modern mode (like the proposed p++/<?php2020 and modules for JS) we should still acknowledge that maintaining compat that far back is not easy.

If you don't do that, you get the python 2 to 3 transition. Which is still going on.

PHP did drop some stuff between 5 and 7, but all of it had been marked deprecated for some time prior (often years).

> Javascript has made progress too.

To be clear, this is what I was saying when I called upon it as an analog.

No one is claiming that PHP is and/or was without fault. The sentiment is that we built things that worked despite them.

That's not being fair. There are many comments on HN of people saying exactly that PHP just isn't bad. The grandparent reply even says:

>My only real gripe with PHP is the annotation syntax.

I never said it was the only problem with the language. I said it was the only one that really bugged me. You're more than welcome to attack my opinion of PHP (which seems like a silly thing to do, but you're welcome nevertheless), but please don't put words in my mouth.

The parent comment claimed that PHP's former sins were being absolved. The quote you are referencing is about the current state of PHP.

From a language design perspective, you're absolutely right. I started with PHP 3, shortly before PHP 4 was released. 4 and 5 were major improvements over 3. And sure, a lot of cruft remain(s|ed). And there are definitely things that could be better. But overall, it's a pleasant language to work in.

> The only ceremony you need to write executable code is the <?php tag.

This is a hugely underrated benefit of PHP overall, and arguably the one reason better designed languages won't replace it for web development purposes. You don't need a command line or SSH access or server management knowledge or many resources/A VPS or dedicated server or well, pretty much anything.

It's also why about 99% of fancier, more up to date alternatives to software like WordPress or Media Wiki or [various forum scripts here] don't catch on too. The older software can be installed/maintained by people who aren't very technical, whereas many attempted replacements require you to be a developer/server admin to understand the install process.

Anyone who truly wants to replace/be rid of PHP should come up with a language that works in much the same way.

Well even bigger reason might be the overhead of php apps. PHP is poormans Lambda. It allows many apps to live on same server and only take resources they need.

It's not pretty but this allows shared hosting to exists. Those power big chunk of the content of the internet.

> The only ceremony you need to write executable code is the <?php tag

This is a really underappreciated aspect to development in general and web development in particular. There are (or at least were) an awful lot of "shared hosting" providers which are cheap, convenient, and run PHP and CGI only.

ColdFusion, Java Server Pages, and other languages copied this syntax. I don’t see it anymore except with php. Does anyone know of any other languages still in use that have this?

As the other comments say, it's not what the syntax is but the way it managed to get itself integrated into the webserver, originally via Apache mod_php. (mod_perl and even mod_tcl existed but were nowhere near as popular)

I believe mod_perl had the 'benefit' of persistent/shared state, which meant multiple users might conflict with each other (via shared memory, IIRC), and the mod_php - while it kept an interpreter bundled in each apache process - didn't leave anything around after a request.

Perl5 has HTML::Mason which runs on Apache mod_perl. The reason that never caught-on is the liability of running mod_perl compared with mod_php which is much better at isolating global variables.

I thought the comment was talking about PHP already being installed, so you could just start using it.

You can do it in a lot of templating engines like Jinja2 and ERB.

That's not comparable with PHP as ERB files are not executable by default within the document root.

> It has a very rich standard library

Yet I still have to define startsWith() and endsWith() any time I touch PHP code...

(More importantly, PHP is the one language I can never write from memory without referencing the manual for each and every function call because of how inconsistent it is. Eg Sometimes $haystack is the first parameter and sometimes it is $needle.)

This is my problem with PHP. Python for instance has it's own issues, but after coding in Python for awhile I can just guess the interface of various methods etc and be correct almost all of the time. PHP in comparison is so egregiously inconsistent that I have to reference documentation constantly. Python, Go and even Javascript are light years beyond PHP quality-wise (I'm comparing to those 3 languages because they're the ones I use daily right now).

There was an RFC for that, but it was voted out: https://github.com/php/php-src/pull/2049

str_starts_with() and str_ends_with() are coming in PHP 8.0.

That would be str_starts_with() and strendswith(). &$ing up functions names is a feature of PHP.

> My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?

It's a workaround to copy Java's annotations which IIRC also came from javadoc. PHP-8 is adding proper annotations as well. In general being able to add parseable meta information to your code can be quite useful.

> My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?

That will change in PHP 8 with the introduction of attributes (https://wiki.php.net/rfc/attributes_v2).

I'm firmly in the Lisp crowd.

I loved to hate PHP until I was forced to dig into it to help a friend set up a Wordpress site. And now I don't hate it any more. It does the job it was designed to do in a reasonably non-horrible way. I don't think I'd ever try to build a Facebook-scale app with it ;-), but as the BASIC of web site creation, it doesn't completely suck.

facebook was built and grew in php tho

And then decided to ditch it for its own version: Hack!

Did you notice my ;-) ?

I also wrote a lot of code in PHP back in the day - although less than you, it sounds like.

I started using PHP just before PHP 5 came around. And let me tell you - working with legacy code that used magic quotes or auto-globals is the reason I'm a die-hard strong type programmer today.

On the other hand, PHP didn't get in the way. It gave you a simple way to map a URL to a piece of code, and then let you respond to the request however you wanted - without "middleware" and "routers" - or "servlets". I sometimes miss that.

Good grief. Magic quotes was such a terrible to work around a terrible problem. Let's try to fox SQL injection by magically messing with user input in the assumption that it will end up being appended to an SQL query Yikes. You'll be pleased to know the feature no longer exists. I haven't mourned its loss. Disabling that was a mainstay of any PHP config I touched.

> A lot of the criticism really should have been aimed at certain PHP developers, rather than the language or the community at large.

Communities should be kept responsible for setting quality standards or failing to do so.

+10000000

PHP has been horrible at maintaining the core library. The core library is a guide for developers, as to what their code should look like. (Brian Goetz goes on a long talk about the fact that all of your code is an API, even if you don;t mean it to be)

That's why every time I chastise Scala developers and Martin Odersky for symbolic operator overloading. The guy talks at length about how it's wrong to abuse the symbolic operator overloading in creating unintuitive operators.... and then introduces :$#@%$%$%:;:/ operator to create a list.

>My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?

Agree. The first time I ran into this, I was completely confused as to why my code wasn't running as expected. Then I noticed the strange formal structure of the comments, made changes there, and voila.

I don't understand why that feature wasn't implemented as decorators or some kind of function code. If anyone has any resources/thoughts on why this path was chosen, I would be interested in seeing them.

It's pretty terrible. ORMs like Doctrine use annotations because their philosophy is that a data mapping class should be a pure class that you decorate with annotations. I personally hate that approach and have had no issues avoiding this path over 20 years of PHP development.

> Is it a perfect language? No. But which language is?

This has got to be one of the worst arguments (or rather, pieces of rhetoric) there is [0].

[0] - https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac...

Something about perfect being the enemy of good comes to mind..

Nothing "wrong" with PHP itself, but it's clearly not designed for modern web programming patterns which makes it feel outdated. No separation of model-view-controller, not friendly for API or AJAX, no class structure until later add-on, and so on.

That's because PHP, like Ruby, Python and Javascript, is not an MVC framework. If you want that you have Laravel and Symfony. PHP, Laravel and Symfony are perfectly fine for returning JSON instead of HTML. I don't get your point. As for classes PHP has had them for 16 years.

Please use a framework - Laravel / Symfony has all of these

it's the most friendly kanguage for ajax. Nothing beats json_encode in simplicity

While <?php ...> and its equivalents for ejs, asp, or jsp are useful and a defining characteristic of PHP, it is implemented carelessly and prone to injection attacks. Using an SGML processing instruction for integrating scripting into markup languages is only a means of last resort when SGML has much better, type-safe expansion and processing features. "Modern" PHP leaves embedded PHP more or less behind in favour of Java-like frameworks, custom template engines, and other code-heavy approaches. However, the more PHP becomes like JS, the less there is a reason to use PHP over JS (which is at least standardized and has an extremely rich ecosystem) IMO.

How is PHP becoming like JS?

I agree with you. PHP did its job. For years it provided features no one had. Actually i find it funny people who didn't code in PHP criticize it. Or, even better, if JavaScript, Node.js, ASP.NET or TypeScript brag about how PHP is bad.

> PHP has taken a lot of flack over the years. Mostly from people who never really worked with it

Detractors of PHP were pretty quiet when this first hit the front page. I think things might have stayed quiet without this first salvo being fired.

>My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?

Don't check out Golang then...

Could you elaborate?

They use comments for compilation directives, build instructions, code generation and other such stuff.

https://dave.cheney.net/2018/01/08/gos-hidden-pragmas

https://dave.cheney.net/tag/build-constraints

https://blog.carlmjohnson.net/post/2016-11-27-how-to-use-go-...

The "annotation syntax" is becoming a language feature with PHP8 attributes.

> My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?

Hey, think about it: in Python we have type annotations that are in code, not comments, and yet THEY DON'T AFFECT RUNNING CODE ! ;-)

> But it's not fair to attack a language over its inexperienced users.

I wrote PHP code in roughly the same period as you. Before a certain point, PHP actively promoted bad practices which was not helpful to the inexperienced users.

PHP also has great bindings for openssl versus the incomplete pyOpenSSL library in Python.

> PHP's low entry barrier is a blessing

That's the error.

What's up with that elitist attitude? Are you saying that people shouldn't be able to write code unless they've first how to do it properly?

I think he's saying that PHP enabled a lot of people to build disastrously broken systems to do jobs they had no idea how to do.

I worked for a shop in the past that had this problem in spades - huge ColdFusion and PHP ecommerce sites that were a gigantic ball of horrifying security and functionality failures, started by people who taught themselves how to program on the job because someone said "we should sell our stuff on the web".

I guess the world is probably net better for those sites existing, even as they are, but it feels like PHP could have done a better job of helping learners not shoot themselves so violently in the foot.

No, obviously. They should not be able to have that code uploaded into package managers without any form of peer review and vetting.

Academic journals, book publishers, Linux distributions do vetting.

Reputable journals, publishers, distros are more strict than non-reputable ones.

Universities do exams. Companies do interviews.

Why is it acceptable that some software communities have zero standards?

    some of the function names make
    me want to stab people

What would be an example?

    My only real gripe with PHP is
    the annotation syntax

What do you mean? Afaik there is no "annotation syntax" in PHP. Could it be that you confuse what certain frameworks and IDEs do with PHP, the language?

Function names are rather inconsistent.

get: gettype get_class

str: str_ireplace str_pad str_repeat str_replace str_shuffle str_split str_word_count strcasecmp strchr strcmp strcoll strcspn

encode: base64_encode quoted_printable_encode session_encode rawurlencode urlencode gzencode

php: php_uname php_sapi_name php_logo_guid phpinfo phpcredits phpversion

htmlentites: htmlentities html_entity_decode

to: stream_copy_to_stream strtolower strtotime strtoupper unixtojd

2: bin2hex deg2rad hex2bin ip2long long2ip nl2br rad2deg

I have heard—and I do not recall the source for this, so it may be incorrect—that when PHP was originally being written, the hashing algorithm for function calls used the length of the function name as its primary key. Thus, making each function name a slightly different length made the code run faster.

Of course it would've been nice if, at any time in the past 20 years, they'd gone back and standardized those function names (possibly also adding some kind of backwards-compatibility shim for people who absolutely cannot update their ancient codebase with global search-and-replace), regardless of whether the story is true.

That reasoning is true to a third.

Length as hash was indeed a thing in PHP/FI 2.

Second third to the reason is that PHP often takes names from underlying C libraries. strlen is strlen since that's the C name etc.

Third third reasoning is that early PHPade it easy to contribute. You had a need and a patch - a few minute Slater it is in. Nowadays there is more of a debate and vote before things are added (in my personal opinion too much emphasize on voting, but, well that's how things go, some day the process will be relaxed again ... and strengthend ... and relaxed)

Cleaning this up isn't trivial. There eis sooooo much code written already. There are sooo many tutorials, books, articles, magazines, videos and muscle memory making a change hard, even ignoring that for many things there is no single truth about what is best.

From time to time some modules might see replacements with more streamlined APIs (i.e. Maybe someday one figures out what a good and practical Unicode aware string library might be, which might replace the classic string mess) but those are multi year things.

Not to mention array_reverse (or is it reverse_array, I forget) which returns a new array leaving the original intact, whereas the sort functions return 1 and operate on the original array in place.

Also, why is it array_reverse, but rsort? I dunno.

> What would be an example?

The mix of c like strpos, strstr and inconsistent parameter ordering (see array map and filter for example)

> What do you mean? Afaik there is no "annotation syntax" in PHP. Could it be that you confuse what certain frameworks and IDEs do with PHP, the language

If there's no official standard, but everyone follows a community standard, then that is the standard. Quit being pedantic.

Hopefully PHP 8's attributes work to fix the mess that is phpdoc being used for annotations.

There's possibly an argument that reusing C names when you're wrapping or emulating C functions is actually a good usability design choice which has, over time, become a negative.

Like a floppy-disk save icon, what helped one generation becomes obscure to the next and they obly see the flaws.

>Hopefully PHP 8's attributes work to fix the mess that is phpdoc being used for annotations.

PHP8 annotations won't allow nested annotations so its only a partial solution.

Stab?

So, all your work must be completely perfect and makes everyone happy?

It's easy to criticize but I don't get how people become so offensive with the wording.

PHP is damn fast now, no joke. And with all of the modern features it's actually not so bad to work in.

I'm becoming increasingly puzzled every time I see PHP hate now, especially when I read tired comments like "just use rails". Laravel is arguably as good or even better than rails at this point, and PHP 7+ is definitely light years faster and lighter.

One thing that still sucks is package management / composer.

> One thing that still sucks is package management / composer

What about Composer? Sure is in par with Slack when it comes to memory usage, bit it's functional and feature rich. v2 has partial offline support, faster downloads, etc. (https://php.watch/articles/composer-2).

Composer IMHO is one of the best dependency managers for any language out there.

Disclaimer: the link above is a for a site I maintain.

Having to setup 10gb swap to get it to work is pretty awful.

I've never had to setup swap for a composer install on any machine with >1gb of memory..

composer is so slow tbh. It takes ages to download package and well requires me to setup swap even when i have 4 gb ram in server.

I've never had issues with this, what sort of maddening package management are you doing? Are you just talking about installs that's only an occasional hit anyways...?

Have you used prestissimo? It allows parallel downloads and makes the process much much faster. https://github.com/hirak/prestissimo

I'm not sure how it compares, but an alpha for Composer 2.0 was released last week[1] and the release notes seem to imply that it runs in parallel by default now.

> Added support for parallel downloads of package metadata and zip files, this requires that the curl extension is present and we thus strongly recommend enabling curl

1: https://github.com/composer/composer/releases/tag/2.0.0-alph...

Yeah, using prestissimo makes package installation sooooo much faster. My Laravel project with over 100 dependencies downloads in under a minute, where it was like... 10 minutes before

The speed is the main reason I decided to experiment with building a Node.js module last week that allows you to use PHP as a templating engine for Express apps: https://www.npmjs.com/package/php

I had guessed that PHP might be faster than mainstream JS-based templating systems like EJS and in my tests so far in an app I'm building it appears my guess was right. Even with the overhead of serializing and deserializing the data model from Node to PHP, on one of my more complex templates the PHP version outperforms the EJS version by around 10%.

Did they seriously take the "php" namespace in the registry?!?! That shouldn't be allowed.

Originally the php module on npm was used by a separate project that attempted to implement a PHP parser in JavaScript for Node.js, but was never finished. One work in progress version was published, then the project remained stale for 8 years. I spoke to the owner of the package and asked him to transfer it to me and he graciously agreed.

Is 10% enough to switch though ?

This is honestly the first I’ve ever heard anyone complain about composer. Having experienced a number of other package managers, composer is by far my favorite. Like have you spent any time with npm? Composer is light years ahead in reliability and expectations matching reality.

The amount of fighting I've had to do with setting up NPM for legacy applications, or with any sort of virtualization is insane. I no longer set up Node/NPM on anything automated without NVM, since they seem to drop support for old packages at random. You have to jump through a ton of hoops to make NVM play well when it's effectively installed by root but ran by another user within the container. Running NPM in a unix VM on Windows means you have to update everything with --no-bin-links since symlinks aren't well supported, and there is no fallback. It's baffling that they haven't had some sort of manual copy management when a symlink can't be created.

Meanwhile, I setup composer in a docker file in 4 lines (download, run, move to bin, cleanup), and it works everywhere for any user, respects permissions, etc. I don't think I've run into a single error on composer that wasn't something like a mis-typed command, package, or a host being down.

Funny! I'm dealing with a very similar problem right now. We're trying to port our CI workflow from DroneCI to GitHub Actions and our private NPM packages have been a literal nightmare. In comparison, our private composer packages worked fine with very little fuss.

What are the "modern" features of php? It looks like it's trying to shed it's dynamic nature and add types (with annotations etc). Also frameworks like Symfony / Laravel look more and more like java web frameworks to me. I'm not saying this is necessarily bad but there's nothing modern about types. Also, might make more sense to choose java if you need types.

The biggest advantages of PHP over Java are build and deploy times, so coding a php app is much more rapid. You can test your app right away, even after a single line change and get immediate feedback on the screen, which I think is important in web dev because a lot of it is visual. The other advantage is the run-time. Java has a slow startup time and when you redeploy then you need to stop/start your entire app. With php you can fix / update one part of your app without the need for a server restart. Another advantage is that php runs each request with a clean state, that means all the variables get destroyed after the request, helping to avoiding memory leaks, and possibly issues with concurrency which Java exposes. Types are great, but sometimes they can get in the way too and slow you down, (I still haven't figured out what those <funny> types mean). In all, development in PHP is so much faster and easier over Java.

> Another advantage is that php runs each request with a clean state

PHP apps are almost guaranteed to be "stateless", thus scaling up and down is quasi-painless also.

OTOH, sometime you need state, then you feel stuck with a half-finished language.

Recently did some nodejs work. It was surprisingly fun. There are A LOT of sharp edges, but working "closer to the metal" is great. Fast deploy and startup is GREAT.

Am an early, vocal Java partisan. Java world HTTP servers fell into a ditch and kept digging. Servlets and JSP weren't too bad. Wasn't crazy about Tomcat or NetSuite, but ok. Then it just got more and more nutty. J2EE, Spring, XML, schemas, annotations, etc.

There's nothing about Java that rules out simple and quick. For medical records stuff, I replaced a huge J2EE/BizTalk style backend with stupid simple process runner for stupid simple tasks. Think Windows OS Task Manager running AWS Lambdas.

In conclusion, I remain sad about the enterprisey detour Java took.

> Another advantage is that php runs each request with a clean state, that means all the variables get destroyed after the request, helping to avoiding memory leaks, and possibly issues with concurrency which Java exposes

Care to elaborate? How is that different than java web frameworks?

In a Java web framework, your classes have static fields, so user code or any library can assign values to them.

Language support for a request being ephemeral is far more effective than frameworks proposing it as a good practice.

And everyone working on PHP libraries in C know what a request is and that it ought to be ephemeral, so even outside the core language there's a clearer understanding.

For one step beyond edit/save/refresh try repl development in Clojure where you get the benefits of the JVM without the startup penalty. After the initial boot, that is.

For what it's worth, Java has hit code reloading, even though it doesn't work perfectly all the time.

> Also, might make more sense to choose java if you need types.

Java is not a replacement for "PHP with types". There is currently nothing you can deploy as easily as a PHP web app. The operational overhead is very low because cheap, robust hosting providers have decades of experience with the most typical LAMP style stack.

I would also disagree in terms of language features. Gradual typing through type hints (and other 'on demand'-style consistency features) is a very ergonomic way to introduce consistency during development (plus implied performance optimizations). You write in 'free-dynamic-mode' initially and then add type hints where they make sense bit by bit, typically in function signatures. There are many examples of this in the (semi?) dynamic world.

You couldn't be more wrong about the ease of deployment.

PHP is one of the hardest things to deploy. You need at least a web server and a process manager. Most popular choices are nginx + PHP-FPM or Apache + libapache2-mod-php.

You also need to learn how to properly configure both of them, since both have like a million options, and default installation doesn't work in a lot of cases (e.g. uploading of files larger than a few MB).

If you don't want to use libapache2-mod-php, you will have to figure out how to deploy two different services, which makes things difficult in a Docker environment.

---

As opposite to that, deployment story with Go, Rust, and similar compiled-to-a-single-binary languages, is a lot easier. Just drop the binary to a server or add it to a Docker container.

Many smaller PHP web sites are deployed on VPSes and managed with CPanel or Plesk control panels. None of what you describe is necessary. The web server is pre-configured and PHP settings can be easily changed. Even setting up PHP on Ubuntu or CentOS is a 5 minute job. Tweaking configuration settings for max upload, max post size, etc. are very common and well understood.

Once everything is in place, most deployments are as simple as copying the new build over and changing a symlink. No process restarts, nothing.

Seconded. I was left scratching my head for a long time trying to work out why php-fpm, when reloaded via systemctl on CentOS 7, was not setting-up /var/run/php-fpm.sock with the correct ownership. I eventually had to write a shell script to resolve the issue. The version of php-fpm in question, by the way, was a more up-to-date version than the CentOS 7 default. Anyway, that's just one example of how mdoern PHP deployments differ from the over-hyped static deploys of yesteryear where you just FTP a bunch of .php files into your DocumentRoot.

Whatever the language there is always a group of people slowly turning it into Java. It seems almost impossible to say no to new features.

Dart is another example. Not exactly Java but certainly built in its likeness. What is it with aping Java's verbosity which, to many, is an embarrassment?

Symfony is directly inspired by Spring, and Laravel is an based on Symfony, so yes, that's the direction they are going.

I kinda hate that trend, but it satisfies a cross section of devs who want "serious" enterprise looking code base but don't want to move from PHP. It's still noticeably different from Java, even with the heavy typing and all the inspiration.

Laravel uses some Symfony components, but it isn't based on Symfony. Laravel was heavily inspired by Rails.

A lot of PHP work is digging around in Wordpress themes & plugins with a bunch of other (third-party) themes and plugins installed, some of them paid which can add another layer of annoyance to testing and deployment and such. Hosting's usually some managed thing rather than anything under your direct control, and usually quirky or limited in some way or another. It's a pretty miserable ecosystem to work in.

PHP itself is, secretly, actually kinda OK. Some major codebases written in it are no fun at all to work with, including the 800lb gorilla that is WP.

Interestingly enough, there was a commit to WordPress core to bump the recommended PHP version to 7.2

If users are running below that, they'll got a notice telling them to contact their hosting provider and get them to upgrade.

https://twitter.com/schlessera/status/1270788445808537604?s=...

Combined with the JS work going on in WP, it's going to be an interesting 5 years I think. I would not be surprised if a lot of WordPress core starts to get rewritten. I know many of the large plugin authors are already pushing full steam ahead with modern PHP features and dropping support for old versions. Now that core can "take the blame" it's a lot easier to justify and I don't blame them.

Just when you thought it couldn't get worse there's Magento.

You don't know how good you have it with composer until you try other package managers.

I took a look at it about 1,5 years ago while having worked with very early versions (2, 3 or 4?) as a teen. It was the first language I put some effort in to learn more about. Not that I remember too much, but it is a complete different language by now.

I would have thought only dinosaurs like Algol or Fortran can be that old.

Composer 2 is coming, and so far it’s shaping up to be vastly improved.

Also, many people are still using that ‘fractal of bad design’ article from years ago to bash on PHP, even though a number of the assertions are no longer applicable.

The point of calling a "fractal" and talking about the "design" is that while you can only look at the surface in an article of reasonable length, it points toward strutural and systemic failings within the language itself.

The problem is that PHP is built on bad foundations and while many of the superficial problems can be mitigated, the underlying foundations can't be fixed without breaking changes. (Or, as Python proved, even if you make breaking changes, you may still not fix many core issues.)

All languages get this way over time, usually as decisions that made sense early on become baggage. But when a language makes poor decisions early on, it accelerates that timeline.

All languages? Ruby doesn't seem to have suffered this fate. Still as elegant and full-featured as ever. Clojure just goes from strength to strength.

yet you don't see articles about how bad python is, it still receive lot of praises and much love. This is telling a lot about how fair are some comments about PHP.

Python received much of its latest praise from introductory level college students that haven't done much programming other than "import numpy". I've used python and sure i like it better than other "bad languages" but when you look around in the real world you see that it's not the best or the most popular choice.

- cloud/ops space has moved to Go

- Java/C# are overall better languages and more productive environments than python for large scale services.

- A million websites still use php and the community is thriving. Billion-dollar companies use ruby to transact billions of dollars (stripe,shopify).

- Js is eating the world

Python found its niche in AI/ML space and sure is a great language but that's it?

Python gets love for a number of choices it made right early on, and that its core langauge is obviously well thought out. Even very old Python is generally readable and clear; except for some colons, it looks like pseudo-code.

This is the same reason I think Java gets a lot of respect: they had a few core language design ideas and built the language around them. People will say COBOL's syntax is horribly verbose, but you can see what they were trying to do.

So you might dislike those choices, but your critique becomes about the consequences of the choice, which implicitly is something the person making it can't know at the time.

With PHP, people are complaining that users have to live with a whole host of accidents or poorly thought out ideas that are now baked in.

Other languages get criticized for that, too. Python was hammered over their poorly thought out support for unicode in Py3K[4], which blocked many distros from supporting it until around 3.4. (And, generally, most people agreed Python3 was a mess until ~3.6 and the whole transition is widely seen as a case study in what not to do.)

Java gets dislike for similar bad choices. Java's Date class is pretty notorious[2] as a how-not-to. Java arrays are covariant, and it was staring them in the face as they coded the ArrayStoreException[5] to deal with otherwise perfectly valid assignments. But the .NET one-upped them by knowingly making their arrays covariant, despite knowing it was a problem in Java. (Probably to make it possible to run Java on the CLR.)

To pick on Javascript, critiques of promises[3] center around the fact that people proposed using monads, and the designers brushed it aside as theoretical. The famous 'wat' presentation[1] talks about behavior in Javascript (and others) that is magical and bizarre, and it's principally because Netscape has some neat ideas they didn't think through.

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

[2]: https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-...

[3]: https://github.com/promises-aplus/promises-spec/issues/94

[4]: https://click.palletsprojects.com/en/7.x/python3/

[5]: https://docs.oracle.com/javase/7/docs/api/java/lang/ArraySto...

Years ago on GitHub when the new Composer logo was just pushed, I commented (on the relevant commit) that it looks more like a "conductor" than a "composer" or perhaps they meant "composer/conductor" which isn't uncommon in the music industry. My comment was promptly deleted. Oh, well.

> not so bad to work in

Yeah, if you know it well enough, maybe. It's horrible to work with as a newcomer or someone who only needs to touch it once in a while.

I'd be interestd to see how much faster Laravel is compared with Rails and also how they compare in memory usage. Last time I looked on Techempower I was surprised to find Laravel performing more slowly than Rails in some of the examples.

> One thing that still sucks is package management / composer.

How? I mean, what are the problems with it?

Personally it's mostly composer update and require that fail in docker or a VM because of the memory requirements, otherwise it works well.

Also I hate json for config files because you can't comment things.

To be fair most package managers suck.

What do you dislike about composer?

"Smarty released. The best-known templating engine for PHP.

Rasmus realized that he had done something wrong when people started writing template engines for his template engine in his template engine"

Yes. The thing he did wrong IMO was to unleash a scripting language hiding in SGML-ish processing instructions without HTML-aware context-dependent escaping upon the world (when SGML has plenty of rules for delimiter recognition in particular parsing contexts), and then later make up for this with braindead quoting routines (like real_escape_string). In other words, the quick and dirty way was chosen, and that choice has plagued websites in the form of injection attacks (and DDOS using PHP injection attacks targetting even non-PHP sites) to this date.

When the guy who created Smarty (his name escapes me) and announced it on the core PHP developers mailing list, the other developers practically begged him not to release it and told him outright how redundant it was. He did it anyway. PHP may deserve some hate but we shouldn't blame PHP for Smarty existing.

You end doing real, production work on some codebase that uses Smarty. You grasp why. Your next PHP project uses Smarty because you learnt some good things about it. Always balance the pros and cons. Until real world work is done, almost all hate is based on judgement done in blog posts.

I strongly agree Smarty is beyond terrible (and I've used it and read the source code, so I know its problems first hand) and the fact that it even exists is indicitive of deep flaws in PHP, but I don't believe Rasmus has ever realized that he did anything wrong. He just doesn't care.

"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I DON'T CARE about this crap at all." -Rasmus Lerdorf

"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say Yeah it works but you're leaking memory everywhere. Perhaps we should fix that. I'll just restart Apache every 10 requests." -Rasmus Lerdorf

https://news.ycombinator.com/item?id=20736574

DonHopkins 9 months ago | parent | favorite | on: YAML: Probably not so great after all

One of the most ridiculous examples of this was the Smarty templating language for PHP. Somebody got the silly idea in their head of implementing a templating language in PHP, even though PHP is ALREADY a templating language. So they took out all the useful features of PHP, then stuck a few of them back in with even goofier inconsistent hard-to-learn syntax, in a way that required a code generation step, and made templates absolutely impossible to debug.

So in the end your template programmers need to know something just as difficult as PHP itself, yet even more esoteric and less well documented, and it doesn't even end up saving PHP programmers any time, either.

https://web.archive.org/web/20100226023855/http://lutt.se/bl...

>Bad things you accomplish when using Smarty:

>Adding a second language to program in, and increasing the complexity. And the language is not well spread at all, allthough it is’nt hard to learn.

>Not really making the code more readable for the designer.

>You include a lot of code which, in my eyes, is just overkill (more code to parse means slower sites).

https://web.archive.org/web/20090227001433/http://www.rantin...

>Most people would argue, that Smarty is a good solution for templating. I really can’t see any valid reasons, that that is so. Specially since “Templating” and “Language” should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is “better for designers, since they don’t need to learn PHP!”. Wait. What? You’re not learning one programming language, but you’re learning some other? What’s the point in that, anyway? Do us all a favour, and just think the next time you issue that statement, okay?

http://www.ianbicking.org/php-ghetto.html

>I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.

Why is the use of Blade(Laravel) or Twig(Symfony) any more acceptable than Smarty?

I personally like having the front end templates separated from the server code as much as possible. I think Blade accomplishes this while also providing you with a syntax that is much more readable than Smarty. On top of that I feel like Blade isn't necessarily trying to do as much as Smarty.

EDIT: I certainly prefer using Blade to doing the old '<a href="' . $url . '">... and other similar variants.

I've written many languages (starting with ML –Machine Language).

I'm currently developing in Swift, and loving it.

I wrote PHP for about 20 of its 25 years. I never really got to love the language, but got fairly good with it. I don't miss it much.

I have used it to write some industrial-scale systems, though. It's a perfectly good language, and is still under active development and improvement; with a vast user base and [m|b]illions of pages of support.

Even though a lot of us like to live on "the bleeding edge," I've found that it's a good idea to stick with the classics for shipping code.

Nowadays, "the classics" includes JS and Python, so there are definitely good, well-supported, mature alternatives to PHP.

I also programmed C++, and ran a C++ shop, for many years. I always find the hate poured onto C++, with the annual "C++ is dead" pronouncement, quite amusing.

But I really like Swift.

I enjoyed working with Swift, and I did enjoy working on Objective-C as well back when; my main gripe with Swift is that it's still a niche language for niche applications, unfortunately, and only really practical in a Mac environment.

XCode is great though, I miss working with it. I miss the browser-like swipe-to-go-back operation. I did set up a theme similar to Midnight in IntelliJ though.

Yes, but it is the prescribed language for native applications (like C#). Java is really becoming a “niche” language for Android development (until it is replaced with something like Go or Dart). We are seeing less and less of it for server code, as Python and JS take over.

C++ is becoming “niche” for engine code. I’m glad it’s no longer really used for UI.

There’s a lot of specialized languages popping out of the woodwork, these days. I once worked with an image processing language called Halide, which I found to be quite painful (it’s basically an FP language with the good parts removed), but an interesting idea. Totally niche.

https://halide-lang.org/

I tried to like Swift but with Perl as my first language Swift's regex implementation made me want to throw up. That and having to escape opening brackets and double parameter definitions. I just don't get the love for Swift other than it being an improvement over Objective C.

I consider Perl to be a “write-only” language. Damn good text processor, though. I wrote an entire CMS in Perl, back in the late 90s.

I still wake up, screaming...

Swift isn’t any worse than most modern languages, when it comes to text processing, but that’s not what I use it for.

In fact, it has some very powerful string handling, built-in, but it’s kind of weird, if you are used to more traditional languages.

Rasmus Lerdorf look at the last 25 years of PHP: https://www.youtube.com/watch?v=wCZ5TJCBWM

Really interesting for anyone wondering what the thinking was behind function naming and other inconsistencies jump to: https://youtu.be/wCZ5TJCBWMg?t=987 and https://youtu.be/wCZ5TJCBWMg?t=1466

If I look from outside - it looks like there was exactly 0 thinking involved in function naming.

That is the look on the inside as well.

You left out a "g" for the first link.

> PHP to have str_contains() A function that checks if a string is contained in another string? That should only take about 25 years.

For anyone else confused by the newest thing on the list who is wondering what the heck str_contains() does that you could not already easily do with strstr() or strpos() since time immemorial, the answer is nothing.

The only difference between str_contains($needle, $haystack) and strstr($needle, $haystack) and strpos($needle, $haystack) is that after they all make exactly the same C function call:

  php_memnstr(ZSTR_VAL(haystack), ZSTR_VAL(needle), ZSTR_LEN(needle), ZSTR_VAL(haystack) + ZSTR_LEN(haystack))

which returns either a pointer to the needle string in the haystack string or NULL,

• str_contains() return false or true, depending on whether that pointer is NULL or not,

• strstr() returns false or the part of haystack starting with needle, depending on whether that pointer is NULL or not, and

• strpos() returns false or the offset of needle within haystack, depending on whether that pointer is NULL or not.

It's equivalent to just writing (strpos(...) !== false) in your current code.

The rationale for adding str_compare() is that strstr() and strpos() are not intuitive, easy to get wrong, or hard for new developers to remember.

I personally don't object to 'trivial' functions sprinkled in my stdlib. I mean your own comment already highlights it, the return value of strstr() and strpos() is not intuitive, whereas you expect a boolean for a 'contains()' function.

Of course, it also highlights one of PHP's often repeated criticisms, that of function naming inconsistency.

Most people don't know this and the timeline also doesn't make it very clear: PHP never started as a language but as a templating system for C.

Feature requests were quickly added and that's why PHP became a language with a lot of quirk's.

Today that is totally different. As a scripting language it is blazing fast. It still has some strange corners, but it's amazing that a templating system because such a wide used language.

I started with PHP 15 years ago, but after 5 years I just moved to Java.

The worst thing with PHP was people and standards, everything was a mess, there was no right way to do stuff and larger projects had like 100 different implementations for the same thing. PHP was really challenging to work with as coming to a shared agreement for how one should implement stuff was a recipe for personal conflicts.

So after a few years, I just started to code web applications with Java. A completely different, but much more enjoyable environment and much more friendly people.

I guess PHP is much more fun today, it was really fun to code in PHP as it was really simple and you feel productive and powerful. But in the old days, bad defaults often caused issues in production. And some of the documentation/knowledge sharing was dangerous(tutorials lacked warnings and information about preventing SQL injections).

Symfony really paved the way for quality PHP code. Excellent Web framework which is a lot of fun.

I could never buy a screen wide enough to display a full path with Symfony. Not quite as bad as its predecessor - Zend Framework - but finding the end of a file path was like jumping down a rabbit hole.

> A completely different, but much more enjoyable environment and much more friendly people.

You must have found a neat subculture in Java - not been my experience at all.

The "shared agreement" thing - I've moved between multiple Java environments over the years, and there's never any agreement between companies on the 'right' way to do Java.

Open communities in Java - I've often felt they require a huge amount of tribal knowledge of their 'ways' before they'll deign to answer questions in helpful ways. Mention that you can do X in perl or php or ruby, and you're often dismissed out of hand.

All communities are defensive, when someone comes in with "this is shit, why can't I do it like I do it in X".

Are you not aware of the flamewars between RoR and Enterprise Java people, when RoR was being pushed into the enterprise?

I'm aware, and coming in with "this is shit" - yeah, that ain't cool, and I'd never expect that to 'work'. Coming in with questions people consider "too basic" is another problem.

Reading this comment it seems JS is the new PHP, culturewise.

"When the world becomes standard, I will start caring about standards." — Rasmus Lerdorf

The fish rots from the head down.

Long time ago I was learning Perl, because at that time basically the whole Internet ran on Perl CGI scripts. I thought, "man, Perl is weird".

Then I learnt PHP, because whole internet seemed to move to Apache+PHP. I thought, "man, that's Perl done right!".

Then I actually learnt Perl, looked at my PHP code written earlier. I thought "WTF?"

Now I use Python. I think "man, why I have to type this silly whitespace?"

I can't wait to see what's next for you!

> "man, why I have to type this silly whitespace?"

I assume it's a joke, but I often have people in my classroom that have been doing python for some times and that keep typing the whitespaces themselves instead of using an editor that does it for them.

But again, I've seen some coding without any syntax highlighting.

Now I never assume people know even the most obvious things.

Did you try HTML::Mason or were you stuck with CGI::Application or even plain old cgi? Mason is like PHP but its dependenc on mod_perl made unfortunately made it a non-starter for cheap hosts. Catalyst was an abomination but I think Mojolicious deserves more adoption that it gets.

I started my professional developer career with PHP 5.2 I think end of 2006.

While the langugage design was garbage, I the developer experience was quite awesome.

This was a curse and a blessing. On the one hand it lowered the bar for many people to get into programming, on the other hand it led many people to believe they can do anything even when venturing in system designs that were much above their pay grade.

I switched to JavaScript in 2011 and again, it was mostly for DX.

The language felt more light-weight (no $ or classes), while it still had similar problems as PHP and being able to use it full stack eased context switching rather much.

Node.js deployments felt much slimmer than setting up PHP with Apache/Nginx too.

I still missed a bit of the "drop a source file in a folder and its an API" feeling.

Last few weeks I played around with Cloudflare Workers and that got me a bit of the PHP feeling again. I can simply say "This file runs at that path" and be done with it.

After several years now of defaulting to Go, in the last month I've gone back to PHP (specifically Laravel) for a new project.

It's... comfortable. That's probably the best way I can describe how I feel about it. I've missed working in PHP, despite how much I enjoy Go.

Same. I love Go, the language, much more than PHP, but Laravel.. Laravel is really great.

I wish Go had something as convenient and complete as Laravel. Unfortunately that's impossible to achieve in a static language without polymorphism (generics) or metaprogramming.

I'm waiting for Go to introduce polymorphism and I'll be watching closely to see how 'post-generics' web frameworks make Go great again!

Have you tried the Buffalo framework? It's touted as Go's answer to Rails.

I've tried Buffalo. It's... fine, but it doesn't have the same feel as Laravel does for PHP.

While I don't use PHP today, it always makes me wonder at deceptively easy it is to deploy a PHP app.

There's no having to worry about restarting processes since the next request picks up the code changes and deploying at scale has so many problems auto-solved by that such as rolling restarts.

You can then handle things like percent based feature roll outs at the application level which is likely where it belongs anyways.

On the flip side, for single server deploys, you can also get by with zero down deploys without needing to set anything up. Most other languages and frameworks can't do this, or the way they do it involves doing very complicated things or using even more complicated tools to solve the problem for you.

It's funny to think back in the early 2000s I was using PHP and deploying was brain dead simple then, but fast forward almost 20 years and it's still pretty much the case today -- at least it seems that way based on the talks I've seen around using PHP in production over the years.

>There's no having to worry about restarting processes since the next request picks up the code changes and deploying at scale has so many problems auto-solved by that such as rolling restarts.

Nearly any serious PHP deployment will use an opcode cache which has to be invalidated, though maybe they are smart enough to do that from the filesystem now.

>On the flip side, for single server deploys, you can also get by with zero down deploys without needing to set anything up

Mod_python works about the same as mod_php although you are right insofar as most advice is to use a separate uWSGI process.

>You can then handle things like percent based feature roll outs at the application level which is likely where it belongs anyways.

You want incremental rollout essentially every time you change code; if you feature flagged every single change, you'd have your codebase's entire history all hanging out on master, with far too many possible combinations of feature flags to ever test. The nice thing about rolling back and forth with code is that each version is internally coherent.

> Nearly any serious PHP deployment will use an opcode cache which has to be invalidated, though maybe they are smart enough to do that from the filesystem now.

Etsy has a massive PHP deployment. In one of their talks they mentioned one of the main perks of using PHP is they can just drop code onto a server and be done with it. They are operating at pretty crazy scale. Even deploying to hundreds of servers can happen very very quickly since you don't need to step through a tiered rolling restart.

> You want incremental rollout essentially every time you change code; if you feature flagged every single change, you'd have your codebase's entire history all hanging out on master, with far too many possible combinations of feature flags to ever test.

Often times you want to restrict features or certain things based on business logic in your app, not just a "dumb" load balancer. For example, you might want to enable new things for specific users who opt into a beta program or maybe only staff to start. But it could also be to a % of users. Usually the idea is to feature flag bigger things and once it's rolled out fully you remove the flag and now it's just something that exists all the time. Of course this depends on your organization tho.

The standard settings for PHP's built-in opcode cache will automatically invalidate cache entries based on file timestamps, though setups trying to eke out maximum performance may disable this and therefore require manual invalidation.

It's so crazy to see how far the language has come, and how much it's matured! I started working in Perl around '98-99, switched to PHP in 2000 just after PHP 4 came out, and ended up running a company around it for all of my 20's. Very thankful for the language and community that made that possible.

These days I still write a fair bit of PHP, but mainly C# and Go, and some Javascript. I understand the criticisms of each language, but I don't mind the type inference/coercion in scripting languages and don't find it actually results in that many bugs. Although I do appreciate the clarity of choosing your types and understanding their performance implications in C# and Go. I guess it comes down to the right tool for the job, and some jobs do just fine without strict types.

Since 7, PHP's also gotten fast enough that most web-related tasks are just faster to solve with it, and it's so easy to deploy a Go binary alongside it for performance-critical parts that it feels like a killer combo in terms of productivity vs performance. Really itching to play with Roadrunner next, which blends those two together into a single app server (https://roadrunner.dev/).

I've been working with PHP for a very long time and apart from web it is also very good at writing shell scripts too.

One of my recent project called 'howdoi' (1) is written in less than 70 lines of code (ignoring ws) - no libraries, no deps and backward comptabile to 5.0. Just copy-paste the file and it's go! If you know how to use it, it's really useful language.

(1) https://news.ycombinator.com/item?id=23230157

I'm really surprised that PHP hasn't picked up in this area. It's a great tool when you're too big for bash, but not big enough for, well, a "more proper" language...

Yeah an in-place file-editing feature like Perl or sed has would make it very useful for command line use too.

because it does not feel right to put <?php after shebang. seriously, I hate it. It's like using a wine bottle as a hammer. it works great, try it, but it will never feel right

Fine. After 20+ years of PHP development I'm going to give it a shot. Will be attempting to migrate from VSCode. Any tips for that transition in particular, or for setting up PHPStorm in general? I have a subscription to Laracasts and plan on watching that series, but I'm not sure if it's outdated. Thanks!

There’s a fairly good plugin for JetBrains IDEs called “Key Promoter X” that reminds you whenever you do an action (click build, open a terminal, change directories) of the keyboard shortcut to do that same thing. It’s very handy for getting into the workflow quickly.

Thanks for this. I'm not necessarily aiming for mouse-free development, but I've known for years that I could be better with keyboard shortcuts. I had no idea this was a thing.

Just installed this, it's fantastic! Thanks!

I second the PHP Inspections (EA Extented) plugin.

If you use Symfony don't miss the plugin, it's almost (dev-)life changing.

If you use xdebug take the time to set it up (way easier these days but can still be challenging depending on your setup), breakpoints work great.

More related to all Jetbrains IDEs:

One often overlooked aspect is the database integration (look at the tabs on the right). In addition to replacing most needs for a third party program it gives you autocompletion for your in-code sql querys.

Checkout the git integration. From the "annotate" entry menu to the all fantastic diff/merging/etc tools.

Lean to use the different searches, "in path" (toggle the preview option), classname, file, or the global shift-shift.

Try all the integrated tools, the terminal & ssh, the http client, the live templates, etc.

Lean about the local history (usually in the context menu above the git entry), it will save your ass at some point (it can restore entire deleted-by-mistake folders).

Please do share your PhpStorm journey at some point. I installed it yesterday after trying out Visual Studio Code for the Nth time and again being utterly unimpressed with having to use a GUI fobic editor in 2020. Everything feels clunky and when you start adding more complex plugins things really start to fall apart, like having to use a FTP plugin through the command line.

PhpStorm has its flaws [0] but so far I'm shocked by how much more productive I am with it as compared to Visual Studio Code. It's like having access to a wise dev who can point out flaws with your code, turning the IDE into a learning tool.

[0] The non-native UI of PhpStorm is annoying but not a major issue. I dislike how project centric it is but I like that you can configure almost every setting on a per project level. It's also very expensive for solo devs (edit: actually the monthly cost for individual use seems to be 8.9 EUR which isn't that bad).

The cost will go down in future years as you resubscribe. I think that works on the monthly as well as annual subscriptions. The entire toolbox for me is now... $140/year I think (I use data grip, web storm, phpstorm, IntelliJ all regularly)

I use it every day and love it. Probably the biggest thing is getting the keyboard shortcuts setup how you like and knowing them.

- "Search Everywhere" with double tapping shift (at least on mine) is really nice. And the fuzzy file search might be the thing I use most often. - Git support is great, especially the shelving changes support. - I use navigating around words using Alt+arrow-left/arrow-right all the time as well. - "Extend selection" command can be very useful for selecting increasingly larger blocks intelligently. - Go to matching symbol (default Ctrl-Shift-M on KDE keymap) is useful

Loads more, I read the daily tips to figure out some of the newer stuff, or look through the keymap.

If you like Vim style keys, there's a plugin for that.

I wrote a blog post on my most-used shortcuts in JetBrains' IDEs (=> also PHPStorm), maybe this is useful for you as well. It was discussed here: https://news.ycombinator.com/item?id=22925484

I've been recommending "PHP Inspections EA" for many, it adds a many more extra inspections provided the environment (PHP versions, extensions, etc) are configured correctly.

Local history will save your butt. Right click in a file and see the local VCS. Survives all sorts of external events or losses.

I wish more digital subscription models were more like the jetbrains one. If you paid for one year continously they handle it like you own that specific phpstorm version, even if you cancel your subscription.

That said, I wish I could subscribe without having a company ._.

What do you mean? They do offer licenses for individuals, and I've had a personal license for over seven years now.

He might be referring to the UX problem they have on the sales page where it is non-intuitive that you have to click a button to switch to the individual pricing. This affected me recently.

I have a personal license, you can absolutely subscribe without a company.

They have personal licenses

'This page is best viewed in landscape mode'

I don't think I'm going to rotate my desktop monitor just for your website :)

Your desktop monitor should already be in landscape mode, shouldn't it?

Not if you code a lot. It is not rare for developer to use vertical screen. https://img.devrant.com/devrant/rant/r_200135_Q9Fh4.jpg

I have a theory that PHP is kind of like erlang -- as a framework and dev environment, not the language itself.

Each request is pretty much independent of the others, and each one can independently crash.

There was also CGI, but CGI always felt a little heavier, and the crashes were harsher (usually just a 501 error and nothing more). PHP embraced the crashes more and provided more information allowing faster debugging.

As a result, generally it was pretty easy to make resilient software.

Critically, PHP also embraced SQL databases, so that crashing meant aborting the transaction (if any). Erlang never meshed quite as well with transactional databases, so trying to keep consistent shared state in erlang felt tricky. In PHP, it was natural.

> Each request is pretty much independent of the others, and each one can independently crash.

Not the case anymore with phpfpm.

php-fpm uses a worker pool. How is this true unless you corrupt the shared memory segment?

I first met Rasmus during my pre-internet BBS days in Toronto, and reached out to him shortly after moving to the Bay Area in '95 when he told me about his pet "Personal Home Page" project. What an amazing trajectory!

Very cool. How did you cross paths?

He was just another dude on the Zooid BBS, which I dialed up on my 300 baud modem. https://en.wikipedia.org/wiki/Zooid_BBS

What ever happened to the PHP-FIG? I noticed in the timeline projects kept dropping from it in the past 2 years. It seemed to have a lot of momentum for a while producing PSRs that were very widely adopted.

Afaik after the whole PHPixie scandal, they got backlash but the PSR standards they adopted are still in use.

PHPixie thread: https://groups.google.com/forum/#!topic/php-fig/cjLBp2weYaA

Oh my. I lol’ed at the comment:

> A big +1 to what Robert said. Let's not be the PHP Drama Group or the PHP Court of Social Justice.

It seems like all these “groups that have arbitrary mechanisms for becoming a member and have some sway in the wider community” eventually end up becoming a giant ball of drama and controversy.

There's so much we can agree upon, right?

If you are the geerlingguy I think you are, Drupal sure had an exit after Larry, and Symfony decided to step out too. Laravel didn't really follow PSR to begin with.

I use Slim framework extensively nowadays, and it has a surprisingly PSR 2,4,7, AND 15 support.

https://github.com/php-fig/fig-standards

The repo is quite active.

Anonymous function and callbacks in PHP are a mess (Have you ever heard of Closure::fromCallable). Native function name and argument order are a mess with no clear convention. This thinks alone have made me abandon the language a couple of years ago. (I have two Zend PHP certifications and I was using PHP since v.3). Now I'm very very happy with fullstack Javascript (plus occasional TS help).

It has been a long time since I have had to deal with Other People's PHP and I have never had to with my own. Mostly, I have had to at least glance over student projects that had security issues I could drive a bus through, honking and dragging a bunch of rusty bikes.

In terms of language design, I couldn't speak to it. I've never designed a language and they are intensely personal things. However, I have the vague sense that the culture of PHP (installed by default, easy to get working) created many fire-and-forget projects done to scratch an immediate itch with no sense for maintenance. It works? Ship it.

You can write obfuscated code in any language, but some languages have a culture which encourages it, such as Perl. Similarly, I think many perceptions of PHP arose from a "make it work, now, anything else is someone else's problem later" mindset I saw from the people who were developing in it.

I would be interested in other perspectives.

I think probably the most ironic thing about all the hate PHP gets, is that those who hate it the most seem to assume that the people who chose to use it did so without exploring other options.

So {your favorite language here} was turned down by a potential developer because they saw PHP as the better option. People aren't stupid but from all the rhetoric it seems the "geniuses" in the group think they are.

I wish I could request a POLL here. I'd ask, from all the people who hate PHP and write extremely long posts about their hate for the language: How many of you used some of that energy you expend hating PHP to write a patch or feature for your favorite language to make it more desirable for other developers?

One thing I really enjoy in JS world is an ability to write both back and front in same language. SPAs now being the norm also puts more weight towards front. PHP had a knack for 'just works' in most cases and will always be dear to my heart.

PHP is still dominant in CMS space. If you are writing webapps use something else. But if you are working on content then PHP CMS ecosystem is just way ahead of everything else. You almost can't afford to go around it. And I dont mean Wordpress. Modern CMSes like Craft, Kirby, Twill or even things like Bolt, Processwire or Grav... they are pretty great mature platforms for custom content websites and basic CRUD.

Hell with Wordpress (which i hate) and some plugins you get your own self hosted website builder ala Squarespace. PrestaShop and OpenCart are solid ecommerce solutions.

It's too dirty and DIY but it gets job done for most small to medium size businesses.

What I love about PHP is its learning curve. You can quickly start making things.

I started two decades ago with dirty PHP mixed with HTML pages, then I learned templating. Then I learned OOP, classes, interfaces, abstract classes, traits, managing dependencies and unit tests. All of these with PHP, no framework.

Because PHP is quite easy to use, I learned all these "general" principles thanks to it. I guess nostalgia plays a big part in my appreciation of this language but I will just say one thing: thank you PHP!

Amazing how many complete rewrites that timeline contains... :)

tbf i have a 12 year old php game that basically prints money - the only thing i had to change was the old mysql module (which was not even buggy/unsafe - just unmaintained).

PHP has unreasonably good backwards comparability, even between v4 and v7.

What does it do?

And WordPress, which is hated even by PHP devs, continues to grow now powering 37.3% of all websites [1]. Until last year, it maintained compatibility with PHP 5.2 essentially relying on PHP of the 2007 (now bumped to 5.6 which was released in 2014).

[1] https://w3techs.com/technologies/overview/content_management

I believe PHP will still be relevant and a lot of the fancy frontend frameworks out there won't be around anymore. Some kind of lindy effect in place.

I first heard about the Lindy Effect from Nicholas Taleb -- for those who don't know it:

The Lindy effect is a theory that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining life expectancy.

I taught myself PHP back in 2007 as it was the only language which had a single click installer (WAMP) & easy tutorial to learn (w3schools) to get started with programming. Since then I wrote a lot of PHP, initially for myself then professionally once I got a good handle on it, until 2012.

Now I'm again thinking of picking up PHP for my side projects because of Laravel.

I'm not a php developer - syntax ain't for me. but props to these folks man. 25 years of getting shit done. shipping, amidst the jeers. I look at Laravel as one of the big 3 web frameworks to use if you're serious about shipping stuff. & in the PHP world, everything has been done - so you won't be doing anything new.

What I tell other people what it's been like working with PHP, it's usually this:

"Working with PHP is like having a crazy guy with a gun on your side, by his nature he is powerful and potent, and you can definitely get a lot of stuff done with him... but who the hell gave this guy a gun?"

There are only two kinds of programming languages. Those that everyone hates, and those that no one uses.

Everyone hates PHP.

I kinda prefer PHP for most of my web backends like yet another REST API.

Modern framewrok like Comet easily beats any NodeJS or Python project regarding performance and latency:

https://github.com/gotzmann/comet

I gotta say... PHP has grown so much and growing further in the right direction (with union types and async I/O).

At the speed of its improvements... it's kind of embarrassing other dynamic languages (I am looking at you Python, even though you are one of my favorites).

I've been using PHP for most of my web development career (a decade). What are the industry standards for backend web development languages in 2020? I was under the impression PHP was the way to go for back end web development.

I would say golang has been a strong contender for that role for a while now besides the usual java/ruby/python stacks. You can use many languages for your backend, but golang is IMHO the best out there right now (but as always: it really depends on your use-case)

> They [two startup founders] find PHP/FI 2.0 to be inefficient and lacking features. In 1997 they embark on a complete rewrite of the underlying interpreter.

Wild. Doing something like this today would be considered so tangential and risky.

"PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl is a great and insidious evil, perpetrated by skilled but perverted professionals." -Jon Ribbens. Programmer.

I’m thankful for PHP. I don’t use it on regular basis or even as my main programming language, but I do use it for side gigs and smaller projects to earn extra cash.

It’s fast, easy to get into and does the job for me.

If it's THAT bad.. why is it still around and under active development 25 years on ?

Sure COBAL is also still around but the amount of new projects started in COBAL vs PHP is a lot less.

Because technologies don't win by being the best, or even by being good.

They just need to provide a killer feature and an easy path to adoption.

After that, inertia does the rest.

I haven't looked at PHP in ages. Now that I hear that the latest version are much better, does anyone have links to good quality PHP code that I can take a look at?

Any pointers at SW that can build timelines in a similar way? I would like to get product roadmaps out in a similar way if it can be kept light weight.

PHP as a programming language is... okay. And it has come a long way in recent years to become "okay". But frankly, wasting another keystroke regurgitating to tired old "PHP sucks" trope would be to completely miss why PHP is so great (hear me out).

PHP as a development paradigm is second to none. The reason to choose PHP isn't because it is such a great language, the reason to PHP is because it gives you the most power for the least effort compared to any platform targeting the web (fight me).

PHP is dead simple. I can make a new directory with a single index.php file and view it in my browser in less than 10 seconds. I can then change/add more files, hit F5, and immediately see those changes reflected on my screen. It is the tightest feedback loop possible. I didn't have to remember/rely on any CLI helpers or package managers or debug tools. I didn't have to redeploy or recompile or restart anything... none of the bullshit. Just one file in one directory with zero indirection. And we aren't even done yet!

PHP also gives you a built-in web framework out of the box. It automatically parses server/request information and hands it to me for processing into a response. What's that? I don't need a special templating engine to format my output nicely either? PHP is a templating engine! Did I mention routing is also built-in (and transparent) as well?

The above is why PHP has become so popular/beloved by so many (and hated by many more). Everyone complaining about the language features ("array doesn't work the way I want it to!") is simply putting their ignorance on full display. There is nothing wrong with wanting something else out of your development environment/paradigm (heck, I've moved on too!), but don't blame PHP because it doesn't conform to your idea of how an application should be written.

The above is also why I am so disappointed by the direction the PHP community seems to be taking the language. I am all for improving PHP as a language, but to be honest, I have a feeling the maintainers are going to prove all of those people that claim "PHP is just a worse Java" right... PHP will never be as powerful of a language as Java or C#, and for the reasons I explain above, it doesn't matter! Nobody is choosing PHP because of the language (if they were, they would have chosen Java/C# in the first place).

If you want to improve PHP, improve upon the things that make it great. Lean in to templating. Lean in to a more functional approach. Lean in to includes. Screw it, add some more magic! Make the platform more ergonomic. It was always the draw anyway. Who cares about the language...

As a new web dev who's never learned PHP, is it worth it? I don't really need to write anything into production.

As another newish web dev, I think it depends. Best thing is to take a look at your local job market and see what people are using. In my area it's a lot of .Net, so I'm focusing more on that. Some other areas have lots of PHP jobs, others have Rails, etc. If you don't care about any of that, I still probably wouldn't pick PHP honestly. I went with Go for my toy project backend, but NodeJS is another good option I think.

May not be the prettiest language out there but it ALWAYS pays the bill.

If you were starting a project now, would you choose PHP or Hack?

Hack is interesting and the native C++ interface is a breeze. But choose PHP if you want to live. Hack has only a fraction of the PHP ecosystem and if you mix with PHP, then you lose the advantages very quickly.

Why would anyone choose Hack? There's no ecosystem to speak of.

PHP. Most of the Hack features are now in PHP core, and more and more libraries are dropping support for hhvm now.

No.

I do, when I can.

Great language to prototype webpage and backend

[flagged]

Ah yes, the classic "my application is shit so the language must be shit" straw man argument.

Sorry to hear you have to work on shitty code. But neither the choice of language nor the lack of framework are to blame. Blame the developers and/or the organizational culture that caused it to be in such a poor state.

> But neither the choice of language nor the lack of framework are to blame.

This is partly true. It is possible to make something great with substandard tools. I suspect a master craftsman with a set of dull saws and blunt chisels using his shoe for a hammer will still have the skill to create something pretty good.

But it will be frustrating, and most people aren't master craftsmen so what they will produce will be adversely affected by the quality of the tools. If you give most people better tools they will have more chance to create something good.

PHP is the rusty saw of the programming world (and yes, I have spend a fair amount of time programming it).

You absolutely can create something great in PHP, but the sheer amount of gotchas and edge cases mean that for a lot of people it's hard to produce something good. There are a lot of people out there who aren't master craftsmen at PHP, and this is reflected in the frequency of the low quality PHP application that are out there.

Once or twice a year I have to peak at the code of a C app that was developed by interns more than 10 years ago. No framework was used, max 3 letters variables are the norm, no blank lines and the only comments are from code copy pasted from examples.

These days I would be more inclined to celebrate the death of C than its birthday !

I'm not sure why this comment identically copies the GP with the exception of the last line, but it doesn't appear to be a spam account.

> max 3 letters variables are the norm, no blank lines and the only comments are from code copy pasted from examples

It's hardly PHP's fault.

> interns

> more than 10 years ago

How that looks to me: Wow, that application has provided so much business value (over a decade worth) despite being designed by less experienced software engineers. PHP must be a great language.

this. PHP just gets shit done. newbies might add few sql injections here and there, so you gotta hand them some code convention/code review/frameworks, but PHP just gets stuff done fast and with extremely low overhead

It's non critical and isn't core to what we do. I don't have much time to allocate to it.

My point is that all else being equal if it had been developed in Java or C# my job would be much easier.

Recently I have been thinking about moving my personal blog from Wordpress to a static site generator, because I don't allow comments or use Wordpress plugins. (Those who want comments can still use a combination of a static site generator and Disqus.)

It occurred to me that once I did that, I could completely disable PHP on my Apache installation. It made me wonder how much usage of PHP out there is essentially a historical accident, and that if modern static site generators had taken off before Movable Type, the language might have been much less widely adopted.

Depend on how you count what is static site generator.

Dreamweaver has a template system you can use to generate pages. It could probably be considered a WYSIWYG static site generator. I have never used FrontPage, but I would imagine similar system also exists. There are also a lot of other WYSIWYG website editors out there during late 1990s and early 2000's.

Despite that, CMS system thrives.

On the "easier to use" front, there was also iWeb and apps like RapidWeaver.

But Movable Type was written (mostly) in Perl... I'm not sure I see how Movable Type affects PHP all that much, but maybe I'm missing something.

Movable Type was popular, but a change in its licensing terms led to people leaving it in droves for Wordpress which had a similar interface and approach. Fast forward to 2020, and Wordpress installations reportedly make up the majority of PHP use in the world.

Static site generators are a niche market, whereas blogging is a mass market. The vast majority of WordPress users probably wouldn't know / care about static sites. WordPress is still significantly more convenient and user friendly for your average user

Does anything like Blogger still exist? Blogger was really easy to use back in the day, and even today, I'd choose it over Wordpress.

edit: Context: I used Blogger to publish to a paid hosting service via ftp

Many people here don't understand the genius of Php. The language thrives of the ability to put out functionality that can be easily used by as many people as possible, even if it is not polished or technically perfect. This raises the ire of lots of programmers from "serious languages", which will usually take years to figure out the best syntax, the perfect framework and tooling environment, etc. While they're doing this, Php programmers are writing billions of lines of code to support millions of websites all over the world. Like many others, I sometimes hate the ugliness of what comes out from Php, but there is no question that it works to get the job done without having to learn the thousandth latest framework for language X.

Reply on news.ycombinator.com