9 ms·

As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and

• jbrooksuk 7y ago
  > [...] its defenders should focus on actually showing what modern PHP code looks like. Laravel does this very well, not just by being a great framework but also in its ecosystem (Envoyer, Forge, Spark, Nova, Horizon, Socialite) and its documentation (https://laravel.com/docs/master https://laravel.com/docs/master).
  • lugg 7y ago
    If laravel is the best we have were fucked. Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.
    • dpcx 7y ago
      Can you share some of the BC breaking changes you've seen? I personally haven't seen any in quite a while, but I'm not using all parts of the framework.
      • lugg 7y ago
        Read the migration notes for the last few releases. Anything that requires you to change your code is a breaking change and the reason you can't skip versions.
    • alunchbox 7y ago
      Can you explain the IOC hell? isn't most IOC / Dependency Injection patterns suppose to help the software maintainability ?
      • jrumbut 7y ago
        I tend to think of these more as enabling modularity and convention-over-configuration (being Rails-y if you will) rather than maintainability. Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code. One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files. That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).
      • lugg 7y ago
        Yes, they are supposed to. The problem is that it gets taken to extremes when it's done at the framework level. The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around. Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful. If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting. IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem. The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC. Within modules usual namespacing and new constructors were used liberally.
  • marcosdumay 7y ago
    Laravel has a Java-like problem of too many indirections, and has a really complex application model that breaks a lot of things. For that you gain an end of 00's quality templating system and ORM. I understand that PHP developers love it. It's orders of magnitude better than doing everything by hand. But no, thanks.
    • isaacremuant 7y ago
      Just out of curiosity. What type of comparable work are you doing and what languages/frameworks are you using? How do they compare?
      • marcosdumay 7y ago
        I've created reasonably complex projects on Django (with late 00's capabilities), I've done things in Flask, Asp.Net, Java (with very out of date components), very simple things on Rails, and also used some non-OOP frameworks like snap, I've also used some newer templating systems. I have never created anything in Laravel, but I have done some maintenance. Compared to Django and Rails, Laravel has those two problems I said. I don't think I ever saw a benefit of Laravel compared to them, except for the easy to deployment of PHP (that is a mixed bag anyway). The ASP.Net and Java frameworks are so different that any comparison could join Django, Rails, and Laravel as a single point. Everything on those languages is more bureaucratic and stable, easier to compose more complex projects, but harder to create simpler ones. Compared to snap (I've used very little of Yesod, but looks like it's alike here), the trio Laravel, Django, and Rails compose pages much better (it's a shame really since "compose" and FP go hand to hand, and I expect that to change in the future), but the FP frameworks are much better for creating data services.
• pdimitar 7y ago
  Agreed, articles like these do absolutely nothing to address PHP's insane warts, some of which you mentioned. That's not helpful. Laravel can objectively be the best web app framework in the world and I still won't touch it, because of PHP. Predictability, minimum WTFs per minute, consistency, sane defaults -- these win over short-term convenience, every time.
  • brendt_gd 7y ago
    For what it's worth, here's the source code of one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io https://github.com/brendt/aggregate.stitcher.io
• return1 7y ago
  > Is performance that much of a big deal for most people? For most people outside VC-funded startups, yes it is. It is also an environmental concern, imagine if 80% of the web was running on ruby.
  • justaaron 7y ago
    https://crystal-lang.org https://crystal-lang.org
    • justaaron 7y ago
      despite it's pre 1.0 status it's arguably more production ready than php ever was/will-be etc.
      • qaq 7y ago
        I bet you rely on things written in PHP way more than you realize.
        • golfer 7y ago
          Exactly. See: Wikipedia, Facebook, WordPress, etc. People talk crap about PHP but it is a workhorse of the web.
          • justaaron 7y ago
            indeed. this is largely legacy, but good luck changing that. I can't say that i miss it much, but then I don't work for either of these 2 entities. I'm familiar with what you are speaking about, so I don't think the lack of respect stems from a general ignorance of what you are referring to. It's rather people who have interacted with PHP in the past and didn't enjoy the experience.
            • golfer 7y ago
              That's a fair point.
• zaphar 7y ago
  Yeah, I've been burned too badly by PHP. There are languages I haven't done in years that I would go back to if there was a compelling need to. PHP is not that language. Far to many sleepless late nights trying to clean up some security hole. PHP is like that abusive Ex that everyone says has changed. It may be true, in which case, good for PHP But I won't be putting myself in that position again.
  • GrumpyNl 7y ago
    You can be burned by every program language if you dont know the in and outs. It all boils down to, pick the right language for the job and more important, know the language you choose.
    • cljs-js-eval 7y ago
      Seems like to know PHP, though, you need to know all the history that the author has picked up by following the PHP space since forever. Which mysql functions are appropriate, etc. If knowing the language means "being a working programmer in 2010 so that you could gain a working knowledge of the old APIs and some context for the new ones" I'm out. Keep PHP, I'll move to a different language where knowing historical baggage isn't a prerequisite.
    • mateuszf 7y ago
      There are languages which have great design from the start though (like Clojure). PHP, javascript are not them. Probably that's the reason why Clojure tends to be in top of the "developer happiness" polls.
      • cutler 7y ago
        .... and the bottom of "jobs available".
    • sethammons 7y ago
      Languages have foot guns. Most however don't default to being loaded and already pointed at your foot.
