It's interesting to see the Apple aesthetic of abstracting and hiding things from the user in general is many decades old and was there since the beginning. No command line, paths, or even a simple debugger is present. (Compare MS-DOS' DEBUG and EDLIN, which were included in version 1.0.)
Apple's way is inherently more idiot-proof, but makes a sharper division between developers and users. PC magazines in the late 80s and early 90s had articles consisting of short assembly-language programs the user could create with DEBUG, and I think in general it encouraged somewhat more open culture of tinkering and learning with their machines than Apple's philosophy of opaqueness.
It wasn't anything like the walled gardens of today, but I remember the effort required to even get started writing applications (or just modifying existing ones) on the Mac was significantly higher than the PC.
While the UNIX and Windows GUIs of the time were abstractions on top of command lines, thr Mac GUI of the time WAS the native UI. It was literally burned into the ROM of the machine. There was nothing lower they were hiding aside from the machine code.
There was a debugger BTW, the very limited programmer's key (which most users only used to kill the current app if it crashed). It could be replaced with the more powerful Macsbug.
Having the UI code in ROM doesn't preclude (and might actually benefit) shipping a simple but versatile sort of debugging tool with the OS. But Apple decided against doing so, making the system more appliance-like overall.
DOS's DEBUG isn't just a debugger; it also functions as a disk editor, hex editor, memory inspector, and general "system inspecting/tinkering" tool.
There's an old deep division between people who think everyone ought to learn the depths of a computer and people who think that's unreasonable and maybe not even good.
I used to be in the former camp and have moves to the latter. Consider cars. There are lots of "car people" who love to tinker with them, but most people just want to get where they are going.
It would be unreasonable to expect everyone to be a car expert, and it would also mean everyone would have to spend the time required to learn it. That would cut into time spent doing other things, which would be narrowing and wasteful. Instead of composing music or starting businesses or writing novels, people would be futzing with cars.
There's a difference between "not needing to" and "explicitly discouraged from", and while I think computers should be designed for the former, the latter is what I find more troubling.
I dunno. If my car were sealed that would be okay with me as long as this development were coincident with less maintenance or lower cost. There's not likely to be many user serviceable parts of an electric car.
If you are a computer person there is more and more diversity of cheap hackable stuff out there today than ever before. The enthusiast market and the general market are not the same and are likely to keep diverging. Same has happened with cars.
I agree. It seems to me that as a class of product matures, it becomes less necessary for people to understand the intricacies of its implementation. And then there will inevitably be those that lament that loss of understanding and widespread tinkering.
Which is why cars, which are now 100-year-old technology, come with their hoods welded shut and you need special manufacturer-authorized tools to even change the oil.
The Apple II was definitely more open. It was physically open in the sense that one could pop open the top and add cards to it. It was also open in the software sense as one had to write 6502 assembly code to get the most out of it.
Inside Macintosh had a high-level description of the hardware, explained the memory map and how to call OS calls, and had good descriptions of the various data structures, but didn't go as far as including full schematics or a full listing. It also was a separate thing to buy, so most users wouldn't have it.
The Apple IIGS was an awkward collision of the Apple II and Macintosh approaches.
Edit: This comment originally went on to briefly describe the Apple IIGS, then tell a long-winded personal story. But I've moved that to its own blog post:
First, as already pointed out by others, the Mac was really a graphical system. The Finder was the shell.
But there were other tools, too. E.g., ResEdit for manipulating program resources (I customized many programs using this, back in the day), eventually there was also an enhanced version including an assembler/disassembler. Also, there was the Mac Programmer Workshop (MPW) including all the developer tools, and it came for free. And inside this package was finally the MPW shell, a true shell for the Mac by Apple. (But this was now quite the other way round an indirect access to the machine.) It should be noted that the MPW wasn't available for early Macs, since there wasn't room to do actual programming. Commonly, the LISA (or "Mac XL") was used for this.
[Edit] Moreover, it was amazingly simple to change the configuration of the Mac, especially with System 7 and higher. Just drag things in out of the System Folder and you had already set up the system to your exact needs.
Apple's way is inherently more idiot-proof, but makes a sharper division between developers and users. PC magazines in the late 80s and early 90s had articles consisting of short assembly-language programs the user could create with DEBUG, and I think in general it encouraged somewhat more open culture of tinkering and learning with their machines than Apple's philosophy of opaqueness.
It wasn't anything like the walled gardens of today, but I remember the effort required to even get started writing applications (or just modifying existing ones) on the Mac was significantly higher than the PC.