9 ms·

Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? PHP is not a likable language but it's probably not going

• Aeolun 5y ago
  I think that’s my biggest problem having moved from PHP to Typescript. I just expect my language to have certain features now, and while PHP is catching up, it still isn’t there yet. And even if they do, what then? It’ll just be feature parity, so there’s no need to switch back either way.
• ehnto 5y ago
  It's still in major use across the industry so I don't think it's too little too late. Maybe late, but not too late. I think it's pragmatism is partly why it's still so popular. No need to rush to the next best thing as PHP is perfectly capable of taking you from side-project to enterprise software with millions of users.
• dskloet 5y ago
  Slow change is good for small projects that you want to build once and use for decades without much maintenance.
  • mojuba 5y ago
    A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die before it evolves into something sensible. Not that I believe PHP will die any time soon, but just replying to your "slow is good".
    • azangru 5y ago
      > A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die Careful there :-) Modern javascript has semicolons and is introducing pretty horrendous syntax for private variables (an octothorpe) and possibly for the pipe operator (percent sign, was it?) and for tuples and records, yet is showing no signs of dying.
      • cute_boi 5y ago
        I have never written JS with semicolons after 2015 idk why you are saying Modern JS has semicolons? I simply didn't get it. Am I missing something.
        • azangru 5y ago
          I mean, it clearly has them; it's part of the syntax. You can skip them, and the parser will insert them for you; but the language has them.
          • cute_boi 5y ago
            yea but its optional so does it matter? In PHP its compulsory, right?
            • Minor49er 5y ago
              Sometimes the extra options can produce unexpected problems. For example, in JavaScript, this would return nothing and may result in an unreachable code warning: function go() { return 5 + 3; } console.log(go()) Since semicolons are optional, it's treating "return" as its own statement and "5 + 3" as a separate one. There are no hidden gotchas like this in PHP though since semicolons are always used: function go() { return 5 + 3; } var_dump(go()); This will return int(8).
    • kaba0 5y ago
      There is no real producticity gain through not having semicolons and somewhat leaner syntax. That was never the bottleneck: ecosystem, libraries are.
• arenaninja 5y ago
  Isn't ARC over a GC evident in PHP with its opcode cache? I don't think I have run into a PHP dev who thinks PHP has a GC
  • thinkindie 5y ago
    the very fact that you don't have to think about memory management it means that there is something else taking care of it. Call it GC or otherwise, no PHP dev will be think about memory management at all, unless they are building some long-lived, large data processing
    • mhitza 5y ago
      > no PHP dev will be think about memory management at all Not nowadays, for sure. In 2009-2010 it was still something to keep in mind, and careful array handling was common so the it wouldn't baloon hundreds of megabytes for not so large data structures. I wasn't working on big data (tm) at that time, but running database imports via ETL processes in PHP required a few optimization passes. I really can appreciate nowadays the huge memory and performance improvements that PHP went through from the 5.x days to the recent 8.1 release. Sidenote: Shout outs to Nikita Popov who came to the scene and revitalized the language for me back then, for his proposals and features implemented in a time when PHP felt stagnant language wise https://www.npopov.com/aboutMe.html#accepted-php-proposals https://www.npopov.com/aboutMe.html#accepted-php-proposals
      • thinkindie 5y ago
        i've been working with PHP for almost 20 years and to be honest i've never had to think about memory management until the last 10 years or so and only in case of long running processes (e.g. cronjobs)
• aeno 5y ago
  PHP uses a garbage collector since version 5.3 that was released around 2009/2010.
  • mojuba 5y ago
    (Repeating myself) PHP's garbage collector is ARC.
    • JiNCMG 5y ago
      How many GCs are we at with Java?