• baybal2 7y ago
  What ended PHP were not the worst parts of its design, but upstream's unwillingness to simply change the language for better. See, as a commercial enterprise (begware as a business) all kinds of "foundations" and sponsorship pools surrounding the language already accumulated a big enough pool of clients who were happy enough with PHP as it was in 4.0 era. They had no intensive to progress. Especially if their business depended on "fixing brokenness" Open source and sponsorship does not always mix well. Just as with front-end frameworks/libraries that live off sponsorships, eventually it leads to people prioritising pleasing sponsors, and working on pushing their software over improving the software itself. The current allergy in JS world about genuinely required breaking changes is all about that as well. Any times a talk of genuine "JS 2.0" starts to entertain minds of powerful players in the JS world, there will be tons of people with commercial interest coming and extinguishing the conversation with "no, we absolutely can not ever break anything, ever, even if it is already broken" Breaking changes in JS world do occur, but most of them being near accidental, security related, or being done as part of actual sabotage like intentional breaking of synchronous AJAX requests after they were shipped. My logic is, if breaking changes are still unavoidable in JS, why not to do them in a controlled manner, rather than through sneaky sabotage ops like one above?
  • qaq 7y ago
    I think ended is pretty strong word for a language that powers a huge portion of the web. Yes the lang. has issues and yet WordPress, Magento etc. are used an order of magnitude more than alternatives written in other languages.
    • proyb 7y ago
      Behind the language, the early day of shared web hosting make it affordable.
  • wvenable 7y ago
    > but upstream's unwillingness to simply change the language for better. Wow that could not be more wrong. PHP definitely changes things to make the language better, especially breaking changes. PHP5 changed objects from value types to reference types -- you don't get a bigger change than that. But they don't just change things willy-nilly -- they do try to maintain backwards compatibility as much as is reasonable otherwise it wouldn't still be PHP.
• brlewis 7y ago
  >I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? This. If there isn't a linter that bombs out on those things that used to be standard PHP, modern PHP is a non-starter. There are too many bad examples out there that will make their way into modern code if you let them.
  • francislavoie 7y ago
    https://www.exakat.io/ https://www.exakat.io/ https://github.com/phpstan/phpstan https://github.com/phpstan/phpstan https://github.com/phan/phan https://github.com/phan/phan Lots of great static analyzers to run in CI and during development to catch all kinds of issues. Also, https://github.com/FriendsOfPhp/PHP-CS-Fixer https://github.com/FriendsOfPhp/PHP-CS-Fixer to clean up code syntax (configurable rules, has good presets).
