4 ms·

PHP as a language and ecosystem is great. Far more suitable for web development than python and trivially easy to scale. But PHP developers, boy oh boy, are a

PHP as a language and ecosystem is great. Far more suitable for web development than python and trivially easy to scale. But PHP developers, boy oh boy, are a different story. My favourite is how they all still debate setter and getters and almost none know the language but only the framework they use and code usually turns into a huge pile of unmaintainable crap. But hey they use ORMs just in case they’ll swap database engines (happens so rarely not even worth mentioning).

JamesonNetworks 3y ago
The Venn diagram of developers who can't successfully use an ORM, but can write their own sane, well formed, normalized data access layer from scratch using just SQL are two entirely separated circles
- gumballindie 3y ago
  Normal people write queries in a bunch of specialised classes. Data access in php is a pdo method call away anyway. But no, php devs need ddd dtos hydration models yml file configs goat sacrifices and a heated religious debate over why php is the belly bottom of web development and indeed the world. Tabs vs spaces. Such a nice language bastardised by over engineering and reinventing the wheel. Sad.
pavel_lishin 3y ago
Yup. If I were picking up side work, I'd be very wary of PHP projects - not because of the language, but because I'd be afraid of inheriting a tremendous, unreadable, unmaintainable mess. That's not to say that it doesn't happen in other languages, but I've never seen PHP code written by a stranger that didn't make me squirm.
- gumballindie 3y ago
  And the odd part is that frameworks were meant to provide structure and make code easier to maintain. Last time, long time ago, when i touched a php symfony project i ended coding yml instead of actual php because _everything_ was in a config file - hundreds of packages and libraries just because the dev couldn't be bothered to issue calls to native php functions. Hilarious. However i did make a killing in training teams in design patterns and coding practices to help them maintain quality. And almost always my advice was to write framework agnostic code (treat the framework as if it were just a dependency). Worked nice. Clean little specialised classes, no config maintenance madness, i also enforced running code linters and smell detectors on each commit and push. Gave up on the language when i noticed that _literarily_ all teams had the exact same issues, the exact same topics of debate and the exact same flamewars.
  - lioeters 3y ago
    At some point, we have to go beyond linguistic relativism, and admit that some languages are inherently flawed - when we observe that everyone who uses it struggle with the same problems. It's like the opposite of the "happy path", or "falling into a pit of success". Some languages guide the user toward poorly built software.
    - gumballindie 3y ago
      Yeah that’s likely true. The reason i like it as a language is that if you do know your design patterns and good engineering it is rather powerful, and the core language has plenty of nice little features. Prior to framework madness and a worker (person that works, not background process) mindset that plagues the php world it allowed for some fun creativity. I remember fondly how fun it was to solve design problems only to learn later on that hey, these are design patterns that other people in other languages use. Was nice to know i had the right “mindset”. It helped me become a better engineer in other languages ironically. I ate slept and dreamt design patterns. But thinking of it it’s because the language so easily becomes a mess that you need to constantly reinvent software programming just to keep things on track. Therefore all in all i think, for me, php belongs to history, and without wanting to insult anyone, i try and avoid any debated with a pho developer - it simply gets stuck in a bike shedding endless loop.
      - lioeters 3y ago
        I'm right there with you, I also grew as a programmer writing lots of PHP. There are many things to like about it, such as the ease of deployment. And how forgiving the language is, especially for beginners - which in retrospect was great for exploration, building my own abstractions and design patterns, but the flip side is that a ton of terrible code has been written because the language lets you. As I gained more experience, I've become wary (and weary) of how a language or framework can mis-guide programmers into messy code that's difficult to grow and maintain. But then again, as long as the work gets done and money gets made, perhaps it doesn't matter much to some people. For myself, I want to take pride and pleasure in the work, and there are other languages with better design and developer experience. Living with some of the hellish code that exists in the wild (and honestly terrible code that I've written myself) has been a great learning experience, making me a better programmer. It's important to be sensitive to code smell, noticing how it's going in the wrong direction and what can happen in the long term, understanding how it happens, what can be done to prevent it - and better yet, how a language (syntax, patterns, tooling, ecosystem) can be designed to guide oneself and others so that good code can be written "naturally" by following best practices that are built into it.
simonhamp 3y ago
In my experience, you're super wrong about the vast majority of PHP engineers And PHP has wide built-in support for multiple database engines (check out PDO) so this is largely not a part of an ORM. This leaves the ORM to focus on higher-level work, like how to abstract the differences away regardless of which engine you end up using and focussing on the representation of your data and the API you use to interact with it. That's pretty powerful and has allowed tools like Laravel and Symfony to suit a super wide range of needs. But yes, it does also mean that you're not switching your entire language or framework stack when some database technology providers baits-and-switches their licensing - which has been known to happen
- deleted 3y ago
  [deleted]
treadmill 3y ago
> trivially easy to scale Can you expand on this please? What exactly makes it easy to scale in which way? How will you deal with the wall you hit when you outgrow your one central database?
- gumballindie 3y ago
  In a web environment each request is an invocation of a script - sort of, apache spawned a process, nginx used a socket, but generally speaking each request was it’s in own context. You maintain session states in an external storage (disk, db, in memory, etc). As such errors would be contained within the context of that request, while memory leaks if any would be a non issue since gc is done when the process literarily ends. So that covers that aspect of scaling. Then all of these external state maintenance dependencies each scale independently. For instance session data can be distributed against endless clusters of redis or nosql instance. Heck some people even used remote file systems for it. Databases would be clustered too - say a couple mysql percona write instances and endless read instances. If that’s not enough then use an intermediary localised storage and queue writes. Or use something like cassandra. Database connections can also be round robin’d since each script would be re executed and connection reopened anyway (can be reused if needed) so they can connect to any server in your cluster. You can also use a database load balancer and sharding, or nosql for fast writes than then get further processed into a relational database. All in all php webapps can be scaled infinitely. Not as efficiently per instance but fairly straight forward by even average devs with the right guidance. For some past clients i scaled apps to billions of unique monthly requests with a fairly low effort. Happy to answer any specific question.

JamesonNetworks 3y ago

The Venn diagram of developers who can't successfully use an ORM, but can write their own sane, well formed, normalized data access layer from scratch using just SQL are two entirely separated circles

gumballindie 3y ago
Normal people write queries in a bunch of specialised classes. Data access in php is a pdo method call away anyway. But no, php devs need ddd dtos hydration models yml file configs goat sacrifices and a heated religious debate over why php is the belly bottom of web development and indeed the world. Tabs vs spaces. Such a nice language bastardised by over engineering and reinventing the wheel. Sad.

pavel_lishin 3y ago

Yup. If I were picking up side work, I'd be very wary of PHP projects - not because of the language, but because I'd be afraid of inheriting a tremendous, unreadable, unmaintainable mess. That's not to say that it doesn't happen in other languages, but I've never seen PHP code written by a stranger that didn't make me squirm.

gumballindie 3y ago
And the odd part is that frameworks were meant to provide structure and make code easier to maintain. Last time, long time ago, when i touched a php symfony project i ended coding yml instead of actual php because _everything_ was in a config file - hundreds of packages and libraries just because the dev couldn't be bothered to issue calls to native php functions. Hilarious. However i did make a killing in training teams in design patterns and coding practices to help them maintain quality. And almost always my advice was to write framework agnostic code (treat the framework as if it were just a dependency). Worked nice. Clean little specialised classes, no config maintenance madness, i also enforced running code linters and smell detectors on each commit and push. Gave up on the language when i noticed that _literarily_ all teams had the exact same issues, the exact same topics of debate and the exact same flamewars.
- lioeters 3y ago
  At some point, we have to go beyond linguistic relativism, and admit that some languages are inherently flawed - when we observe that everyone who uses it struggle with the same problems. It's like the opposite of the "happy path", or "falling into a pit of success". Some languages guide the user toward poorly built software.
  - gumballindie 3y ago
    Yeah that’s likely true. The reason i like it as a language is that if you do know your design patterns and good engineering it is rather powerful, and the core language has plenty of nice little features. Prior to framework madness and a worker (person that works, not background process) mindset that plagues the php world it allowed for some fun creativity. I remember fondly how fun it was to solve design problems only to learn later on that hey, these are design patterns that other people in other languages use. Was nice to know i had the right “mindset”. It helped me become a better engineer in other languages ironically. I ate slept and dreamt design patterns. But thinking of it it’s because the language so easily becomes a mess that you need to constantly reinvent software programming just to keep things on track. Therefore all in all i think, for me, php belongs to history, and without wanting to insult anyone, i try and avoid any debated with a pho developer - it simply gets stuck in a bike shedding endless loop.
    - lioeters 3y ago
      I'm right there with you, I also grew as a programmer writing lots of PHP. There are many things to like about it, such as the ease of deployment. And how forgiving the language is, especially for beginners - which in retrospect was great for exploration, building my own abstractions and design patterns, but the flip side is that a ton of terrible code has been written because the language lets you. As I gained more experience, I've become wary (and weary) of how a language or framework can mis-guide programmers into messy code that's difficult to grow and maintain. But then again, as long as the work gets done and money gets made, perhaps it doesn't matter much to some people. For myself, I want to take pride and pleasure in the work, and there are other languages with better design and developer experience. Living with some of the hellish code that exists in the wild (and honestly terrible code that I've written myself) has been a great learning experience, making me a better programmer. It's important to be sensitive to code smell, noticing how it's going in the wrong direction and what can happen in the long term, understanding how it happens, what can be done to prevent it - and better yet, how a language (syntax, patterns, tooling, ecosystem) can be designed to guide oneself and others so that good code can be written "naturally" by following best practices that are built into it.

simonhamp 3y ago

In my experience, you're super wrong about the vast majority of PHP engineers And PHP has wide built-in support for multiple database engines (check out PDO) so this is largely not a part of an ORM. This leaves the ORM to focus on higher-level work, like how to abstract the differences away regardless of which engine you end up using and focussing on the representation of your data and the API you use to interact with it. That's pretty powerful and has allowed tools like Laravel and Symfony to suit a super wide range of needs. But yes, it does also mean that you're not switching your entire language or framework stack when some database technology providers baits-and-switches their licensing - which has been known to happen

deleted 3y ago
[deleted]

treadmill 3y ago

> trivially easy to scale Can you expand on this please? What exactly makes it easy to scale in which way? How will you deal with the wall you hit when you outgrow your one central database?

gumballindie 3y ago
In a web environment each request is an invocation of a script - sort of, apache spawned a process, nginx used a socket, but generally speaking each request was it’s in own context. You maintain session states in an external storage (disk, db, in memory, etc). As such errors would be contained within the context of that request, while memory leaks if any would be a non issue since gc is done when the process literarily ends. So that covers that aspect of scaling. Then all of these external state maintenance dependencies each scale independently. For instance session data can be distributed against endless clusters of redis or nosql instance. Heck some people even used remote file systems for it. Databases would be clustered too - say a couple mysql percona write instances and endless read instances. If that’s not enough then use an intermediary localised storage and queue writes. Or use something like cassandra. Database connections can also be round robin’d since each script would be re executed and connection reopened anyway (can be reused if needed) so they can connect to any server in your cluster. You can also use a database load balancer and sharding, or nosql for fast writes than then get further processed into a relational database. All in all php webapps can be scaled infinitely. Not as efficiently per instance but fairly straight forward by even average devs with the right guidance. For some past clients i scaled apps to billions of unique monthly requests with a fairly low effort. Happy to answer any specific question.