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?
As I thought I'd alluded to in the above, when I was using PHP "in anger" as it were, there were 3 options for dynamic content:
1) Write a C program, and use the GCI-BIN interface. In developmental terms, this sucked dead bunnies through thin straws
2) Use some god-awful server-side script thing, updating static files with externally-invoked changes. Yes, people resorted to this.
3) Use PHP/FI. Life is now harmonious and (relatively) pain-free.
There was Cold Fusion, but it was Windows-only. The sane world, at the time, wouldn't serve websites on windows software unless there was a dedicated uptime team involved.
One of these was clearly the better solution. For things it didn't do, it was easy to extend (I wrote the PHP database support for Illustra, a now-defunct object-orientated database that we used)
These days I use it for shell-scripts, and I can bash out something that I need/want in much shorter time (basically because of the enormous standard library) than using any of the other options. My criterion here is "a text editor and 10 minutes"... There are some, very modern, languages that it takes 10 minutes to spin up the IDE and set up the damn project...
You're moving the goalposts. PHP was a great option in 1995. It is not today (except as a basic scripting language, where you and I agree completely. I would use PHP as soon as my bash script gets to about 100 lines).
Your post here is arguing about 1995 or whatever. The post I replied to was full of present-tense about "just use the good parts" and "all languages have issues", etc.
It was an accessible and good enough option, for multiple reasons.
The primary of which was the fact that it was built up for the web and was extremely cheap to host.
Not just moving the goalposts, but actually programming PHP 14 years before it first appeared in 1995, and putting database-driven websites on the web 8 years before it was invented in 1989.
His post here is arguing about 1981, actually.
>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.
For what it's worth, I started using PHP at Oyster Partners (then Oyster Systems). We did the London Metal Exchange, Swiss Bank, Euromoney and all it's sister magazines. When I joined Oyster, it was 3 people and it ran off a dual-link ISDN line... These days the company has been subsumed into a much larger business worth several million, but Luke still runs that business.
I left Oyster after a couple of years (then 50-strong) to set up my own business in 1998 with an angel investor - the business that Apple eventually bought, and the wayback machine puts us on the web in 2001, which makes sense - we spent a couple of years writing the app before it went public.
> 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).
Many of the PHP extensions are direct exposure to underlying libraries. MySQL introduced a 'real escape string' in their client library, PHP exposed that directly. Had they ignored it, or renamed it, or changed param order, people would have complained about that too, no?
> 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
You could mostly get that from going to the PHP doc site itself, which would indicate things that are deprecated. Or your IDE might tell you.
Or, for things that are really out of date, like mysql_real_escape_string, they simply ... aren't in the language any more, having been removed completely from PHP7 several years ago. If someone is starting brand new today using a blog post walking them through setting up PHP5... they'll have much bigger problems.
There's a shitload of 'tribal knowledge' around stuff in many languages - you find out a lot of that stuff via searching. If I read an 'older blog post' on Go from 2015, and complained that my Go didn't work very well (or was insecure, or whatever), how much blame should the language itself take?
> Many of the PHP extensions are direct exposure to underlying libraries. MySQL introduced a 'real escape string' in their client library, PHP exposed that directly. Had they ignored it, or renamed it, or changed param order, people would have complained about that too, no?
Don't most ecosystems use some type of namespace for that instead of exposing everything as global functions? Those practices were quite late to the PHP community.
Um, I'd criticize a C++ programmer who didn't know anything about the STL as well. Sure, you don't need to know the STL to write C++, but it's an odd decision. If you're going to use a tool, you have to learn it if you want the job done properly.
PHP is old and carries some cruft along with it for compatibility reasons (I suppose). When mysql_* was implemented, the world was a gentler place, and SQL injection wasn't really a thing (or at least, known to be a thing). What you're really complaining about there is "they didn't throw away the stuff that doesn't work well today". That's a decision I can see going either way.
[aside]
Having said that, the number of interviews I do where the candidate, poorly, attempts to write me code that implements what could have been done with std::vector is crushingly disappointing.
[/aside]
I agree that the population of programmers who knew about SQL injection was much smaller, but it was certainly widely understood by people who cared.
I believe that msql_* were implemented in PHP 3.0, in 1998. By comparison Perl's DBI was first released in 1994, with placeholders and an explanation of why they were important. Of course the idea wasn't original to DBI, the feature was based on an existing Oracle feature known as bind variables that I know was available and recommended with Oracle 7 in 1992. (I don't know if it was there before. It might have been.)
So there was certainly no attempt to figure out best practices on the part of PHP. And compared to the other injection attacks that proliferated in PHP in this time frame, the mysql functions were practically sane.
>but it was certainly widely understood by people who cared.
Rasmus Lerdorf and the early-to-mid PHP community simply didn't care. As you can see by the quotes I posted in another comment, Rasmus Lerdorf actually brags about how much he doesn't care. It's a textbook example of anti-intellectualism.
What the early-to-mid PHP community cared about, and was extremely successful at, was evangelism, and recruiting as many new inexperienced developers as possible.
That didn't mix well with all the foot-guns and design flaws they carelessly built into the language, and left in for far too many long years.
Along the axis of care, PHP is the opposite of Java. Compare PHP's complete lack of design with how carefully and conscientiously Java was designed (I may not agree with all of Java's design decisions, but at least they're all carefully researched, thought out, and debated to death first):
>"In the Java universe, pretty much everybody is really disciplined. It's kind of like mountain climbing. You don't dare get sloppy with your gear when you're mountain climbing, because it has a clear price." -James Gosling
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.
>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].
I started trying to figure out when it was by when I was at college, how long I did the PhD for, how long I was in the first job, how long into the second job I started using it and I screwed up the maths along the way. It was in 1996, not 1981... No excuses, that's just bad.
You also said you wrote the asset management system that was used by Lucasfilm on Star Wars, which was released in 1977. Are you sure you don't mean one of the later J. J. Abrams films, and not the film whose title was actually "Star Wars"?
Mistakes about dates and context aside, I still can't believe you're actually trying to make excuses for mysql_real_escape_string. It has the word "real" in it. I mean, come on, who would ever name a function "real", and why?
That implies the existance of a not-so-real mysql escape string function. Why didn't they simply FIX the gaping security hole in the not-so-real mysql escape string function, instead of maintaining one that was real that you should use, and one that was not so real that you should definitely not use, in the name of backwards compatibility?
Or were there actually people out there using the non-real mysql escape string function, and they didn't want to ruffle their feathers by forcing those people with code that had a security hole so big you could fly a space shuttle through to fix their gaping security holes?
The name of the function "mysql_real_escape_string" says all you need to know about the culture and carelessness and lack of security consciousness of the not-so-recent PHP community.
And you shouldn't be making excuses for it, or blaming it on the wrong people for using it, instead of the right people for creating it then evangelizing it then not fixing it. It was a TERRIBLE mistake.
The crappy code was PHP itself, and the code was crappy because the culture was crappy. I'm not going to start linking to all the anti-intellectual Rasmus quotes, or to the bug report about the time he checked in huge security regression to the crypto code that would have been caught by the tests, and then CUT A RELEASE, but didn't bother running the tests first because they produced so many errors. But you can google that debacle yourself.
PHP has its issues (boy howdy), but sometimes those issues are being propagated from other places.
Also, I'm gonna (very gently) push back on "evangelizing it then not fixing it," at least with respect to this particular boy howdy issue. PHP may have been late to get on board with bindings and basic DB abstraction, but they've had PDO since 2004. There are a lot of things like this in PHP -- big problems with its original conception/implementation that have been tackled in later iterations of the language, but that people seemingly won't forgive either because they're offended the sins were committed in the first place or because PHP preserves the stupid ways to do things for years and years in the name of backward compatibility.
(I mean, I don't want to overstate anything here. PHP basically started out as a cargo cult version of Perl, and the PHP community collectively decided a few years ago that the proper thing to do to move the language forward was to turn it into a cargo cult version of Java which seems, well, debatable.)
It's not which verion of Star Wars you worked on in what year, it's that you're choosing to defend mysql_real_escape_string, and the culture that produced and maintained and evangelized it.
What you've so brilliantly and unwittingly illustrated here is that PEOPLE MAKE MISTAKES. And that contradicts your argument that attempts to shift the blame for PHP's footguns like mysql_real_escape_string onto "crappy coders" instead of the culture and designers of PHP itself. People love to use that argument the self-aggrandize themselves, claiming they're too smart to make those mistakes, and only crappy inexperienced coders do that, so it's not a problem.
But PHP has always been widely evangelized to inexperienced coders, foot-guns and all.
Yes it DOES make a difference if a language is full of foot-guns, and the culture and developers around it don't give a shit (and don't bother running tests before checking in buggy changes to crypto functions before making a release) because they think they're too hot-shot to aim the foot-guns they designed and loaded at their own feet, then go around evangelizing their language to inexperienced crappy programmers.
dramaticus3 on Aug 22, 2011 | parent | favorite | on: Do not upgrade to PHP 5.3.7 due to a bug in crypt(...
Get ready for some WTF-ery Crypt takes an optional salt. If that value is an MD5 hash it is prefixed with the chars $1$ to tell the underlying crypt(3) function to use Modular Crypt Format[1].
MCF is an ad-hoc cruft because the orginal crypt() is weak.
Anyway guess who did it :
"let's use strlcpy/strlcat instead for these static string copies" - Rasmus I guess that's Lerdorf himself
Whoever it was also didn't check the return values for error. Strlcat returns the length of the new string which might not be the same as strlen(dst) + strlen(src).
"I'm not a real programmer. I throw together things until it works then I move on." - Rasmus Lerdorf
Um, I'm not defending mysql_real_escape_string. I'm not sure how you got that from what I wrote. I was saying use PDO.
Anyway, I don't care enough about what you're going on about to spend the effort arguing with you - it seems like you just want to argue, so how about we say "you win" and move on.
I know you don't care, you've made that very clear. If you cared about truth or accuracy, you wouldn't have made an appeal to your own authority by bragging about impossibly using PHP and making database driven web sites for 39 years, or tried to excuse your moving the goalposts by claiming to "have a bad habit of not clicking on parent to see what the context of a post is".
"I don't care" is Rasmus Lerdorf's attitude about security, software quality, programming, computer science, and unit tests, which is my point. mysql_real_escape_string is just a symptom that you're brushing aside and ignoring of the real problem you're in denial of, but guilty of yourself, which is systemic CARELESSNESS.
"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
"PHP is about as exciting as your toothbrush. You use it every day, it does the job, it is a simple tool, so what? Who would want to read about toothbrushes?" -Rasmus Lerdorf
"I actually hate programming, but I love solving problems." -Rasmus Lerdorf
"I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." -Rasmus Lerdorf
"When the world becomes standard, I will start caring about standards." -Rasmus Lerdorf
"I don't like programming. It's tedious." -Rasmus Lerdorf
What are you getting out of this? He worked on php and look how far it came, what have you done?
Your own website was written in php which you took down due to a security vulnerability in a framework... now is it php fault that someone wrote vulnerable code?
"Temporarily offline due to Drupal security vulnerability."
When did I blame php for Drupalgeddon? My web site says "Drupal security vulnerability", not "PHP security vulnerability", so I don't know where you're getting that from.
Back to the point: We're discussing mysql_real_escape_string. What's your excuse for it even existing in the first place, instead of simply fixing the security hole in the original mysql not-so-real escape string function?
Melania Trump's "I REALLY DON'T CARE DO U?" jacket sums up Rasmus Lerdorf's attitude towards security, software quality, programming, stardards, computer science, and unit tests. I just quoted his own words and bug reports that prove that point.
Do you like to leave loaded AK47s strewn around daycare centers, then blame the kids when they shoot each other? Is it ok if after the massacre you realized you made a mistake, and then scatter a few Nerf Guns around so the smart experienced kids who survived will have something safe to play with, but you still leave all the loaded AK47s?
I asked what you did. Then asked if drupals security was phps fault.
Are you seriously this butthurt about a function name, look up where the name came from originally. I also wonder what magical perfect language you use, dont tell me its php...
Not sure where you're going with the rest of this comment so I wont entertain that part. whew...
This is quite the thread and I'm having trouble following it, so maybe there's a reason why you're referencing such an old version, but you know PHP's currently on 7.4 right? Tons of progress over the last few years. If someone picks up a book that's 10 year's old or reads a blog post from 2010 and expects it to be 'current' then they have bigger issues. There are plenty of resources that cover modern PHP.
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 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).
> 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.
> 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.
“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
Not related to the discussion but as an East African and Ugandan( East Africa has five countries). I find this quote extremely offensive. I kindly request you to stop perpetuating such ignorant and degrading narratives even for the sake of comparison.
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.
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.
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.
Stop looking at the syntax, then. PHP semantics almost completely match Java's- single inheritance, no const, everything is a reference, effectively no top-level functions, etc.
And in what way is it actually less verbose? It's almost identical to Java...
As in defined outside of any class, object, or interface? PHP has a million of those and people write their own that way all the time. Everything is certainly not a reference and constants exist. Are you just talking about some narrow subset of PHP used in some frameworks?
I feel like your reply needs a little more context. Is the first part of responding to my claim of "effectively no top level functions"? If so, my response is that no public code seems to use them and they're much more of a pain in the butt to use because the PSR-whatever autoloader stuff only picks up classes. It's way more idiomatic to write static methods on a class- exactly like Java.
"Everything" is a reference as in "every instantiated class". Again, exactly like Java. Java has primitives. Any data type YOU write is a reference.
PHP is almost exactly Java 7, but with better null handling and way worse containers.
I'm trying to give you the benefit of the doubt here, but I'm really suspecting that I'm just falling for a troll.
I'm talking about WRITING PHP code. You don't WRITE top level functions. Every data type you WRITE is a reference type.
In C++, it is common to write top level functions in a namespace for others to use. In C++ you can write a class/struct and pass it to function BY VALUE. In Java and PHP you cannot pass by value, except for primitives (which you cannot author yourself).
Your PHP code will be semantically almost-identical to a similar project in Java. Not so with C++.
So TLF's exist and get used constantly but people don't write them often in code you look at (they do in the code I look at), you don't have to use classes and lots of pages don't but frameworks tend to stick with them, there are global variables, the syntax looks a lot more like C but class semantics exist, therefore it's exactly like Java. Whatever, if that's how you see it I guess I can't stop you.
And, even with syntax, the singular part of the syntax that looks like C is the arrow for method calls. Everything else looks like Java, including the fact that you use `struct` to group data in C, not `class`.
Also, you said C++ originally, not C. And PHP classes are NOTHING like C++ classes. They are everything like Java classes.
You're just wrong about being inspired by C++. At least in its current form.
Top level functions DO exist, admittedly. I just never see any libraries use them. I assume it's because the autoloader and composer work better with classes. What projects do you look at that use TLFs? Also, may I ask why you'd prefer them to static methods on classes (with private ctor). Isn't it less convenient to import them?
I never said PHP was inspired by C++. There are some similarities to any language of course but to me it's closer to looking like C with classes which is where the C++ comparison came from. Not really interested in that subject anymore.
> What projects do you look at that use TLFs?
Drupal defines a lot of TLF's and I've seen user-defined ones in it sometimes. Smaller/hobby projects use them a lot.
> 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.
The array key thing doesn't crop up often, but I've had it happen. Sometimes you are parsing something, such as "all files in this directory" and want to use the filename as the key and maybe store metadata or something as the value. Well, the second one of those filenames looks like a number, you're basically screwed. Now your array has some string keys and some int keys and operating on it is inconsistent at best.
And, you're right, of course that Apache and Nginx don't actually support PHP out of the box. It's been a bit since I've configured a server and I forgot that mod_php is an extra step. That is definitely the main "pro" to using PHP, though- the deployment is great and so easy I can literally forget it. ;)
Yeah, alright, I understand your example now but I would argue that it's more of a problem with actually using filenames as array keys than it is a problem with PHP.
Even so, wouldn't you be able to ensure that it's a string by doing `$array[(string)$filename] = ...`? (Again, I don't think using filenames for array keys—in any language—is a good idea but we're theorycrafting here.)
> Yeah, alright, I understand your example now but I would argue that it's more of a problem with actually using filenames as array keys than it is a problem with PHP.
No. Just no. There is no reason, a priori, that you can reason that filenames shouldn't be keys in a hashmap. I think you're just projecting from "can't be done reliably in PHP" to "software should not do it" which are NOT the same things. Seriously. What is it about filenames that causes you to think "No. There's never a good reason to map a filename to data without defining a whole new type"? What other things scream out to you that should never get to be keys for dictionaries? Names? Planets? Flavors of candy? Would you really believe this if you were working in another language?
It's exactly this reasoning that drives me nuts about PHP. You can point out the most insane behavior and someone always comes by and says "Nothing to see here. Just don't do that." Or "I just know not to do that, therefore PHP is fine."
> Even so, wouldn't you be able to ensure that it's a string by doing `$array[(string)$filename] = ...`? (Again, I don't think using filenames for array keys—in any language—is a good idea but we're theorycrafting here.)
Nope. Doesn't fix it. Because it's only converted to an int after being passed in. $filename was already a string. You're casting a string to a string and PHP, in all its wisdom, is then making it an int.
And I think it speaks to my point that you tried and failed to solve the issue. That's not an affront to you, by the way. It's more evidence that PHP is impossible to do correctly.
> You can point out the most insane behavior and someone always comes by and says "Nothing to see here. Just don't do that." Or "I just know not to do that, therefore PHP is fine."
I'm pretty sure what you're describing there is every programming language—or any object of fancy really. People tend to defend the things they like.
However, PHP wasn't even my reason for not wanting to use filenames as array keys. You're reading WAY too much into my response. And maybe you're right, maybe it's fine to use filenames as keys, but my initial thought was that maybe some programming languages weren't too happy about using e.g. emojis as keys so I'd prefer to be a bit more in control of what ended up in my keys, but I guess a string is a string (except when it's not ... apparently).
> Would you really believe this if you were working in another language?
I'm not even primarily working with PHP. I just don't have any huge issues with it and its quirks. You're not gonna hear me deny that it has its inconsistencies but I don't feel like I'm spending more time fighting the language than I save by developing in it, so for me it comes out as a net positive still.
> And I think it speaks to my point that you tried and failed to solve the issue.
I disagree. First of all, I gave you the very first idea that popped into my head without even knowing at what point the bad type-casting occurred. It was even phrased as a question specifically because I wasn't sure if it would fix it. Second, I would argue that this is an edge-case. I've done PHP on and off for a long time ("off" for at least the last 6 months though) and I've never run into this before. Or maybe I have, but then it hasn't been a problem because I usually don't mix associative and numerically indexed arrays, so `$arr['123']` would still find `$arr[123]` and I'd likely never notice what was actually happening underneath.
Oh, come on, don't try to defend a PHP design flaw by blaming people who use perfectly valid file names, and people who do perfectly valid things like using file names as array keys.
Can you actually refer me to a programming language style guide that says not to use file names as array keys, or are you just pulling that out of your ass -- I mean theorycrafting?
I've got a great idea, inspired by mysql_real_escape_string:
PHP should have a real_array() function and data type that doesn't screw you when you use file names as keys! Now we just have to get all the php programmers to defensively use the "real" version of every function and data type, just in case. And also a linter that complains when you use functions without the word "real" in them.
Sarcasm aside, can we please stop blaming the victims to whitewash PHP's obvious design flaws?
> or are you just pulling that out of your ass -- I mean theorycrafting?
That seems really uncharitable, he's just trying to better understand the issue and reason about why it may not have been an issue for him. Can we not all agree that if there are objective flaws in PHP, speaking about it objectively might be the simplest way to communicate it? I feel like you're quite emotionally charged, which isn't always a bad thing but I could imagine it being quite discouraging for other people to deal with.
"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.
The problem isn't about a preference between dynamic types and static types. I do think the tacked-on type system of PHP is pretty poor. But even without the mediocre type system, PHP still sucks. You want dynamic? Do Clojure, Lisp, Python (eh), Elixir. PHP and its broken foreach loops and lack of concurrency need not apply (and who in the world believes that forking a process is a good enough for EITHER concurrency OR parallelism for a backend programming language in this day and age?).
> 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.
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
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.
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.
My point is that it's not an undeserved reputation, there were many real problems. That's what was being challenged.
And the idea that it was reasonable to ship paper thin wrappers around a C API in a high level scripting language is one of the many problems that used to plague PHP. You could even get it to segfault with certain APIs because they would basically just call C completely unchecked. You also have functions having "out parameters" because the underlying C function does, even though PHP has multiple ways to return multiple values. I could also point out how basically every PHP subsystem had its own set of functions for error handling instead of having any kind of unified error system.
MySQL itself having made very questionable choices around the same era (and PHP and MySQL walking hand in hand) definitely doesn't help either, I grant you that.
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.
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.
But if PHP in 2020 still has a TON of warts and other languages (even ones with large ecosystems) have WAY FEWER warts, does it matter if PHP has improved since 2008?
Again, I stopped messing with PHP at 5.7 and have watched 7+ grow. My daily language is Go, which I like a lot. Had or have runs with python, asp!, Perl, c#, node, delphi and used rust and Java for personal projects.
I can find warts in all of them. At one point I'd have put PHP right above JavaScript and ASP down at the bottom. Now? I don't see it. Legacy issues are still there, like inconsistent standard library function names, but otherwise I don't see it - as a whole - as any more 'warty' than most of those.
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.
Please don't take HN threads further into programming language flamewar. That's one of the things that destroyed earlier internet communities, leading to the founding intention of this site [1], which is not to turn into scorched earth [2] or at least to stave that fate off for a while longer [3].
> 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.
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).
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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.
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.
A good place to start would seem to be creating naive aliases to these functions to at least fix the consistency problem. There's a possibility of breaking some code out there if someone made their own, say, "str_cmp", but we're used to breaking changes between major revs, and these could be fixed with a grep -l | xargs sed.
After that's done, we can talk about deprecation warnings, and then finally outright removal.
Doing that means you have to first agree on a name, strcmp has vertical consistency with C. str_compare might be nice, string_compare even nicer.
Once that debate is over you have to migrate all old code and all developers and teach them to use the new form. Throwing away all preexisting documentation and telling them why typing more is better.
Only then the old form can be removed.
Is it really worth it? - And yes, there is an argument "in the next 25 years there will be noore code written than in last 25" but still, is it worth it?
To give a feeling on the time period: PHP had this register_globals feature where URL (GET) and POST parameters became global variables. Getting rid of that, from introducing a replacement, over changing default and final removal of the option, too 10 years. When taking that time frame it's 10 years of confusion.
Problem 1 is basic standardization and naming things. Hard, but possible.
Problem 2 is is solved by adding the deprecation warnings. The code works, but it generates warning messages.
Yes, it'll take some time, but I'd argue it's necessary. Unless you've memorized the entire standard library, remembering which functions use underscores and which don't (and which ones use "to" vs "2") is an unnecessary mental burden.
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.
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.
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.