• chriswarbo 7y ago
  > ven assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? I think the "path of least resistance" is important: developers are time-constrained, understanding-constrained, lazy (if they're virtuous), etc. There's a big incentive to do whatever is easiest/quickest. When I last used PHP, about 5 years ago, there were OOP APIs cropping up to replace many of the standard global functions; namespaces had just been introduced; closures had become useful; frameworks like Symfony (and Drupal 8) were becoming established, rather than the old "plugin" approach of throwing around arbitrary code and hoping for the best; dependencies were being managed by composer; files could be autoloaded from sensible locations; testing frameworks like PHPUnit and PHPSpec had become best practice; etc. Yet all of those things were opt-in and verbose. The path of least resistance was still: <html> <body> Hello <?php echo $_GET['name']; ?> </body> </html> (For non-PHP programmers, this is appending a GET parameter straight into the page, which is an XSS vulnerability). Doing things "properly" took a great deal of effort and discipline. Compare this to something like Java: it favours class-based OOP so much that even "hello world" needs a class. The path of least resistance is to do things "right" (from Java's perspective). Haskell's path of least resistance is simultaneously easier ("hello world" is just `main = putStrLn "hello world"`) and harder (`main` uses the `IO` type, whose API enforces certain conventions). Deprecation warnings, linters, etc. can help with this; but PHP's only real strength is its installed base of code and developers; changing the language too much would throw away this advantage (akin to being a new language, see Python 3 and Perl 6); not changing it enough prevents the more serious and/or systemic issues from being dealt with. I wish the language designers and users luck, but I'm really hoping to never use it again ;)
  • stickfigure 7y ago
    You can't remove those old APIs without changing culture, and culture is really hard to change. One thing that shocked me during my brief foray into PHP was how heavily popular PHP apps like WordPress rely on the filesystem. Want to move a site? Copy the database, and copy a bunch of files. It seems like there's a cultural expectation that applications run on a single server in your closet. Of course you don't have to write code this way... but people still do.
• k_bx 7y ago
  > Server are cheaper and vastly more powerful now than in PHP's infancy Slightly off-topic, but I think that nowdays it's actually less of an argument than when PHP started becoming popular. The thing is, back in the days, statically typed languages were just bad and unproductive. Today, they are way better, and the fact that I can run my service on $3/month server with 900M of RAM and not think about the price tag at all is actually quite a decent argument to stay away from dynamic languages (but not the main one, tbh).
  • mywittyname 7y ago
    With more companies moving to virtualized hosts, I bet performance becomes a real consideration. With most services I've seen, you buy server capacity in doubling increments. So either your application fits into 2 vcores @ 2.2GB with 8GB or RAM, or you step up to 4 vcores and 16GB, with costs also doubling.
    • k_bx 7y ago
      Good point! Let's not forget that, unlike the old days, it's kind of a standard to require redundancy and load-balancing from day 1, so not fitting machine's RAM hurts even more.
• jaabe 7y ago
  One of my old friends has been working with php since forever, we’ve teased him over the years. Since then we’ve moved to a world where every program is web-based. I mean, even huge enterprise systems in healthcare run on some JavaScript MVVM framework and a web-backend in the cloud. The truth is that php is more adapt at handling this than a lot of the stacks you see in enterprise. It’s really kind of silly, but I don’t think we’ll ever adopt php either exactly for its bad rep. But sometimes I wonder if we shouldn’t.
• swalsh 7y ago
  I was pretty anti-PHP before I worked for a multi-billion dollar company that was built on top of it. It's not a beautiful language, but it offers a lot of side benefits in terms of dev-ops, and tooling, and frameworks. As a company, the language was not something that held us back. The company moved really fast, and PHP was a large part a big part of why. In my career over the past 14 years I've done web work using ruby, python, C#, javascript, and Java. but that ugly PHP site was the one that impressed me the most. People moved fast in it, our tooling never held us back, everything just worked. It was the most utilitarian environment i've worked in. The first time I touched PHP, it was a spaghetti disaster... but today, next to python It's my go to language. It gets the job done faster, and it's maintainability is just fine. It really doesn't matter if sometimes things just look odd.
  • brendt_gd 7y ago
    I appreciate you sharing this. The goal of my post was not to convince people to "switch to PHP right now", but rather to tell them you can do pretty cool things with it, and that it's actually fun to work in.
  • mywittyname 7y ago
    I have to echo this. I worked on a data pipeline that was a mountain of PHP scripts bolted together with Bash and it was such a breeze to maintain. Using Symfony ensures that every command is well documented and consistent in design and use. Something I never appreciated about PHP until recently is that character encoding is so much more robust in PHP than other languages. We were forced to replace our pipeline with Python because of a combination of "Eww, PHP" from new management and "data scientists use Python." Character encoding was a huge, unexpected annoyance.
    • kibwen 7y ago
      Which version of Python? I ask because making fundamental changes to character encoding was the single most disruptive feature of the Python 2/Python 3 split.
    • wwweston 7y ago
• brendt_gd 7y ago
  > its defenders should focus on actually showing what modern PHP code looks like This is one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io https://github.com/brendt/aggregate.stitcher.io Here's a list of all OSS package we maintain at work: https://github.com/spatie https://github.com/spatie
  • duiker101 7y ago
    some very interesting stuff in there! Thanks for sharing!
• dangerface 7y ago
  Your comment reads as "I like ruby therefor php is dumb" > Is performance that much of a big deal for most people? Yes obviously. Performance is important no matter the language. > the counter-intuitive behaviour of '==' You should learn the languages type system instead of assuming it works how you think. Again this is true of every language. > I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? The built in linter gives you a warning that its obsolete. The inconsistent naming and arguments. Dumb defaults and thousands of functions in a global namespace is the real problem and there is no solution to it. Oh and calling functions is unacceptably slow, that they can and need to fix the rest of this is just I like my language better.
  • simias 7y ago
    I haven't used Ruby in about a decade and I was never a fan. I used it as an example of a technology that managed to become popular despite abysmal performance. I think that's proof that in many situations, especially for web development, performance is a very secondary concern. > You should learn the languages type system instead of assuming it works how you think. Again this is true of every language. A good language should have good ergonomics. Criticism that `123 == "123foo"` is not reasonable cannot be brushed away by claiming that users should RTFM (although arguably in this case it's less an issue with == than "123foo" being implicitly cast into an integer). Maybe this has been fixed and is no longer relevant though (I'm citing the Fractal of Bad Design page).
• onlyrealcuzzo 7y ago
  It's gotta be the easiest stateless system to get started with, right? It's decidedly not a BAD language anymore. It probably has some of the best tooling for said system as well. And it has a GIGANTIC community. That's worth a lot to most people, I think?