@cstross 48 KiB? Ha! 😉

I used Visicalc on a *32 KiB* CBM 8032!

@bumpus @june I've dug on this aspect (abstractions vs. specializations in engineering) in this message https://social.platypush.tech/@blacklight/110804405853563768.

You are right, when you optimize you usually specialize and lose abstractions, which means losing the general-purpose aspect.

But the opposite is also true - create too many abstractions, and you start introducing more cognitive burden, besides the performance overhead.

I feel like there's a "sweet spot" for general-purpose software.

Fabio Manganiello

2023-07-30 18:17:36

good point there.

I've looked at some of the Assembly code that was written at NASA in the 1960s and 1970s (the one for the Apollo programs was also open-sourced a while ago).

I was impressed by how "embedded" it was, with literally zero room for abstractions. The code was tightly coupled to the hardware. Each single bit was crafted and optimized for its specific purpose on that specific hardware.

You can do amazing things once you remove all the abstractions. You can get very creative on how to optimize resources if you know that your code will only run on one specific piece of hardware, for a very specific purpose.

Let's not forget that until at least the early 1980s most of the computers didn't even agree on the "word size", and even on the byte as the minimum quantity of addressable information.

As we started seeking for compatibility, more general-purpose hardware and software, lower entry barriers for coding etc., we started introducing abstractions.

Those abstractions came with many advantages - namely lower barriers for coders and greater portability. Also, decoupling software from hardware meant that you no longer have to be a electronic engineer (or an engineer who deeply understands the architecture the software is running on) in order to code. But I also feel like there's an inflection point, and once we pass it those advantages start to fade.

It's obvious why a compiler that can digest the same piece of C/C++ code and produce an exe on different architectures is a useful abstraction. Same goes for a virtual machine that can run the code on any architecture without recompiling it from scratch.

But when building a basic website ends up creating a node_modules folder of 200 MB, requires the developer to be familiar with npm/yarn/gulp pipelines, transpiling etc., and maybe also with deploying their code to a Kubernetes cluster running on somebody's private cloud, I wonder if we've already passed that inflection point.

@cybeej @lorq Do you (both) think it has to do with the commercialisation of education itself?

I keep seeing all those certifications and courses for and by companies and their products as well as universities and schools being filled with tech by either Google, Apple or Microsoft, and I wonder whether studying informatics is the only way nowadays to actually get taught necessary basic skills to understand the technology you're working with.

good point there.

I've looked at some of the Assembly code that was written at NASA in the 1960s and 1970s (the one for the Apollo programs was also open-sourced a while ago).

I was impressed by how "embedded" it was, with literally zero room for abstractions. The code was tightly coupled to the hardware. Each single bit was crafted and optimized for its specific purpose on that specific hardware.

You can do amazing things once you remove all the abstractions. You can get very creative on how to optimize resources if you know that your code will only run on one specific piece of hardware, for a very specific purpose.

Let's not forget that until at least the early 1980s most of the computers didn't even agree on the "word size", and even on the byte as the minimum quantity of addressable information.

As we started seeking for compatibility, more general-purpose hardware and software, lower entry barriers for coding etc., we started introducing abstractions.

Those abstractions came with many advantages - namely lower barriers for coders and greater portability. Also, decoupling software from hardware meant that you no longer have to be a electronic engineer (or an engineer who deeply understands the architecture the software is running on) in order to code. But I also feel like there's an inflection point, and once we pass it those advantages start to fade.

It's obvious why a compiler that can digest the same piece of C/C++ code and produce an exe on different architectures is a useful abstraction. Same goes for a virtual machine that can run the code on any architecture without recompiling it from scratch.

But when building a basic website ends up creating a node_modules folder of 200 MB, requires the developer to be familiar with npm/yarn/gulp pipelines, transpiling etc., and maybe also with deploying their code to a Kubernetes cluster running on somebody's private cloud, I wonder if we've already passed that inflection point.

That's not really the only option though, #CommonLisp performs within a magnitude of C/C++ with barely any effort (maybe just a few type annotations in some loops).

There are other structural problems with cpython (not sure if inherent to the language though or just a cpython problem) because it performs significantly worse than many other bytecode VM languages (like #Racket).

(I'm very willing to believe it's just cpython being a bad compiler/implementation)