Live data from Hacker News

The Rise of SQL:the second programming language everyone needs to know

spectrum.ieee.org

101–110 of 139 posts

Re: The Rise of SQL:the second programming language everyone needs to know

#101
post #24

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.

Not really. ORMs have defining characteristics that hand-rolled SQL with mapping code does not. Eg, something like `Users.all.where(age > 45)` create queries from classes and method calls, while hand-rolled SQL queries are...well..hand-written.

Re: The Rise of SQL:the second programming language everyone needs to know

#102
post #69
post #16

> 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?

I wouldn't think so, knowing SQL has been a benefit, and knowing how to use LLMs to write SQL even more so.

Re: The Rise of SQL:the second programming language everyone needs to know

#103
post #86

The 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.

Is that really how it should be judged? If I need to get data from state A to state B, SQL is the most elegant and efficient way to do it. If I need to modify the states, or break them up to optimize for memory, SQL is the easiest way to do it. It’s been around for over 50 years and no one’s come up with anything better.

Re: The Rise of SQL:the second programming language everyone needs to know

#105

This 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…

This looks promising!

Re: The Rise of SQL:the second programming language everyone needs to know

#106
post #72

Earlier 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…

That's not how LLMs work. There are several sources covering the basics nowadays!

Re: The Rise of SQL:the second programming language everyone needs to know

#107
My 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). 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

#108
post #5

I'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…

> Nah. Just write the good SQL for your database.

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

#109

My 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…

luckily you can use parameterized queries and completely avoid this problem.

Re: The Rise of SQL:the second programming language everyone needs to know

#110

My 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…

You'd have to be using very antiquated (by nearly two decades!) patterns or practices for SQL injection to be a concern.
Post reply on HN