The Apple //e was the hacker-friendliest machine ever. It's probably the ideal learning platform for anyone looking to go into computer science, although perhaps not app programming as a career, which requires a narrower skill set and more focus.
Because the Apple ][ was a locked design, folks started poking directly into ROM and RAM locations, for instance directly manipulating system variables, or even jumping into the middle of ROM subroutines. A book called "What's Where in the Apple II" documented almost every known hook.
My mom had that book. She's my hacker role model.
As a result of the way that software interacted, it became virtually impossible for Apple to update the ROMs without breaking popular apps.
The next generation of personal computers all represented different approaches to avoiding this problem by providing well documented entry points while offering no guarantee of long term code stability. IBM made one mistake: They let people hard code the address of video RAM, which is what led to the legendary 640k barrier.
Having BASIC (or another language) built into the machine was a big plus and encouraged people to see continuity between the OS, the hardware and the code.
If that BASIC had to use built-in functions and data-types instead of simply POKE-ing and PEEKING-ing as a de facto interface with the underlying machine code, that would still have been hacker-friendly without being inflexible.
It was such a weird relationship between desktop machines and UNIXes back then. It's like the desktop designers had to re-learn the lessons of UNIX in the small. So much was forgotten.
But lots of us wanted to write Bad Software such as little programs for our own use, or for limited, specialized use by other people. I found the Mac programming docs (Inside Mac) to be impenetrable, and the overhead for writing Hello World enormous.
Then I fell in love with HyperCard. But we all know what happened to that.
I imagine this is a quandary that shows up not in computing, but anywhere that users interact with a single source of definitive rules.
For example, it might be easier for government to erect certain walled gardens... or for companies to do this with their employees, parents with their kids, etc.
It's not that I don't understand their position or view it as probably the best way to herd cats (I mean, "consumers").
But hacker-friendliness is what gets you the top echelon of users drifting toward your hardware and software. As a result, it's a huge (but invisible) business draw.
It should be noted that during this time period, outside of a few affluent districts, virtually all teaching of programming at the K-12 level was done on an ad hoc basis by teachers who volunteered their time and money.
Edit: Not "was" a hacker but "is" a hacker. ;-)
] CALL-151
* !
! 300: LDA 1000
The day I discovered the mini-assembler was absolutely mind-blowing.
I have very fond memories of the Apple //e (and I have some with broken PSUs that I must get around to fixing) I bootstrapped my own assembler on DOS3.3 using the mini-assembler.
On Prodos I bought the full development kit which came with an assembler and a nice debugger. Wrote a Forth for the Apple with help from Loeligers Threaded Interpretive Languages and a copy of Starting Forth by Leo Brodie (both borrowed from the library) good times...
If all you want is LISP, burn it into an EPROM and replace the stock one.
I don't have access to my Apples at the moment, so can't check the details, but I'm now curious to know exactly what might have changed between various II+ - what did others gain that we were missing, or why did we have room for it when they didn't...
Two years later I got a '386 clone, bought Turbo C and all the fun came back at once.