It was because every developer in the West was taught that inheritance based OOP was the one thing to rule them all.

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.

> It was because every developer in the West was taught that inheritance based OOP was the one thing to rule them all. > > 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)

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.

Correct, OOP in itself it’s not bad. I use it every day, but I mostly use composition rather than inheritance.

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.

I totally agree. What I'd actually welcome these days is a web "glue language" which adheres to what PHP wanted to be in the beginning (easy HTML output, one file per page, easy database querying, easy CGI interfacing), but without any OOP bolted on (C-style procedural would be fine), without any of the horrible security decisions, and with strong typing.

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).

Isn't this what PHP still is? Can't you just drop index.php into a directory?

Was going to ask the same thing.

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.

> The biggest 'drawback' might be that there's not one name-branch 'framework' which takes this approach

Exactly! That comes close to the point I wanted to make

It is, but also note my other points:

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.

Probably because Java (and it’s structure) is what is taught in school.

It does surprise me to encounter over-complicated Java-style patterns in PHP.

It would be impossible to maintain backward compatibility if they made the language HTML context aware. It would make it more difficult to output any non-HTML content type from a PHP script. It would require many new syntaxes (e.g. for outputting variable data in the attribute values of elements, selectively outputting elements or attributes, looping through them, etc). It would also mean the language is tied to specific HTML versions and it would not be able to be forgiving of HTML syntax errors, defeating much of its ease of use.

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.

Backward-compat and syntax doesn't have to be a problem. The `<?php ...>` processing instruction can stay as it is, only to be augmented with a new opt-in mechanism based on entity expansion (the fully context-aware templating mechanism built-in to SGML/XML). Eg roughly

    <title>bla</>
    <?php let x =
      "<p>whatever</p>"?>
    &x
    <div class="debug">
     <![ RCDATA [
       &x
     ]]>
    </div>

where x is bound to markup checked against permissible elements in the first context (eg rejecting <script>) and escaped into &lt;p>whatever&lt;p> in the second. Rejecting script elements in user or other dynamic content as well as escaping comes for free with regular SGML parsing.

There are many cases that doesn't solve, for example, how can I conditionally decide to either inject an attribute or not inject it using this technique? How do I mix user-controlled text which should be escaped with dynamically generated HTML in PHP strings that I don't want to be escaped? How will scope be managed and can those constants be redefined (not normally a concern in SGML)?

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?

Good points, some of which can be addressed:

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
    ]]>

Re: mixed user/system text SGML supports quite restrictive content model exclusions, eg the "-(script)" part below makes SGML reject script elements in main's content anywhere:

    <!element main - - ANY
      -(script)>

Moreover, you can declare an entity as a so-called data text entity, special chars in which are preserved

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?