Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

spectrum.ieee.org

Post reply on HN
Print view View original

111–120 of 139 posts

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

#111

Post by gfody »

TomasBM wrote: post #8

Somewhat tangential to the article, but why is SQL considered a programming language ? I understand that's the convention according to the IEEE and Wikipedia [1], but the name itself - Structured Query Language - reveals that its purpose is limited by design. It's a computer language [2] for sure, but why programming ? [1] https://en.wikipedia.org/wiki/List_of_programming_languages [2] https://en.wikipedia.org/wiki/C…

"structured query language" is actually a backronym, SEQUEL is indeed a programming language and the only mainstream 4GL. consider the output of the compiler (query planner) is a program with specific behavior, just that your sql code is not the only source - the other inputs are the schema and its constraints and statistics. it's an elegant way to factor the sourcecode for a program, I wonder if Raymond Boyce didn't die young what kind of amazing technology we might have today.

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

#112

Post by system2 »

baq wrote: post #55
system2 wrote: post #32

Earlier quoted context omitted.

I agree. Claude Code writes superb SQL queries for very complex data. I was dealing with PostgreSQL recently, and it improved the query from 30 seconds to 5 seconds. I couldn't figure it out myself.

sonnet 4.5 was really bad at anything more than simple queries. even GPT 5 was not great. gemini was consistently good even at 2.5; caught multiple bugs in outputs of either. I haven't tested Opus 4.5 properly at SQL yet, but I've got a feeling Anthropic doesn't prioritize it in training and google does.

I switched to Opus permanently, but I am being cautious. It tends to go berserk and add a bunch of extras. Most of my time is spent narrowing the task to it. Sonnet was much more straightforward forward, but Opus' quality is unmatched when compared. I caught Opus messing up my CSP settings, and I had to restrict the access levels to deeper levels. Using it as an agent with full access without a plan more is suicide with Opus, but Sonnet didn't have this problem.

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

#113

Post by [deleted] »

petcat wrote: 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…

[deleted]

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

#114

Post by pjmlp »

johnh-hn wrote: post #63
pjmlp wrote: post #25

Earlier quoted context omitted.

Indeed, Dapper, myBatis, jOOQ,...

Dapper is fantastic, and I'm happy to see it getting some love. It does exactly what I want: provides strongly-typed mapping and protects against SQL injection. It makes it easy to create domain-specific repositories without leaking anything. In contrast, every company I've joined that used Entity Framework had enterprise products that ended up being a tightly coupled mess from IQueryable being passed around like the…

In my case, it has been either applications where Dapper is possible, or very high abstractions in CMS like Sitecore and Optimizely, where they come with their own approach which then again, needs a whole indexing engine.

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

#115

Post by solumunus »

zanellato19 wrote: post #36
danem wrote: post #34

Earlier quoted context omitted.

Anytime this topic comes up, this opinion is invariably at the top of the comments. However I've never seen a non-trivial application made this way. Mind sharing one? More than the query generation, I think people reach for ORMs for static typing, mapping, migrations, transactions, etc. I'm not doubting that it can be done, I'm just curious to see how it's done.

Every single time. Where are these developers? Orms are a god send 98% of the time. Sure, write some SQL from time to time, but the majority of the time just use the ORM.

> Orms are a god send 98% of the time.

Writing queries is trivial and in any marginally complex case I'll write something which beats the ORM for efficiency. I suppose they are a god send if you don't know SQL but you can learn SQL quite quickly.

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

#116

Post by forgetfreeman »

mgkimsal wrote: post #96
simonw wrote: post #57

Earlier quoted context omitted.

Did that 12 page query have any automated tests?

I doubt it was even under version control...

It was absolutely under version control and there was a full test suite. The guy that wrote it is easily in the top 3 smartest human beings I've ever met and an incredibly talented developer. Unfortunately a lot of his stuff required being at the same level on the IQ bell curve, which meant it was functionally unmaintainable by anyone else. If you're familiar with the Story of Mel, it was kinda like that.

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

#117

Post by forgetfreeman »

yobbo wrote: post #28
forgetfreeman wrote: post #20

Earlier quoted context omitted.

There's value in not having to hunt in several places for business logic, having it all in one language, etc. I was ambivalent on the topic until I encountered an 12 page query that contained a naive implementation of the knapsack problem. As with most things dogma comes with a whole host of issues, but in this case I think it's largely benign and likely did more good than harm.

> hunt in several places for business logic But that is the result of having multiple applications needing to enforce valid states in the database. "Business logic" is a loose term. The database is the effective store for state so it must enforce states, eg by views, triggers, and procedures. Other "business logic" can happen outside of the db in different languages. When individual apps need to enforce valid states,…

Other than a few ill-advised attempts to implement microservices infrastructure by well-intentioned co-workers I've not encountered situations where multiple applications needed to access a single data store. While I'm sure there are valid use cases there I suspect they're rare and should be treated like the outliers they are.

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

#118

Post by bazoom42 »

iamsomewalrus wrote: post #41
HillRat wrote: post #6

Earlier quoted context omitted.

The cargo-cult shibboleth of "never put business logic in your database" certainly didn't help, since a lot of developers just turned that into "never use stored procedures or views, your database is a dumb store with indexes."

genuinely curious, can you steel man stored procedures? views make intuitive sense to me, but stored procedures, much like meta-programming, needs to be sparingly used IMO. At my new company, the use of stored procedures unchecked has really hurt part of the companies ability to build new features so I'm surprised to see what seems like sound advice, "don't use stored procedures", called out as a cargo cult.

Stored procedures are great for bulk data processing. SQL natively operates on sets, so pretty silly to pass a dataset over the wire for processing it iteratively in a less efficient language, and then transfer the resultset back to the database.

Like any tool, you just have to understand when to use it and when not to.

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

#119

Post by bigstrat2003 »

hunterpayne wrote: post #77
randomNumber7 wrote: post #44

Earlier quoted context omitted.

Also SQL is not turing complete. I see it more as a descriptive language like e.g. html is a language but not a programming language.

This is completely wrong. The SQL spec isn't Turning complete but multiple DBs provide Turing complete extensions (like pgplsql) that make it so. Also, even without the extensions, it is still very much a programming language by any definition of the term. Like most takes on SQL, it is more about your understanding (or lack thereof) of SQL.

If the spec isn't Turing complete, only individual extensions to the spec, I think it's correct to say "SQL isn't Turing complete".

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

#120

Post by bigstrat2003 »

calebm wrote: post #52

With LLMs, you should be able to just query in English and have LLMs transpile from English to SQL.

You should also be able to reliably generate working code with LLMs, but you can't. They aren't a good tool until they actually work when they are supposed to.
Post reply on HN