I have 20 yrs of programming experience in various languages than I care to count, as much as 20! So I do know my languages. From an academic perspective, PHP blows! But from a practical standpoint, it's a tool. It get's the job done, so long as you know it's quirks, you can avoid them. It's much better now with the OOP support and with PHP7 supporting scalar type and return types declaration. It's going to even make it possible to develop more robust software.
I'm indifferent to hearing about PHP sucking. So people say it as a put down. Perhaps they groovy or scala. I really don't care. It pays and that's all I care about. When I engage in my own personal projects, I never use PHP. PHP's documenation is not bad, but best-in-class? Please! With that said, I agree with your last sentence, in the sense that a good programmer can get more done with a bad language like PHP than a bad programmer can get done with whatever the hell one chooses to consider a good language.
You're using Apache Groovy as a counter-example to PHP blowing? Groovy's the PHP equivalent in the JVM world, the sloppy partner to the more exacting Scala, Clojure, and Kotlin.
Since its first release in late 2003, Groovy's been extended and repurposed so many times it's not really one unified language anymore. The MOP stuff was added for Grails in 2006, the half-baked types when generics were added in v 1.5, the pluggable annotations in v 1.6, the command syntax in v 1.7 to appeal make Gradle builds look nicer, the static typing in 2.0, traits in 2.2, the unsuccessful switch to Android deliverables after that, with backwards incompatibilities between minor versions. And then there's the stuff that silently got dropped, like interceptors and empty try statements.
Groovy's OK for quick'n'dirties scripting Java classes and defining builds, but for actually building systems use a language built from the ground up for that purpose, e.g. Java, Scala, or Kotlin.
There's seriously wonky things in there like the associativity on ?: being wrong, and == being even more broken than in js. There's order of arguments on array_map and array_filter being inconsistent. It's not that there's a massive flaw in there that kills it, it's death by a thousand paper cuts.
Threading/asynchronicity comes to mind. I've worked on a few projects that started out as a web-front end, but then needed to do some background processing. Eventually the background process needs to be multi-threaded and the choices are: rewrite your code to support pthread's wrappers classes, use fork and shared memory segments, asynchronous web requests. All those solutions work, but they are much more complicated than the same task would be in most other languages with native threading support.
I find it quite sad that most PHP developers seem to think that writing code that looks more like Java is the "correct" thing when its greatest features have always allowed loose types and first class functions. After all that's what makes it so easy to work with?
Perhaps PHP could have been more like Scala a few years back already.. the perfect combination of Objects and Functions...
The real annoying part is that by nature it will never have the same amount of IDE niceties you'd get with more typed languages
I understand JS having its place as being ubiquitously supported in browsers but, just as PHP, it's bad and its problems are not about niceties from IDEs or static typing.
It's not quite bad enough to count as a Turing tarpit like INTERCAL or brainf*ck, but it's one of the closest mainstream languages to the tarpit.
I like PHP and JavaScript a lot. They are not perfect but these organically grown languages tend to be better from my experience.
And yeah I HATE inclusion in PHP... it's a mess
And I'm quite tired of hearing this silly, totally meritless defense in every single thread that discusses PHP. Can't we just agree that it's not a very good language, but people are still doing cool stuff and lots of money with it? So many pointless fights could be averted like this.
I usually recommend that new developers start with Python. It teaches structure and consistency without as much variation or room to screw up.
Advantage: they'll never create a mess that you'll have to maintain.
/s
Yes, I totally agree with you: the advantage of PHP is that anyone can pick ut up, and they have done.
The question was often never if it should be coded in PHP or Java but if it should be coded at all and, if so: if it should be an excel file on a file share or sent in email or a php script.
Disclaimer: PHP and Java coder. I can get stuff done quickly in Java, but it takes some practice.
Personally, I'd rather everyone just stop the good/bad language debates entirely.
So really I don't think "good language" is subjective. PHP is not fast, it's not well-designed, it's not particularly terse, it doesn't have particularly great tooling (Facebook has made that better with their HHVM initiative in all fairness), it isn't consistent and easy to reason about and the worst offender of all, it doesn't offer a dramatically different or original model of thinking about programs.
What is has going for it has nothing to do with the language itself: jobs, ecosystem and easy hosting. I totally agree that a good language is whatever works for you, but in the meantime, "whatever is good enough" is a mindset that doesn't help us strive for something better, which does matter if we're going to collectively spend decades in this line of work.
Wrong, otherwise we would have this discussion in Esperanto.
Sometimes Real Life (TM) experience beats clever design. PHP was first, has iterated, always had a niche and is now better than ever. Not good but good enough to save people a lot of work.
Actually, it is.
In PHPs niche this should be in the advantages section.
The real problem is that so many people who use it are utterly incompetent.
When someone says they work in/with PHP you immediately wonder if they're in the "let's duplicate a 900-line function across dozens of files just to give various pages a different icon" camp, the "I call myself a PHP Developer, but all I really do is Drupal Templates" camp, or in the "using Composer and everything is pretty much like you'd expect it to be in any web app built with Ruby or Python or Node" camp.
Until you know, you fear acknowledging them or associating with them. But you can't really ask them up front. So it's easier to just avoid them.
And I say this as someone who occasionally works in PHP.
I've felt for quite some time that most of the anti-PHP sentiment is an effort of other developers to justify the language they've selected to focus on. "Yeah, I'm doing Javascript and Node.js and yeah it's got it's sharp edges, but at least it's not PHP!"
The problem is, if the negativity continues, the next step is that business WONT want PHP in their ecosystem... And not because it can't get the job done for them, but just because "ew PHP. I heard that was bad."
Would you be surprised if I told you that pro-PHP sentiment looks exactly like that as well?
When was the last time we saw a "PHP is Great!" article make it to the front page of HN? Most of the time, PHP developers are on their heels because it seems others are constantly on the offense. I've not figured out what value this constant aggression provides to these developers making the arguments. My only conclusion is that they're just trying to make themselves seem more important. To that note, the pro-PHP camp becomes more of a "non-anti-PHP." :)
Version control, documentation, checking their work before committing and sending to QA, documentation, and learning how little they actual know about development on a real timescale >> which language they use. I'd rather start out in a well run IT shop that uses PHP than a quirky single dev small shop (or god-forbid an academic ivory tower of babel) with the most cutting edge startup blessed tool set.
If I have to do a beauty contest of the programming languages I used a lot, from uglier to most beautiful, I'd sort them like this: PHP, Perl and C (no ++), Java, JavaScript, Ruby.
I didn't use Python a lot and I'm undecided if it should be placed before or after JS. That silly method(self) looks as useless as PHP's silly $this->attribyte. They're just bad designs and other languages knew better. I'm starting to use Elixir and it goes between JS and Ruby so far. Java has its own way to make me feel like wanting to wash my hands at the end of the day (the language and the tooling) but not as much as PHP, even if I agree that PHP7 is somewhat more sane than it used to be. Why didn't they do it at version 2?
And if I have to sort them about what pays more... We could sort them by looking at the salary stats but eventually it's a matter of where we live and which opportunities we have. Any language will earn us money. No hard feelings.
Anyway, that is the way of Python. A lot of people is happy with that and will never be changed. It's beauty contest matter :-)
"Explicit is better than implicit" -- PEP 20
Python was the first language I ever learned and I just took it for granted that you had to manually specify "self" like that. When I see code with implicit self, it reads strangely to me. Like, "Where does 'this' come from? Oh yeah."
My first serious language was C, which is way more lower level than Python. Still Python has something that reminds me of C. Those wierd __xyz__ methods, looking like what we used sometimes in #define; the useless : instead of some { (I know where the : comes from but it should be deprecated or made optional) and that self, which is the pointer to the C struct we were using to implement OOP in C. It's a strange mix of low and high level constructs, not fully OO and definitely not functional. Being at midway on many axis maybe it's the reason why it appeals so many people: it's a little bit familiar to everybody and this is important for the success of a language. Think of Elixir which was designed to look similar to Ruby, even if they have nothing in common.
In the context, it's also a common occurrence that I can tell when developers came from the php (non framework) world. When I see them move to Rails (or in javascript), I often see an obvious lack of understanding / adaptation of MVC, Single Responsibility, asynchronicity, testing, and variable scoping - I've seen Senior PHP Developers come out with less of these concepts than codeschool graduates.
That's not to say that PHP has this, or that every Rails/JS developer writes tests and understands these things (it still confounds me how companies choose rails and don't implement any tests, despite testing being a core idea)..
OTOH RoR has its own bunch of problems, and exploits a number of anti-patterns "in the name of simplicity", and Ruby as an ecosystem has its own set of pain points (e.g. deployment).
Catchphrase so ironic I laugh every time I hear it. The language also is written by a programmer, who sucked in PHP's case IMO.
Yes, I am a terrible coder, but I am probably still better than you :)
- Rasmus Lerdorf
"For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :)"
https://github.com/symfony/symfony/tree/master/src/Symfony
or you can look at simpler sample codes I wrote for a class in design patterns with php
Older projects will suffer till they're brought up to spec, true.
I think traits, and their Java equivalent, are OK to touch up legacy APIs (as they did with the Java collections API) but I have found no good place to stick them in a new project.
Not to say PHP hasn't been introducing functionality for writing good, stable code bases (type hinting in function signatures, namespaces, better garbage collection, an actual AST — as an aside: how ON EARTH did they do without an AST pre-PHP7?) but traits don't strike me as the feature to think of when designing a new code base.
They're not extendable, they're not overridable, they're monolithic, and classes expose their implementation details to them, which makes traits super fragile.
It's not like rails is the only alternative.
My reference for what you quoted was a Rails project written by a Python dev who thought he needed to make Ruby more like Python. The resulting code was so horrendous that I literally cannot tell which of 2-3 parts that compose one feature (all heavily monkey-patched together) is responsible for what. It's like 2-3 complete implementations, but depending on load order any piece of the 2-3 implementations could be handling it. The client didn't have the time required for me to fix it.
... to quote myself:
> More often it's the programmer who sucks, not the language.
Give me a break, it's not like there are only PHP jobs out there. If you can't find anything else then it's because you're not capable of coding something that is outside PHP domain, IE basic CRUD apps ..
In many ways, if a "coder" comes in and starts wanting to change a bunch of things purely because they are opinionated about languages, then that person is not going to go very far.
PHP: 30%; .NET for finance/enterprise: 25%; Java for finance/enterprise: 20%; Java for android: 10%; iOS: 10% (~5% overlap); Everything else: 10%.
And as far as payscales go, PHP is nearly always > the "Everything else" unless it's super specialized. But clearly everyone paying median or above for PHP is getting conned and they should convert their entire business to [flavor of the month] language.
[edit]And I'm leaving js off there on purpose as there are very few web devs who are expected to only work in PHP and never touch the js. And in those other orgs, you usually have a specific "front end" developer that probably doesn't deal with any other kind of code and makes less than the "full stack" devs.
citation needed, I don't believe one second these figures are accurate.
Or the client sucks.
But I quickly moved away from it and I'll explain why.
I think that many programmers are starting to realize that the less "cognitive load" your language demands of you as a programmer, the better (the fewer bugs, etc.) Simple example, the recently-maligned "==" comparison operator has a very complex table of possible outputs (note that Javascript is also implicated here): http://stackoverflow.com/questions/7615214/in-javascript-why...
I mean, as a PHP programmer debugging code that used ==, you'd have to basically have that table memorized in order to successfully debug it. Contrast this with, say, Ruby, where only nil and false evaluate to false and everything else evaluates to true.
While there are of course "PHP best practices" that suggest === (which has a MUCH more sensible truth table), I find that much of the language is still simply not well thought-out and therefore is unsuitable for any large codebase. Sure, you can "get by" (see: Facebook), but you'd "get by" a hell of a lot better in a different (possibly a functional) language.
If you can't grasp all the cognitive load mentally, then you are invariably going to introduce unexpected states into your code (read: "bugs").
Lastly, a language should be 100% deterministic. Last time I checked, PHP didn't even consistently pass its own test suite. It literally has so-called "flagging" and "known-fail" tests which are just marked as such (and not fixed). I cannot explain how bad this is to build something else on top of.
So, yeah. If you're a great programmer, you can code almost anything in PHP (since you can handle the cognitive loads it introduces), just like you could code almost anything in, say, Brainfuck, or assembly. But as a great programmer, you'd be far better served by another high-level language (speaking as someone who knows and has worked with dozens of computer languages) which demands less cognitive load and therefore naturally reduces the number of bugs you will introduce.
I'll also plug John Carmack's piece on functional programming in object-oriented languages, because it's relevant: http://www.gamasutra.com/view/news/169296/Indepth_Functional...
Do you realize what a ridiculous statement that is?
Either that, or I'm just a really good programmer under pressure (I pulled an all-nighter for that one), which I would not disagree with, I've basically been coding since I was 12 in 1984, so I would HOPE that I'm somewhat of a force to be reckoned with at this point. ;)
More work was available locally with PHP. Clients were more willing to pay. I've done a ton of things in WordPress that shouldn't have been, "to save money". And I've done greenfield development with CodeIgniter, Laravel (v3 and v5), and a customized set of the Symfony components. I've also maintained and improved brownfield projects that were outsourced.
I'm very tired of hearing that PHP sucks. PHP is a good language. And in my opinion, it has fewer ways to sabotage your own project than any language with monkey patching. PHP7 looks really awesome, and the community has been upgrading quickly toward it. PHP has always had best-in-class documentation in my opinion.
More often it's the programmer who sucks, not the language.