Hacker News Reader

Comment by mightyham | Hacker News Reader

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, raw strings, macros/preprocessors) comes with unpleasant rough edges. The best thing young developers can do is read a book like "Designing Data-intensive Applications" and learn how the fundamental technology behind databases work. Learning relational modelling is great, but learning SQL itself, unless you actively have to work with it, is a waste of time.

View on HN

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

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.

The issue is that most of these tools try to reinvent the wheel. Instead of using sql, you use 'fluent builders' or whatever, and they have their own tricks and cevats.

Sqlc is the best thing I've personally used because it produces models and repositories based on plain sql queries.

It's much easier to reinvent one of the most used tools in the world as a far worse version than better.

It's almost as if it was easy to reinvent something highly used that someone would've already done it...

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.

The point is that you will actively have to work with it. If you are designing data intensive applications without sql you are the exception, not the rule.

Reply on news.ycombinator.com