20 ms·

I founded the mailing list the book was based on. These days I say, Unix went from being the worst operating system available, to being the best operating syste

I founded the mailing list the book was based on. These days I say, Unix went from being the worst operating system available, to being the best operating system available, without getting appreciably better. (which may not be entirely accurate, but don't flame me). And still miss my Lisp Machine. It's not that Unix is really that bad, it's that it has a certain model of computer use which has crowded out the more ambitious visions which were still alive in the 70s and 80s. Much as the web (the Unix of hypertext) crowded out the more ambitious visions of what computational media for intellectual work could be (see the work of Doug Engelbart and Ted Nelson). That's a bigger tragedy IMO. Unix, eh, it's good enough, but the shittiness of the web makes humanity stupider than we should be, at a time when we can ill afford it.

linguae 8y ago
When I discovered Linux and FreeBSD as a 15 year old, I was absolutely amazed by what I saw, coming from the world of Windows with some elementary school memories of the classic Mac OS sprinkled in. My exploring these *nix variants and learning about their development and history led to my decision to major in computer science and pursue a career in systems software research. I still have a high level of respect for people like Ken Thompson, Dennis Ritchie, Bill Joy, and Marshall Kirk McKusick. I had a dream of working for Sun before the Oracle acquisition and working on projects like ZFS. But lately I’ve been studying systems that for whatever reason ended up losing out in the marketplace despite having really interesting design decisions and features that would be welcome today. Although I like the classic Mac OS, NeXT, and the modern macOS, I wish Steve Jobs would have “copied” all of Smalltalk and then added Mac-like touches to it. I also wish that Genera were open-sourced instead of the current situation where it’s difficult to obtain legally and inexpensively. I have a dream of writing a modern OS inspired by Genera, Smalltalk, and Apple’s OpenDoc, but writing a new OS is a major undertaking. Maybe it’s my inner romantic speaking, or maybe I’m just drawn to beautiful things, but I’ve always been attracted to “what could have been” things. Hopefully one day we’ll have a “right thing” OS again, and maybe one day we’ll have an alternative to the Web that isn’t as much of a technology hodgepodge.
- pjmlp 8y ago
  I had a similar path, from MS-DOS 5 / Amiga OS point of view, something like SGI seemed great and I dived into Linux zealotry a couple of years later. But then a rich library at university campus opened my mind to other models of computing and sundenly pure old UNIX wasn't that interesting any longer, only NeXT, which used UNIX compatibility more for winning over Sun's customers than anything else.
- mpweiher 8y ago
  Funny, for me NeXT pretty much was Smalltalk + Mac + Unix. And there were mechanisms for an OpenDoc-like system of embedded content (maybe more like OLE). While the rough idea of OpenDoc was and is appealing, I don't think that version of the idea is actually tenable. Alas, since it was killed, it sort of lives on and occupies that space as an ideal version of the rough idea, rather than as an artefact that can be criticised and improved upon.
kickingvegas 8y ago
Mary Shaw (http://spoke.compose.cs.cmu.edu/shaweb/ http://spoke.compose.cs.cmu.edu/shaweb/) had a backhanded reference to Unix/AT&T Bell Labs as the "New Jersey School of Computing." The misery of it is that it was good enough to get to where computing is now. The downside is that is also what is holding computing back.
ken 8y ago
I'm slightly too young to have lived through it myself, but from what my dad told me, pre-GNU Unix and post-GNU Unix are almost completely different in their user experience. Prior to GNU, Unix (the tools and the kernel) used to simply crash a lot, or drop data. It was not an especially good system in any regard. As the GNU coding standards say: > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. This never really clicked with me because I didn't live through a time when my primary Unix utilities weren't robust. The closest I got was using old (1990's) HP/UX and Solaris and AIX systems where the sysadmins had installed the GNU tools already. All I knew is that I shouldn't use the system tools, because they were worse. Personally, I think what helped Unix succeed is that the implementations were bad but the architecture made it (mostly) possible to improve the implementations piecemeal. Accordingly, the parts that have had the most trouble improving (like X11, and C) are those where the design doesn't allow this.
- pjmlp 8y ago
  Yes, using standard POSIX tools wasn't the best experience of the world. What helped Unix succeed was that originally Bell Labs wasn't allowed to sell it, so they gave it to universities for what was a symbolic price in comparisasion what a standard OS used to cost, alongside its source code. So naturally many stundents from those universities went out and started businesses based on UNIX, like Sun for example. One of the reasons behing the BSD lawsuit was that AT&T got the license to charge for UNIX after Bell Labs was broken down into smaller units and they were trying to kill off those free branches. People have a tendency to gravitate towards free stuff regarless how bad the quality happens to be.
  - x122 8y ago
    Eh, what? At the time (1994) the handbook was written reasonably priced alternatives were MacOS and Windows, both of which froze all the time and had horrible programming environments. AIX, non-free, was notoriously horrible, too. And the Wirth systems that you promote here were actually free. So what exactly is the great stable commercial alternative in the 90s?
pryce 8y ago
It's probably been a long while since you've gone back to it, but The "Worse is Better" chapter in this book seems to show rather amazing foresight; it basically predicts the situation you describe regarding Unix being "the best operating system available without getting appreciably better" and offers compelling reasons why that was likely. 25 years ago. Who the hell does that?
- mpweiher 8y ago
  Richard Gabriel, that's who ;-) I heartily recommend his other writings. In fact, he considers "Worse is Better" some of the worst of his writings, and it is the most successful. ¯\_(ツ)_/¯ Just one that I've gotten a lot of mileage out of is "Habitability and Piecemeal Growth" in Patterns of Software. Lots of other gems in there: Reuse vs. Compression, The Quality Without a Name, etc. EDIT: Forgot the link https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
chrismaeda 8y ago
MT- Here we are 25 years later and now UNIX is the "good" OS. The horror. -Chris
marmshallow 8y ago
Do you have any suggested reading to learn more about the more ambitious visions from the 70s and 80s, and why they didn't pan out?
- jayalpha 8y ago
  Probably likely with the WWW and the very complex competing version. Too complex and takes too long to deliver.In the end, the winner takes it all.
- KineticLensman 8y ago
  Well in some cases it was because conventional hardware caught up. When I arrived at my first job in 1998 we were using Symbolics Lisp machines. Two years later we were using TI microexplorer Lisp cards that were hosted in a Mac IIFx (something like [0]). When I left, two years after that, we were running Procyon Common Lisp on the IIFx itself, with no Lisp co-processor. The old Symbolics machine was booted up occasionally, and in fact had the best diagnostics for the climate conditions in the server room. If the air con failed, the Symbolics would send temperature reports to a remote console before gracefully shutting down while the Sun workstations would just overheat and randomly fail. [0] https://imgur.com/gallery/Vw5agg5 https://imgur.com/gallery/Vw5agg5
  - KineticLensman 8y ago
    Too late to edit - 1998 should be 1988.
  - lispm 8y ago
    Lots of people used Macintosh Common Lisp on Macintosh IIFX machines and later. The 68030 in the FX also enabled a better garbage collector for MCL.
    - KineticLensman 8y ago
      We used Procyon Common Lisp because it was very nicely integrated with the Macintosh - especially for graphics - and had a great CLOS implementation. I used it to reimplement a clunky VAX-based FORTRAN modelling environment that had been developed in-house into a smooth Macintosh app with a graphical node-graph editor. In all of the system development I've done, this had the biggest 'awesome gosh wow' reaction I've ever received from the users.
hyperpallium 8y ago
the meek (=cowards=euniques=unix) shall inherit the earth
avar 8y ago
> And still miss my Lisp Machine[...] This all happened before my time, but having read a lot about the Lisp Machine I'm as interested in the what-ifs of history if it had won out as the next guy. I wonder though how much of the legitimate sentiment in this book is simply raging against a machine that's successful and installed in production. Given widespread commercial use a system where you could modify the running Lisp code of any program down to the kernel would have had its own nightmare stories of sysadmins monkeypatching things in production, and e.g. the perceived shittyness of NFS being replaced by some Lisp-native system where you sent serialized Lisp objects for your program over the wire, with corresponding upgrade hassles if you needed to upgrade a client/server pair.
- tabtab 8y ago
  I really like the concept of Lisp, but just plain find it too hard to read. Part of the problem is that small-scale groupings too closely resemble large-scale groupings. In most production languages, "big blocks" are visually different than "small blocks" (or groupings). For example, in C, parameter statements are grouped within parenthesis. Large scale groupings are done with curly braces. This provides visual cues about scope and intention without first reading each token. Plus it's too easy to "reinvent the language" in Lisp. In C-based languages, the block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent. In Lisp, one can roll their own. It's great if you are the lone reader: you can customize it to fit your head. But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop.
  - lispm 8y ago
    > This provides visual cues about scope and intention without first reading each token. There isn't even a token to read in C. You have to infer what it is by parsing the thing in your head. Well, our visual systems have no problems doing this. The C function definition doesn't have an operator which would help me to identify what it actually is. float square ( float x ) { float p ; p = x * x ; return ( p ) ; } Where in Lisp we have this operator based prefix syntax: (defun square (x) (* x x)) Oh, DEFUN, short for DEFine FUNction, it's a global definition and it defines a global function. Or with types/classes: (defmethod square ((x float)) (the float (* x x))) Oh, DEFMETHOD, DEFine METHOD, so it's a global definition of a method (kind of a function). The names and lists may not tell you much, but to a Lisp programmer it signals the operation and the structure of the code, based on typical code patterns. Once we learned basic Lisp syntax this is the usual pattern for definitions: <definition operator> <name of the thing to be defined> <parameters> <body of definition> Most definitions in Lisp follow that pattern. Function definitions extend/refine this: <define function> <name of function> <parameter list> <declarations> <documentation> <body of definition> Code then has a layout which is always similar - since the layout is hardwired/ supported in editors and Lisp itself (via the pretty printer, which prints code to the terminal according to layout rules). > block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent These are also hardwired in something like Common Lisp. But the general language is differently designed. Common Lisp has relatively few built-in basic syntactic forms (around 30) and the other syntax is implemented as macros. > It's great if you are the lone reader: you can customize it to fit your head Over the decades of Lisp usage a bunch of conventions and some language support for common syntactic patterns have emerged. It is considered good style to follow those patterns. > But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop. That's the same problem everywhere: the new control structure implemented as a Lisp macro is the new control structure in any other language implemented by a bunch of different tools (macros, preprocessor macros, embedded languages, external languages, a web of classes/methods, a C++ template, ...). If you add a new abstraction, there is always a price to pay. In Lisp the new language abstraction often gets implemented as a new macro and may hide the the implementation behind a more convenient form.
coldtea 8y ago
So, unix is like kudzu, if you also could somewhat eat kudzu.
- syn0byte 8y ago
  ...You can. https://www.thekitchn.com/did-you-know-you-can-eat-kudzu-92488 https://www.thekitchn.com/did-you-know-you-can-eat-kudzu-924...

linguae 8y ago

When I discovered Linux and FreeBSD as a 15 year old, I was absolutely amazed by what I saw, coming from the world of Windows with some elementary school memories of the classic Mac OS sprinkled in. My exploring these *nix variants and learning about their development and history led to my decision to major in computer science and pursue a career in systems software research. I still have a high level of respect for people like Ken Thompson, Dennis Ritchie, Bill Joy, and Marshall Kirk McKusick. I had a dream of working for Sun before the Oracle acquisition and working on projects like ZFS. But lately I’ve been studying systems that for whatever reason ended up losing out in the marketplace despite having really interesting design decisions and features that would be welcome today. Although I like the classic Mac OS, NeXT, and the modern macOS, I wish Steve Jobs would have “copied” all of Smalltalk and then added Mac-like touches to it. I also wish that Genera were open-sourced instead of the current situation where it’s difficult to obtain legally and inexpensively. I have a dream of writing a modern OS inspired by Genera, Smalltalk, and Apple’s OpenDoc, but writing a new OS is a major undertaking. Maybe it’s my inner romantic speaking, or maybe I’m just drawn to beautiful things, but I’ve always been attracted to “what could have been” things. Hopefully one day we’ll have a “right thing” OS again, and maybe one day we’ll have an alternative to the Web that isn’t as much of a technology hodgepodge.

pjmlp 8y ago
I had a similar path, from MS-DOS 5 / Amiga OS point of view, something like SGI seemed great and I dived into Linux zealotry a couple of years later. But then a rich library at university campus opened my mind to other models of computing and sundenly pure old UNIX wasn't that interesting any longer, only NeXT, which used UNIX compatibility more for winning over Sun's customers than anything else.
mpweiher 8y ago
Funny, for me NeXT pretty much was Smalltalk + Mac + Unix. And there were mechanisms for an OpenDoc-like system of embedded content (maybe more like OLE). While the rough idea of OpenDoc was and is appealing, I don't think that version of the idea is actually tenable. Alas, since it was killed, it sort of lives on and occupies that space as an ideal version of the rough idea, rather than as an artefact that can be criticised and improved upon.

kickingvegas 8y ago

Mary Shaw (http://spoke.compose.cs.cmu.edu/shaweb/ http://spoke.compose.cs.cmu.edu/shaweb/) had a backhanded reference to Unix/AT&T Bell Labs as the "New Jersey School of Computing." The misery of it is that it was good enough to get to where computing is now. The downside is that is also what is holding computing back.

ken 8y ago

I'm slightly too young to have lived through it myself, but from what my dad told me, pre-GNU Unix and post-GNU Unix are almost completely different in their user experience. Prior to GNU, Unix (the tools and the kernel) used to simply crash a lot, or drop data. It was not an especially good system in any regard. As the GNU coding standards say: > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility. This never really clicked with me because I didn't live through a time when my primary Unix utilities weren't robust. The closest I got was using old (1990's) HP/UX and Solaris and AIX systems where the sysadmins had installed the GNU tools already. All I knew is that I shouldn't use the system tools, because they were worse. Personally, I think what helped Unix succeed is that the implementations were bad but the architecture made it (mostly) possible to improve the implementations piecemeal. Accordingly, the parts that have had the most trouble improving (like X11, and C) are those where the design doesn't allow this.

pjmlp 8y ago
Yes, using standard POSIX tools wasn't the best experience of the world. What helped Unix succeed was that originally Bell Labs wasn't allowed to sell it, so they gave it to universities for what was a symbolic price in comparisasion what a standard OS used to cost, alongside its source code. So naturally many stundents from those universities went out and started businesses based on UNIX, like Sun for example. One of the reasons behing the BSD lawsuit was that AT&T got the license to charge for UNIX after Bell Labs was broken down into smaller units and they were trying to kill off those free branches. People have a tendency to gravitate towards free stuff regarless how bad the quality happens to be.
- x122 8y ago
  Eh, what? At the time (1994) the handbook was written reasonably priced alternatives were MacOS and Windows, both of which froze all the time and had horrible programming environments. AIX, non-free, was notoriously horrible, too. And the Wirth systems that you promote here were actually free. So what exactly is the great stable commercial alternative in the 90s?

pryce 8y ago

It's probably been a long while since you've gone back to it, but The "Worse is Better" chapter in this book seems to show rather amazing foresight; it basically predicts the situation you describe regarding Unix being "the best operating system available without getting appreciably better" and offers compelling reasons why that was likely. 25 years ago. Who the hell does that?

mpweiher 8y ago
Richard Gabriel, that's who ;-) I heartily recommend his other writings. In fact, he considers "Worse is Better" some of the worst of his writings, and it is the most successful. ¯\_(ツ)_/¯ Just one that I've gotten a lot of mileage out of is "Habitability and Piecemeal Growth" in Patterns of Software. Lots of other gems in there: Reuse vs. Compression, The Quality Without a Name, etc. EDIT: Forgot the link https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf

chrismaeda 8y ago

MT- Here we are 25 years later and now UNIX is the "good" OS. The horror. -Chris

marmshallow 8y ago

Do you have any suggested reading to learn more about the more ambitious visions from the 70s and 80s, and why they didn't pan out?

jayalpha 8y ago
Probably likely with the WWW and the very complex competing version. Too complex and takes too long to deliver.In the end, the winner takes it all.
KineticLensman 8y ago
Well in some cases it was because conventional hardware caught up. When I arrived at my first job in 1998 we were using Symbolics Lisp machines. Two years later we were using TI microexplorer Lisp cards that were hosted in a Mac IIFx (something like [0]). When I left, two years after that, we were running Procyon Common Lisp on the IIFx itself, with no Lisp co-processor. The old Symbolics machine was booted up occasionally, and in fact had the best diagnostics for the climate conditions in the server room. If the air con failed, the Symbolics would send temperature reports to a remote console before gracefully shutting down while the Sun workstations would just overheat and randomly fail. [0] https://imgur.com/gallery/Vw5agg5 https://imgur.com/gallery/Vw5agg5
- KineticLensman 8y ago
  Too late to edit - 1998 should be 1988.
- lispm 8y ago
  Lots of people used Macintosh Common Lisp on Macintosh IIFX machines and later. The 68030 in the FX also enabled a better garbage collector for MCL.
  - KineticLensman 8y ago
    We used Procyon Common Lisp because it was very nicely integrated with the Macintosh - especially for graphics - and had a great CLOS implementation. I used it to reimplement a clunky VAX-based FORTRAN modelling environment that had been developed in-house into a smooth Macintosh app with a graphical node-graph editor. In all of the system development I've done, this had the biggest 'awesome gosh wow' reaction I've ever received from the users.

hyperpallium 8y ago

the meek (=cowards=euniques=unix) shall inherit the earth

avar 8y ago

> And still miss my Lisp Machine[...] This all happened before my time, but having read a lot about the Lisp Machine I'm as interested in the what-ifs of history if it had won out as the next guy. I wonder though how much of the legitimate sentiment in this book is simply raging against a machine that's successful and installed in production. Given widespread commercial use a system where you could modify the running Lisp code of any program down to the kernel would have had its own nightmare stories of sysadmins monkeypatching things in production, and e.g. the perceived shittyness of NFS being replaced by some Lisp-native system where you sent serialized Lisp objects for your program over the wire, with corresponding upgrade hassles if you needed to upgrade a client/server pair.

tabtab 8y ago
I really like the concept of Lisp, but just plain find it too hard to read. Part of the problem is that small-scale groupings too closely resemble large-scale groupings. In most production languages, "big blocks" are visually different than "small blocks" (or groupings). For example, in C, parameter statements are grouped within parenthesis. Large scale groupings are done with curly braces. This provides visual cues about scope and intention without first reading each token. Plus it's too easy to "reinvent the language" in Lisp. In C-based languages, the block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent. In Lisp, one can roll their own. It's great if you are the lone reader: you can customize it to fit your head. But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop.
- lispm 8y ago
  > This provides visual cues about scope and intention without first reading each token. There isn't even a token to read in C. You have to infer what it is by parsing the thing in your head. Well, our visual systems have no problems doing this. The C function definition doesn't have an operator which would help me to identify what it actually is. float square ( float x ) { float p ; p = x * x ; return ( p ) ; } Where in Lisp we have this operator based prefix syntax: (defun square (x) (* x x)) Oh, DEFUN, short for DEFine FUNction, it's a global definition and it defines a global function. Or with types/classes: (defmethod square ((x float)) (the float (* x x))) Oh, DEFMETHOD, DEFine METHOD, so it's a global definition of a method (kind of a function). The names and lists may not tell you much, but to a Lisp programmer it signals the operation and the structure of the code, based on typical code patterns. Once we learned basic Lisp syntax this is the usual pattern for definitions: <definition operator> <name of the thing to be defined> <parameters> <body of definition> Most definitions in Lisp follow that pattern. Function definitions extend/refine this: <define function> <name of function> <parameter list> <declarations> <documentation> <body of definition> Code then has a layout which is always similar - since the layout is hardwired/ supported in editors and Lisp itself (via the pretty printer, which prints code to the terminal according to layout rules). > block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent These are also hardwired in something like Common Lisp. But the general language is differently designed. Common Lisp has relatively few built-in basic syntactic forms (around 30) and the other syntax is implemented as macros. > It's great if you are the lone reader: you can customize it to fit your head Over the decades of Lisp usage a bunch of conventions and some language support for common syntactic patterns have emerged. It is considered good style to follow those patterns. > But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop. That's the same problem everywhere: the new control structure implemented as a Lisp macro is the new control structure in any other language implemented by a bunch of different tools (macros, preprocessor macros, embedded languages, external languages, a web of classes/methods, a C++ template, ...). If you add a new abstraction, there is always a price to pay. In Lisp the new language abstraction often gets implemented as a new macro and may hide the the implementation behind a more convenient form.

coldtea 8y ago

So, unix is like kudzu, if you also could somewhat eat kudzu.

syn0byte 8y ago
...You can. https://www.thekitchn.com/did-you-know-you-can-eat-kudzu-92488 https://www.thekitchn.com/did-you-know-you-can-eat-kudzu-924...