• heurisko 5y ago
  > Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. I don't see that as its biggest killer feature. In fact most projects built on PHP using a framework won't use the feature, as every request will be routed through a front controller. This has been true for at least a decade. I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient.
  • egeozcan 5y ago
    It's a blessing and a curse. Makes it amazingly easy to start with, which is how many PHP developers started (with perhaps folder root index.php rewrites and that's it), but later it makes it confusing, especially if "it always worked" for you, when you want to do dynamic routing. I see the same pain for some next.js devs these days, even though it does allow parameters in roues in [name].js file form, I saw some people generating routers from file trees and finding it an acceptable compromise. Well, each to their own, I guess.
  • sidkshatriya 5y ago
    > I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient. I agree. Shared nothing is definitely the killer feature. Even if php-fpm is tear down at every x requests, each request still starts afresh in which each needed PHP file is required and loaded again. This is not slow because of opcode caching means that parsing etc. does not need to be done afresh. PHP just pulls from the opcode cache. At the end of the request the request is torn down. The interpreter instance might be reused again for performance (though that may be torn down every x request also as you implied with php-fpm for instance). When you want to find out why something did not work in PHP you just need to go back to the start of the request and work your way from here. With a stateful system like Django (Python) or nodejs (JavaScript) you need to worry about the state of the full server in addition to what happen in a specific request. This is an ideal model of course because large PHP implementations uses caching (in things like redis) to speed things up and the cached state could be the one introducing a bug. However, in practice, PHP tries to put in most of the state in a relational db so debugging a PHP script is much simpler due to this shared nothing feature.
• mschuster91 5y ago
  > Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language? No. While PHP won't be the language of choice for academia or some new hipster startup that wants to woo junior engineers with the promise of "we're using the latest cool shit", the trio of PHP, Java and .NET with their associated ecosystems has managed the fine balance of evolution speed between uprooting everything on the regular (like NodeJS which went through at least three major build toolings with zero compatibility and the Javascript language itself with at least four ways of creating modules) and becoming a live fossil (like Perl) pretty well.
  • egeozcan 5y ago
    A typical Java project has way more complexity (and confusion and sadness and pain) than your typical node.js project in the enterprise world. I have stomach cramps thinking about the stuff my eyes have seen. .NET is not innocent either. For PHP, just look at the Drupal, Joomla and Wordpress codebases to see how many ways there are to include files. For a current example, see the hate Laravel receives on how it does DI from Symfony-likers. There's also the Laminas (Zen) crowd going all-Java. If something is popular, there WILL be many ways to do the same thing. Look at how Python is evolving.
    • mschuster91 5y ago
      > A typical Java project has way more complexity (and confusion and sadness and pain) than your typical node.js project in the enterprise world. Personally, in my career I've seen and worked with projects in SAP, Java (Tomcat), .NET, PHP and various JS-based projects - of all these, the JS projects had the most variety of bullshit (although SAP still gets the cake for "stuff I'll never willingly work with again" simply because how mind-boggling the entire environment is). At least it's easy enough to get a bunch of Java developers to agree on what package manager and build tool they will be using - it will mostly be Maven and that's it. For a nodejs project, you will first have to decide on the framework to choose, then on the build tool because not every framework works with every build tool, then you will lose a lot of time until Webpack finally does what you want, and in a year half the libraries you use will be unsupported.
• Isinlor 5y ago
  There is a garbage collection: https://www.php.net/manual/en/features.gc.php https://www.php.net/manual/en/features.gc.php > This section explains the merits of the new Garbage Collection (also known as GC) mechanism that is part of PHP 5.3. > First of all, the whole reason for implementing the garbage collection mechanism is to reduce memory usage by cleaning up circular-referenced variables as soon as the prerequisites are fulfilled. In PHP's implementation, this happens as soon as the root-buffer is full, or when the function gc_collect_cycles() is called. In the graph below, we display the memory usage of the script below, in both PHP 5.2 and PHP 5.3, excluding the base memory that PHP itself uses when starting up.
  • mojuba 5y ago
    PHP's garbage collector is ARC, unlike any other dynamic language that I know of. ARC is more performant but can introduce memory leaks via circular references, which is probably not a big problem for short-lived scripts anyway.
    • nicoburns 5y ago
      Sounds optimal for PHP where 99% of scripts are short lived.
      • JiNCMG 5y ago
        Which is perfect for a HTTP request.
    • Isinlor 5y ago
      I'm not sure if you did not read what I quoted, or I misunderstand something. Yes, PHP has reference counting, but it also has specific process that kicks in to clean up circular references.
    • kaba0 5y ago
      How is it more performant? If you have multiple threads than you will get serious atomic operation or other synchronization overhead.
