4 ms·

ORM: don't need, I can write SQL. Prepared statements sufficient to prevent SQL injection. Both PHP and Go have good database abstraction libraries. Sockets: D

ORM: don't need, I can write SQL. Prepared statements sufficient to prevent SQL injection. Both PHP and Go have good database abstraction libraries. Sockets: Don't use but if I did I wouldn't need a framework. SPA: I don't write apps that way. Server-side, which is why we're talking specifically about PHP and Go. Queue handler, scheduler: Can easily do in the database or with Redis. Container: What? Do you mean something like Docker? That has nothing to do with the web app development language or framework. Auth: OAuth2 and SAML not a big deal, but maybe worth introducing a dependency depending on requirements. Regular username/password/MFA auth easy to implement, certainly no framework needed for that. Likewise with routing, "MVC" structure, etc. Frameworks can save some time beginning but eventually you have to debug them, or run into limitations to work around. And one day the framework gets updated and you have to deal with breaking changes.

the_real_cher 2y ago
That stuff you find easy isnt easy for developers who use frameworks.
- gregjor 2y ago
  Because they only know how to program with a framework. Take off the training wheels and learn the language and libraries.
  - Mrdarknezz 2y ago
    I know several languages, and in none of them is it preferable to ignore using the correct tooling.
    - gregjor 2y ago
      Right, that’s my point. We only disagree about what “correct tooling” means. Since PHP and Go have everything needed I prefer not adding more abstractions and dependencies, for less code, fewer black boxes, and fewer external dependencies. Programmers comfortable writing in PHP and Go with their comprehensive standard libraries can also work with frameworks if necessary, but those who can’t get stuck as Laravel developers, baffled by the much larger number of projects and existing code that doesn’t use their “correct tooling.”
      - Mrdarknezz 2y ago
        You're more productive when you don't have to reinvent the wheel, as I already stated.
        gregjor 2y ago
        You know of a way to quantify and measure “productivity” of programmers? Of code? Programmers make claims about productivity and throw the word around, like we all understand what it means.
Mrdarknezz 2y ago
I highly doubt the technical debt and inevitable vulnerabilities weigh up any perceived time saved. Also when you use a framework like laravel you're sort of forced into building applications in similar styles making it easier for other developers to cooperate instead of having to figure out some weird homemade framework.
- gregjor 2y ago
  If you know the language and libraries you can figure out any framework code, whether Laravel or some "weird homemade" thing. If you only know a framework then you have limited your options and job opportunities. And you stay in the shallow end with all of the other semi-skilled programmers.
  - gjsman-1000 2y ago
    > semi-skilled programmers Elitism is not welcome here. Are you a "semi-skilled" programmer if you are a web dev and don't know C++ and pointers? Are you a "semi-skilled" programmer if you are an embedded developer and don't know JavaScript? > If you only know a framework This makes the assumption that by knowing a framework, you will be unable to learn how to use the language at large. This is not necessarily true - a person who has learned Laravel will probably figure out CakePHP or CodeIgniter in a weekend. They just prefer Laravel for their jobs, and that's a legitimate choice. They've also made the decision that, even though Laravel makes breaking changes over time, the productivity boosts are greater than the downtime. Which is also a legitimate choice when Laravel upgrades have been automated for years for $29. https://laravelshift.com/ https://laravelshift.com/
    - gregjor 2y ago
      Semi-skilled means knowing a framework to some degree, but struggling with the language the framework is written in. Nothing to do with C++ or embedded -- I clearly contrasted Laravel et al. with PHP, and Goravel with Go. Anyone who prefers Laravel or any other framework can use it. I wrote that neither PHP nor Go need a framework because they have everything necessary to implement web applications. If you don't want to get laid off because everyone and their mother, and now LLMs, can copy-paste Laravel sample code for $15/hr (see Upwork, for example) improve your skills. If you want to have more opportunities in the programming job market expand beyond frameworks and learn the underlying languages and libraries.
mplewis 2y ago
Writing SQL is a miserable slog because it isn’t composable. I’ll take an ORM over raw SQL any day.
- gregjor 2y ago
  SQL is a declarative language for working with relational databases. The concept of composability doesn’t apply. SQL does support code reuse and building layers of abstractions. If you only use SQL through an ORM you won’t get to use things like CTEs and views and user-defined functions, because ORMs by definition deform the relational model and SQL to fit OOP. In 40+ years programming SQL expertise has paid the bills and kept me employed more reliably than any other language or tool I have mastered.
  - randomdata 2y ago
    > SQL is a declarative language for working with relational databases. No. First and foremost, SQL is for tablational databases. A relation and a table are similar, to be fair, but have some key differences: - A relation is an unordered set of tuples. SQL opts for an ordered list of tuples (a table) instead. - A relation has no concept of NULL. A table does. - The implications of those differences also bring a whole bunch of other differences that further divide SQL from the relational model. SQL's only association to relational databases is in its name, being originally SEQUEL which was a play on QUEL – a language actually for relational databases that was a direct adaptation of Alpha from Codd's original paper. > The concept of composability doesn’t apply. Of course it does. Why wouldn't it apply? Datalog, a declarative language for querying data, is in many ways similar to SQL and it supports composition just fine. Many of the compile-to-SQL languages also support composition just fine. SQL could be composable. It should be composable. It just, because it still desperately clings to its COBOL-era glory days, is too afraid to add support. > In 40+ years programming SQL 40+ years of working with SQL and you are still this confused about it...?
    - gregjor 2y ago
      Nothing you wrote has anything to do with ORMs, the actual point of this thread. The shortcomings of SQL with respect to a pure relational model are well-known. For all practical purposes we have SQL. Almost everyone using a popular relational database engine — those that might have ORM support — uses SQL. The history of SQL and niche alternatives, while interesting, don’t have anything to do with using an ORM vs writing SQL. I’m not confused about relational vs SQL. I just didn’t think the pedantry would add to the discussion. Pointing out that SQL doesn’t implement the relational model correctly seems like pointing out that C++ doesn’t implement object oriented programming as Alan Kay defined it. True, but C++ got a lot of adoption and Smalltalk did not. Pointing out the OO shortcomings of C++ don’t help with using the language.

