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?).
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?