[flossly]

I find SQL a very thick "wrapper masking low-level logic". Think of the query planning, the index-maintaining, the upholding of guarantees, the writing-to-disk and caching that you are all not doing by using a RDBMS!

I'd say SQL is a very high level language.

"SQL teaches you to reason and approach problems logically" -- I kind of agree here. It teaches relational data mgmt. I think it is better to attack most software design challenges at a higher level, and --once settled at that level-- consider how to "serialize" those solutions to an RDBMS (if that's the tech that you've chosen for persistence; still a very solid choice after 50+ years!).

[rspeele]

> I'd say SQL is a very high level language.

Yes indeed. When I learned SQL in college, the professor made a HUGE deal about how it was a "4th generation language" so it was so abstract you didn't have to think about how the computer would answer your query.

Even at that time I thought that was massive overstatement of what using SQL was like. It didn't deliver on that promise very well. But it's very funny to see plain SQL now sometimes called "low level"!

[adammarples]

Yes it did, you don't need to worry about whether the sql execution engine is spark, or snowflake, or sqlite or what, you just reason about the top level logic

[graemep]

Yes, i think the right wording is something like "the power of understanding the concepts" or "having the right mental model" rather than "low level".

[flossly]

And this I think is best not done in SQL/ the relational-data paradigm. It's better to understand the problem in terms that do not tie you in to a specific technology. And once you have a clear picture of what need to be built, then choose persistence tech; if that happens to be SQL, you can then translate your solution to SQL.

In my experience, SQL sorely misses sum-types. So I need to find a way to serialize the sum-types of my domain model to SQL.

[hdjrudni]

I think it'd be easier to work backwards.

They tried teaching us this relational algebra (or whatever you call it) in university but most of it went over my head because it was too abstract. Using weird mathematical symbols. But when we started writing actual SQL, all of that made sense to me.

I think it might be easier to see it in action and then go back and understand the fundamentals of how/why it works.

[flossly]

That's the difference between academia (like to make simple things look complex -- but very correct in wording/modelling/approach) and engineering (like to make complex stuff look easy -- sometimes cutting some corners).

[layer8]

“Fundamental” rather than “low-level”. Which also matches the article picture.

[flossly]

I was reacting to the parent post. And F and LL are very different. I'd say F is a more subjective metric.

[layer8]

I was reacting to the parent post as well, suggesting that they should have used “fundamental” rather than “low-level”, and that “fundamental” would also match the article picture.

[flossly]

Dunno. I think the pic is useless. SQL is not in the foundation of all those langs.

SQL is still very useful after all these years: that's the point that anyone will agree on.

Not low level. Not "fundamental" (by most definitions I can think of).

[psychoslave]

Not sure what you mean with higher level tools to start with, could you precise please?

[flossly]

Where did i say "higher level tools"?