Learn SQL Once, Use It for 30 Years • Hacker News Board

Re: Learn SQL Once, Use It for 30 Years

#241

Post by mightyham » Sun, Jun 07, 2026, 10:01 PM UTC

onlyrealcuzzo wrote: post #73

mightyham wrote: post #71

The comparison with JavaScript as an exemplary imperative language is silly. You can find examples of C code from 40 years ago that still work perfectly with modern compilers. Like C, SQL is a technology that has far outlived its usefulness, though, for very different reasons. SQL was not designed for application development, and every attempt to integrate it into higher level programs (ORM, fluent query builders, ra…

> Learning relational modelling is great, but learning SQL itself, unless you actively have to work with it, is a waste of time. What a wild statement. SQL is one of the most useful tools ever developed, as evidence that it's BY FAR the most widely used programming language in the world. The idea that it is an ABSOLUTE LAST RESORT that should never be used unless you ABSOLUTELY HAVE TO is insane...

Scoffing and acting exasperated doesn't actually refute anything I said. I obviously don't disagree with you that SQL has been wildly useful and popular, but that has very little to do with my comment. SQL is an outdated and flawed technology, that is propped up by decades of institutionalization. You can say a similar thing about C++: that's it's one of the most popular and useful languages in existence, yet it's also a total trash fire that owes it's lasting success more to historical trends and institutional adoption then technical merit.

Re: Learn SQL Once, Use It for 30 Years

#242

Post by mightyham » Sun, Jun 07, 2026, 10:47 PM UTC

onlyrealcuzzo wrote: post #84

HelloNurse wrote: post #81

Earlier quoted context omitted.

Even wilder: > SQL was not designed for application development, and every attempt to integrate it into higher level programs (ORM, fluent query builders, raw strings, macros/preprocessors) comes with unpleasant rough edges. Forgetting that interactive SQL queries, and to an even greater degree the underlying databases, are applications.

Anyone who hates SQL typically is completely clueless how hard it is to actually do what SQL does correctly and efficiently. SQL makes doing something that is VERY hard stupidly easy.

Feel free dismiss my option by assuming I'm some ignoramus that doesn't know anything about how databases work.

I'm well aware of the underlying challenges that SQL provides convenient abstractions over, and what I'm saying is that it actually isn't all that helpful for complex use cases unless you know a decent amount about dbs; which at that point, I'd rather program against a thinner , less abstract persistence API.

The flip-side of what you've stated is that SQL makes doing things that that SHOULD be hard, because they are stupid, stupidly easy. For instance, it's dead simple to make read queries with complex filters that join together an arbitrary number of tables and transactional updates that change values in rows across multiple tables. However, on large datasets or application that need high throughout, relying on those kinds of queries would be a terrible idea.

Furthermore, databases like Postgres use SSI by default which means that complex transactions that mix reads with writes can have subtle and hard to catch bugs that are completely non-obvious to new comers. I could easily forgive a junior developer for thinking they could implement an accurate counter in postgres using a transaction with a select then update to increment a value in a given row.

Re: Learn SQL Once, Use It for 30 Years

#243

Post by kermatt » Fri, Jun 12, 2026, 4:03 PM UTC

Rendello wrote: post #115

kermatt wrote: post #100

Not quite as simple as learning it once. SQL evolves like other languages, across vendor implementations. The ClickHouse and DuckDB dialects for example extend the language with analytic options not found in ANSI SQL, nor T-SQL, Pl/PgSQL, etc. DuckDB QoL enhancements are greatly missed when not available.

Which SQL-specific QoL enhancements do you miss? I was really excited to use DuckDB for things like structs and enums, but after a while I just went back to regular SQL and used it for its other features.

https://duckdb.org/docs/lts/sql/dialect/friendly_sql