5 ms·

> So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish I disagree, I think the Unix philo

> So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish I disagree, I think the Unix philosiphy solves the problem. You build simple tools that do one thing, and do that one thing well, but you make it easy for the tools to work together and then you can have pieces that do one simple thing while still serving needs. When new needs come up that aren't addressed by current tools you simply put together another simple tool that does that.

wildrhythms 4y ago
I don't think this adequately addresses the counterexample of the Word toolbars. Sure, there's Excel, but what if I want the tabular data to live in my Word document? Now the Microsoft engineers are building a whole secondary table editing system into a word processor...
- shakna 4y ago
  If everything is modular, you can copy any feature between the various parts of your office applications. You've got a plugin doing one thing, and a host whose one thing is bundling all of those one things together.
- jimmaswell 4y ago
  This could just call Excel with COM
- kevingadd 4y ago
  This is one of the things that motivated the creation of OLE and COM, so that you could embed an entire Excel spreadsheet into a Word document.
invalidname 4y ago
That's also how Word solved the problem with the toolbars. It hid the functionality using the ribbon and added plugins. Unix is a monster in terms of features if you look at it as a whole. It's just modular so it can solve all problems.
iudqnolq 4y ago
Could this explain why the average person doesn't directly use linux?
- emodendroket 4y ago
  It would be a start.
ako 4y ago
Have you looked at the help of some of these so-called simple tools? Pages and pages of options that you can configure. Not so simple.
emodendroket 4y ago
That just moves the complexity somewhere else (writing shell scripts, for instance). Not a real solution.
- b112 4y ago
  Not true. Let's say you take a mega-program, break it into 100 programs. Each now becomes more stable, due to simplicity. Yes, it really does. But my point is, when you use those individual things, you use a random allotment of 3 or 4 of them. Not all 100. Thus, the stringing-together bit is far, far less complex.
  - bigfoot675 4y ago
    If this was true, non-technical people would be stringing these together instead of using products that were created with the end user in mind
  - edanm 4y ago
    > Thus, the stringing-together bit is far, far less complex. This is the statement I disagree with the most. The problem is that combining different programs, that aren't strictly written to interoperate in a specific way, gives you an order of magnitude increase in the complexity. Sure, running find and grep together is common enough, but how about running {obscure_command_rarely_used} through {other_command} through {other_other_command}. There are always corner cases that can crop up, and even before we get to corner cases, just understanding how to fit the pieces together correctly is not so simple. One cohesive program designed to all work together sometimes just makes more sense, especially when we're talking about complicated, high level actions, as opposed to the more common low-level actions of unix commands. (Or well, maybe high level and low level is the wrong way to put it - maybe the lower abstraction stuff in Word vs. the higher abstraction stuff that Unix tools deal with.)
    - bstpierre 4y ago
      > One cohesive program designed to all work together sometimes just makes more sense Yes, your example of find|grep is perfect for this. Sometimes (not often) I have a situation where a simple pipe combination doesn’t work and I have to fall back to awk, which would be the single cohesive (and more complicated ) program.
b112 4y ago
You build simple tools that do one thing, and do that one thing well You're right, systemd does fail in this.
- OJFord 4y ago
  Does it? If you mean 'all things under the systemd umbrella' then sure, but if you think in terms of systemd (core), systemd-networkd, systemd-homed, etc. isn't it pretty much as 'one thing'(s) as it could reasonably be? And the umbrella just seems arbitrary - GNU, Mozilla, X11, anything that's a package group, etc. are also failing.
amadeuspagel 4y ago
The unix philsophy might make sense for command line apps — though even there if you look at any manpage you find that they usually do more then one thing, including things you could easily do by piping the output to another command — but what does it mean in the context of a word processor? You want another app to count the number of words in a document, for example?
alkonaut 4y ago
Customers don’t want to glue things together they want whatever solves their problem efficiently. Integration and ease of use are features in themselves. The best of both worlds would be building things that is modular from the developers perspective but integrated from the perspective of the user. Few will pull that off though, and when they do the modular systems become complex and expensive bespoke setups (Typical of e.g SAP, Oracle).

