> if you try to use a string as a key, but it is a string of digits. It will automagically(sic) convert your string to an int and totally F-up your dictionary
I've been a PHP programmer for over 15 years and I cannot think of a single time this has been an actual problem. It sounds like you were embarrassed by a bug in your code and have just decided to blame it on the tools.
It's a real-life problem. I just recently stepped in it while working on some software that interfaces with imap. A couple of folders were named "2018" and "2019" and common array*() operations kept blowing up with those keys.
There are native-php workarounds and if you're very very careful you can probably maybe encounter this and code around it without triggering any of the strange behaviors, but it's a minefield.
I'm not new to PHP, either. I think by chance people just usually don't encounter the circumstances for this particular bad behavior, but when it happens, it's really bad. Array keys shouldn't be getting implicitly typecasted.
My guess is that the numeric indexing thing happens a lot but it's definitely rare for it to cause a visible problem and even rarer to be identified as the cause since it is unexpected.
I've been bitten by it and also stuff like 800=="8E2".
I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I have wondered whether something about PHP, or something that it lacks, makes PHP projects easier to estimate.
Ease of deployment? Batteries included standard library? Pragmatic community? Surprisingly adequate performance? It never seems like enough to overcome the obvious deficits. I can neither ignore my own experience nor convince anyone that it's actually great.
I'm in a similar boat. I've decided that whatever it is that makes PHP successful must be exactly the same thing that has made JavaScript successful.
It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light of those immensely popular languages, I could see why someone might not think that any of the deficiencies are deal-breakers.
Maybe, in my case since I am currently in the non-PHP phase of my alternating PHP/non-PHP job history. PHP has been less than 50% of what I've done (the rest being far more on-trend, if you will) though disproportionately represented among successful and profitable projects.
The only-ever-PHP coders I have known tend to be fairly polarized between fear of the unknown and the "grass is greener" attitude.
The ease of estimation thing was an aside, but I'm getting more convinced. With PHP there is only one way to do any feature: look up the library function, type it, refresh the page, and slowly accrete your functionality. With other languages there's some hope of a free lunch and it engages our tendency to optimism.
With other languages there's some hope of a free lunch and it engages our tendency to optimism.
Asking as someone who's mostly only written PHP (and some javascript, more recently): can you expand on this? What kind of "hope of a free lunch" is there with other languages?
I think there are a few, and maybe I am the only one who has ever been foolish enough to think these things or incompetent enough not to achieve them.
The first is the promise of DSLs and meta programming, where you can tune the syntax of the language to more naturally express your problem domain. When this works it's beautiful, but sometimes it is a distraction and makes the code difficult to debug.
The second, which is conceptually very different but I find it can play out similarly, are rich type systems where you can hopefully build up your application as a series of well defined type relations and transformations. Again, when this works you get really robust, reliable, and easy to modify software but there are often cross cutting concerns or business practices that break the model.
Edit: when I talk about a free lunch or a silver bullet, I am often thinking about the writing of Fred Brooks.
As someone who's worked heavily in C++/Java and tends toward functional programming approaches I enjoy PHP. There are some features in the language you should avoid, variable-variables being one of the ones that makes logic very difficult to decipher - but C, C++ and Java all have those - and Javascript has the wonderful combination of substr & substring. The useful portions of PHP are extremely powerful, having access to magic functions, a much more advanced concept of a local symbol table and a surprisingly good approach to inheritance & composition all end up bringing down code maintenance when well applied to provide clearly intentioned logic.
Going a bit off-topic, but I can't imagine doing "functional" programming in PHP or Java. C++ has const and top-level functions (PHP kind of does, but the autoloader...). It has (real) generics. It has move semantics, which is great for functional pipelines.
I do functional programming in C# and used to do it in Java at university. C# makes it marginally more pleasant but in general it’s pretty feasible, people will just look at you funny.
Just to tease it out more. What do you mean by functional? I assume that you design your classes to be immutable (only getters with defensive copies when needed). Do you also keep most business logic as pure, static methods on non-data-holding classes?
That's about as far as you can go with Java, I guess, but honestly, now that I type that out, I guess that does get you pretty far...
Yes, classes are just POCOs (sometimes with some sealed subclasses, to hack sum types) and business logic is static functions in separate classes. Like I said, C# makes this somewhat easier, with things like readonly fields, get-only auto-properties, System.Collections.Immutable, readonly structs, pattern matching, etc. With Java you have to take more care to encapsulate things properly, though I’m excited for records coming into the language.
The most salient problem is the fact that the languages do not distinguish between references and values (aka “mutability by default”) which means that the compiler will not maintain those invariants for you unless you annotate things specifically, and the authors of the libraries you use do the same.
My overall preference is for F#, which is ironically a better object oriented language than C#, by virtue of using ML-like syntax instead of C-like. Nonetheless, C# is a passable functional programming language these days, and the language designers keep adding more functional-inspired features with every release.
Yes, that did sound condescending. I'm both a defender and detractor of JavaScript. I'm mostly a detractor of PHP, but could possibly defend it once in a while if I see misinformation.
Peter Norvig at some point came to the realization that the deficiencies of Python relative to Lisp were not deal-breakers, and I don't think that stemmed from his limited experience.
Perhaps it was condescending, but it was, first of all, not intended to be malicious. I have had the luxury of having used a lot of programming languages for various projects. The first N years of my career, I used mostly C++ and Python. I didn't like Python much and was pretty convinced that C++ was the pinnacle of programming languages.
Since then I've done (real, professional, for-profit) projects in PHP, Go, Java, Kotlin, Swift, Rust, JavaScript, Elixir, and Clojure.
So when I work on PHP and Java I can feel what they're missing. It's simply the luxury of having experienced working in (what I consider to be) better languages. Clojure and Elixir were not my cup of tea, but I still find them to be better quality languages than JavaScript.
I have met many developers in my life. Some with quite a lot of experience. The VAST majority of them have only ever worked in a handful of very similar languages. Mostly the ones I listed originally (I forgot C# in the list, but that's more-or-less Java++). If I'd only ever used PHP and Java I would literally not know what a good type system looks like. It's ignorance, but not stupidity.
And I'm talking about people I have much respect for. People who I acknowledge are smarter than me. That doesn't mean I don't know anything they don't, though. And if they've only used PHP and Java, then I know some things they might not. That's all.
EDIT: Also, I'm not sure what Peter Norvig has to do with it. I bet he doesn't like PHP, either.
> Also, I'm not sure what Peter Norvig has to do with it. I bet he doesn't like PHP, either.
Your comment wasn't about people who like PHP. Your comment was about people who defend JS or PHP to the minimal extent of saying their deficiencies are not deal-breakers.
There are people with broad experience who are willing to accept deficiencies of a particular language if the context is right.
(I don't actually know what the right context would be for PHP; I'm more stating a general principle.)
I suppose you're right. I did not mean people who shrug and say "Yeah, PHP sucks, but I'll defend its use here for X reason."
I was more, in my head, describing people who say "Well, all languages have issues." or "You can write good/bad code in any language." or whatever other bottom-of-the-barrel defenses I often hear and read.
Is "powerful" really even the right description? I can't even do a map + filter without looping through the array twice. Ew. I guess I'll just stick with the primitive foreach loop (which leaves a dangling allocated object after you use it... sigh).
I agree that the issue mentioned above isn't that bad - as a long time PHP developer (and PHP admirer) one gotcha that still really annoys me is persistence of key refs outside of foreach loops and I present this eval[1] as a wonderful example of why you should really prefer array_map for mutating array values or be very pedantic about unsetting variables when you leave a foreach using ref loop.
Except that if you do anything other than mapping, you start taking a performance hit. If you want to use array_map with array_filter, you're now iterating your array twice. Also, if you ever use array_filter, you almost certainly need to wrap it in array_values, so now you're looping N times.
It's no wonder people still lean on the broken foreach. I always use unset() after foreach. It makes me die inside a little.
I've been a PHP programmer for over 15 years and I cannot think of a single time this has been an actual problem. It sounds like you were embarrassed by a bug in your code and have just decided to blame it on the tools.