Uhm no for me coming from a C background I love PHP since its basically C with a lot of the boring/repetitive stuff abstracted away
Good PHP code exists, it only got a bad name due to "web developers" with no formal programming education stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.
PHP is a hammer, blaming the hammer is silly when the person using it might now know how to swing it safely.
Except for this one weird trick: PHP absolutely bulls-eye nothing-but-net nailed deployability before deployability was even a word. In 2000, you could download an installer that set up Apache, MySQL and PHP on your Windows box (and it worked, first time and every time), you could fire up Notepad and 15 seconds later look at "Hello World" in your browser. Then you could upload that PHP file to a web hotel at $10/month and the world could see that same Hello World perhaps 10 minutes after that.
Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.
That's why PHP is so popular.
1: in zero-to-one deployability for a new user -- the full development and deployability experience just a tiny bit up the learning curve is orders of magnitude better.
- no classes (so people end up emulating them: Backbone has methods to emulate class declaration and class inheritance)
- no type hinting. You cannot specify function argument type or return type. It makes code harder to read and to maintain.
- too forgiving. You can divide by zero or mistype a property name and get no error. You can add arrays to strings. It makes bugs harder to find.
- no coding standard. Everyone uses whatever style they like
- no single modules standard
- no syntax for asynchronous operations
- difficult to install XML library on Windows (you need to setup a Visual Studio to compile binary modules)
> Heroku + Ruby on Rails gets close[1], but it took them nearly 10 years to catch up.
You have to learn Linux and command line to use Ruby. No wonder it is more difficult for a newbie. Deploying and running an application is more complicated in Ruby. Also with long-living applications it is easy to get a memory leak.
But recently PHP started to depend more on CLI tools too (installing and using composer might be not easy for people who got used to GUI and don't understand concepts like "working directory").
Furthermore, I remember a few years back, Ruby was a hassle to set up, especially on Windows.
Nearly all PHP I came across was the mess of some self-taught stumbling way beyond the point they should have been screaming for help, and going back to photoshopp. The docs don't exactly help here (may have changed, it's been a few years) as the apparently helpful comments on each feature aren't moderated in any way and are frequently unhelpful or plain wrong - but they're left to encourage the unwary.
I don't disagree it's perfectly possible to produce decent code with a good coder, and good principles applied to the project. I've seen some very clean looking PHP, and OO classes. That's been because they know the problems of the language and have been careful around such areas, or tried to avoid them entirely. I've worked on a couple of PHP based projects where I couldn't say a word against it as they'd used it well from the start.
We are where we are, but I would have been happier if the tool most often used by "web developers" stumbling in was a little more constrained and consistent about it.
I know developers who couldn't afford a "formal programming education" or couldn't/didn't go for various reasons, and they'd blow most "formally educated" developers out of the water. I think the word "formal" is surplus here.
> stumbling across PHP and going "aha this can generate my html etc" and then proceeding to make a pile of mistakes.
This holds true for anything in life, really. Anyone who uses a tool which they don't understand will sooner or later make a mistake with that tool, and keep making mistakes.
WARNING: The next might be anecdotal, so YMMV. I used to write a lot of code in PHP (and I am grateful, because it is partially responsible for introducing me to the world of programming), but I slowly moved away from as time passed.
The main problems with PHP (apart from some interpreter issues/design decisions which I won't cover, because there's an abundant amount of that online already) are the fact that:
1) it probably has the lowest entry barrier, with near-instant gratification and
2) there is an insane amount of online tutorials, blog posts, courses and even "books" created by people who *think* they understand programming (and PHP), but actually don't.
To be proficient in either, you need need to cover a very wide range of domains, but PHP resources makes you feel like web development is trivial and easy. Anyone who assumes web development is trivial doesn't really know shit about web development (excuse the language).
tl;dr: I mostly agree with you that PHP's design decisions aren't the only problem bad PHP code exists, and that people who use PHP are largely to be blamed for their own mistakes.
Yes PHP makes it easy for ANYONE to stumble into scripting/programming
But IMHO that is a good thing, the world needs more people getting into programming, if they make mistakes so be it, learning from mistakes is a good way of learning anything.
It got a bad name due to the weird nature of PHP which is still a template engine , no matter how much features you had on top. It's like developing webapps in pure HAML, Jinja or Handlebars.
PHP also has a lot of bad design language wise, due to the incompetence of its creator and early maintainers when it comes to language design.
The correct way is to use Twig for your templates
PHP is alot more than a "templating engine" if thats all you think of it then that is your choice
The more stupid thing about them, which transcends PHP and touches all other programming languages, is the very idea of assembling HTML piecemal from unstructured text. HTML is a textual representation of a tree, and should always be constructed as such - and not by gluing strings together. It's kind of the same problem as with SQL injections, which would not be possible in the first place if people weren't gluing them together from strings.
I'll probably get flamed for saying that, but really - many of the popular tools on the web are broken on a fundamental, conceptual level.
[0] - because of a misunderstanding of the "don't write logic in your views" principle; sure, don't write business logic in your views, but that doesn't mean you don't need, or shouldn't use, a real programming language in your views.
That is why you should prefer Twig or other templating engine with autoescaping.
> They all start as an attempt to remove the possibility of writing meaningful code
I don't think so. Twig developers have a large list of reasons on their frontpage: http://twig.sensiolabs.org/
<?= escape($var) ?>
{{ var | escape }}
A few helper functions and you're good to go, with simplicity, flexibility and speed you will not get from any templating library in PHP.
Though, some coding customers don't know what to make of it. Some people have trouble with not being able to see HTML in the code, because "where do I paste my Google Analytics code?".
{{ var }}
> Nevertheless, I used DOM/libxml on the server side in PHP/C,
There used to be XSLT templates but they don't seem to be popular now. Constructing DOM trees in the code without using templates is probably inconvinient and produces bloated code.
Beginners also forget about balancing HTML tags, which is quite unpleasant experience when creating and changing more complicated templates with loops, conditions, etc. You can also do post-processing on the constructed DOM, even during construction.
Bloated code only happens if the programmer fails to structure the code into nicely re-usable functions. Anyway, it seems to be quite popular right now with all the react hype - React.createElement is such a helper function to help construct DOM tree.
It's pretty much the same concept on the server side. Except you don't need to care about DOM diffing, because server has no persistent DOM.
I've had decent success using an xml-object based approach, so certain structured parts of the template (navigation, form controls, etc) are built programmatically using dom methods and then serialised into the template.
In this case, both the hammer and the hammer's user can be blamed.
One great example is the removal of the mysql_real_escape_string function. http://php.net/manual/en/function.mysql-real-escape-string.p...
Another is finally giving us a null coalescing operator, which is a solution for a constant pain point in dealing with raw PHP POST and GET parameters.
The full "new features" list of PHP7: http://php.net/manual/en/migration70.new-features.php
The change log of PHP7+: http://php.net/ChangeLog-7.php
$pdo->prepare("SELECT id FROM foo WHERE bar = ? AND baz = ?")
->execute([$baz, $qux]);
https://github.com/paragonie/airship/blob/8b7edde11b5b57fcb4...
It has a C-style syntax, but similarities almost completely stop there. Especially in modern OO PHP.