4,428 karma · joined February 6, 2016
Sadly, I've yet to find a viable alternative.
The goal was to explicitly tell people not to bother "just reading it" as one (and by one I mean myself and most people I know, surely there are exceptions) is naturally inclined to do unless something is particularly piquing our interest.
Without engaging in active, conscious effort, syntax that is different than what we're used to (specially something as established as SQL) where the changes aren't groundbreaking at first glance can easily make us dismissive without realizing the benefits. And after seeing it too many times with all kinds of technologies that stray away from the familiar, I just want to prepare the reader so that their judgment can be formed with full use of their faculties rather than a reflex response.
If you engage the syntax with your System 2 thinking (prefrontal cortex, slow, the part of thinking we're naturally lazy to engage) rather than System 1 (automated, instinctual, optimized brain path to things we're used to) you'll most likely find that it is simpler, makes more logical sense so that you're filtering down things naturally like a sieve and composes far better than SQL as complexity grows.
After you've internalized that, imagine the kind of developer tooling we can build on top of that logical structure.
ADSL on wet string: https://www.revk.uk/2017/12/its-official-adsl-works-over-wet...
As a comparison, DX-wise this is no safer and is indeed very similar to the usual idiom in Go for example, where you just concatenate (pre-interpolated) SQL strings. But when you actually want the compiler to prove the correctness of your queries even in a rudimentary way, these .sql file solutions usually (if not, everytime) fail to provide the necessary external checker that processes templates and uses an accurate model of your database and SQL to verify that all used combinations make sense.
The closest thing to a proper take on this I've seen is https://github.com/andywer/squid with https://github.com/andywer/postguard which, although the SQL is inlined in the code, it uses the right approach for verifying correctness as far as I could tell in the little time I experimented with it.
Dynamic SQL.
And voice channels are a convenient feature people prefer rather than handling yet another tool with its own idiosyncrasies.
And voice is not enough, it also needs video and screen sharing. It all needs to be "free" (AKA someone else pay for it) too, or people will keep using Discord.
People should also be able to create their own servers without worrying about technical details, and again, without directly paying for it.
That's how high the bar is.
If you use a lot of VMs, it comes in handy. If you do a lot of heavyweight compilation in parallel, same thing. But at least on Linux, popping 3 VS Code projects and 4 more browsers doesn't even hit 50% utilization.
I'm happy to use a !bang to indicate what kind of response I want. I'm not the average user but people understand the difference between asking your roommate who's right there and asking a professional about something, so this doesn't seem like much of a stretch.
It's no different than a photocopier or a VCR when you're using it for that purpose, it's the end result that matters.
What is a component? A global variable, a pure function, a procedure, an endpoint, a business usecase, a microservice, a microservice fleet?
What is the whole, if not the same list of questions just asked in backwards order?
It gets worse: Once you arbitrarily come up with one definition that you stick with in your project, does the definition you chose leave little to no room for interpretation? Do all kinds of tests that are worth writing fit neatly within those definitions?
Technical terms that are so loosely defined we can do without, for only two things ultimately result from their use: Apathy, or madness.
While this dev you encountered might have had no idea what they were doing, a most charitable explanation is that they may subscribe to the idea that the "unit" is a business usecase within a single service (often a 1:1 correspondence with an endpoint, but sometimes even more than one, e.g. a form upload with a separate signed upload step to a 3rd party service).
FWIW the concept of small/medium/large as presented in the Google testing blog is a much more useful denomination.
Except for basic demand and supply. The more of those "zelenskys" you have around, the less they're worth.
When it comes to these matters, reality is a secondary concern.
It is thus reassuring that given the superficial attractiveness of this trend it is not that popular among the average populace.
It's just reality, it's hard to care about non-problems, specially when fixing them creates real my-problems.
I don't know if this is actually been a problem ever brought to a judge to be honest, but that's the reason why that disclaimer is made and of course, I am not your lawyer.