wildrhythms 4y ago

I don't think this adequately addresses the counterexample of the Word toolbars. Sure, there's Excel, but what if I want the tabular data to live in my Word document? Now the Microsoft engineers are building a whole secondary table editing system into a word processor...

shakna 4y ago
If everything is modular, you can copy any feature between the various parts of your office applications. You've got a plugin doing one thing, and a host whose one thing is bundling all of those one things together.
jimmaswell 4y ago
This could just call Excel with COM
kevingadd 4y ago
This is one of the things that motivated the creation of OLE and COM, so that you could embed an entire Excel spreadsheet into a Word document.

invalidname 4y ago

That's also how Word solved the problem with the toolbars. It hid the functionality using the ribbon and added plugins. Unix is a monster in terms of features if you look at it as a whole. It's just modular so it can solve all problems.

iudqnolq 4y ago

Could this explain why the average person doesn't directly use linux?

emodendroket 4y ago
It would be a start.

ako 4y ago

Have you looked at the help of some of these so-called simple tools? Pages and pages of options that you can configure. Not so simple.

emodendroket 4y ago

That just moves the complexity somewhere else (writing shell scripts, for instance). Not a real solution.

b112 4y ago
Not true. Let's say you take a mega-program, break it into 100 programs. Each now becomes more stable, due to simplicity. Yes, it really does. But my point is, when you use those individual things, you use a random allotment of 3 or 4 of them. Not all 100. Thus, the stringing-together bit is far, far less complex.
- bigfoot675 4y ago
  If this was true, non-technical people would be stringing these together instead of using products that were created with the end user in mind
- edanm 4y ago
  > Thus, the stringing-together bit is far, far less complex. This is the statement I disagree with the most. The problem is that combining different programs, that aren't strictly written to interoperate in a specific way, gives you an order of magnitude increase in the complexity. Sure, running find and grep together is common enough, but how about running {obscure_command_rarely_used} through {other_command} through {other_other_command}. There are always corner cases that can crop up, and even before we get to corner cases, just understanding how to fit the pieces together correctly is not so simple. One cohesive program designed to all work together sometimes just makes more sense, especially when we're talking about complicated, high level actions, as opposed to the more common low-level actions of unix commands. (Or well, maybe high level and low level is the wrong way to put it - maybe the lower abstraction stuff in Word vs. the higher abstraction stuff that Unix tools deal with.)
  - bstpierre 4y ago
    > One cohesive program designed to all work together sometimes just makes more sense Yes, your example of find|grep is perfect for this. Sometimes (not often) I have a situation where a simple pipe combination doesn’t work and I have to fall back to awk, which would be the single cohesive (and more complicated ) program.

b112 4y ago

You build simple tools that do one thing, and do that one thing well You're right, systemd does fail in this.

OJFord 4y ago
Does it? If you mean 'all things under the systemd umbrella' then sure, but if you think in terms of systemd (core), systemd-networkd, systemd-homed, etc. isn't it pretty much as 'one thing'(s) as it could reasonably be? And the umbrella just seems arbitrary - GNU, Mozilla, X11, anything that's a package group, etc. are also failing.

amadeuspagel 4y ago

The unix philsophy might make sense for command line apps — though even there if you look at any manpage you find that they usually do more then one thing, including things you could easily do by piping the output to another command — but what does it mean in the context of a word processor? You want another app to count the number of words in a document, for example?

alkonaut 4y ago

Customers don’t want to glue things together they want whatever solves their problem efficiently. Integration and ease of use are features in themselves. The best of both worlds would be building things that is modular from the developers perspective but integrated from the perspective of the user. Few will pull that off though, and when they do the modular systems become complex and expensive bespoke setups (Typical of e.g SAP, Oracle).