It tried for decades to be one with Doctrine, Symonfy and co, trying to copy the worst of Java EE with every single possible design pattern implemented in these frameworks, XML configuration files and co... The problem is no generics, no private packages makes PHP OO a horrible mess compared to Java (or C#).
No it's not a different culture, they(enterprise Java and enterprise PHP) both try to force some IoC container everywhere, except PHP is an interpreted language, it doesn't need a IoC container with with XML/YAML configuration files cause there is no long and costly compilation step to begin with...
When I used composer the first time I really enjoyed it, that project also used Silex a minimalistic symfony2, which I also really liked. But what I found out is that in general it is really terrible to be dependent on others, as Silex was dropped by Potencier and my project is left in limbo, sadly. Its very sad because its one of the coolest things I ever worked on, and its still in use today many years after. But I am worrying that some time in the feature, a vulnerability or problem with Silex comes up, the company will have to rewrite the project completely some day.
I worked alot with Drupal7, absolutely hated it mostly because the hook system was hard to remember and performance of Drupal7 in general was absolutely terrible. Then I tried Drupal8 and though some changes are welcome, some stuff are just so god damn complicated, a task that would have been as simple as a few lines of code becomes pages of boiler plate, EventSubscribers and YML config files.
PHP used to be a good choice because it was rapid application development on crack cocaine, developers were cheap and diverse in skill and background.
I still think there is SOME use for PHP, I personally like it for shell scripts mostly because im so familiar with it. I used it alot the past 10 years for making stuff fast for friends and personal use I guess its also a decent beginner language for web development, though javascript would be higher on my list today because of the obvious front end relation.
Nowadays i develop in laravel which is breeze to work with. A simple framework and you can choose whether to use it as simple as silex, full blown like symfony or somewhere between. I started using it like a silex with controller classes and migrated more and more to the symfony way, but still its really easy understandable for any new developer.
If you need a framework, look for something small, small enough to read thru and understand in one hour.
It would make a nice counterpoint to all OOP-style web dev languages (Django, RoR, PHP8+framework + routing logic) and all frontend-focused frameworks (React, Vue). Super-simple, super old-fashioned, but rock-stable and easy to kickstart a small website or prototype, and great for teaching (nothing is easier than "drop a index.lang" file in this directory and you have a website).
There's not much in PHP 5/7/8 which precludes just doing some raw db queries and including some templates.
The biggest 'drawback' might be that there's not one name-branch 'framework' which takes this approach (indeed, it's the opposite of 'framework' thinking). But if there was some project that documented/demonstrated 'best practices' for 'non-framework' projects, it might help reduce the "I need a framework because raw PHP is so messy" objections.
Exactly! That comes close to the point I wanted to make
1 - security-safe and type-safe from the beginning 2 - none of the additional programming paradigms. PHP wants to be everything in one language. I know you can still use PHP "basics" like that, but it's not going to be easy to find tutorials etc. showing that
The main point I wanted to make was not about the index.php file. In other words, I'd like a PHP3, but a clean, safe, very well-designed one.
It does surprise me to encounter over-complicated Java-style patterns in PHP.
I am not sure it would have been practical to turn PHP into a strongly HTML aware template language like Thymeleaf for example, while still having it be useful as a general purpose programming language. IMO, the dream of PHP/CFML/JSP/ASP mixing code with templates just isn't realistically possible.
<title>bla</>
<?php let x =
"<p>whatever</p>"?>
&x
<div class="debug">
<![ RCDATA [
&x
]]>
</div>
Plus, what makes you expect this opt-in syntax would catch on if people already don't care enough to use HTML-aware template engines?
EDIT: Also, what happens if the static parts of the document aren't syntactically correct SGML? How can you even know if the final output will be syntactically correct SGML until you run all the legacy parts of the PHP code that output directly in the document stream?
Re: conditionals SGML allows marked sections to have parameter entities as keywords, and recognizes INCLUDE/IGNORE in their expansions:
<!entity % e "include">
...
<![ %e [
will only be included if
e expands to INCLUDE
]]>
<!element main - - ANY
-(script)>
Re: running legacy parts There's no difference to what PHP does now eg just running through the page/template doc until the end, erring out on validation errors?
And that unfortunate school of thought created the Java mythos that spread to many languages, not only PHP, eg JavaScript (everyone trying to write inheritance based OOP in a prototype based language).
Few years ago the mythos changed somewhat to every programming language should be functional.
Thus it is not a specific PHP problem, it is common problem of trend sensitivity in programming culture.
And the funny thing is that much of the critique against PHP, like in this thread, is in the form of "why isn’t PHP like the other programming languages?"
But agree PHP should go it’s own way, it has much to contribute to the world still and it feels like it has started to create its own path again.
I don't think it's as simple as OOP being bad but rather the culture of complexity that everything had to have deep object hierarchies, layers of indirection and runtime configuration, etc. If you write Python, JavaScript, PHP, etc. classes which don't try to follow the enterprise Java style and only pay for the complexity needed by the problem domain the results are fine.
I think a large part of it was that many people learned not OOP but how the Java standard library and J2EE worked, and internalized the idea that you were trying to produce a reusable abstraction for the entire stack which could be used by unrelated projects without realizing how expensive that kind general framework development is.
What I was trying to say was that the inheritance based OOP was sold as the ultimate problem solver.
We all remember programming classes with Hello World like examples of Cat inherits from Animal.
Problem is of course that in the real world is never that simple so the inheritance based model turned out many times to be a mess because it was applied to problems where it didn’t fit.
That doesn’t mean that inheritance based OOP has its place, it does, but that is usually in very specific domains.
Second because they are using all kind of tricks to add variables into it (ENV, ...): the configuration is often dynamic by nature or by re-use.
Third because it's only strings, which is prone to mistakes: they are having a huge lot of code to check those configurations.
Same. I've written some complicated ETL/data transform processes in PHP, and used arrays because the array_* functions are so useful for manipulation.
But keeping track of what keys were available was a nightmare - especially coming back to maintain the system.
Like you I've switched to Value Objects. In many ways it's a pain (the intermediate representation that I'd stick into a new array key and pass to the next transformation - it doesn't belong on any of the objects; and PHP needs the equivalent of the array_* functions for objects) but knowing I can't use the wrong key somewhere makes it worthwhile.
/* @return MyObject */