3 ms·

Hold on, we are talking php here. There is no code compiling. Either way what you are describing sounds like instead of maintaining sql code you prefer maintai

Hold on, we are talking php here. There is no code compiling. Either way what you are describing sounds like instead of maintaining sql code you prefer maintaining orm code. DTOs are just overhead. I gave up on all these after 15 years of using them because the benefits are precisely zero (except for migrations). Similarly with typescript, if you are competent enough with js and as a programmer you dont need it. The web can overkill itself perfectly fine without a scripted language that transpiles to a scripted language. Perhaps its just me, i rarely make typos and when i do the linter or ide catches them early on. In highschool they made us keep track of variables and their types with pen and paper and as a result i always know what type my var is. I was also taught that just because you can it doesnt mean you should. So i dont write a dto for transferring an object to a different api. It’s just a waste of time, specific to PHP devs. Edit: the type of code you pasted is horrible to maintain. You can achieve that with less sql.

bottlepalm 4y ago
With hundreds of developers and millions of lines of code - yes Typescript and ORMs will completely eliminate entire classes of bugs, and be a force multiplier when it comes to productivity. You should never rule out a tool as 'unnecessary' even if you can't think of any possible reason for it. Try to keep an open mind here, you may not know everything.
- yrgulation 4y ago
  Totally agreed re keeping an open mind. But after having used all the niceties you describe i understood that php itself is a fractal of poor design and practices. Gave up on using literally everything you described and ended up writing better code at a fraction of the time. I do recommend reflecting on things as not knowing everything goes both ways.
  - bottlepalm 4y ago
    I am concerned how much your posts center around you writing code and not a team. Are you concerned about maintainability? Have you written software with large teams before and have had to maintain that software over a number of years?
    - yrgulation 4y ago
      All good code starts with the individual. In the PHP world it starts with the collective, not much room for creativity on the assembly line, and any such attempts are met by endless debates over petty code reviews - many of which can be replaced by linters. Of course i wrote in large teams, thats why i know that a large codebase with hundreds of people working on it is usually a sign of either bad practice (the monolith that grew too much) or high turnover (php work places are often toxic and filled by mediocrity). Instead of ignoring my advice on maintainability, consider breaking your code into smaller chunks and write less code that doesnt solve self inflicted issues (ie your complex queries across hundreds of tables, dtos that dont solve much, custom functions for stuff that can already be done in sql). Once you do the above you wont need all of the overhead you describe and so specific to php. My code usually lasts a good number of years, often even after i’m no longer working on it. It’s difficult to break and easy to maintain. At least thats the feedback i get from repeat clients. The teams i lead have easily delivered code that generates returns in the billions. All without the mess you describe.
      - bottlepalm 4y ago
        It's interesting how you can observe thousands of developers utilizing Typescript and ORMs. Code bases with millions of lines. And have someone like you assume that these tools are 'useless' and solve 'self-inflicted' problems. Assume that large code bases are 'bad practice'. Assume 'breaking' something up is some amazing insight and will simply fix problems and not create new ones. Also assuming that we're not aware of these things already and have not evaluated these options such as plain javascript and raw sql. You really think you're that above everyone else? No doubts that you might be missing something?
        yrgulation 4y ago
        I appreciate your passion for php and i like our otherwise enjoyable debate, but instead of projections and a misuse of the term “assume” i would appreciate counter arguments.

bottlepalm 4y ago

With hundreds of developers and millions of lines of code - yes Typescript and ORMs will completely eliminate entire classes of bugs, and be a force multiplier when it comes to productivity. You should never rule out a tool as 'unnecessary' even if you can't think of any possible reason for it. Try to keep an open mind here, you may not know everything.

yrgulation 4y ago
Totally agreed re keeping an open mind. But after having used all the niceties you describe i understood that php itself is a fractal of poor design and practices. Gave up on using literally everything you described and ended up writing better code at a fraction of the time. I do recommend reflecting on things as not knowing everything goes both ways.
- bottlepalm 4y ago
  I am concerned how much your posts center around you writing code and not a team. Are you concerned about maintainability? Have you written software with large teams before and have had to maintain that software over a number of years?
  - yrgulation 4y ago
    All good code starts with the individual. In the PHP world it starts with the collective, not much room for creativity on the assembly line, and any such attempts are met by endless debates over petty code reviews - many of which can be replaced by linters. Of course i wrote in large teams, thats why i know that a large codebase with hundreds of people working on it is usually a sign of either bad practice (the monolith that grew too much) or high turnover (php work places are often toxic and filled by mediocrity). Instead of ignoring my advice on maintainability, consider breaking your code into smaller chunks and write less code that doesnt solve self inflicted issues (ie your complex queries across hundreds of tables, dtos that dont solve much, custom functions for stuff that can already be done in sql). Once you do the above you wont need all of the overhead you describe and so specific to php. My code usually lasts a good number of years, often even after i’m no longer working on it. It’s difficult to break and easy to maintain. At least thats the feedback i get from repeat clients. The teams i lead have easily delivered code that generates returns in the billions. All without the mess you describe.
    - bottlepalm 4y ago
      It's interesting how you can observe thousands of developers utilizing Typescript and ORMs. Code bases with millions of lines. And have someone like you assume that these tools are 'useless' and solve 'self-inflicted' problems. Assume that large code bases are 'bad practice'. Assume 'breaking' something up is some amazing insight and will simply fix problems and not create new ones. Also assuming that we're not aware of these things already and have not evaluated these options such as plain javascript and raw sql. You really think you're that above everyone else? No doubts that you might be missing something?
      - yrgulation 4y ago
        I appreciate your passion for php and i like our otherwise enjoyable debate, but instead of projections and a misuse of the term “assume” i would appreciate counter arguments.