> 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!).
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 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
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.
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).
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.
>, 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.
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.
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.)
Depends on how the database engine sets up the join. I've seen queries where the join ends up spilling into a temp table and it takes a lot longer to do it that way. IIRC, this can happen especially if you've asked the database engine to sort things.
Same with UNION vs IN. If you union 10 queries for one row each by id, it'll hit the index every time; but if you do it with IN, maybe it decides to do an index scan which takes longer.
You could say well the database engine is broken if client-side join works better than database-side join, and sure it probably is, but given the choice of fix the database engine or do a client-side join, I know which one is feasible in the short term.
Every major database uses nested loop, hash, or sort-merge joins. If the data is small enough to fetch in a second query, I don't see any scenario where it would make a query spill to disk when it otherwise wouldn't have (except those pesky OR's).
Most JOIN issues can be resolved by composing using sub-queries/CTE's to defer a join to a smaller intermediary result, and the only time this generally can't be done is if you need a predicate on the joined table.
> you've asked the database engine to sort things
I've only found this to be true when there's an OR condition where the single query ends up doing a bitmap against every row, in which case a UNION will be faster since it's just appending two already-index-ordered streams.
> Same with UNION vs IN
A union is almost always going to be worse - most query planners cannot optimize across queries in a UNION, so each query is going to have separate ops vs. a single op with the IN. The only case I've seen this be true is for multi-column predicates with an OR clause against a composite index. I just tested the former in both Postgres and MSSQL and the UNION query cost was 2x the IN clause.
> maybe it decides to do an index scan which takes longer
This has not been my experience unless the table statistics are bad.
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."
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
You'd have a future in modern sculpture. ;-)
Okay, sorry sculptors! I like the brute force of the bat/garbage symbolism that seems so fitting in this day and age.
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?
I read the same piece you did (if it was on HN, anyway), and it described highly-educated-in-Kenya people. Nothing low-class implied. I suspect (though I may be wrong about this) that lower-class Kenyans aren't likely to be literate in English.
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.
Like an early article having headline "ORM will replace SQL knowledge".
I am professional dev for 15 years and hobbyist for 20 years and I might have missed something. But only thing I do remember was "anti ORM" people nagging how "one should really know SQL" - where I never heard anyone saying "don't learn SQL" maybe only NoSQL hype... but no one else.
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.
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.
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.
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.
> ..idea anticipated centuries ago by the philosopher Baruch Spinoza: that our Soul could be a phenomenon of the same basic nature as any other phenomenon in nature.
Even the current Artificial Intelligence revolution is showing us that:
what was thought to be purely immaterial and intangible, that is, human abstract Reasoning and Thoughts, are actually tangible, physical, and even machine-reproducible.
For most of human history, access to a great education has been a function of where you were born and how much money your family had, and of a parents social class.
The best teachers, the best tutors, the best learning resources, they’ve always been concentrated in a small number of places and available to a small number of people.
In my opinion, the AI has the potential to genuinely disrupt that.
The direction of travel is toward a world where a kid in a rural area with a smartphone has access to a quality of personalized instruction that would have been unimaginable only one generation ago.
> During the 40 years since the disaster, it has become clear that many species are living quite happily within the 37-mile-wide (60km) exclusion zone set up around the ruined power plant. But that's not to say nature hasn't changed here – sometimes for the worse.
So.. the radiations has had virtually no impact on the natural ecosystem's regrowth?
Not only... we've always been told about the disastrous consequences of nuclear radiation, but, according to the BBC article (by Chris Baraniuk), that's not the case.
Due to our long lifespan, humans are relatively vulnerable to radiation, radioactive materials, and other bioaccumulative poisons. A fish might not accumulate enough mercury to kill itself over its lifetime, but when you eat one every day it all adds up.
This was why the disaster was so bad for so many farmers across Europe: https://www.bbc.com/news/uk-wales-36112372 ; the caesium is not enough to kill a sheep, which has a life of one or two years before slaughter, but should not be consumed by humans.
The man-made radioactive isotope caesium-137 can be detected in the bodies of all living humans and it was there even before the Chernobyl accident. The first nuclear explosion in 1945 spread, for the first time, the isotope caesium-137 over the whole planet. We have so sensitive methods of detecting caesium-137 that we can use them to check if a bottle of wine was produces before 1945
Of-course there were radionuclides in our bodies even before the first nuclear test in 1945. For example Potassium-40 or Carbon-14. The presence of Carbon-14 in organic matter is the basis of the radiocarbon dating method to date archaeological, geological and hydrogeological samples.
The big question is how much radionuclides is safe and how much radionuclides is a health risk.
In addition to that, if a quarter of animals die prematurely from some horrible disease, that’s just Tuesday. People tend to get upset when that happens among humans.
For a long time there was a serious debate over whether wild animals actually experienced aging or not, because they’d never live long enough to get noticeably aged.
There are dogs roaming around the Buryakovka nuclear waste storage facility. About ~10 years ago I have been told that their average lifespan was in a ballpark of three years. Make what you will from it.
OTOH Przewalski's horses are just thriving in the Zone!
> All of these features are about breaking the coupling between a human sitting at a terminal or chat window and interacting turn-by-turn with the agent.
This means:
- less and less "man-in-the-loop"
- less and less interaction between LLMs and humans
- more and more automation
- more and more decision-making autonomy for agents
- more and more risk (i.e., LLMs' responsibility)
- less and less human responsibility
Problem:
Tasks that require continuous iteration and shared decision-making with humans have two possible options:
"Did the vehicle just crash" has a short feedback loop, very amenable to RL. "Did this product strategy tank our earnings/reputation/compliance/etc" can have a much longer, harder to RL feedback loop.
But maybe not that much longer; METR task length improvement is still straight lines on log graphs.
> The AI has read all the business books, blogs and stories.
This seems like a liability as most business books, blogs, and stories are either marketing BS or gloss over luck and timing.
> Unless your CEO is Steve Jobs, it's hard to imagine it being much worse than your average pointy haired boss.
As someone using AI agents daily, this is actually incredible really easy to imagine. It's actually hard to imagine it NOT being horrible! Maybe that'll change though... if gains don't plateau.
But they are shit. Over the last 2 days I've got bored of the predictable cycle of it first getting excited about a new idea then back peddling once I shoot it to pieces.
They can't write and think critically at the same time. Then subsequent messages are tainted by their earlier nonsensical statements.
Getting to that point is likely going to involve a lot of (the business and personal equivalent of) Teslas electing to drive through white semitrailers.
Let's not forget that Waymo requires an extensive, custom mapping and software/pre-training development process for every new city they operate in, are only in 10 cities total after over 20 years, and are still nowhere near profitability (or even with a clear plan to get there as far as I can tell).
I personally believe widely available self-driving cars which don't operate at a loss will continue to elude us until we accept the tradeoffs of dedicated lanes, a standardized vehicle-to-vehicle communication protocol, and roadside sensors. We were lied to.
For a fraction of the cost of developing self-driving cars we could have self-driving trains/trams/subways and most likely minibuses as part of public transportation networks.
And self-driving minibuses would basically provide 95% of the benefits of self-driving buses. They could offer 24/7 frequent service with huge coverage, we already have dedicated bus lanes in many places (and we could scale dedicated bus lanes much faster than dedicated self-driving car lanes), etc.
Now, I understand that in many places (especially the US) this is infeasible because public anything = communism.
Folks in the US are happy to spend tax dollars on roads, it's just that mass transit spending is considered communism.
To be fair to the anti-train crowd, we've been led so far down this disastrous path of car-led sprawl that the hope of even building feasible buses that can reach into the byzantine suburbs is unlikely.
So, maybe our best hope is self-driving EVs? At least in our lifetimes.
If they put a pricing page, I think there would be someone who would buy it, especially nowadays when with embedded llms there is a huge hunger for RAM (as well as CPU). :))
I was thinking... will x402 protocol make it super easy for scammers to commit such frauds in future? By tricking online searches done by LLM's to trick them into spending money?
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?
reply