I like this bit because it really is a common answer whenever someone complains about how maddening/inefficient some tooling is nowadays. Like, why the fuck is this [OS EXCLUSIVE] application made with electron and running its own node server? It’s what “they know”, fuck it if there are alternatives that could do a much better job
About half a year ago I stumbled upon some front-end web developers who did not know that you can create a website without a deployment tool and that you don’t need any JavaScript at all, even when the website takes payment.
Said front-end dev is probably too young to have perused the 2004 and earlier internet. Javascript already existed, but it was more of an afterthought. When a site wanted to be flashy and visual, it used Flash, but I don’t think any halfway decent site was crazy enough to leave the payment inside a Flash page
I like this bit because it really is a common answer whenever someone complains about how maddening/inefficient some tooling is nowadays.
I don’t think this is a valid take. What we see in these vague complains about levels of abstraction is actually an entirely different problem: people complaining that they don’t understand things, and they feel the cognitive load of specific aspects is too much for them to handle.
If the existing layers of abstraction were actually a problem and they solved nothing, and if removing them would solve everything, it would be trivial to remove them and replace them with the simpler solutions these critics idealize.
I think that it’s because a) the abstraction does solve a problem, and b) the idealized solutions aren’t actually all that simple.
But I still agree with the article because I also think that a) the problem solved by the added abstraction isn’t practical, but emotional, and b) the idealized solutions aren’t all that complex, either.
It seems to me that many devs reach immediately for a tool or library, rather than looking into how to create their own solution, due more to fear of the unknown than a real drive for efficiency. And while learning the actual nuts and bolts of the task is rarely going to be the faster or easier option, it’s frequently (IMO) not going to be much slower or more difficult than learning how to integrate someone else’s solution. But at the end of it you’ll have learned a lot more than you would’ve by using a tool or library.
Another problem in the commercial world is accountability to management.
Many decades ago there used to be a saying in tech: “No-one ever got fired for buying IBM.'” What that meant was that even if IBM’s solution was completely beaten by something offered by one of their competitors, you personally may still be better off overall going with IBM. The reason being, if you went with the competitor, and everything worked out, the less tech-savvy managers were just as likely to pat you on the back as to assert that the IBM solution would’ve been even better. If the competitor’s solution didn’t meet expectations, you’d be hauled over the coals for going with some cowboy outfit instead of good old reliable IBM. Conversely, if you went with IBM and everything worked, everyone would be happy. But if you chose IBM and the project failed, it’d be, “Well, it’s not your fault. Who could’ve predicted that IBM wouldn’t come through?”
In the modern era, replace “IBM” with the current tool-of-the-month, and your manager will be demanding to know why you’re wasting time reinventing the wheel on the company’s dime.
I think that it’s because a) the abstraction does solve a problem, and b) the idealized solutions aren’t actually all that simple.
I’d go a step further and state quite bluntly that these critics do not even understand the problem that the abstraction solves, and their belief is formed based on their poor and limited understanding of the problem space.
Everyone can come up with simpler alternatives if they throw most requirements out of the window. That’s basically the ages old problem caused by major rewrites and their expected failure once the unknowns start to emerge.
But I still agree with the article because I also think that a) the problem solved by the added abstraction isn’t practical, but emotional, and b) the idealized solutions aren’t all that complex, either.
Hard disagree.
There is not a single technical argument refuting these abstraction layers; only ignorance of the problems they solve. It’s easy to come up with simpler solutions if you leave out whole sets of hard requirements.
The idealized solution never leaves the conceptual stage because the idealized solution is never thought all the way through and the key requirements are never gathered. That’s when the problems solved by the abstraction layers rear their head, and what forces these critics to face the fact that their proposed solution is inconveniently converging to the real world solution they are complaining about, but that they are reinventing the wheel poorly.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
I like this bit because it really is a common answer whenever someone complains about how maddening/inefficient some tooling is nowadays. Like, why the fuck is this [OS EXCLUSIVE] application made with electron and running its own node server? It’s what “they know”, fuck it if there are alternatives that could do a much better job
Said front-end dev is probably too young to have perused the 2004 and earlier internet. Javascript already existed, but it was more of an afterthought. When a site wanted to be flashy and visual, it used Flash, but I don’t think any halfway decent site was crazy enough to leave the payment inside a Flash page
I don’t think this is a valid take. What we see in these vague complains about levels of abstraction is actually an entirely different problem: people complaining that they don’t understand things, and they feel the cognitive load of specific aspects is too much for them to handle.
If the existing layers of abstraction were actually a problem and they solved nothing, and if removing them would solve everything, it would be trivial to remove them and replace them with the simpler solutions these critics idealize.
Except that never happens. Why is that, exactly?
I think that it’s because a) the abstraction does solve a problem, and b) the idealized solutions aren’t actually all that simple.
But I still agree with the article because I also think that a) the problem solved by the added abstraction isn’t practical, but emotional, and b) the idealized solutions aren’t all that complex, either.
It seems to me that many devs reach immediately for a tool or library, rather than looking into how to create their own solution, due more to fear of the unknown than a real drive for efficiency. And while learning the actual nuts and bolts of the task is rarely going to be the faster or easier option, it’s frequently (IMO) not going to be much slower or more difficult than learning how to integrate someone else’s solution. But at the end of it you’ll have learned a lot more than you would’ve by using a tool or library.
Another problem in the commercial world is accountability to management.
Many decades ago there used to be a saying in tech: “No-one ever got fired for buying IBM.'” What that meant was that even if IBM’s solution was completely beaten by something offered by one of their competitors, you personally may still be better off overall going with IBM. The reason being, if you went with the competitor, and everything worked out, the less tech-savvy managers were just as likely to pat you on the back as to assert that the IBM solution would’ve been even better. If the competitor’s solution didn’t meet expectations, you’d be hauled over the coals for going with some cowboy outfit instead of good old reliable IBM. Conversely, if you went with IBM and everything worked, everyone would be happy. But if you chose IBM and the project failed, it’d be, “Well, it’s not your fault. Who could’ve predicted that IBM wouldn’t come through?”
In the modern era, replace “IBM” with the current tool-of-the-month, and your manager will be demanding to know why you’re wasting time reinventing the wheel on the company’s dime.
I’d go a step further and state quite bluntly that these critics do not even understand the problem that the abstraction solves, and their belief is formed based on their poor and limited understanding of the problem space.
Everyone can come up with simpler alternatives if they throw most requirements out of the window. That’s basically the ages old problem caused by major rewrites and their expected failure once the unknowns start to emerge.
Hard disagree.
There is not a single technical argument refuting these abstraction layers; only ignorance of the problems they solve. It’s easy to come up with simpler solutions if you leave out whole sets of hard requirements.
The idealized solution never leaves the conceptual stage because the idealized solution is never thought all the way through and the key requirements are never gathered. That’s when the problems solved by the abstraction layers rear their head, and what forces these critics to face the fact that their proposed solution is inconveniently converging to the real world solution they are complaining about, but that they are reinventing the wheel poorly.
I’ll get to it soon. /s