• viraptor 5y ago
  > pretty much the only dynamic language in use today with ARC and not a GC Python uses RC, with GC available but only used for cycles.
• swalsh 5y ago
  The big guys, who know what they're doing use PHP because it makes devops stupid simple. Throw it on the server, its ready. That's always been PHP's killer feature.
  • snov 5y ago
    Is it? Last time I used PHP (around 5.x-7.x) it was exactly the other way around. For production you needed php-fpm, nginx, opcode cache... it was a nightmare compared with go or even java. Is it better now?
    • Aeolun 5y ago
      I think the thing is, you install those once, and then you can run an infinite number of websites. They also share the same resources, so even your little blog can take as much (or more) traffic than your production application.
    • 9dev 5y ago
      Does anyone really deploy PHP directly on servers still..? Running it in a Docker container is the simplest thing possible, runs anywhere, and has top-notch performance.
      • snov 5y ago
        I meant Docker. The fact that I needed multiple processes (nginx+fpm) made PHP setup tricky compared with e.g. Java with embedded server.
        • 9dev 5y ago
          I know what you mean; that has been a problem in the past. In case you have to again, I'd recommend looking into either Roadrunner or Swoole. That makes it possible to have your application run more or less standalone in a single container, hosted by a native application server. This boosts performance incredibly, and exposes a single HTTP port, as it should be. For Symfony: https://github.com/k911/swoole-bundle https://github.com/k911/swoole-bundle For Laravel: https://laravel.com/docs/8.x/octane https://laravel.com/docs/8.x/octane
• dagw 5y ago
  Its concept of "one endpoint is one script" is one of its biggest killer features Is that still a thing in PHP world? I recently ended up working on a 'modern' PHP project using Laravel and it was all routers and views and models and auto-generated scaffolding code, just like Rails and Django. There was no sign left of that 'old' approach.
  • 9dev 5y ago
    It's not. You usually hear that kind of reasoning exclusively from people that last interacted with PHP decades ago.
  • toast0 5y ago
    There's a lot of popular examples of more or less abandoning the old ways, but the old ways still work. I'm of the strong opinion that modern PHP with frameworks and auto-include and a ton of modelling is the wrong way to do it, but everyone else can do it that way, and I can still do things the old way and I can be happy. PHP has this amazingly zen model of computing. At the end of the request, everything is thrown away to start fresh. This means anything you don't output is garbage. I don't think it makes a lot of sense to make sculptural models of your data and page structure only to throw them away. It's best to keep things simple. There's some times and places where it makes sense to use more features, but starting with a kitchen sink framework makes it very hard to get simple where it's needed, but you can always pull in a little bit of something more complex into a simple thing.
    • dagw 5y ago
      You know, I kind of agree with you. When using Laravel I felt a lot of the time I was fighting against PHP rather than leveraging it. Back in the 'old' days when I was using PHP4 in the way you describe, PHP made sense as a choice compared to, say Python, for certain use cases. Today, I have a hard time coming up with an argument why using modern PHP and Laravel makes more sense than Rails or Django. Maybe we need a post-modern PHP movement focusing on bringing PHP back to its roots.
      • 5y ago
