You are very close to implying that the language doesn't matter if you can hire developers and there are a lot of good packages in the ecosystem.
Having worked on several PHP projects (Most being version 7.0+ and zero of them being older than 5.3), the languages is STILL full of gotchas, and it's a huge drag on productivity. I assert that this DOES matter. Even basic stuff like trying to use the default "array" as a dictionary has absolutely ridiculous issues like if you try to use a string as a key, but it is a string of digits. It will automagically convert your string to an int and totally F-up your dictionary.
I've actually been bitten by that one. And it showed up in production, because I didn't know or care what the string keys might be. Who the hell would've guessed that behavior after working with non-broken languages before?
Inb4 "That just means you're dumb. Just use SPL. You can write bad code in any language."
I've used Symfony. It's good. I haven't used Laravel. I assume it's also good. I still don't know why you'd choose to start a project in PHP today when there are great libraries in many other languages that are not as broken as PHP.
Honestly, PHP 7+ is not horrible, but it's also not better than anything else... In fact, the very best PHP code you can write today looks basically the same as the best Java code you could've written a decade ago.
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.
I ended up building out a whole new array class to work around it. The notes at the top of my class file pretty well describe the problem: https://github.com/robsheldon/asinius-core/blob/master/src/A...
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.
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.
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.
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.
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?
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.
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...
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.
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.
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.
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 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.
However, I also use C/C++(Mostly low level embedded), C#, and Golang regularly.
If I was given the choice of what language(excluding C/C++) to launch a new web site I would still choose PHP with `strict_types=1` enabled.
The proliferation of Collection classes may be one side-effect of how poweful-yet-awkward they are.
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'm not that talented. I write bugs all the time. Most of the time, tests save me.
You can size me up as just childishly trying to divert blame when I made a mistake, but you're missing out by doing so.
Not sure about the productivity claim. I once wrote from scratch (frameworks excluded) backend and frontend (version 1) of a multi-tenant, cloud-based video-sharing platform with PHP as the backend (aws cloud) in a matter of weeks.
I once wrote, from scratch (frameworks excluded), an entire backend (and front-end) of version 1 of a hybrid mobile app (backend in PHP) for a medium-size logistics company in a matter of less than 2 months.
I have other examples, but life is too short trying to convince "haters" that they might not be 100% correct.
I was the only developer on both of those projects. Your mileage may vary :)
Also, the PHP ecosystem is friendly to beginners. Compare these authentication docs for a PHP project vs a .NET project:
Laravel (PHP): https://laravel.com/docs/7.x/authentication ASP.NET Core (.NET): https://docs.microsoft.com/en-us/aspnet/core/security/authen...
This is available with many other languages as well, i.e. https://github.com/cosmtrek/air
It may require an external tool, but the deployment experience is a lot simpler for Go than PHP.
I personally spend a lot of time hopping among technologies and I always lean heavily on documentation. PHP has pretty good documentation, and this helps a lot in my opinion. I would guess that a lot of developers don't read the docs and just assume that something in a less-familiar language will work exactly like they expect it to, and then call this a "gotcha" when it doesn't.
Because of spaces vs tabs additional overhead. Packages vs built-in libruaries. RAD frameworks like laravel vs Django.
Most of it won't survive a handful of years at best and most companies won't ever benefit from the attitude of some developers that ever developer on ever task should be writing FAANG level code.
What 3nds yo happening it matter what you do is the next agency / person comes along and claims its not fit for purpose any more and redoes it 'better' and the cycle continues of low value
Seems like a fairly minor language quirk (of which almost every language has) rather than a huge feature that makes one want to avoid the language at all cost.
Of course, feel free to make your own choice when picking a language, but I don't think this is a compelling reason why one would always want to avoid using PHP for their web backend.
Do you truly believe that I articulated that there was exactly one reason that I think PHP hinders developer productivity?
And of course, we brought out the old "every language has quirks" apology. Yes, you can bang a nail in with a rock. But, don't. Use a hammer.
Do better, please.
https://repl.it/@JadoJodo/SelfreliantEdibleUsers
edit: Not trying to discount your feelings overall, but just curious about that specific example.
https://repl.it/repls/CompetentBlondInstructions
Here I changed your string index to an int and it still says success!
If I hadn't considered string-number-keys in my code, I would also have forgotten about them in my unit tests. Maybe you're different.
I'm sure there are many with well-thought-out reasoning though, like seen in this thread.
It's useful to keep an open mind about things though. I'm probably more a PHP fan, but I can't say that I'm a huge fan of its programming style. It's much more enjoyable to me to churn out applications in .NET or in Ruby, but it's hard to argue with the speed at which I can develop in PHP or with the level of support online for doing so.
So the anti-PHP feeling for this group is broad but shallow. Here's what I think is interesting: JavaScript is here right now. Like PHP, it's incredibly popular, almost mandatory to know in some degreee, and using it for any length of time causes one to build up a catalog of "WTF?" and workarounds and "use this library instead" and a constant churn of "it's great if you use <some framework or conceptual approach> on top of it".
I used PHP a lot, and found it quite pleasant with Laravel, but the latent pool of distaste means I'll never go back. I work heavily with JS now, and can feel that wide puddle of "why do I have to put up with this?" spreading, even while other parts are really good.
I don't know how you overcome this, broadly. Perhaps it doesn't matter, because I think this group (and I'm part of it) blows with the wind more than most, and if the winds shift back, we'll probably come along.
As you said, there's almost always a solution to avoid the pitfalls but that makes you more and more "unhappy" with the language over time. I'm one of the rare people who can answer most JS trick-questions correctly, and that puddle has been building for many years (let's say more than 10).
On the other side, I'm very pragmatic and using tools like ESLint and Typescript (well that's just JS with SUPER pragmatic typing in my eyes) started to make it a joy again in the last few years. I hope the trend continues. I can't say the same for my PHP experience.
Also, I have a theory that with the more common languages, you obviously find a much broader user base of beginner-level programmers, or, worse, programmers who just don't care about quality, which translates to more dysfunctional code in the community in general. My coworker at one company did not have good things to say about PHP, but when he had to take over a PHP project of mine when I left the company, he said it was some of the most well-written PHP he's ever seen -- organized, easy to follow and modify, etc. He didn't even realize PHP could be written in an eloquent fashion. (Not to brag, I've written plenty of bad code too.) Point being that if all you see in a certain language is jumbled spaghetti code, it's easy to think of it as a bad language.
A good programmer should be able to create eloquent code in any language.
Edit: Realized after posting I may have sounded like I thought you were not a good programmer -- that's not what I was saying at all! You can write eloquent code and still be frustrated with what the framework or community forces upon you.
It's a very good point: the more widespread a language, the larger the proportion of users will be beginners, who will almost certainly confuse their own inexperience with language-driven frustration (again, c.f. JavaScript). My pet theory on the broad appeal of PHP is that it coincided with the easy availability of shared hosting accounts where PHP was the default scripting environment available. The barrier to entry for blogs, shopping carts, forums, everything was incredibly low, leading to an explosion of software, tutorials, walkthroughs, and community that was heavily slanted towards beginners, dilettants and "low end" programmers". I made a living as one for several years, doing PHP for $5-10k jobs, and there was endless small-business work in this segment.
If modpython had worked as well as modphp, the world might look very different today.
After years of using a lot of products and seeing which ones succeed and which ones fail, I question whether there's much of a connection between code quality and product success, assuming of course that the code isn't bad enough that it prevents the use of the product.
Heck, I'm not even sure there's a strong correlation between basic product function and success, at least in the enterprise space; I've seen a number of successful products that barely even work. Seems like market positioning and sales are the bigger factor.
One brand of hammer causes RSI. This brand of hammer tends to bend nails unless they're made of titanium alloy at 80% higher cost. The houses built are basically fine, but they have quirks as a result of the builders trying to avoid having to use nails. You lose 10% of your workforce after every project to medical leave and burnout. Everything is fine because people keep buying houses (there's a shortage).
It's one of those foundational issues that I just can't get over.
...but it's my personal problem - I don't hate PHP.
In all new work we require static typing on method parameters and defined return types. Of course, if your type is 'array' it could be an array of anything but we also try to avoid that and use collection classes. It honestly feels a lot like Java now, without the compile step.
As a mostly-acceptable alternative, we just type hint as array and document the actual containing types in the phpdoc block and run phan for static analysis to catch any potential screwups.
/**
* Method for converting Foos into Bars
*
* @param Foo[] $foos
* @return Bar[]
*/
function convertFoosToBars(array $foos): array
{
// ...
}
In theory this isn't perfect. In practice we haven't run into any issues yet.Edit: and by "our" dumbass bullshit, I mostly mean when we thoughtlessly return type T when we claimed we'd return type U
I wouldn't be surprised if many of them don't even have that experience. I've found a lot of people just parrot whatever someone else wrote or said without much thought. The tribalism within the development community is approaching what you'll find with in gaming, sports and even politics.
That being said the biggest argument for PHP is productivity and I just prefer Ruby + Rails for that. Honestly though I will say I find PHP more pleasant to work with than Python these days.
Think this is true. I am one of those php haters, although I wouldn't trash it. I worked with 4 and 5 and the transition between the two, so it is a while ago. I am not fondly remembering that time and have moved to other branches than web development to evade it.
That being said, if I would go back to web development, I would have a look at it. Why not?
The point being, you can hire good php devs.
Heck, I just read the docs of hack for 2 hours, and I already got a good sense of what the language can do. I worked with PHP internals, and a bunch of other languages in my career.
* as language we define the language, its syntax and semantics, not any other library or the ecosystem. And yes, the standard library is still just a library. Knowing a list of functions and parameters does not mean knowing a language.
Some developers live in a kind of technical vacuum where, I guess they assume, the technical features of their programming language are what makes the difference in the value of the business they're building.
In reality, the difference is in how easy it is to hire developers, the package library, overall ecosystem and developer experience, or: how can I make a great product.