Live data from Hacker News

Learn SQL Once, Use It for 30 Years

fagnerbrack.com

211–220 of 243 posts

Re: Learn SQL Once, Use It for 30 Years

#211

Earlier quoted context omitted.

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

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

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.

Re: Learn SQL Once, Use It for 30 Years

#212

Earlier quoted context omitted.

A pretty common request is to lift the FROM up before the select, like the below. I'm pretty fine with status quo since my mind is usually "hmm what do I need to get" first, then I figure out how to get it, but some engines (duckdb, I think?) support both so everyone gets their cake. What people often want:

Also helps with autocomplete, which is why LINQ starts with `from`

Linq took that from Hibernate in believe. But in general, I'd say almost all ORM and SQL-gen libraries have FROM first, because it's clearer for programmers.

Re: Learn SQL Once, Use It for 30 Years

#213
post #30

> If you are a junior developer, “learn SQL properly” is the most valuable 40 hours you can spend. Not a tutorial. Not an ORM. Actual SQL: joins, subqueries, window functions, query plans. That investment pays you back at every job, in every stack, for decades This is the power of low-level reasoning. Today, even for a junior developers, even if they have AI that solves syntax problems, SQL teaches you to reason and…

> Actual SQL: joins, subqueries, window functions, query plans

And indexes. Many times in my career, adding the right SQL index has solved a serious performance problem.

Re: Learn SQL Once, Use It for 30 Years

#214
post #30

> If you are a junior developer, “learn SQL properly” is the most valuable 40 hours you can spend. Not a tutorial. Not an ORM. Actual SQL: joins, subqueries, window functions, query plans. That investment pays you back at every job, in every stack, for decades This is the power of low-level reasoning. Today, even for a junior developers, even if they have AI that solves syntax problems, SQL teaches you to reason and…

> Actual SQL: joins, subqueries, window functions, query plans And indexes. Many times in my career, adding the right SQL index has solved a serious performance problem.

I'd argue that indexes is an implementation detail here and exactly the kind that should not leak into the abstract "thinking about sets and how to combine them".

It is valuable and critical in lots of real situations. But it may interfere with the actual learning.

Re: Learn SQL Once, Use It for 30 Years

#215
The real lesson is to learn low level details once and use it forever.

The advantage of abstractions that maintain backwards compatibility better than most (linux syscall, SQL, etc) is that they become low level in the sense of the above statement. There is absolutely no way most syscalls or SQL are actually low-level, but for the most part you can write your code as if they are.

Of course, these abstractions do leak, but for X% of usecases, they reduce the learning required to get the same output as you would have gotten with "true" low level knowledge.

The actual quality of the abstractions is completely moot, the backwards compat _alone_ means that their value exists at almost any value of X. See: the web platform, with a very low value of X.

This is why I love libraries and APIs that focus on backwards compat more than most. Everything else is unknown - you don't know how high quality your API is and how it will stand the test of time. But one thing is for sure, a backwards compatible API will _always_ be useful in some capacity.

Re: Learn SQL Once, Use It for 30 Years

#216

That's true. SQL knowledge is one of the few skills that didn't age. 1. C language. 2. *nix tools (shell and friends). 3. SQL. 4. Basic IPv4 networking. These things I learned around 20 years ago, they didn't change much and they are useful for me to this day.

Well, IPv4 is obsolete.

It is not obsolete. In fact, I've yet to encounter IPv6 anywhere, so my IPv6 knowledge so far stays mostly theoretical. And I work with servers.

Probably depends a lot on a particular location.

Re: Learn SQL Once, Use It for 30 Years

#217
post #5

> Edgar Codd formalised relational algebra in 1970. SQL sits on top of it as a declarative interface. You describe what you want. The database engine decides how to get it. The engine improves every year. Your query stays the same. Although SQL is of course not relational Algebra (and others like Datalog and D4M are better), it's still cool. It inspired kSQL like Lil uses https://beyondloom.com/decker/lil.html#lilthe…

Fascinating stuff! It's the second time I see D4M mentioned this week, and I remember seeing Lil as the little language for Hypercard-like Decker but didn't know about it as a query language.

Declarative DSLs, I just started browsing the project and the code is beautiful. I've been curious about Janet for a while now, I plan to set aside some time to explore this.

Re: Learn SQL Once, Use It for 30 Years

#218

Earlier quoted context omitted.

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

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.

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

Re: Learn SQL Once, Use It for 30 Years

#219
post #54

Earlier quoted context omitted.

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

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

Where did i say "higher level tools"?

Re: Learn SQL Once, Use It for 30 Years

#220

Earlier quoted context omitted.

Also helps with autocomplete, which is why LINQ starts with `from`

Linq took that from Hibernate in believe. But in general, I'd say almost all ORM and SQL-gen libraries have FROM first, because it's clearer for programmers.

Hibernate puts SELECT last if requesting only specific properties?

LINQ:

  var query = 
    from e in entities
    where e.property1 == value
    select e.property2;
Post reply on HN