6 ms·

Where is this "complete and correct" code that came at the expense of being large and complex? I've certainly never seen it.

by toolz 4y ago

User23 4y ago
NASA has written such code.
- toolz 4y ago
  I'm reading over NASA's 10 rules for safety critical code and it's littered with the word simple and keeping things small. I don't think NASA is an example for large and complex at all. Not to mention NASA is known for many of the the most famous software bugs in history, but I'm guessing that's just related to space exploration more than anything particularly novel/incorrect about their approach to software.
ajross 4y ago
Multics. The Unix philosophy (and name) is a direct response to the failure of Multics. And they were right. It's true that by the 80's, we were starting to see real competition. But really what distinguished Unix in the 70's was that it worked at all on the kind of interactive hardware its users wanted to buy. Most stuff was either missing huge features, aimed at IBM style batch environments, or priced out of reach. Unix worked.
- eternityforest 4y ago
  It worked because it was necessary. And occasionally still is. But we have workable alternatives now. We have bigger teams with version control servers, static analysis, and safer languages. We can make it general enough to be attract 1000 developers, then those 1000 developers can all decide to go for correctness in all cases with high feature richness. "Software" barely existed at the time of UNIX. UNIX philosophy basically says "Don't write software, assemble it onsite as needed just for one task". UNIX was amazing, and provided a great base to eventually evolve Linux and co, but it no longer seems to be the only way to do things.
  - trasz 4y ago
    >We have bigger teams with version control servers, static analysis, and safer languages. That’s why enterprise software is such a crap - what you are describing is part of a problem, not a solution. Also, at that time big teams definitely existed: see OS/360 and Fred Brooks’ book. High level languages were there too, eg Lisp. What you want to replace Unix with is exactly what Unix itself had replaced.
    - eternityforest 4y ago
      I'm not sure I've everyone been on the user side of true "enterprise software" since I don't do business side work, but basically all the commercial-inspirex stuff is made with the same idea. Feature rich, high level languages, high integration, opinionated workflow. Krita, FreeCAD, LibreOffice, Ardour, browsers, and VSCode mostly all seem to fully ignore anything UNIXy, and are amazing. I don't really see software doing significant amounts of sucking these days. When I do, it's usually because it's subscription or cloud dependent, or because they left out something important for simplicity's sake. Software basically runs the entire modern world. The expectations of computers are no longer to just "Compute". Everything is interactive, embedded systems are everywhere, and the stuff that really is "Computing" is often GPU accelerated or distributed. Computers were their own separate thing in the UNIX era. They weren't fully replacements for any other device yet, outside of research. People used real filing cabinets and records or cassettes. Large complex software enables huge classes of applications that would otherwise have enough friction that nobody would want them, you'd juat get a pen and paper rather than reading a man page to do what should be a 4 second task. And when you have dozens or hundreds of them, not many people are going to want to learn them all, and actively go out of their way to stay current with them. People complained CONSTANTLY about computers into the early 2000s. Somehow it was always a challenge, you always had to spend time figuring out how to get the computer to do what you wanted, and you might often wonder if it was worth using them at all. UNIX users have a very different perspective from average users. They spend a lot of time dealing with text and processing data, and mostly like computers for academic reasons or for tasks that are completely impractical by hand. Not many of them seem to actually want an ubiquitous IoT type future with an app for anything. With an appreciation of simplicity seems to come a love of the analog, because that's the ultimate UNIX philosophy, not using a computer at all.
- chasil 4y ago
  Indeed, Microsoft Xenix was implemented on 80286 processors, which allowed a maximum of 64k of program text per process. The POSIX shell was designed to fit within that limit.
