6 ms·

> If someone's still hating on PHP in 2023 it makes me wonder if they've been focused on more exotic technology because they were looking to pad their resume wi

by dgb23 3y ago

> If someone's still hating on PHP in 2023 it makes me wonder if they've been focused on more exotic technology because they were looking to pad their resume with more expensive skills, build science projects for their own amusement vs. what the business needed, etc. etc. Red flag. I get that you are arguing from personal experiences, people you met and worked with. But this statement lacks context and nuance. There are developers who don't like PHP because of outdated reasons and possibly because they are snobs. Sure, that's a red flag. But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore. Even though PHP has evolved (with regular breaking changes...) and tries its best to put something useful on top of a shaky foundation: The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code. However I would say there are three very good reasons why you should use or at least consider the language: - You want to quickly hack together something useful with minimal fuss, AKA its original purpose. - Buy-in of the OO, code generation, IoC/DI, magic framework stuff that Laravel/Symphony provide. - You have to.

jusssi 3y ago
> magic framework stuff that Laravel/Symphony provide The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
- dgb23 3y ago
  I agree with you. But, and this is a big but, it's a tradeoff. You also get benefits. This is why I said "buy-in". If you are comfortable with doing things in their way, you get a ton of leverage: easily consistent code, a fast and productive "get off the ground" experience. The downside is what you described. Personally I'm just not a fan anymore of these things. You quickly produce code that _looks_ clean and consistent. But it's also bloated and brittle, especially if you need to break out of the happy path. A framework like that is great if you don't do software design, but more of a hindrance if you do. There's no framework that can help you do a holistic solution. For that you need good tooling, a robust foundation (AKA not PHP and probably not JS) and a simple design. Again: Trade off. That's why many here in these discussions will tell you that X or Y is the best thing since sliced bread - because it fits their needs almost perfectly. But you also get many (like us) who have at least some reservations, because had to bend over backwards to fit a square peg into a round hole and ultimately wasted so much time that using X or Y wasn't worth it at all.
  - psychoslave 3y ago
    Out of curiosity, what foundation would you consider solid currently?
  - karlerss 3y ago
    I've been building on Laravel for some years now and I'm always delighted how you can just ctrl+click and see the internals (and the magic). They're pretty modular and extensible/overridable.
  - nine_k 3y ago
    It's like that with every framework: Laravel, Rails, Django, you name it. If you build a class of thing which the framework creators had in mind, and do not have a need to deviate from the prescribed ways, it's a force multiplier. Once you try to build something that does not fit the confines of the framework, it's of course possible, but the framework stops helping you, and after some time becomes more of an impediment instead.
    - 0xblinq 3y ago
      "...Once you try to build something that does not fit the confines of the framework..." Can you provide an example of that? In my experience people think too quikcly they're smarter than the community behind the framework and that it doesn't fit their use case, and the real cause is just that they don't "like" the recommendations and think they can do better. Plot twist: They don't, and usually end up creating a terrible mess. What would be the alternative? Building your own in-house undocumented, untested, unproven framework and/or tying together 100s of libraries? Are you convinced that's going to lead to a better result for all use cases of your application? And that once you leave the company, the next developer will think "Oh, this custom framework is great... I'm glad they didn't use Rails/Django/Laravel"... not my experience... at all. I think that these frameworks are the best choice for most project, and if they're not (Like.. you're building Google Earth or Figma or something really different) then the problem is that you picked the wrong tool from the get go. I don't think that "this one special case" is special enough like to not use a batteries included framework and go wild with your imagination. Unless you're a FAANG, otherwise you're wasting your employers money. As an anecdote, I once worked for a shop that used Django. One of the developers before I was there "decided" the Django ORM was bad and promoted bad practices, etc, etc... so he wrote his own "better" ORM on top of a postgresql library. You can imagine how that went, specially after he left and the second gen of devs arrived to deal with the monstrosity. This happens a lot more frequently than you think. We should stop thinking we're "so special". We must focus more on providing business value by writing product code, tests and documentation and less rewriting the world because it's cool.
- irobeth 3y ago
  > when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called. debug_backtrace() has always been my friend in situations like this
  - nine_k 3y ago
    Indeed so. But there's value in an ability to find out such things without running the code, just by looking at it.
- okeuro49 3y ago
  > The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Have you actually used Symfony? It's an absolute pleasure in its domain and includes rich debugging abilities through its dev toolbar.
  - jusssi 3y ago
    I have, though I admit it's been about 10 years since and my memory may be mixing in (pun intended) things from version 1.
    - okeuro49 3y ago
      You're really doing a disservice to others with opinions that are so out of date.
      - jusssi 3y ago
        https://symfony.com/doc/current/page_creation.html https://symfony.com/doc/current/page_creation.html Apparently there's now something called annotation routes. Which appear to be inferring functionality from comments. You made me look though. I suppose I had it coming.
        Arkounay 3y ago
        They are not comments they are php8 attributes
        jusssi 3y ago
        PHP8 attributes are comments with a special format.
        hazn 3y ago
        They are not. Attributes are metadata that can reflected/accessed at runtime: https://php.watch/versions/8.0/attributes https://php.watch/versions/8.0/attributes
- krapp 3y ago
  What ruined PHP's reputation is people believing the language itself was a sufficient framework and unsafe SQL and escaping practices being the norm, due to naive developers (which PHP has plenty of) thinking the simplest solution (eg concatenating strings and variables into SQL queries vs prepared statements) is always the most correct. I mean, with PHP you either use a framework or you necessarily end up writing your own ad-hoc, informally specified, bug ridden implementation of one. At least frameworks like Laravel are battle-tested and should at minimum cover the most obvious issues.
- 0xblinq 3y ago
  I honestly prefer community supported battle proven production ready "magic" than what most product developer under a deadline cobble together. In my experience the problem you describe happened like... 2 times in my 20 years career. And I literally spend my entire days fighting my own colleagues very explicit smartnesses
  - tored 3y ago
    Sure, but it does exist frameworks that uses minimal amount of magic. It is the magic part that is the problem, regardless if it is the framework or your own code that it is doing it.
    - psychoslave 3y ago
      There are really different topics here. One is that the framework can do all the magic under the wood, or not, and in (almost) no case leak any clue about that. Or, the framework can provide a lot of facilitation through conventions and there no real benefit to use this framework if you don’t leverage on these facilities. Having conventions doesn’t mean you have to be acculturated to all of them upfront though, as with proper modern IDE the learning curve can be very smooth and funny.
galangalalgol 3y ago
OOP, codegen, vendorlock, and bloat-magic... Those resonate with me reminding menof some of the worst development experiences in my career. Different language, different domain, but I recognize it. The simplicity is alluring, and even enticed me at first. It just doesn't scale for problems that are complicated vs the ones you are shown as marketing. The managers and architects like it because it hides the confusing or non-elegant details from view, but that just makes it hard for the devs to work on it.
chrisan 3y ago
This comes across exactly what the previous poster was saying as someone who turns their nose up to PHP. Especially the "you have to" gibe. > But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore. I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it? No because they are "outdated reasons" as you say > The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code. Do you have an example of this?
- gspencley 3y ago
  > I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it? Yes. And I say that as someone who has been developing "modern" Typescript web apps full-stack for the last few years. My issue with JavaScript are fundamental to language design decisions that can't be removed due to major breaking changes. Things like having to deal with `undefined` AND `null`. `==` vs `===` (more specifically, type coercion), prototypal inheritance in addition to ES classes in addition to TypeScript classes. Array.push causing mutations. Having `for of` in addition to `Array.forEach` etc. etc. etc. And then you have the fact that it is neither OOP nor Functional. So you get people from both backgrounds, and ideologues from both backgrounds, trying to squeeze JavaScript into their preferred paradigm, within the same code-base ... and JavaScript obliges. Because it is neither. Every single JavaScript application looks radically different from each other and, worse, in a large organization with many teams working on a common code-base, consistency becomes damned near impossible to enforce. And so you start adding lint rule after lint rule after lint rule until you have an entire team dedicated to maintain your custom linting bullshit. JavaScript is a complete shit show to this day even if it does have nice features and even if you can get up and running with it quickly. If it weren't so popular, and if it weren't the "language of the browser", I wouldn't recommend it for anything other than small teams who can decide on which "version" of a JavaScript adventure they want to strictly adhere to.
0xblinq 3y ago
> But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore This applies to absolutely every language or stack. You switch to Ruby because the grass is greener, and 5 years down the road you feel the same. Then you switch to Kotlin or Erlang or JavaScript and you'll end up hating it anyways if that's how you roll.

by dgb23 3y ago

jusssi 3y ago

> magic framework stuff that Laravel/Symphony provide The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.

dgb23 3y ago
I agree with you. But, and this is a big but, it's a tradeoff. You also get benefits. This is why I said "buy-in". If you are comfortable with doing things in their way, you get a ton of leverage: easily consistent code, a fast and productive "get off the ground" experience. The downside is what you described. Personally I'm just not a fan anymore of these things. You quickly produce code that _looks_ clean and consistent. But it's also bloated and brittle, especially if you need to break out of the happy path. A framework like that is great if you don't do software design, but more of a hindrance if you do. There's no framework that can help you do a holistic solution. For that you need good tooling, a robust foundation (AKA not PHP and probably not JS) and a simple design. Again: Trade off. That's why many here in these discussions will tell you that X or Y is the best thing since sliced bread - because it fits their needs almost perfectly. But you also get many (like us) who have at least some reservations, because had to bend over backwards to fit a square peg into a round hole and ultimately wasted so much time that using X or Y wasn't worth it at all.
- psychoslave 3y ago
  Out of curiosity, what foundation would you consider solid currently?
- karlerss 3y ago
  I've been building on Laravel for some years now and I'm always delighted how you can just ctrl+click and see the internals (and the magic). They're pretty modular and extensible/overridable.
- nine_k 3y ago
  It's like that with every framework: Laravel, Rails, Django, you name it. If you build a class of thing which the framework creators had in mind, and do not have a need to deviate from the prescribed ways, it's a force multiplier. Once you try to build something that does not fit the confines of the framework, it's of course possible, but the framework stops helping you, and after some time becomes more of an impediment instead.
  - 0xblinq 3y ago
    "...Once you try to build something that does not fit the confines of the framework..." Can you provide an example of that? In my experience people think too quikcly they're smarter than the community behind the framework and that it doesn't fit their use case, and the real cause is just that they don't "like" the recommendations and think they can do better. Plot twist: They don't, and usually end up creating a terrible mess. What would be the alternative? Building your own in-house undocumented, untested, unproven framework and/or tying together 100s of libraries? Are you convinced that's going to lead to a better result for all use cases of your application? And that once you leave the company, the next developer will think "Oh, this custom framework is great... I'm glad they didn't use Rails/Django/Laravel"... not my experience... at all. I think that these frameworks are the best choice for most project, and if they're not (Like.. you're building Google Earth or Figma or something really different) then the problem is that you picked the wrong tool from the get go. I don't think that "this one special case" is special enough like to not use a batteries included framework and go wild with your imagination. Unless you're a FAANG, otherwise you're wasting your employers money. As an anecdote, I once worked for a shop that used Django. One of the developers before I was there "decided" the Django ORM was bad and promoted bad practices, etc, etc... so he wrote his own "better" ORM on top of a postgresql library. You can imagine how that went, specially after he left and the second gen of devs arrived to deal with the monstrosity. This happens a lot more frequently than you think. We should stop thinking we're "so special". We must focus more on providing business value by writing product code, tests and documentation and less rewriting the world because it's cool.
irobeth 3y ago
> when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called. debug_backtrace() has always been my friend in situations like this
- nine_k 3y ago
  Indeed so. But there's value in an ability to find out such things without running the code, just by looking at it.
okeuro49 3y ago
> The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Have you actually used Symfony? It's an absolute pleasure in its domain and includes rich debugging abilities through its dev toolbar.
- jusssi 3y ago
  I have, though I admit it's been about 10 years since and my memory may be mixing in (pun intended) things from version 1.
  - okeuro49 3y ago
    You're really doing a disservice to others with opinions that are so out of date.
    - jusssi 3y ago
      https://symfony.com/doc/current/page_creation.html https://symfony.com/doc/current/page_creation.html Apparently there's now something called annotation routes. Which appear to be inferring functionality from comments. You made me look though. I suppose I had it coming.
      - Arkounay 3y ago
        They are not comments they are php8 attributes
        jusssi 3y ago
        PHP8 attributes are comments with a special format.
        hazn 3y ago
        They are not. Attributes are metadata that can reflected/accessed at runtime: https://php.watch/versions/8.0/attributes https://php.watch/versions/8.0/attributes
krapp 3y ago
What ruined PHP's reputation is people believing the language itself was a sufficient framework and unsafe SQL and escaping practices being the norm, due to naive developers (which PHP has plenty of) thinking the simplest solution (eg concatenating strings and variables into SQL queries vs prepared statements) is always the most correct. I mean, with PHP you either use a framework or you necessarily end up writing your own ad-hoc, informally specified, bug ridden implementation of one. At least frameworks like Laravel are battle-tested and should at minimum cover the most obvious issues.
0xblinq 3y ago
I honestly prefer community supported battle proven production ready "magic" than what most product developer under a deadline cobble together. In my experience the problem you describe happened like... 2 times in my 20 years career. And I literally spend my entire days fighting my own colleagues very explicit smartnesses
- tored 3y ago
  Sure, but it does exist frameworks that uses minimal amount of magic. It is the magic part that is the problem, regardless if it is the framework or your own code that it is doing it.
  - psychoslave 3y ago
    There are really different topics here. One is that the framework can do all the magic under the wood, or not, and in (almost) no case leak any clue about that. Or, the framework can provide a lot of facilitation through conventions and there no real benefit to use this framework if you don’t leverage on these facilities. Having conventions doesn’t mean you have to be acculturated to all of them upfront though, as with proper modern IDE the learning curve can be very smooth and funny.

galangalalgol 3y ago

OOP, codegen, vendorlock, and bloat-magic... Those resonate with me reminding menof some of the worst development experiences in my career. Different language, different domain, but I recognize it. The simplicity is alluring, and even enticed me at first. It just doesn't scale for problems that are complicated vs the ones you are shown as marketing. The managers and architects like it because it hides the confusing or non-elegant details from view, but that just makes it hard for the devs to work on it.

chrisan 3y ago

This comes across exactly what the previous poster was saying as someone who turns their nose up to PHP. Especially the "you have to" gibe. > But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore. I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it? No because they are "outdated reasons" as you say > The effort required to make PHP work with you, in comparison to other languages, becomes too large and painful. I'm not talking about superficial things here, nor do I have the tendency to overengineer stuff, quite the contrary. I'm talking about writing simple, robust and efficient code. Do you have an example of this?

gspencley 3y ago
> I could say the same thing about javascript from the early days, through Jquery, and beyond. Should I turn my nose up to modern javascript because of the past 2+ decades I've been working with it? Yes. And I say that as someone who has been developing "modern" Typescript web apps full-stack for the last few years. My issue with JavaScript are fundamental to language design decisions that can't be removed due to major breaking changes. Things like having to deal with `undefined` AND `null`. `==` vs `===` (more specifically, type coercion), prototypal inheritance in addition to ES classes in addition to TypeScript classes. Array.push causing mutations. Having `for of` in addition to `Array.forEach` etc. etc. etc. And then you have the fact that it is neither OOP nor Functional. So you get people from both backgrounds, and ideologues from both backgrounds, trying to squeeze JavaScript into their preferred paradigm, within the same code-base ... and JavaScript obliges. Because it is neither. Every single JavaScript application looks radically different from each other and, worse, in a large organization with many teams working on a common code-base, consistency becomes damned near impossible to enforce. And so you start adding lint rule after lint rule after lint rule until you have an entire team dedicated to maintain your custom linting bullshit. JavaScript is a complete shit show to this day even if it does have nice features and even if you can get up and running with it quickly. If it weren't so popular, and if it weren't the "language of the browser", I wouldn't recommend it for anything other than small teams who can decide on which "version" of a JavaScript adventure they want to strictly adhere to.

0xblinq 3y ago

> But there are many who have so many battle scars and war stories with the language and its ecosystem that they decided it's just not worth the pain anymore This applies to absolutely every language or stack. You switch to Ruby because the grass is greener, and 5 years down the road you feel the same. Then you switch to Kotlin or Erlang or JavaScript and you'll end up hating it anyways if that's how you roll.