3 ms·

> In fact, the operating systems that run on "old computers" are surprisingly sophisticated and complex. Are they? Or are we just slowly forgetting that everyt

> In fact, the operating systems that run on "old computers" are surprisingly sophisticated and complex. Are they? Or are we just slowly forgetting that everything in modern software is composed of concepts invented pre-1980 (and in fact pre-1970 for the most part)? It's called "Turing's Curse" [0] To clarify, it's the "surprisingly" part that is not true. Certainly the software is sophisticated. What is surprising is how often we think our modern software is "sophisticated". [0] https://www.youtube.com/watch?v=hVZxkFAIziA https://www.youtube.com/watch?v=hVZxkFAIziA EDIT: but, I guess we have done some modern cool stuff with GPUs, consensus algorithms including PoW, and a few cool ML model architectures and training techniques.

swiley 5y ago
I think there was a certian degree of bravery (or foolishness really) that authors of older software had WRT their willingness to couple with certain things (poking registers/DMA with specialized hardware, monkey patching OS components etc.)
handrous 5y ago
We have a lot more layers of abstraction, in the name of productivity. That's certainly more complex, and from a certain point of view, more sophisticated. Meanwhile (I can't be the only one who's noticed this?) it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent. I'm not sure what to make of that.
- retrac 5y ago
  > it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent. While I can't attest to team performance, I wrote a toy compiler over the long weekend here just now. There were wizards who could do that 30 years ago in a weekend, of course. But I'm not one of them. It occurred to me that if I hadn't used Haskell and some great libraries, built with a compiler that takes hundreds of MB of RAM to run, and was instead using C or assembly even, I'd probably still be trying to get integers parsing correctly. The productivity increase of modern development tools seems real enough to me.
  - swiley 5y ago
    I've written parsers in C, you get used to it. It would probably take you as long to write an integer parser in C as it would take me in Haskell.
    - retrac 5y ago
      It's literally two lines, yet it handles hexadecimal and octal too. :) Of course, if you set up some parser combinators with a nice library in C, it could be a one liner in C too. I figure it's not the language, so much as the libraries and tooling around the language. Back in the day, one couldn't stick a term in the project definition, have the compiler automatically download and assemble a library, then invoke it with one line in the program code, all within 10 seconds. You'd have to start with "is this a digit?" and build up from there, like I did back in my CS courses with Pascal, once upon a time.

swiley 5y ago

I think there was a certian degree of bravery (or foolishness really) that authors of older software had WRT their willingness to couple with certain things (poking registers/DMA with specialized hardware, monkey patching OS components etc.)

handrous 5y ago

We have a lot more layers of abstraction, in the name of productivity. That's certainly more complex, and from a certain point of view, more sophisticated. Meanwhile (I can't be the only one who's noticed this?) it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent. I'm not sure what to make of that.

retrac 5y ago
> it seems like it takes a team 5x as large 2x as long to write a program that does the same thing as some 80s or 90s equivalent. While I can't attest to team performance, I wrote a toy compiler over the long weekend here just now. There were wizards who could do that 30 years ago in a weekend, of course. But I'm not one of them. It occurred to me that if I hadn't used Haskell and some great libraries, built with a compiler that takes hundreds of MB of RAM to run, and was instead using C or assembly even, I'd probably still be trying to get integers parsing correctly. The productivity increase of modern development tools seems real enough to me.
- swiley 5y ago
  I've written parsers in C, you get used to it. It would probably take you as long to write an integer parser in C as it would take me in Haskell.
  - retrac 5y ago
    It's literally two lines, yet it handles hexadecimal and octal too. :) Of course, if you set up some parser combinators with a nice library in C, it could be a one liner in C too. I figure it's not the language, so much as the libraries and tooling around the language. Back in the day, one couldn't stick a term in the project definition, have the compiler automatically download and assemble a library, then invoke it with one line in the program code, all within 10 seconds. You'd have to start with "is this a digit?" and build up from there, like I did back in my CS courses with Pascal, once upon a time.