#politics #computers #business 2023q4 2023q3 2023q2 2023q1 2022q4 2022q3 2022q1 2021q1 2020q3 2020q1 2019q4 2019q3 2019q2 2019q1 2018q3 2018q2
==> Unixsheikh says, “We have used too many levels of abstractions and now the future looks bleak”.
The article anticipates a “Yes, let’s all go back to coding in assembly!” critique and responds.
For a really, really long time after high-level languages had become mainstream, you did still have to know assembly to be a programmer, even if you did most of your work in, say, C, or Pascal. That’s because compilers for high-level languages and their debugging tools were initially a “leaky” abstraction. When your programme failed, you had to know assembly to figure out what went wrong and work your way back to what you could do in your high-level language to fix the problem. Now, compilers and debugging tools have become so good that those days are mostly gone, and you don’t need to know assembly any more (for most practical intents and purposes).
The lesson here is that when a new abstraction hits the scene, you can anticipate that it will take a long time until the technology is so reliable that you really don’t need to understand the lower-level stuff. Meanwhile, you’re dealing with leaky abstraction.
Today, we pile on layer upon layer upon layer of leaky abstraction without ever giving it the time it needs to mature. We’re designing for shortening the amount of time a developer spends on getting something done, under the misguided assumption that the developer will never leave the “happy path” where everything works. This neglects that developers spend most of their time debugging situations that don’t work. Usually, if you make the “happy path” time more productive with a side effect of making the “unhappy path” time less productive, that amounts to a net negative, and that’s the big problem.
#computers | Oct-21 2023
#politics #computers #business 2023q4 2023q3 2023q2 2023q1 2022q4 2022q3 2022q1 2021q1 2020q3 2020q1 2019q4 2019q3 2019q2 2019q1 2018q3 2018q2