• bluetomcat 5y ago
  In its early years up until around 2006, PHP was mostly "HTML on steroids", that is, an HTML preprocessor with lots of goodies like "batteries-included" DB access, form handling, image processing, text processing, all accessed via a single Apache module. You simply rename your .html file to .php, and put some magic between "<?php" and "?>". Then came along templating engines like Smarty, and they introduced a new templating language for a language that was already built for templating. For some reason, "<?= $foo ?>" was considered much worse than "{$foo}".
  • hparadiz 5y ago
    It was one of the first freely available languages that allowed you to do image manipulation so sites like DeviantArt would use it.
  • ehnto 5y ago
    > For some reason, "<?= $foo ?>" was considered much worse than "{$foo}". A stigma that remains to this day, even though the spec is very clear about those kinds of short tags and the flags that affect them. PHP developers are absolutely terrified that some imaginary environment flag they have control over is going to brick their application, but are happy to bring in an entirely new templating language as a dependency instead. I'm sure Smarty was borne of a need, but I was never sure what it brought to the table except different tags for existing features.
  • tannhaeuser 5y ago
    That's exactly what has puzzled me for a long time: a language with HTML templating as unique selling point needs a templating "engine" after all? smarty.net has a pamphlet up there where pros/cons (but actually only pros) are discussed [1]. Failing to understand that "<?php ...>" syntax is a SGML processing instruction with well-defined ways to embed into a hosting markup language like HTML, they go even so far as to say > Another issue with PHP tags is that they share the <> characters of HTML tags. In the application code this isn't an issue, but mixed with HTML, <?php ?> tags are a maddening process to tell them apart from the HTML tags. This also blurs the line between application and presentation separation since any PHP logic can be injected into a template. Yeah no, now you need new escaping syntax if you ever wanted to have verbatim {$whatever} in your HTML. Notably missing is a discussion about HTML-aware, injection-free templating such as for preventing {$bla} expanding into <script>alert('Pwnd')</script> when sourced from user input, which is what SGML and other HTML-aware template engines can do, and which in the name of everything that's holy should've been implemented in PHP 2 to save the web from becoming a botnet. [1]: https://www.smarty.net/syntax_comparison https://www.smarty.net/syntax_comparison
• pjmlp 5y ago
  More funny is how developers keep being unware that ARC is a GC algorithm implementation. Then they tell learning CS theory is not required.
  • mojuba 5y ago
    I do know ARC is also a garbage collector, but is there an agreed name for the other GC's? There is a significant difference and performance implications with ARC vs. the other ones, that's what I meant.
    • pjmlp 5y ago
      You mean being the worse implementation of any GC algorithm, unless it makes use of tracing GC like optimizations, e.g. hazard pointers with deferred collection? Maybe. Naturally there are agreed names for other GC's, that is what widely acknowledged books in CS like "The Garbage Collection Handbook" [0], or papers like "A unified theory of garbage collection" [1] go about describing. [0] - https://gchandbook.org/ https://gchandbook.org/ [1] - https://dl.acm.org/doi/10.1145/1028976.1028982 https://dl.acm.org/doi/10.1145/1028976.1028982
• throw_m239339 5y ago
  PHP is either a flawed scripting language for some or a "poor man's java" for others. I had to learn JEE(JSP,JSF,CDi,JPA) for some project lately, so now I understand a bit more why Doctrine, Synfony and co are the way they are, coming from Go, Ruby, Python and JS... Well I prefer just writing some JEE stuff rather than using a PHP framework in that case, because I realized the Java cargo culting was just insane in the PHP community and how PHP is poorly equipped to replicate that JEE stack... PHP isn't going away though, billions of PHP scripts out there to maintain, and CMS are built in PHP mostly because of hosting providers still defaulting to Apache servers because cost. Nothing is too little too late though, when I read about the evolution of Java, I realize I'm lucky to suffer through it today rather than 15 years ago... > Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course. JSP on Tomcat works mostly the same way. and nothing prevents anybody from using python or ruby, (or C++) in FastCGI mode. PHP has that whole "templating stuff" though.
  • ehnto 5y ago
    > PHP has that whole "templating stuff" though. That might be underestimating the feature, it was very much the core proposition of the language and likely why it's so well suited for web applications.
    • throw_m239339 5y ago
      Yes, that's exactly why I'm pointing it out. Neither Python or Ruby have(or had) that.
• Zababa 5y ago
  > That, and also the fact that it may be pretty much the only dynamic language in use today with ARC and not a GC. Python and Perl use reference counting too. Ruby, Lua and JS (at least v8) are GC'd. PHP isn't unique in that regard.