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.
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.
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...?
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
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%.
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.
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.
Yeah sure, no need for state in a CRUD API. But while it is the most common use case for PHP applications (well actually for application written in scripting languages working with http servers), it's not the only use case.
When the only place where you can put state is the database then every piece of state is written in the database. Which lead to intelligent individuals (no pun/offense intended) to write clever piece of infra such as Redis. The truth is, for 10 Redis deployment there's 7 (8? 6? Well, a substantial part) where a long living process holding little state would have done the trick. Now you need to deploy, maintain and scale Redis too.
Yeah, but having to use Redis is a must for any web app/API that grows. So all PHP is doing here is forcing you to adhere to best practices of shared-nothing architectures early on.
Session variables are tied to user sessions (like name suggests), so they cannot be used to persist application state (e.g. cached content, compiled templates, metrics, etc.)
I see downvotes on my GP post, I'm simply stating the fact: if you need state for a building a powerful webapp then obviously there's better runtimes that PHP+Apache, I don't see how one could disagree with that statement, apart from not having sufficient experience in that matter.
There's plenty of good reasons to counterbalance that fact thought, PHP has a very good ecosystem, multiple mature/powerful web frameworks, and cheap/abundant workforce. But it lacks a state holding runtime and for the most demanding applications it's a sufficiently big technical hassle to encourage seeking other runtime and/or 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.
> 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.
"Easy to deploy" and "Many cheap webhosts are already configured for it" are still very different things. I never found it helpful to conflate them. For example, a VPS with CPanel/Plesk is quite the dependency. As is "a cheap PHP webhost with servers configured for your PHP scripts".
I look at it this way: PHP apps are so easy to deploy, it's a commodity. I run my own dev servers then move them to VPSes, billed to the client, for deployment.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
>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?
>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.
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.
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.
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 never got the "write-only" criticism. If you understand a language thoroughly code is always readable. What's with the insane double param naming? And why do I have to escape and opening paren? No other language requires this.
It’s an enormously flexible language, and can be used to write almost inscrutable code, if we choose.
However, it can also be used to write extremely readable code.
I think it’s a sisyphean exercise, trying to get programmers to write readable code, but we keep trying.
Like I said, Swift is a bit like C, where it can be used to write obfuscated junk, if the programmers want.
My experience is that “idiomatic Swift,” as prescribed by many authorities, is starting to look like that.
I’m not exactly sure what you mean by “escape an opening paren.”
Do you mean inside of strings? That’s a direct inline shorthand that is similar to `...` in other languages. Totally optional.
For example: print(“There are \(numberOfSheep) sheep.”) is direct, as opposed to print(“There are “ + numberOfSheep + “ sheep.”), or print(“There are “, numberOfSheep, “ sheep”).
The fact that most devs use _ to work around it surely suggests that it was a pointless idea in the first place. Of all the barmy ideas to make a programming language unique this surely tops the list. As for escaped opening brackets you have to ask why no other language found this necessary. Is the Swift parser really so dumb? These 2 language features prove that however clever a language creator may be he/she can end-up producing features which are frankly absurd.
Not “most.” Just “many.” I do feel that "most" Swift programmers try to stay within the philosophy; even if only by rote.
I tend to eschew argument labels for the first argument; relying on the function name to provide context. That's a pattern that Apple also uses, and comes from ObjC, which came from Smalltalk, so Swift is actually informed by Smalltalk; a venerable OO language.
I’m sure that you can do amazing stuff in Perl, and I apologize for my "write-only" crack. It was not conducive to the conversation (which was about PHP). One of the reasons that I don’t use it, is that I guess I never got good enough with it to really sing.
The best tools can be misused.
Ever see a great musician play a beat-up old Univox, and sound like a chorus of angels, then someone buys a PRS, and sounds like a cat being tortured?
We can get hung up on the tools, and forget that the tool is secondary to skill and experience.
Well, toe-MAY-toe/toe-MAH-toe. No matter. I’ll keep programming in Swift, and limp along.
> 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:
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).
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.
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.
> "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.
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!
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.
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...
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.
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.
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 ._.
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.
Holy shit I was just looking at their site the other day and bounced because the price was way beyond anything I'd consider spending. It didn't occur to me that they price differently for individuals, or that it'd default to showing me organization pricing, and after reading theses posts and checking the site my first guess was that individual pricing would be higher (it's much lower for some reason? Are the org. ones multi-seat? They don't seem to be. WTF.)
I'd never have even looked at their site again if I hadn't happened to read these posts. Yikes. They need to call that out much more vividly if they're gonna have weird pricing like that.
I just started using an extra vertical screen, but when I move my head to the left, everything turns red then darkens, and when I move my head to the right, everything turns green then darkens. Should I be wearing those red/green 3d glasses to compensate?
With modern monitors being as large as they are already, I'd say the need for a vertical monitor is likely an indication you're working with spaghetti code.
With modern monitors being as large as they are already, I'd say the need for a landscape monitor is likely an indication you are working in callback hell.
But it's not code all the way from side to side; I've got project structure on, etc.
Meanwhile on the screenshot in the comment I responded to, the vertical monitor is shown only to display a long script or program of sorts, nothing else. I googled for the images of "vertical monitor programming", and the same is true for virtually every picture of such setup. I feel it's not a coincidence
Yeah but usually vertical screens are really easy to rotate back to landscape. Does anyone use an exclusively vertical screen? I've never come across it.
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.
I haven't checked it, but I think the worker stays up, and deal with several requests during its life time, not just one then die. Hence, there is pesistence.
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!
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.
> 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.
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.
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 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!
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).
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).
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?"
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.
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 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.
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.
Once or twice a year I have to peak at the code of a PHP 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 PHP than its birthday !
However this app isn't GDPR compliant and I have good hope that it will be gone in about a year.
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.
> It is possible to make something great with substandard tools.
Is PHP substandard though? While it's no longer my cup of tea, I do remember it being fairly stable and performant.
Some of the enterprise software I work with, that was written in Java is ridiculously bad, but I don't consider Java substandard. Real world example: the "Configuration" app I use takes a minute to start up on modern hardware, and it's main job is to give a tabular GUI to an XML file. Even saving the configuration can take a minute.
In my experience, and of course opinion, yes. Java might also be "bad", I don't know. I programmed it for a bit but didn't like it so moved on.
The main problem with PHP, the real killer, is not that it's complex, or the needle/haystack parameters to functions changed, or the iffy string escaping/unescaping or all that stuff, it's that it's hard to know all the edge cases in the language that could cause you to write a bug. It's hard to look at a piece of code and say "that's going to work the way I think it does". Javascript has the same problems with it's string/number/NaN/coercion wattitude.
I want to be able to reason about my programs, because almost all of what I do (and I guess most people writing anything other than the most trivial application) revolves around handling data. Names, emails, files, data, preferences. If the language I am writing makes it hard to see the bugs, then it makes it more likely that there will be bugs.
There is a common counter to this, and that's that good PHP programmers know about the edge cases, but there's a hell of a lot of average programmers out there.
I definitely get where you're coming from. But everyone is different, and thinks differently.
I did a lot of Rails after PHP, so I like using Coffeescript, even though that admission would get me mocked on any JS forum, since I've seen many people be called an idiot for not preferring Typescript.
As for frameworks, I like Svelte, because it works the way I think. I've seen a lot of negative comments from React and Vue users on people using less popular frameworks like Svelte.
My general attitude about these things is "if it works for you, that's great". I'm no longer a PHP user, but I don't think the reasons why I liked it 15 years ago have changed, even though my preferences have.
> I definitely get where you're coming from. But everyone is different, and thinks differently.
You have talked about preference a lot, and I honestly don't really care what people do or don't prefer, that's totally up to them. I will judge people for it, in the same way I would question someone's judgement if they insisted against all evidence that there was nothing wrong with their shoe-hammer. Personaly I quite liked Objective-C, but a lot of people kinda thougt it was the devil in programming language form.
The problem with PHP is that there's a huge amount you have to know about the corner cases and edge cases that could cause you to write a bug or security flaw into your application. It's like there's an encyclopedia of weird behaviour that you have to remember all of, and it's going to be hard to remember all of the issues in all situations.
> The problem with PHP is that there's a huge amount you have to know about the corner cases and edge cases that could cause you to write a bug or security flaw into your application.
The amount of PHP you need to know to avoid the sharp edges depends on the complexity of your application and what you're trying to do.
I don't make assumptions about what people are trying to build.
> I will judge people for it, in the same way I would question someone's judgement if they insisted against all evidence that there was nothing wrong with their shoe-hammer.
I also don't make assumptions about how a person evaluated and/or prioritized the tradeoffs involved with their choices, because their choice in itself doesn't tell a complete story.
Sometimes what might appear to be a bad choice was well reasoned at the time it was made. When Twitter was made, "Rails doesn't scale" was a common insult against it. But Twitter might not have been built they been forced to make it in Java.
> The amount of PHP you need to know to avoid the sharp edges depends on the complexity of your application and what you're trying to do.
Not really. You aren't insulated from the edge cases until your application reaches a certin number of lines, at which point PHP flips the switch and you get the edge cases.
The edge cases are there and affect you from the smallest program right up to the largest, it's just that with larger programs you're more likely to hit them because you have more code. The target is bigger.
So you're saying if I do a simple PHP status page that is only rendering data from a static JSON file into some HTML (which is basically all I'd use PHP for these days) it requires me to know a pile of edge cases?
Does someone making a simple a PHP application on a home NAS that isn't exposed to the outside world need to worry about SQL injection from their kids?
Are you saying that PHP is only suitable for trivial non user-facing apps? We are in agreement!
The reason you need to know all the edge cases though is because when you write a sigle line of PHP you need to know how to avoid the edge cases in that single line.
Just because you are writing a short program doesn't mean the edge cases aren't there. Array keys getting converted to numbers doesn't suddenly start to become a problem when you hit 300k lines.
If you don't know the edge cases then when you do need to write something more complex, or larger, or user facing, PHP is a terrible choice because there are so many edge cases that they are hard to completely internalise.
Wouldn't it be better to write in something that isn't such a terrible footgun?
There are hundreds maybe thousands of languages. And when you measure all things (expressiveness, stdlib, productivity, ability to build a team, etc.) PHP would come up in TOP10 for any webapp.
Of course, it has its gotchas. So does Clojure, Ruby, Python, C#, etc. Honestly, once a person knows PHP very well, switching a language has almost no impact besides their "feeling".
I have switched from PHP to Clojure 8 years ago. I feel better. But I am not significantly more productive. The brevity of code is higher, abstractions easier to do, overall it just feels better. But it's not a silver bullet. At the end, when a huge amount of webapps are mainly working with a database, validation, putting data to templates, and all the auth staff. All this is usually well developed in existing frameworks and libs without any extra overhead. There's not a lot of space for elegant abstractions in average webapp.
> If PHP is a rusty saw, what isn't? There are hundreds maybe thousands of languages.
I was curious, there's about 9000 according to a cursory google search.
> And when you measure all things (expressiveness, stdlib, productivity, ability to build a team, etc.) PHP would come up in TOP10 for any webapp.
>
> Of course, it has its gotchas. So does Clojure, Ruby, Python, C#, etc. Honestly, once a person knows PHP very well, switching a language has almost no impact besides their "feeling".
Maybe PHP is in the top 10 for some of the things you mentioned, and you can definitely build a PHP team pretty easily, however:
Productivity:
I am sure that most people can get their PHP programs to a state where they at least seem to do what they want, the problem with PHP is the sheer number of gotchas and edge cases. Here's some I put together for another commenter: https://gist.github.com/wjessop/0923e0667d7dd53ae0503459894e.... It took me minutes to find these, there are many many more.
Sure, you might be able to get your e-commerce site off the ground really fast in PHP, but are you doing the job that you should be doing? Did you remember to check for every single edge case? Are you coding security flaws into your app? How sure are you that you didn't miss an edge case and you're tallying your basket wrong in some circumstances?
Unless you are veryvery good at PHP then you are going to miss this stuff and it's going to come back and bite you in the ass. There has even been a study into how bug-prone different languages are: https://www.i-programmer.info/news/98-languages/11184-which-...
A key phrase:
"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."
All languages have flaws, but PHP has way more than most.
Building a team:
Most PHP developers are likely very average PHP programmers, just like most Ruby developers are likely very average Ruby developers. You would need to be a super-human to be able to program PHP correctly taking into account all the edge cases, and so yes, building a team is easy, but if you want to build a team that build software that isn't a liability, then you need to hire the absolute best PHP programmers, and that's going to be very hard.
you mean your favorite language prevents you to copy paste code, have variables shorter then 4 letters and also fixes the bugs for you, let me know this cool language so I can try it.
I am also sure that in your first years of coding your code had no issues similar with the ones you described.
> your favorite language prevents you to copy paste code, have variables shorter then 4 letters
"here's one place that PHP doesn't prevent poor quality code that is the same as other languages, and so all languages are the same"
No languages prevent these things (that I am aware of), but not all languages have the same number of edge cases that PHP has.
> and also fixes the bugs for you, let me know this cool language so I can try it.
I've written a lot of languages over the years, but right now I'm enjoying Go, which kinda does help prevent me from writing bugs with it's static typing, but also it's simplicity.
> I am also sure that in your first years of coding your code had no issues similar with the ones you described.
What's your point here? Noobs write bugs and bad code? Sure, we agree! But that doesn't mean that PHP is a good programming language.
If PHP is a bad language, your complaints are just just irrelevant, I could probably find some bad code base made in Go and prove that Go is bad.
> but not all languages have the same number of edge cases that PHP has.
I agree , some have more some have less
The things is that from your comment it shows you have no idea what you are talking about, I suggest you let people with experience in PHP to explain hat are the issues and how to work around them. I have a few experience in PHP, experience with 5.4 and older PHP not the 1990 version.
What I could complain about PHP are small things I do not feel that I need some feature from Java or C#, my time is spent reproducing bugs reported by our users, debugging and fixing them or spent on adding new features, creating solutions etc.
I admit when I was younger I would complain about why do we have to use AS3, or PHP or X for this, there are better languages but this days I know that the language is a small part of the entire project, the hard part is creating solutions, a new dev will start by typing code and offering you a fast solution that someone else needs to fix it later, an experienced dev will think at 2,3 or more solutions, consider all the advantages and disadvantages, test then and finally start writing the code - so IMO the fact that soem language has a bit more sugar coding or and IDE starts 2 times as fast is irelevant, what is important is the person that generates the solutions and the person that when a bug is raised can dig deeper and find the cause and fix it.
> If PHP is a bad language, your complaints are just just irrelevant
I don't really understand what you mean here.
> I could probably find some bad code base made in Go and prove that Go is bad.
"It is possible to write bad programs in PHP and also in Go, and therefore the languages are the same"
YOu can write bad code in all languages, but PHP makes it harder to write good code.
> The things is that from your comment it shows you have no idea what you are talking about
Yes, my 21+ years of experience writing code in over 10 different languages, including a decent amount of time writing PHP, pretty much means I don't know what I am talking about.
> I suggest you let people with experience in PHP to explain hat are the issues and how to work around them.
<raises hand>
> What I could complain about PHP are small things I do not feel that I need some feature from Java or C#
I am not talking about features. In fact, Go has a surprising lack of features, it's one of the things that makes it pleasant to write, and easy to write well.
I mean your proof is I seen PHP code then conclusion is PHP is bad.
You are trying to compare PHP with Go, probably Go is better then PHP, but if Go is better that does not mean PHP is bad, just that Go is better (probably not for all use cases).
So you have experience with PHP, probably are you thinking at html code mixed with PHP code? yeah that thing is bad but only news use that for large projects. If you do not mean that then I am not sure what PHP issues prevent you to write good code.
> I mean your proof is I seen PHP code then conclusion is PHP is bad.
You're over simplifying my point to make yours.
I have seen bad PHP code. I have seen bad Go code. I have seen bad code in many languages.
The proportion of bad PHP code however, is higher in PHP, for the reasons I've stated around edge cases and the difficulty in reasoning.
> You are trying to compare PHP with Go, probably Go is better then PHP, but if Go is better that does not mean PHP is bad, just that Go is better (probably not for all use cases).
Go being good doesn't make PHP bad, and PHP being bad doesn't make Go good. I'm not saying one thing is true because the other thing. I'm saying that PHP is a bad language.
> So you have experience with PHP, probably are you thinking at html code mixed with PHP code? yeah that thing is bad but only news use that for large projects.
Nope, you're making untrue assumptions about my experience. The largest project I worked on was over 300,000 lines of PHP and used templating. It controlled everything from a companies finances, to printing plate layout, to believe it or not, sorting robots on a conveyer belt.
> If you do not mean that then I am not sure what PHP issues prevent you to write good code.
I've talked about this. Edge cases and the inability to reason about the code. In PHP there are a ton of weird little behaviours or edge cases that you just have to know about that could cause bugs. It's hard to know all of these, and even if you do the sheer number of intricacies of the language means that it would be easy to miss some.
PHP isn't alone in this. Go has little gotchas, Ruby has a fair few, Javascript has plenty, but PHP has loads.
Here's some that are utterly trivial to find. There are plenty more. Feel free, as a supposedly competent PHP programmer, to go and find the rest, becayse you definitely need to know about them to be able to write code that's going to work properly.
Moved the examples to a gist due to HN formatting:
This gotchas are similar to JS or Python ones. I hit more issues related to php configuration or server configuration then language issues, maybe because I use a good IDE that will prevent such trivial bugs.
There are edge cases in many languages, there are more in PHP. It would be better to not have the edge cases than to have an IDE that tried to pretect you from them.
I agree with you in most part, just it seems you imply PHP is the worse, I assume you mean is worse then Go,Python ,JS etc.
As I said earlier if PHP < Go it does not mean PHP is a dull tool and not suitable for some projects.
If you disagree I am curious of a really example of something that is super hard to do in PHP compared to Python/Ruby/Go , some real world thing. I am aware of the weak points of PHP but I think you can do your job with it, the language is not dragging you down.
I absolutely believe that PHP is worse than many, if not most, other langauges. I have programmed (in a non-trival way) close to 10 programming languages (and fiddled with more) over more than 20 years. Of all those, there are only two that I hate, PHP and Javascript.
PHP (and to a lesser extent JS) are the only languages (that I have experience of) that it seems actively work against the developer writing bug free programs.
Tools reach a point where they can be considered to be dull, and they're not dull before that. PHP in my experience and opinion has crossed that boundary.
> it does not mean PHP is a dull tool and not suitable for some projects.
I think it depends. Should you use PHP for small stuff? one-off's that you run on your home network? I mean, you could, right? No-one's going to access it other than you, so you don't have to worry about user supplied data. But should you use it for Internet facing stuff? Shopping carts, user data? The difficulty is going to be ensuring that you've not coded bugs or security problems into your code, so I would say the answer there is no. I looked, there's been a study (there might be more than one, this was the first result) that has found that PHP is more prone to defects than a lot of other languages (beaten only by c and c++): https://www.i-programmer.info/news/98-languages/11184-which-...
The interesting quote:
"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."
This is my experience both writing PHP (lead developer for over a year on a 300k line plus app), and reading it. PHP is hard to write well.
So if you have decided it's not for you with the big projects, why bother with the small ones? They might after all become big projects, but even it they don't, the other languages aren't really that hard. I wrote a Go program yesterday that reads temp and humidity off an i2c bus connected sensor on a Raspberry Pi and writes the data to an influx DB. It is less than 100 lines. It can run from systemd, it uses threads, it's damn fast, and it was even easier to deploy than PHP necause it's just a binary.
It's also far far less likely to have bugs in it.
> If you disagree I am curious of a really example of something that is super hard to do in PHP compared to Python/Ruby/Go , some real world thing. I am aware of the weak points of PHP but I think you can do your job with it, the language is not dragging you down.
You can pretty much do anything in PHP that you can in other languages, it's turing complete after all, but then again, so is the sendmail configuration language.
The issue with PHP is that it makes the task of writing bug free software so so hard.
Actually my favorite language (C#) comes with static typing, a compiler, a step by step debugger and an IDE that allows me to have long variable names at no cost and I have fewer bugs.
So yes my first year code was better than what these 2 interns did in PHP and a random text editor.
Had they used C# (or Java for that matter) the app would be much more maintainable in the short time that I can allocate to it.
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 !
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
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.
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
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.
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.