Hacker News new | past | comments | ask | show | jobs | submit login

It's becoming kind of an Enterprise language [1]. Don't get me wrong I think PHP is getting cooler, hopefully everybody catches up and the fact that You can have a shared hosting for pennies run Your PHP code really puts it at an advantage compared to others.

[1]: https://github.com/joaomilho/Enterprise




> It's becoming kind of an Enterprise language

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


I agree with you. Symfony and composer in general has just turned our code base into some kind of fugly java like monstrosity.

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.


I have been bitten too by the abandoning of silex and symfony becoming more and more like a complex java beast. The zend framework 1 was once good with a simple abstraction but they turned java like too.

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.


PHP is filled to the brim with bad frameworks with one size fits all type of mentality. Just avoid them and make your life easier.

If you need a framework, look for something small, small enough to read thru and understand in one hour.


Silex was ok but to be fair you can get almost the same thing with the Symfony micro-kernel trait.


Have you tried October CMS? It really gets back to the basics and is awesome for rapid application development. Disclaimer, I'm the lead maintainer


That's what baffles me with PHP. Instead of building on PHP's unique capabilities, they try to become more like Java. When PHP was and is quite successful as server-side language for HTML templating, rooted in embedded PHP triggered from SGMLish processing instructions in otherwise static HTML. It's only that they made such a hack job without context-dependent, HTML-aware escaping, making it a primary vector for injection attacks.


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?


Symfony supports YAML files too since... almost forever.


actually in future versions symfony will move mostly to php based configs instead of yamk, xml. at least parts of internal configs which were xml now are rewritten to php


Which is a sad choice on it's own


Is it? Why is that?


First because you don't really have completion or templating over its content: you mostly do copy/pasting or guessing what you have to put in there.

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.


It's a different culture. They go around the problems differently. Also the way the write programs seems simpler and leaner (composer in mind)... probably not ultra safe but a good enough ratio I guess.


> It's a different culture. They go around the problems differently. Also the way the write programs seems simpler and leaner (composer in mind)... probably not ultra safe but a good enough ratio I guess.

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


That's unrelated, you can tell very rapidly how nicer a tool like composer is from most java things of this era; this is entirely cultural IMO.. you can use xml or yaml in fine or absurd ways.


I’ve seen some self-balancing backed priority queues implementations, using some quirks of PHP, that are faster than the C implemented ones and faster than a “standard” implementation. Wall clock time, it’s still O(log n).


Lately I see myself abusing (???) types more often than ever. Before, I'd feel comfortable returning an array of structured data from a function. Now, I'm creating Value Objects to ensure my data is both valid and correctly used elsewhere. Kinda feels nice to get intellisense working too and knowing that the things that I'm trying to do with that VO are valid


> Before, I'd feel comfortable returning an array of structured data from a function. Now, I'm creating Value Objects to ensure my data is both valid and correctly used elsewhere.

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.


PHPStan and Psalm support what they call "array shapes", basically you can treat the array keys as a type, similar to how TypeScript does it.


But your IDE could understand your code for years with:

  /* @return MyObject */
Returning an array with unknown items has always been bad practice imho.


Your IDE but not the PHP Interpreter, that's the advantage of making a typed return.


that's why I like the "shape" type in Hack - the ease of returning an assoc array, but with field and type checks enforced.


PHP started to enterprise the moment they add PSRs IMO. It was no more a scripting language first. It was also at the clean OO push. Very Java like in a way.


I really like the idea of different types of comments for usage with external tools.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: