This is the right perspective, and you should continue to pursue your own projects using the languages that make you most productive. Don't study what does not interest you.

The problem is if you change majors to engineering, the first courses are not going to teaching you what is exciting and flashy, they are going to teach you the very boring, mostly unmotivated maths that you need later to build bridges that won't collapse. SICP represented the engineering approach, by starting from first principles (more logical than mathematical, but appealing for similar reasons) and then proceeded to an understanding of interpreters, compilers, register machines, and so on. Giving up on SICP meant giving up on the engineering approach which produces programmers, to the software engineering approach, which leaves out the hard parts of engineering and produces software users, who plug together libraries that are written by others.

> Knowledge of the underlying machine is irrelevant.

As you look back on your assembly experience later, you'll realize this is false.

I agree.

I simply think, the assembly model will be replaced.

There will eventually be a new, "better," set of principles. For reasoning about library gluing.

> Knowledge of the underlying machine is irrelevant.

> As you look back on your assembly experience later, you'll realize this is false.

Better to clarify: truly deep knowledge of the underlying machine is irrelevant.

At this point, I'd say I'm immensely richer from "thinking" about assembly. Nowhere else would I have truly learnt about CPU cycle times to copy data from register to register to call stack, and back. The concept of "time to copy data" is highly present in networking and other fields.

Important to know that "C" and other high level languages abstract over it.

I'm not entirely sure my knowledge of JTAG debugging/Rust borrow checker is ever going to be substantially useful. The time/benefit equation of doing all that work was... less than ideal.

In hindsight, maybe an afternoon of assembly copying data from place to place, seems like "all" the big picture learning I needed?

Then again. Maybe I invested far more time than undergraduate courses spend on the topic, regardless.

On the JTAG points, I (sadly) don't have enough hardware hobbies under my belt to appreciate that pain. On the Rust borrow checker front, I too share this same sunk cost and the have the same lingering regret. Uniqueness types have been done before and better, but it's interesting for systems programming, and already better than C++. Just don't do applications work in it, unless you would pick C or C++ for the same job.

I don't like "shaming" people for not learning "fundamentals", and I believe people should learn whatever they want to at their own pace, but since you asked --

Sometimes you run into bugs (or leaky abstractions) that force you to go down a couple layers. Perhaps you run into a bug in the C/C++ code of your language's compiler. Sometimes a dependency (written in C of course) of your stack gets a nasty CVE and you need to figure out the implications (often being able to read the patch will help). Ever heard of "Meltdown" and "Spectre"? Those were bugs in CPU design which require understanding of how low level operations work.

In junior roles nobody will bother you with these questions, but senior devs are expected to know how to understand and deal with these issues if relevant, even if they're normally using a super high level language, because they don't exist in a vacuum, they depend on these low level things to form the whole "stack" so to speak.

In terms of education in schools, time is limited, so there's obviously a need to choose the most relevant topics to focus on. Learning fundamentals has always been at least occasionally useful though. I mean, you could probably do 99% of your job without knowing this stuff and you'll probably even have a great career. Personally, I just hate to feel ignorant about the things I do for a living...

> I truly, truly, cannot see myself using non-garbage compiled programming languages

Unfortunate typo.

For me, an older dev, I felt that knowing assembly and other "not useful" techs had a general positive effect on my skill as a dev.

Does that still resonate at all?

I had a similar trajectory, but would not describe that learning as useless or irrelevant. That knowledge informs my every decision, and understanding hardware or algorithms is why I'm sometimes able to find a better technique or abstraction for a project than other folks. Plus it's just more satisfying.

Yes, this fits my understanding and know I'm not judging you or people like you. I understand this because I'm the same way, but from my own era.

In truth, I don't hold my view strongly.

Software is a YOUNG field.

An undiscovered ocean of knowledge absolutely awaits us.

Far more knowledge remains to be found. Far more focused on "what haven't I learnt."