the_real_cher 2y ago

That stuff you find easy isnt easy for developers who use frameworks.

gregjor 2y ago
Because they only know how to program with a framework. Take off the training wheels and learn the language and libraries.
- Mrdarknezz 2y ago
  I know several languages, and in none of them is it preferable to ignore using the correct tooling.
  - gregjor 2y ago
    Right, that’s my point. We only disagree about what “correct tooling” means. Since PHP and Go have everything needed I prefer not adding more abstractions and dependencies, for less code, fewer black boxes, and fewer external dependencies. Programmers comfortable writing in PHP and Go with their comprehensive standard libraries can also work with frameworks if necessary, but those who can’t get stuck as Laravel developers, baffled by the much larger number of projects and existing code that doesn’t use their “correct tooling.”
    - Mrdarknezz 2y ago
      You're more productive when you don't have to reinvent the wheel, as I already stated.
      - gregjor 2y ago
        You know of a way to quantify and measure “productivity” of programmers? Of code? Programmers make claims about productivity and throw the word around, like we all understand what it means.

Mrdarknezz 2y ago

I highly doubt the technical debt and inevitable vulnerabilities weigh up any perceived time saved. Also when you use a framework like laravel you're sort of forced into building applications in similar styles making it easier for other developers to cooperate instead of having to figure out some weird homemade framework.

gregjor 2y ago
If you know the language and libraries you can figure out any framework code, whether Laravel or some "weird homemade" thing. If you only know a framework then you have limited your options and job opportunities. And you stay in the shallow end with all of the other semi-skilled programmers.
- gjsman-1000 2y ago
  > semi-skilled programmers Elitism is not welcome here. Are you a "semi-skilled" programmer if you are a web dev and don't know C++ and pointers? Are you a "semi-skilled" programmer if you are an embedded developer and don't know JavaScript? > If you only know a framework This makes the assumption that by knowing a framework, you will be unable to learn how to use the language at large. This is not necessarily true - a person who has learned Laravel will probably figure out CakePHP or CodeIgniter in a weekend. They just prefer Laravel for their jobs, and that's a legitimate choice. They've also made the decision that, even though Laravel makes breaking changes over time, the productivity boosts are greater than the downtime. Which is also a legitimate choice when Laravel upgrades have been automated for years for $29. https://laravelshift.com/ https://laravelshift.com/
  - gregjor 2y ago
    Semi-skilled means knowing a framework to some degree, but struggling with the language the framework is written in. Nothing to do with C++ or embedded -- I clearly contrasted Laravel et al. with PHP, and Goravel with Go. Anyone who prefers Laravel or any other framework can use it. I wrote that neither PHP nor Go need a framework because they have everything necessary to implement web applications. If you don't want to get laid off because everyone and their mother, and now LLMs, can copy-paste Laravel sample code for $15/hr (see Upwork, for example) improve your skills. If you want to have more opportunities in the programming job market expand beyond frameworks and learn the underlying languages and libraries.

mplewis 2y ago

Writing SQL is a miserable slog because it isn’t composable. I’ll take an ORM over raw SQL any day.

gregjor 2y ago
SQL is a declarative language for working with relational databases. The concept of composability doesn’t apply. SQL does support code reuse and building layers of abstractions. If you only use SQL through an ORM you won’t get to use things like CTEs and views and user-defined functions, because ORMs by definition deform the relational model and SQL to fit OOP. In 40+ years programming SQL expertise has paid the bills and kept me employed more reliably than any other language or tool I have mastered.
- randomdata 2y ago
  > SQL is a declarative language for working with relational databases. No. First and foremost, SQL is for tablational databases. A relation and a table are similar, to be fair, but have some key differences: - A relation is an unordered set of tuples. SQL opts for an ordered list of tuples (a table) instead. - A relation has no concept of NULL. A table does. - The implications of those differences also bring a whole bunch of other differences that further divide SQL from the relational model. SQL's only association to relational databases is in its name, being originally SEQUEL which was a play on QUEL – a language actually for relational databases that was a direct adaptation of Alpha from Codd's original paper. > The concept of composability doesn’t apply. Of course it does. Why wouldn't it apply? Datalog, a declarative language for querying data, is in many ways similar to SQL and it supports composition just fine. Many of the compile-to-SQL languages also support composition just fine. SQL could be composable. It should be composable. It just, because it still desperately clings to its COBOL-era glory days, is too afraid to add support. > In 40+ years programming SQL 40+ years of working with SQL and you are still this confused about it...?
  - gregjor 2y ago
    Nothing you wrote has anything to do with ORMs, the actual point of this thread. The shortcomings of SQL with respect to a pure relational model are well-known. For all practical purposes we have SQL. Almost everyone using a popular relational database engine — those that might have ORM support — uses SQL. The history of SQL and niche alternatives, while interesting, don’t have anything to do with using an ORM vs writing SQL. I’m not confused about relational vs SQL. I just didn’t think the pedantry would add to the discussion. Pointing out that SQL doesn’t implement the relational model correctly seems like pointing out that C++ doesn’t implement object oriented programming as Alan Kay defined it. True, but C++ got a lot of adoption and Smalltalk did not. Pointing out the OO shortcomings of C++ don’t help with using the language.