Comment by ken
6 years ago
The first example I thought of was on the C=64, with assembly language. The second was on MS-DOS with C++ and assembly language.
> Creating something useful using nothing but the raw materials of ideas, with essentially limitless possibilities, with your own creativity as the only physical limit on what's possible.
As soon as there's an OS and compiler and runtime in between me and the computer, this all goes out the window. It's an artificial world with pre-built materials, and limitations everywhere you turn, and 99% of the ideas you work with will be someone else's, and how to fit in with that.
My view of a computer in 2020 is all about the tooling, and I spend the most time on that, because everything I touch is someone else's tooling. The "endlessly fascinating process" that hoodwinked young me into software no longer exists.
I didn't pick up the "C=64 Programmer's Reference Guide" because I mistook it for a business manual, or even because I wanted to build Amazon.com and just needed to write the infrastructure first.
The CPU’s instruction set and machine architecture are just as artificial. Try FPGAs and you can really experiment with non von neumann machines.
But even that is artificially limiting. The tooling makes it nearly impossible to build fully asynchronous designs.
That's technically true but I think it misses the point. A CPU (at least an older one) is simple enough that it can be fully understood by one person. It was probably designed by a very small team. If you want to know if something works, you don't have to read thousands of pages of documentation. You can just try it. Nearly any combination of operations you put together is going to do something.
None of that is true of the big complex language/library/framework/OS stacks we have today. Most of my effort programming today is on something simple to describe in words, but complex to encode in the language's type system, or the framework's classes, or the OS's security model.
I feel that Lisp is the closest I can get to those early systems I grew up with. It's based on symbols rather than bytes but the flexibility and coherence is the same.
Today we have different systems for different needs. You can use an interpreted language like Python to get simplicity or you can use something like Rust where a program essentially doubles as proof of correctness. Strong typing is really about managing complexity as the program grows. This was never an issue on 8-bit micros because there just wasn't that much room to grow anyways.