2 Likes
I think, you really have to watch this to appreciate what the LISA & Co did for us!
Also interesting, a comment regarding the relatively small default memory segment (6K) and that developers (a) resorted to small code modules to work around this and (b) usually grabbed larger memory segments, if available, which (c) is also what drove devlopers to late hours on multi user systems.
This is magnificent. The “compose” editor reminds me very much of the “ed” editor on Unix/Linux, it’s got the same vibe about having to know where you are in the file, although “ed” is of course not tape-based.
Also, I think there’s an Amdahl’s-law-adjacent fail in there? A 10x speed-up in one part of the program will not in general lead to a 10x speed-up in the program as a whole, so his narrative about the cost of the progress bar service call is probably not right – there’s still the arithmetic “overhead” (scare-quotes because of course the arithmetic is not overhead, it’s the point of the program…), and that hasn’t gotten any faster. Amdahl’s law is about parallel speed-ups, but it’s the same principle here.
1 Like
All the LAW’s to improve speed don’t matter, when it comes keyboard input processing.
As long as you processes a keypress quickly, the machine appears fast.
{wait for cache to process line and smile}
Sadly modern software can not follow this this law.
Ben.
1 Like