> PHP has matured and has been a nice language for a decade now.
And how did it manage that? Python forced people to deal with encodings properly and the result was a lot of pain. You're claiming PHP somehow invisibly fixed the numerous problems of the language without anybody noticing? That "fractal of bad design" blog post, everything described in it has been fixed?
If so I want to learn how they did it. That's some heavy duty language evolution work.
> It started clumsy, true, but it became a solid and quite elegant way of doing things.
No. Just no. PHP will not be solid and elegant by evolution. It might have become an excellent tool for the area it's supposed to be used in, but the only way it could ever become elegant is if it had its python2=>python3 sort of moment. They would need to break it to fix it.
I don't think they'll do that, since I think they understand that it doesn't matter at all that the language sucks.
I am sorry, but bolting on a ton of 'modern' features on a broken language does not make it not-broken. If it does anything, it is to put up an appearance of being modern, while remaining rotten on the inside, and hence all the more dangerous.
Remember, the most broken aspect of the language is also reason for it's very defining feature (No or very little learning required to get started). Hence one cannot hope that PHP will be fixed at some point in the future. Because fixing the language thus will actually involve killing it and designing it from the ground up, at which point you can just use Python 3.
And that is even considering that the PHP community is competent enough to identify the flaws of the language. But I think what happens inevitably is that, people who can really see how broken the language also see the hopelessness of the situation and immediately switch to something else or use it only to pay their bills.
If you think I am not familer with modern PHP, here is a tool I wrote some time back in php, for php programmers to deal with the pain of working with namespaces and also provide intelligent auto completion for editors like vim..
> why would anyone want to start something new with PHP in 2021?
What can you make in X language than I can't make in PHP? And vice versa?
Don't get me wrong, I fully support the "select the right tool for the job", there are obviously better languages and frameworks for different kind of tasks, but let's just consider the context in what PHP is usually used in.
I get that people dislike a syntax. I loathe Python, basically because indentation actually controls how and whether your software works and I can't use indentation for organizing the readability of my code.
But that doesn't mean that I would ever argue against the use of Python; again - what can you make in Python that I can't make in PHP? And the other way around still.
inb4 "But PHP doesn't do async" - [fibers](https://wiki.php.net/rfc/fibers) is a start on that journey. We've managed so far.
This is your issue - PHP < 5.3 is very different to PHP 7+. Not just at the language level - but the community, frameworks and best practices too. No more random scattering of SQL statements in HTML files!
Modern PHP (with a framework like Laravel or Symfony) is probably one of the most productive ways to build web applications.
> It's not beautifully well thought-out the way Python is.
This is definitely an interesting take... Python hasn't even solved package management yet. And the 2.7 => 3 migration is probably the most famous example of making a mess of an ecosystem with backwards incompatible changes. In contrast PHP has Composer and 5.3 code is pretty much compatible with 8.0 (although ideally all code from the 5.3 era should be burned at the stake).
> and people who don't know any better keep championing it. I think people do eventually catch up with what's going on though as soon as they personally experience writing anything remotely serious (5-10,000+ LOC) that isn't a simplistic web-app.
You've basically just said that PHP devs are too inexperienced to be able to scale a codebase past 10k LOC? Pretty much every serious web dev using Symfony/Laravel would disagree with you.
> and the availability of web tools is much wider in php than for python.
If that was a metric for language quality, then Javascript would be undeniably the most perfect language ever designed by any intelligent species in the universe, judging by the number of frameworks.
> to an almost decent language
And now I would like to hear a good reason why I should use an "almost decent language", when I can use a decent one instead.
> It can be used properly if you know what you are doing
It doesn't matter what I do, the language still insists of having multiple modes of error handling, a massive amount of builtins all of which sit in my global namespace, it's configuration is still seperated between compiler flags, a system wide ini, and local config. The base deployment mode is still "dump files into folder and let CGI do the rest".
One of the gripes that I -and many- have is that PHP wasn't ever "designed" in the first place.
This is changing. Has changed. But for people, like me, who started with PHP back in the 3.x days, and left in the 5.x days, PHP has a bad history. It might overcome this, or already have. But the history sticks to it.
And it begs the question: why make PHP into a new Python, or Ruby or JS, if we already have a Python or Ruby or JS (or Typescript)? Because if any language is actually designed (for a broad sense of that term) for the Web, it is JavaScript.
> I wouldn't consider it python code if it is a cookie cutter website where the creator didn't have to write a single line of python.
So if I got someone else to press the deploy button in bitbucket, it suddenly isn't python code? That doesn't make sense does it?
> Why don't you consider each and every website running PHP also a C website?
The web site/app logic is written in PHP, not C. The runtime for the vast majority of PHP deployments happens to be written in C.
Additionally while I did say interpreted earlier that really isn't true anymore. PHP runtimes these days tend to break the PHP script down into byte-code. There are alternative runtimes for PHP just as there is Java or .NET.
There are at least 4 I can think of. Two of those aren't C (C++ and .NET). However there is nothing stopping you from writing a runtime that runs on the JVM / Lisp / Go / Brainfuck / Lol code / 68k assembler.
> PHP just started so, so, so far down, it's had more to overcome than most.
This is probably fair. :) I think PHP tried to combine Python's "batteries included" approach with Perl's "more than one way to do it" style, but did it in a pretty disorganized way that created lots of Catch-22 issues later -- when you get that popular, it makes backward-incompatible changes fraught with peril, even if you're addressing obviously craptacular past mistakes.
I think PHP has become pretty solid in version 7+ on, although my feelings about using it remain mixed. I've joked in the past that it's stopped being a cargo cult version of Perl and is now a cargo cult version of Java.
> 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.
That's just, not correct. I programmed web sites primarily in PHP back in the PHP3-5 days (and have had some jobs and contracts since, in PHP7+).
PHP, pre-5.3ish, was a bad language. It had terrible design decisions, a polluted global space, bad default configurations, weird scoping rules, function/objects with massive security holes that the developer had to patch around (the MySQL functions, being notorious) and a terrible object model. PHP5-5.3 did a lot to fix that, and 5.3+ became a usable language. PHP7 finally did a ton of work to clean up the global environment, deprecate and toss out old/buggy libraries, clean up the ABI and improve performance. They also reworked the object model completely. It is now a genuinely decent language. But it was not "always great".
> I can literally copy and paste what you said replacing it with any language and end up being correct.
This is the best point in this thread, IMHO.
I think it also is due to the fact that PHP is a fairly easy language for a non-coder to pick up little-by-little. One can easily start using it for doing simple things, like injecting dynamic data into a web page. From there one can learn to scale up to full web apps.
I think this lower barrier of entry makes a lot of developers feel insecure. A lot of coders think they are blessed with some sort of special ability to write code. They seem themselves as elite and they use elite tools. When some kid comes in with some PHP snippets and generates a lot of value from that they complain that their code sucks, the language sucks, the developers suck, blah blah.
In my 20 years of writing code (starting with PHP) I have learned the lesson over and over again that while writing code commercially the fact that the language has feature X or that it forces certain patterns means almost nothing. Sure, your developers might feel better about themselves but that is about it.
> Most of the criticism of php seems to contrast it with a language plus a framework. If you really want to compare, compare php with ruby or python, not Django or RoR.
Why? What difference does that make as a programmer using it? If another language is more modular, and lets libraries handle things that are baked into php, isn't that a good thing?
> As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many awesome programmers than languages such as python.
Maybe not, but it makes it harder to hire the good ones.
> 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.
> Frankly I think PHP doesn't have as strong a fan club as ruby/python, which are decent languages but they too come with their own quirks.
The reason quite possibly is that those are joy to use where PHP isn't. In my mind the developer happiness should be on top of the list, also the syntax is still ugly however you look at it. The versatility of Python is unmatched. Ruby allows me to do things I could only dream of in other languages, in PHP those dreams are nightmares.
Because it sucks! We tried it, it was bad, the Python community left it behind. Maybe if PHP left things that suck behind too then fewer people would say that PHP sucks.
>I think PHP is a horrible, cobbled together language. If the core maintainers had a strong grounding in language theory, design, and practice, they do an impeccable job filtering it out of the final product.
urg and then ?? We will have just another Python, C, .Net or Go, which are all good for some ppl and some things.. Sometimes you just need some outside the box thinking...
Honestly, how can languages (what PHP in the end boils down to) possibly evolve?
Example: you cannot bolt OO to it later on, PHP, Perl and to some lesser extend even Python are a testimony to that. It just does not feel right, leads to syntactic horrors and is usually not very performant.
Neither can you modify the syntax. You can add to it. But not much modify existing syntax. For tiny changes all hell breaks loose.
> [...] and feel like they're doing the wider community a service by making declaring a religious war against PHP.
I think the religious-war card is clearly overused. This is not a religious-war, it is an effort by programmers who rather use the best tool for the job then the bizniz/customer dictating them a languages/framework/CMS. PHP will not be fixed, mission impossible, they know it and therefor advocate a retreat-strategy.
The article describes that the community has (be it very late) finally developed some tool, a package manager, that make it slightly more bearable. But the language and its community still suffer the exact same unfixable problems.
An analogy: even in COBOL-land some problems get fixed up until today, but not fundamental language issues, nor community issues.
Yes, I compare COBOL with PHP. Many, or most, languages will someday be 'legacy' languages. Some just a little sooner then others. :)
And how did it manage that? Python forced people to deal with encodings properly and the result was a lot of pain. You're claiming PHP somehow invisibly fixed the numerous problems of the language without anybody noticing? That "fractal of bad design" blog post, everything described in it has been fixed?
If so I want to learn how they did it. That's some heavy duty language evolution work.
reply