linguae 4y ago
Richard Gabriel's "The Rise of Worse is Better," written around the same time period the Unix-HATERS Handbook was written, gives some clues. Unix was contrasted with environments such as Scheme (which is rather small, but because it's designed as a "crown jewel"), Common Lisp (the exemplar of a "big complex system" that is complete and correct, but large and complex), and the ITS operating system (https://en.wikipedia.org/wiki/Incompatible_Timesharing_System https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste...). Thankfully there are many open-source Scheme and Common Lisp implementations, and ITS is also available as open source (https://github.com/PDP-10/its https://github.com/PDP-10/its). Of course, modern Unix-like systems these days are large and complex, though Plan 9 and Inferno are quite architecturally refined, reducing some of the complexities that you'll see in contemporary Unix-like systems.
- toolz 4y ago
  Correct and complete systems are large and complex, sure, but they are almost always comprised of small and simple parts. Unix in the 90s was around 300k LOC, hardly a small and simple system, but if we're to believe the author, it must have been made of small and simple parts.
- skissane 4y ago
  > ITS is also available as open source (https://github.com/PDP-10/its https://github.com/PDP-10/its) Sometimes I wonder, if you wanted to create an operating system like ITS for more modern platforms, what it would look like? ITS is written in PDP-10 assembly, what if someone wrote a compiler which read in PDP-10 assembly language and spit out C code? Could that be a first step to porting it? It is surely a lot more complicated than that. It contains self-modifying code, which would obviously break that translation strategy. A lot of hardware-specific code would have to be rewritten. 6 character filenames without nested directories might have been acceptable in the 1970s, but few could endure it today. A multi-user system with a near-total absence of security was acceptable back then, obviously not in today's very different world. ITS does have some interesting features contemporary systems don't: A process can submit commands to be run by the shell that spawned it – actually MS-DOS COMMAND.COM also had that feature (INT 2E), but I haven't seen anything else with it. A Unix shell could implement this by creating a Unix domain socket, and passing its path to subprocesses via an environment variable–but I've never seen that done. Another was that a program being debugged could call an API to run commands in its own debugger – I've never seen that in any other debugger, although I suppose you could write a GDB plugin to implement it (have a magic do-nothing function, then a GDB Python script sets a breakpoint on that function, and interprets its argument as commands for GDB.) Actually, in ITS these two features were the exact same feature, since the debugger was used as the command shell. Another was that a program had named subprocesses (by default the subprocess name was the same as the executable name, but it didn't have to be.) Compare that to most Unix shells, where it is easy to forget what you are running as background jobs 1, 2 or 3.

Where is this "complete and correct" code that came at the expense of being large and complex? I've certainly never seen it.

by toolz 4y ago

Where is this "complete and correct" code that came at the expense of being large and complex? I've certainly never seen it.

User23 4y ago

NASA has written such code.

toolz 4y ago
I'm reading over NASA's 10 rules for safety critical code and it's littered with the word simple and keeping things small. I don't think NASA is an example for large and complex at all. Not to mention NASA is known for many of the the most famous software bugs in history, but I'm guessing that's just related to space exploration more than anything particularly novel/incorrect about their approach to software.

ajross 4y ago

Multics. The Unix philosophy (and name) is a direct response to the failure of Multics. And they were right. It's true that by the 80's, we were starting to see real competition. But really what distinguished Unix in the 70's was that it worked at all on the kind of interactive hardware its users wanted to buy. Most stuff was either missing huge features, aimed at IBM style batch environments, or priced out of reach. Unix worked.

eternityforest 4y ago
It worked because it was necessary. And occasionally still is. But we have workable alternatives now. We have bigger teams with version control servers, static analysis, and safer languages. We can make it general enough to be attract 1000 developers, then those 1000 developers can all decide to go for correctness in all cases with high feature richness. "Software" barely existed at the time of UNIX. UNIX philosophy basically says "Don't write software, assemble it onsite as needed just for one task". UNIX was amazing, and provided a great base to eventually evolve Linux and co, but it no longer seems to be the only way to do things.
- trasz 4y ago
  >We have bigger teams with version control servers, static analysis, and safer languages. That’s why enterprise software is such a crap - what you are describing is part of a problem, not a solution. Also, at that time big teams definitely existed: see OS/360 and Fred Brooks’ book. High level languages were there too, eg Lisp. What you want to replace Unix with is exactly what Unix itself had replaced.
  - eternityforest 4y ago
    I'm not sure I've everyone been on the user side of true "enterprise software" since I don't do business side work, but basically all the commercial-inspirex stuff is made with the same idea. Feature rich, high level languages, high integration, opinionated workflow. Krita, FreeCAD, LibreOffice, Ardour, browsers, and VSCode mostly all seem to fully ignore anything UNIXy, and are amazing. I don't really see software doing significant amounts of sucking these days. When I do, it's usually because it's subscription or cloud dependent, or because they left out something important for simplicity's sake. Software basically runs the entire modern world. The expectations of computers are no longer to just "Compute". Everything is interactive, embedded systems are everywhere, and the stuff that really is "Computing" is often GPU accelerated or distributed. Computers were their own separate thing in the UNIX era. They weren't fully replacements for any other device yet, outside of research. People used real filing cabinets and records or cassettes. Large complex software enables huge classes of applications that would otherwise have enough friction that nobody would want them, you'd juat get a pen and paper rather than reading a man page to do what should be a 4 second task. And when you have dozens or hundreds of them, not many people are going to want to learn them all, and actively go out of their way to stay current with them. People complained CONSTANTLY about computers into the early 2000s. Somehow it was always a challenge, you always had to spend time figuring out how to get the computer to do what you wanted, and you might often wonder if it was worth using them at all. UNIX users have a very different perspective from average users. They spend a lot of time dealing with text and processing data, and mostly like computers for academic reasons or for tasks that are completely impractical by hand. Not many of them seem to actually want an ubiquitous IoT type future with an app for anything. With an appreciation of simplicity seems to come a love of the analog, because that's the ultimate UNIX philosophy, not using a computer at all.
chasil 4y ago
Indeed, Microsoft Xenix was implemented on 80286 processors, which allowed a maximum of 64k of program text per process. The POSIX shell was designed to fit within that limit.

linguae 4y ago

Richard Gabriel's "The Rise of Worse is Better," written around the same time period the Unix-HATERS Handbook was written, gives some clues. Unix was contrasted with environments such as Scheme (which is rather small, but because it's designed as a "crown jewel"), Common Lisp (the exemplar of a "big complex system" that is complete and correct, but large and complex), and the ITS operating system (https://en.wikipedia.org/wiki/Incompatible_Timesharing_System https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste...). Thankfully there are many open-source Scheme and Common Lisp implementations, and ITS is also available as open source (https://github.com/PDP-10/its https://github.com/PDP-10/its). Of course, modern Unix-like systems these days are large and complex, though Plan 9 and Inferno are quite architecturally refined, reducing some of the complexities that you'll see in contemporary Unix-like systems.

toolz 4y ago
Correct and complete systems are large and complex, sure, but they are almost always comprised of small and simple parts. Unix in the 90s was around 300k LOC, hardly a small and simple system, but if we're to believe the author, it must have been made of small and simple parts.
skissane 4y ago
> ITS is also available as open source (https://github.com/PDP-10/its https://github.com/PDP-10/its) Sometimes I wonder, if you wanted to create an operating system like ITS for more modern platforms, what it would look like? ITS is written in PDP-10 assembly, what if someone wrote a compiler which read in PDP-10 assembly language and spit out C code? Could that be a first step to porting it? It is surely a lot more complicated than that. It contains self-modifying code, which would obviously break that translation strategy. A lot of hardware-specific code would have to be rewritten. 6 character filenames without nested directories might have been acceptable in the 1970s, but few could endure it today. A multi-user system with a near-total absence of security was acceptable back then, obviously not in today's very different world. ITS does have some interesting features contemporary systems don't: A process can submit commands to be run by the shell that spawned it – actually MS-DOS COMMAND.COM also had that feature (INT 2E), but I haven't seen anything else with it. A Unix shell could implement this by creating a Unix domain socket, and passing its path to subprocesses via an environment variable–but I've never seen that done. Another was that a program being debugged could call an API to run commands in its own debugger – I've never seen that in any other debugger, although I suppose you could write a GDB plugin to implement it (have a magic do-nothing function, then a GDB Python script sets a breakpoint on that function, and interprets its argument as commands for GDB.) Actually, in ITS these two features were the exact same feature, since the debugger was used as the command shell. Another was that a program had named subprocesses (by default the subprocess name was the same as the executable name, but it didn't have to be.) Compare that to most Unix shells, where it is easy to forget what you are running as background jobs 1, 2 or 3.