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 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.
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.