Comment by aledevv
18 hours ago
> 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 approach problems logically. Without any wrapper masking low-level logic.
It's something like the letters of the alphabet that form concepts: why should they change?
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!).
> 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"!
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 sum-types of my domain model to SQL.
“Fundamental” rather than “low-level”. Which also matches the article picture.
I was reacting to the parent post. And F and LL are very different. I'd say F is a more subjective metric.
2 replies →
The breakthrough for me was thinking in terms of sets and not in terms of "how would I do this imperatively."
If you see SQL where someone wrote a SELECT and is then using a cursor to loop through those results and do other queries, you've found the person who is still thinking imperatively.
SQL teaches Set based thinking.
Prolog teaches logical constraint based thinking.
ML/Lisp/etc teach functional thinking.
There is a lot of use in learning these other things beyond the standard imperative thinking from C/Python/Java/etc. Since some problems reduce their complexity significantly in one form or another.
> If you see SQL where someone wrote a SELECT and is then using a cursor to loop through those results and do other queries, you've found the person who is still thinking imperatively.
To a first approximation, yes. But 'client-side joins' can be a valuable tool when the database engine won't cooperate. For some queries and some engines, you can do a select with a join to get everything you need in one query, but a select to get a list of ids followed by a union of selects (not an IN query) to get details for each id will have the results at the client sooner, with less load on the database, at some potential loss of consistency. Your client needs to be within a reasonable round trip of the server or the two queries approach won't get the answer faster.
I'm not sure I follow. Fetching the data in one query should almost always be faster and more efficient - the same work is being done regardless, except now you have the additional overhead involved with a second query (network and connection overhead, parsing etc.)
3 replies →
A thousand times this. I've resolved performance issues in so many stored procedures written by programmers who don't grasp set theory and reach for the CURSOR early and often.
The quote that comes to mind: "His pattern indicates two-dimensional thinking."
Also from that film comes the quote:
> I've done far worse than kill you. I've hurt you. And I wish to go on hurting you.
Which I believe is a paraphrase of the Oracle Master Agreement.
I guess I think in 2.5D because I’ll often sketch an imperative, dumb query and then refine it once I know I’ve got the data I need. But I have a hard time starting with elegance. I use a baseball bat to shape the garbage can into the desired form
1 reply →
Fascinating.
How is a cursor different from a jdbc call that fetches all records after executing a query? What advantages doez the cursor have that a recordset does not?
>, SQL teaches you [...] Without any wrapper masking low-level logic.
I understand the point you're trying to make, and yes, it does seem like SQL is "low-level" from the perspective a wrapper like ORMs or a GUI db browser tool with menus for filtering data.
But it's also worth remembering that SQL itself is a high-level wrapper that hides the lower-level C/C++ code of the db engine that has the loops that iterate through b-trees, 8k data pages, memory blocks of the buffer cache, etc.
And C/C++ itself is a high-level wrapper that hides the logic in lower-level Linux o/s system calls that manages RAM and disk i/o.
And Linux itself is a high-level wrapper that hides low-level device drivers like SATA/SSD memory-mapped IO ... and so on and so on.
Depending on the type of app, you can ignore all the lower levels and just work at the abstraction level of higher-level wrappers.
> Not a tutorial. Not an ORM. Actual SQL
ah, this is an Ai article
Darn. I write exactly like this. You need to consider that people write in different ways, and the LLM is choosing from among the different styles.
There is little chance your writing is as consistently the exact same as the default LLM output, which this definitely is.
I knew a lady who was named Isis at birth.
She stopped using that name.
I heard it mostly writes in a style associated with low-class people from Kenya.
1 reply →
So AI also thinks people somehow get away only with ORM without understanding SQL?
Funny thing is, that is always argument of „anti ORM” people.
I yet have to see someone actually argue that you don’t need to understand SQL and ORM will suffice in the wild. Then also find devs who can’t do a simple join as joins and index usage is not some black magic and is still required to use ORM properly.
> I yet have to see someone actually argue that you don’t need to understand SQL and ORM will suffice
Well that's because decades of bitter experience has told us all that object graphs rarely map cleanly to sets of relationships.
However, I do think that must have been the original idea as tools such as Hibernate tried so hard to obscure the underlying SQL and database. As a result all Hibernate objects have their own particular identity requirements which only made sense to a developer that knows what's going on under the hood.
1 reply →
Can we stop calling specific literary devices as automatically AI?
Yes, LLMs overuse that pattern. But it's a valid rhetorical device used for many , many years by human authors. Quite often too, especially in philosophical writing, and fantasy novels.
I'll give you that it wasn't often used in blogs or tech articles, but LLMs have been around long enough to have influenced human writing in other domains without the entirety of the content itself being LLM generated.
But its called out so often I swear people online will go read some classics and accuse them of being AI generated.
The amount of em dashes in Nietzche; the amount of semicolons in Hegel
I just assume anyone posting it, at this point, doesn't read, doesn't write, or simply isn't clever enough to say anything that's actually worth listening to. Pure noise that won't go away because it makes the teenagers feel validated in how mad they are about AI.
[dead]
It's always AI until proven otherwise... even then I'm skeptical.
Ellipses where a comma would suffice? Definitely AI. Not even a good model.
John23832, you are still an AI to me too.
Did you not see the banner image?
I'm actually learning SQL now and finding it HIGHLY enjoyable.
I'm by no means a senior dev, but I don't know if I fit in the box of a junior either.
Regardless, SQL is proving enjoyable. But I really like logic, so it fits.
That’s not low-level reasoning, but rather low-resolution thinking. SQL is a high level language. It’s so high level that you barely need to express how the computer should do things, but only declare what you want to have.
A couple of sites worth checking out to level up, both by Markus Winand:
https://modern-sql.com/
https://use-the-index-luke.com/
I ran across https://use-the-index-luke.com organically while learning SWL recently and I've been really enjoying it.
I can't vouch for it from any perspective except as an SQL neophyte but for me it has been teaching me a lot.
also a few different para-sql languages that can be useful, to lower the complexity:
- https://prql-lang.org/ - https://www.malloydata.dev/
A self para-sql-lang plug if you like the direction of malloy but prefer something closer to native SQL syntax. (a controversial take at times)
- https://trilogydata.dev/
The whys will vary, but letters of alphabets do change indeed.