9 ms·

The basic point is right, but I think a lot of the details are off. The core idea is composition. A system is compositional if you can build it from small reusa

The basic point is right, but I think a lot of the details are off. The core idea is composition. A system is compositional if you can build it from small reusable parts. It's one of the key ideas in functional programming, and it's somewhat core to object-oriented programming. (OO is too big to be able to claim their is a consistent philosophy behind it.) But ... firstly, let's stop with the Unix worship. They didn't deliver, even in the domain of the terminal. My copy of `ls` has at least 40 flags (where I stopped counting). Secondly, people have tried composition on the desktop. That's what CORBA, COM, and OLE were all about. They all kinda sucked for various reasons. Finally, the place at which the author arises has been around for as long as Unix: it's Emacs.

pjmlp 3y ago
Not only is COM still around, it is the main delivery mechanism for Windows APIs since Vista. Agree with UNIX worship point, I also had it, I was young and naive, lacking experience in the history of computer systems.
- noelwelsh 3y ago
  Wow, I didn't realise. I haven't paid attention to Windows APIs for a long time. I really thought it would have died a long time ago.
  - pjmlp 3y ago
    That is what people outside Windows keep thinking. After WinDev managed to botch Longhorn efforts, its .NET ideas were redone in COM for Vista, and it has been like that ever since. WinRT/UAP/UWP, is basically COM with a new base interface IInspectable, .NET metadata instead of TLB files, and app boxing. And it is the foundation of WinAppSDK, whose goal is to port UWP subsystem into plain Win32, although their current execution leaves a lot to be desired.
  - dist-epoch 3y ago
    The core of COM is about allowing binary code to be used from any language through a standardized interface. As pjmlp mentioned, this part was very successful and all new Windows APIs are based on it. The COM which failed and which you are thinking about was related to OLE and the idea of embedding Excel sheets inside Photoshop drawings, ...
    - deleted 3y ago
      [deleted]
    - abwizz 3y ago
      > the idea of embedding Excel sheets inside Photoshop drawings, ... that's still a thing isn't it?
      - zweifuss 3y ago
        Microsoft ported OLE 1 to Macintosh, but never OLE Version 2, because Apple guidelines forbid programes to start other programs. Because of that Photoshop had a not supported version of OLE. I don't know if it is still available in up to date Photoshop. On Windows it works both ways with OLE 2.
