Maybe a similar bifurcation will arise where there are vibe coders who use LLMs to write everything, and there are real engineers who avoid LLMs.
Maybe we’re seeing the beginning of that with the whole bifurcation of programmers into two camps: heavy AI users and AI skeptics.
Im more surprised by software engineers who do know these things than by the ones who don’t.
It’s not that SQL is hard, it’s that for any discipline the vast majority of people don’t have a solid grasp of the tools they’re using. Ask most tradespeople about the underlying thing they’re working with and you’ll have the same problem.
Reasons: - I can compose queries, which in turn makes them easier to decompose - It's easier to spot errors - I avoid parsing SQL strings - It's easier to interact with the rest of the code, both functions and objects
If I need to make just a query I gladly write SQL
It's just a shame that many languages don't support relational algebra well.
We had relations as a datatype and all the relevant operations over them (like join) in a project I was working on. It was great! Very useful for expressing business logic.
> 'real' engineers can use SQL just fine.
To be very explicit instead of snarky about my point: I think it is both factually incorrect and unnecessary gatekeeping to say real engineers know sql and imply not knowing sql marks someone as not a real engineer, hence the "no true Scotsman" fallacy.
I probably agree with most of your opinions here within the context of the thread - I think good engineers can learn sql and other tools as necessary. I don't, however, think experience with any particular technology is a valid bar for a good or bad engineer at this point and I'm happy to speak against that when I see it.
I share your sentiment though - I'm a data engineer (8 years) turned product engineer (3 years) and it astounds me how little SQL "normal" programmers know. It honestly changed my opinion on ORMs - it's not like the SQL people would write exceeds the basic select/filter/count patterns that is the most that non-data people know.
Is this true? It doesn't seem true to me.
Yes, there are so many so called developers in backend field of work who do not know how to do basic SQL. Anything bigger than s9imple WHERE clause.
I wouldn't even talk about using indexes in database.
(Also of other food, energy, and materials sourcing: fishing, forestry, mining, etc.)
This was the insight of the French economist François Quesnay in his Tableau économique, foundation of the Physiocratic school of economics.
> Strictly speaking, farming is where all our livelihoods come from, in the greatest part. We're all living off the surplus value of food production.
I don't think farming is special here, because food isn't special. You could make exactly the same argument for water (or even air) instead of food, and all of a sudden all our livelihoods would derive ultimately from the local municipal waterworks.
Whether that's a reductio ad absurdum of the original argument, or a valuable new perspective on the local waterworks is left as an exercise to the reader.
Working the summer fields was one of the least desirable jobs but still gave local students with no particular skills a good supplemental income appropriate for whichever region.
A good example of this phenomenon is sports. Even thought it can't be done remotely, it's so talent dependent that it's often better to find a great player in a foreign country and ask them to work for you, rather than relying exclusively on local talent. If it could be a remote job, this effect would be even greater.
We increase the overall total prosperity with that automation.
Well, what we had before SQL[1] was QUEL, which is effectively the same as Alpha[2], except in "English". Given the previous assertion about what came before SQL, clearly not. I expect SQL garnered favour because it is tablational instead of relational, which is the quality that makes it easier to understand for those not heavy in the math.
[1] Originally known as SEQUEL, a fun word play on it claiming to be the QUEL successor.
[2] The godfather language created by Codd himself.
The Alpha/QUEL linage chose relations, while SQL went with tables. Notably, a set has no ordering or duplicates — which I suggest is in contrast to how the layman tends to think about the world, and thus finds it to be an impediment when choosing between technology options. There are strong benefits to choosing relations over tables, as Codd wrote about at length, but they tend to not show up until you get into a bit more complexity. By the time your work reaches that point, the choice of technology is apt to already be made.
With care, SQL enables mimicking relations to a reasonable degree when needed, which arguably offers the best of all worlds. That said, virtually all of the SQL bugs I see in the real world come as a result of someone not putting in enough care in that area. When complexity grows, it becomes easy to overlook the fine details. Relational algebra and calculus would help by enforcing it. But, tradeoffs, as always.
>SQL [...] is a database language [...] used for access to pseudo-relational databases that are managed by pseudo-relational database management systems (RDBMS).
>SQL is based on, but is not a strict implementation of, the relational model of data, making SQL “pseudo-relational” instead of truly relational.
>The relational model requires that every relation have no duplicate rows. SQL does not enforce this requirement.
>The relational model does not specify or recognize any sort of flag or other marker that represents unspecified, unknown, or otherwise missing data values. Consequently, the relational model depends only on two-valued (true/false) logic. SQL provides a “null value” that serves this purpose. In support of null values, SQL also depends on three-valued (true/false/unknown) logic.
Or, in other words, "relation" does not mean the relations between the tables as many assume: the tables, as a set of tuples, are the relations.
None of these had "semantic expressivity" as their strength.
> If SQL looked like, say, C#'s LINQ method syntax, would it really be harder to use?
Yes.
SQL is pretty horrifying when you start getting tree structures or recursive structures. While Datalog handles those like a champ.
SQL is really nice for columnar data, and it's well supported almost everywhere.
Though Datalog isn't half bad at columnar data either.
They are very much the exception that proves the rule though.
(I'd love for someone to substantiate or debunk this for me.)
Incorrect.
Encoding a program was considered secretarial work, not the act of programming itself. Over time, "encoding" was shortened to "coding."
This is why the industry term "coder" is a pejorative descriptor.
For some people some of the time. I don't think that's true in general.