Earlier quoted context omitted.
ORMs come with a lot of baggage that I prefer to avoid, but it probably depends on the domain. Take an e-commerce store with faceted search. You're pretty much going to write your own query builder if you don't use one off the shelf, seems like.
I once boasted about avoiding ORM until an experienced developer helped me to see that 100% hand‑rolled SQL and customer query builders is just you writing your own ORM by hand. Since then I've embraced ORMs for CRUD. I still double-check its output, and I'm not afraid to bypass it when needed.
The Rise of SQL:the second programming language everyone needs to know
101–110 of 139 posts
Re: The Rise of SQL:the second programming language everyone needs to know
#102> the second programming language everyone needs to know Do they though? I've been writing SQL for over twenty years, and my experience is that LLMs have been better at writing it than I am for at least most of 2025, for most use cases. I have zero doubt that I will only be writing SQL when I want to for fun no later than sometime 2027.
> I've been writing SQL for over twenty years, and my experience is that LLMs have been better at writing it than I am for at least most of 2025 Wow, bad career choices?
Re: The Rise of SQL:the second programming language everyone needs to know
#103The mere existence of Pandas makes me extremely grateful for SQL, because my job would be absolute hell if I had to use pandas or a similar syntax. It’s hard to overemphasize just how perfect SQL is for the job that it does.
I don't think SQL is "perfect" and I'm not sure it's rational to even be saying that. For instance, why is it that the syntax for an SQL query is "select A from B" when many SQL-inspired syntaxes have switched to something like "from B select A" to make it more compositional? The relational model is pretty simple though. Pandas is an awful mess.
Re: The Rise of SQL:the second programming language everyone needs to know
#104SQL is not a programming language.
Re: The Rise of SQL:the second programming language everyone needs to know
#105This is a nice coincidence. I’ve been heads-down on publishing a JavaScript full-stack metaframework before the end of the year. However, in the past two weeks I’ve been goaded by Claude Code to extract and publish a separate database client because my vision includes Django-style admin/forms. The idea is to use Zod to define tables, and then use raw SQL fragments with JavaScript template tags. The library adds a tin…
Re: The Rise of SQL:the second programming language everyone needs to know
#106Earlier quoted context omitted.
In addition to the great replies folks are sharing, I've found LLMs are quite good at authoring non-trivial SQL. Have effectively been using these to implemnt + learn so much about Postgres
Many great SQL examples have long existed on stackoverflow and similar sources, but until the recent past were buried by lower quality questions and answers or SEO spam. You will find that if you check sources they are lifted almost verbatim. LLMs are a way to cut through the noise, but they are rarely "authoring" anything here. It's wild how far a little marketing can go to sell the same or an arguably worse product…
Re: The Rise of SQL:the second programming language everyone needs to know
#107IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL). So that any invalid SQL parameters like "1;DELETE FROM users;--" would just fail to parse.
It may be called ABI, although it may be textual as well (like json), not necessarily binary (like protobuf).
PostgreSQL already supports binary wire protocol, but I never seen it's being used, instead people prefer sending raw SQL strings designed for humans even from applications.
Re: The Rise of SQL:the second programming language everyone needs to know
#108I've loved and used Django ORM and SQLAlchemy for many years. It got me a long way in my career. But at this point I've sworn-off using query-builders and ORMs. I just write real, hand-crafted SQL now. These "any db" abstractions just make for the worst query patterns. They're easy and map nicely to your application language, but they're really terrible unless you want to put in the effort to meta-program SQL using w…
You may not need to use an ORM, but hand writing SQL, especially CRUD, should be a terminable offense. You _cannot_ write it better than a process that generates it.
Re: The Rise of SQL:the second programming language everyone needs to know
#109My only problem with SQL is it was designed for human input (same as shell commands), not for machines. Hence the SQL Injection attacks and other peculiarities and inefficiencies. IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL…
Re: The Rise of SQL:the second programming language everyone needs to know
#110My only problem with SQL is it was designed for human input (same as shell commands), not for machines. Hence the SQL Injection attacks and other peculiarities and inefficiencies. IMO for machine-to-machine talk we should not be using a long text that needs to be parsed carefully and securely on the other side, but rather a structured structure that's easy to de-serialize (like AST packed into a protobuf, but for SQL…