doctor_eval 3y ago
Let's just be careful what we call Unix though. In SVR4, I don't think "ls" had that many options. It didn't even have colour (not that I would know; my Wyse 60 could only have Green, Orange or White text... and the colour was set in the factory). It's the same for many programs that started small but grew loads of knobs with age. You can't claim that this was the Unix vision, because what we call Unix today isn't even technically Unix. I'm not saying Linux is bad or anything; I'm just pointing out that it's much more organic than Unix ever was, and that the resulting system is not necessarily carefully orchestrated.
- noelwelsh 3y ago
  IMO the problem with the Unix model is not that it's been corrupted over time, but that it was fundamentally flawed from the start. I'm hardly the first to point this out, but sending around unstructured text makes doing some things inordinately hard (imagine writing a separate program to color ls's output, instead of having that as a flag) + going beyond pipes leads to the awful experience of programming in shell.
  - benj111 3y ago
    Ls seems like a bad example. Anything that you'd want to colour, the data should already be there. Further I'm not sure the Unix way inherently requires completely unstructured text
    - rcxdude 3y ago
      Unstructured text is the unix way. You can have pipelines sending other things between your programs (see powershell), but that's definitely not Unix.
      - rakoo 3y ago
        I disagree, the unix way has structure: lines of text each consisting of space-separated fields. The real issue is that sometimes your data has spaces, or even newlines, so the structure quickly isn't enough. And that "sometimes" happens xay more often than it has to, and the escape hatch is a mess.
throwaway31381 3y ago
>But ... firstly, let's stop with the Unix worship. They didn't deliver, even in the domain of the terminal. My copy of `ls` has at least 40 flags GNU is Not Unix. I count 13 flags on both Unix V10 [1] and on Plan 9 [2], its spiritual successor. [1] http://man.cat-v.org/unix_10th/1/ls http://man.cat-v.org/unix_10th/1/ls [2] http://man.cat-v.org/plan_9/1/ls http://man.cat-v.org/plan_9/1/ls
- cpach 3y ago
  I think you’re actually making the point for him here. You are correct that GNU is not Unix. And what version of ls has the most installations? I betcha it’s the ls from GNU Coreutils. I do agree that GNU tools are sometimes too maximalist. But they are also more useful than the minimalist alternatives.
  - abwizz 3y ago
    seems like you agree that the extra flags make sense
    - cpach 3y ago
      In many cases, yes! On my Mac, which has a userland derived from FreeBSD, I have voluntarily installed stuff like GNU Findutils and GNU sed to get that extra functionality.
  - tuukkah 3y ago
    To me, the point is you don't need many flags for ls to be useful. You will learn a few idioms early, such as ls -a and ls -lR but after that, the rest of the flags are nice to haves: if you wish there was a certain feature, you can look it up on the man pages etc. "I wish I could sort by time - oh there's -t"
  - throwaway31381 3y ago
    I don't believe GNU's triumph over the BSD derivates was for the most part technical, they just happened to be at the right moment at the right time to ride along Linux's success. A consequence of the proliferation of arguments in the GNU tools is imho that it made the GNU manpages too verbose and information dense to the detriment of their usefulness.
dgb23 3y ago
Composable systems have a very clear property: uniform interfaces. CLI flags are typically arbitrary. What if they weren’t? How would they look like?
- throw16180339 3y ago
  PowerShell has fairly uniform interfaces.
mannykannot 3y ago
Yes, ls does have a lot of flags, but how did it get them, and what are the alternatives? It got them to satisfy real needs, and using flags, especially when combined with having man at your fingertips, was (and is) a highly effective interface for interactive work. If there is anything to be learned from the proliferation of command-line flags, it might be that one should not attribute too much significance to a vague aphorism such as "do one thing, and do it well."
docfort 3y ago
I agree that composition is the core idea and I was disappointed that the author neglected to summarize the idea correctly. Composition is a structured way of describing a unique task using a few common nouns and verbs. But composition needs to be understandable and controllable to be useful. For it to be understandable, it needs to match the user’s anticipated mental model. Now, this isn’t an appeal to an intuitive notion uninformed by user education. But it does need to make logical sense to connect two things together temporarily to solve one task. And that logic needs to come from the user and not the developer. In other words, the developer needs to provide concepts that conform to a user’s algebra. For a photo editor, that’s hard to provide to the average user. For some CLI tools like wc and cat, it is easy. For composition to be controllable, the primary method of configuration needs to be in the contextual relationships among the tools and not in the tools themselves. That is, using cat and wc to count the number of words in a text file is primarily enabled by the filesystem and shell features, none of which require user configuration during the operation. Configuring wc to count instead the number of lines doesn’t distract too much, but imagine counting the number of lines emitted from a streaming serial device: you want it unbuffered, but only kinda because of other issues that arise, like multiline error conditions. In that case, the value is disrupted by edge cases and you have to configure the nouns (the serial stream at least) by looking it up on Stack Overflow. It’s not just easier to consider building a monolithic tool, but arguably the right thing to do because you need to configure everything so much. Plus, this is too much to expect the user to handle through a simple composition. In my opinion, desktop composition doesn’t work because the tasks are often beyond the limits of composition. And without a culture of composition among users, it’s harder and harder for remaining desktop applications to do it. Especially as younger users are unfamiliar with concepts like the filesystem, system keyboard shortcuts, “saving” files, offline operation (i.e. you have to reason through a problem and cannot lookup the answer), etc. Better to go with the monolithic app model, which can still use plugins under the hood or multiple processes for developer productivity. And I’m sad about that.
RetroTechie 3y ago
> A system is compositional if you can build it from small reusable parts. Take big monolith. Refactor into 1001 pieces. Glue together again. If glue is inflexible, then result is monolith+glue. If glue is thick, then result is mostly glue + little bits of monolith. If glue is superb (well designed & flexible), the whole works the same as monolith, but pieces can easily be rearranged as needed (and individually tested!). Designing good glue is HARD! And then some.
grumblingdev 3y ago
> My copy of `ls` has at least 40 flags Good point. You have to hand it to them though, that shell commands are still the least-typing way to do something compared to every programming language out there. Like if you gave the user an always-on JavaScript or Python repl, shell commands are still going to win every time. There are so many JS functions I have that I wish would just get automatic cli interfaces...instead of having to go through the ceremony, or use a repl, or something like that.

pjmlp 3y ago

Not only is COM still around, it is the main delivery mechanism for Windows APIs since Vista. Agree with UNIX worship point, I also had it, I was young and naive, lacking experience in the history of computer systems.

noelwelsh 3y ago
Wow, I didn't realise. I haven't paid attention to Windows APIs for a long time. I really thought it would have died a long time ago.
- pjmlp 3y ago
  That is what people outside Windows keep thinking. After WinDev managed to botch Longhorn efforts, its .NET ideas were redone in COM for Vista, and it has been like that ever since. WinRT/UAP/UWP, is basically COM with a new base interface IInspectable, .NET metadata instead of TLB files, and app boxing. And it is the foundation of WinAppSDK, whose goal is to port UWP subsystem into plain Win32, although their current execution leaves a lot to be desired.
- dist-epoch 3y ago
  The core of COM is about allowing binary code to be used from any language through a standardized interface. As pjmlp mentioned, this part was very successful and all new Windows APIs are based on it. The COM which failed and which you are thinking about was related to OLE and the idea of embedding Excel sheets inside Photoshop drawings, ...
  - deleted 3y ago
    [deleted]
  - abwizz 3y ago
    > the idea of embedding Excel sheets inside Photoshop drawings, ... that's still a thing isn't it?
    - zweifuss 3y ago
      Microsoft ported OLE 1 to Macintosh, but never OLE Version 2, because Apple guidelines forbid programes to start other programs. Because of that Photoshop had a not supported version of OLE. I don't know if it is still available in up to date Photoshop. On Windows it works both ways with OLE 2.

doctor_eval 3y ago

Let's just be careful what we call Unix though. In SVR4, I don't think "ls" had that many options. It didn't even have colour (not that I would know; my Wyse 60 could only have Green, Orange or White text... and the colour was set in the factory). It's the same for many programs that started small but grew loads of knobs with age. You can't claim that this was the Unix vision, because what we call Unix today isn't even technically Unix. I'm not saying Linux is bad or anything; I'm just pointing out that it's much more organic than Unix ever was, and that the resulting system is not necessarily carefully orchestrated.

noelwelsh 3y ago
IMO the problem with the Unix model is not that it's been corrupted over time, but that it was fundamentally flawed from the start. I'm hardly the first to point this out, but sending around unstructured text makes doing some things inordinately hard (imagine writing a separate program to color ls's output, instead of having that as a flag) + going beyond pipes leads to the awful experience of programming in shell.
- benj111 3y ago
  Ls seems like a bad example. Anything that you'd want to colour, the data should already be there. Further I'm not sure the Unix way inherently requires completely unstructured text
  - rcxdude 3y ago
    Unstructured text is the unix way. You can have pipelines sending other things between your programs (see powershell), but that's definitely not Unix.
    - rakoo 3y ago
      I disagree, the unix way has structure: lines of text each consisting of space-separated fields. The real issue is that sometimes your data has spaces, or even newlines, so the structure quickly isn't enough. And that "sometimes" happens xay more often than it has to, and the escape hatch is a mess.

throwaway31381 3y ago

>But ... firstly, let's stop with the Unix worship. They didn't deliver, even in the domain of the terminal. My copy of `ls` has at least 40 flags GNU is Not Unix. I count 13 flags on both Unix V10 [1] and on Plan 9 [2], its spiritual successor. [1] http://man.cat-v.org/unix_10th/1/ls http://man.cat-v.org/unix_10th/1/ls [2] http://man.cat-v.org/plan_9/1/ls http://man.cat-v.org/plan_9/1/ls

cpach 3y ago
I think you’re actually making the point for him here. You are correct that GNU is not Unix. And what version of ls has the most installations? I betcha it’s the ls from GNU Coreutils. I do agree that GNU tools are sometimes too maximalist. But they are also more useful than the minimalist alternatives.
- abwizz 3y ago
  seems like you agree that the extra flags make sense
  - cpach 3y ago
    In many cases, yes! On my Mac, which has a userland derived from FreeBSD, I have voluntarily installed stuff like GNU Findutils and GNU sed to get that extra functionality.
- tuukkah 3y ago
  To me, the point is you don't need many flags for ls to be useful. You will learn a few idioms early, such as ls -a and ls -lR but after that, the rest of the flags are nice to haves: if you wish there was a certain feature, you can look it up on the man pages etc. "I wish I could sort by time - oh there's -t"
- throwaway31381 3y ago
  I don't believe GNU's triumph over the BSD derivates was for the most part technical, they just happened to be at the right moment at the right time to ride along Linux's success. A consequence of the proliferation of arguments in the GNU tools is imho that it made the GNU manpages too verbose and information dense to the detriment of their usefulness.

dgb23 3y ago

Composable systems have a very clear property: uniform interfaces. CLI flags are typically arbitrary. What if they weren’t? How would they look like?

throw16180339 3y ago
PowerShell has fairly uniform interfaces.

mannykannot 3y ago

Yes, ls does have a lot of flags, but how did it get them, and what are the alternatives? It got them to satisfy real needs, and using flags, especially when combined with having man at your fingertips, was (and is) a highly effective interface for interactive work. If there is anything to be learned from the proliferation of command-line flags, it might be that one should not attribute too much significance to a vague aphorism such as "do one thing, and do it well."

docfort 3y ago

I agree that composition is the core idea and I was disappointed that the author neglected to summarize the idea correctly. Composition is a structured way of describing a unique task using a few common nouns and verbs. But composition needs to be understandable and controllable to be useful. For it to be understandable, it needs to match the user’s anticipated mental model. Now, this isn’t an appeal to an intuitive notion uninformed by user education. But it does need to make logical sense to connect two things together temporarily to solve one task. And that logic needs to come from the user and not the developer. In other words, the developer needs to provide concepts that conform to a user’s algebra. For a photo editor, that’s hard to provide to the average user. For some CLI tools like wc and cat, it is easy. For composition to be controllable, the primary method of configuration needs to be in the contextual relationships among the tools and not in the tools themselves. That is, using cat and wc to count the number of words in a text file is primarily enabled by the filesystem and shell features, none of which require user configuration during the operation. Configuring wc to count instead the number of lines doesn’t distract too much, but imagine counting the number of lines emitted from a streaming serial device: you want it unbuffered, but only kinda because of other issues that arise, like multiline error conditions. In that case, the value is disrupted by edge cases and you have to configure the nouns (the serial stream at least) by looking it up on Stack Overflow. It’s not just easier to consider building a monolithic tool, but arguably the right thing to do because you need to configure everything so much. Plus, this is too much to expect the user to handle through a simple composition. In my opinion, desktop composition doesn’t work because the tasks are often beyond the limits of composition. And without a culture of composition among users, it’s harder and harder for remaining desktop applications to do it. Especially as younger users are unfamiliar with concepts like the filesystem, system keyboard shortcuts, “saving” files, offline operation (i.e. you have to reason through a problem and cannot lookup the answer), etc. Better to go with the monolithic app model, which can still use plugins under the hood or multiple processes for developer productivity. And I’m sad about that.

RetroTechie 3y ago

> A system is compositional if you can build it from small reusable parts. Take big monolith. Refactor into 1001 pieces. Glue together again. If glue is inflexible, then result is monolith+glue. If glue is thick, then result is mostly glue + little bits of monolith. If glue is superb (well designed & flexible), the whole works the same as monolith, but pieces can easily be rearranged as needed (and individually tested!). Designing good glue is HARD! And then some.

grumblingdev 3y ago

> My copy of `ls` has at least 40 flags Good point. You have to hand it to them though, that shell commands are still the least-typing way to do something compared to every programming language out there. Like if you gave the user an always-on JavaScript or Python repl, shell commands are still going to win every time. There are so many JS functions I have that I wish would just get automatic cli interfaces...instead of having to go through the ceremony, or use a repl, or something like that.