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.
And I suggest that having relations in both places is the way to go.
So to conclude, objection-orientation is fine and relational is fine too, the issue is that the optimal way to translate between them does not scale.
If your language supports relation, there's no need to badly translate to objects. (And even if your language doesn't support everything your database does, there's still less of an impedance mismatch if you use an 'RRM' instead of an ORM.)
> '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.
Water largely isn't fundamenally transformed with use (unless it's involved in a chemical reaction, though that's a minute fraction of all water usage), though it may be dispersed or degraded (usually contaminated with something). But it can recover its earlier state with appropriate applications of process and energy. Water (and much else we consume) is a material input rather than an energy input.
With energy inputs it is the energy potential itself which provides value, and that potential is intrinsically consumed in their use. Water, wood, iron, aluminium, lithium, helium, etc., can all be recycled, restored to their useful state, at comparatively little cost.
Collecting the waste products of food don't give you that, on two counts. First, most of the actual metabolic output is gaseous and lost to the atmosphere at large (CO2 and water vapour in your breath), and to the extent that solid and liquid human waste are useful in producing new food, it's a nutrient fertilisers which enable energy conversion of sunlight to fuel, and not the primary energy input itself (sunlight).
Recycling all the materials you mentioned costs 'energy' (to use your terminology). The same for food: we can use used-up food and a lot of energy and grow new food.
The process for 'recycling' wood is basically the same that for recycling food: you grow some plants. The waste products of used up wood are also basically the same as those for used up food.
---
In any case, I don't see how any of this makes food more special than eg petrol or sunlight?
And you can argue that food is only useful, if we have air, ie oxygen to burn it with.
You could argue that water being so cheap is exactly what you'd expect when the surplus value of water production is sky-high: people only spend a fraction of their income on both food and water production, exactly because the surplus is so high.
Thus if water isn't the basis for all our livelihoods, neither is food production these days.
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.
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.