3 ms·

The so-called "Unix spirit" is itself a rather hilarious mistake from the early days of software engineering, when programmers knew essentially nothing about hu

by p-e-w 4y ago

The so-called "Unix spirit" is itself a rather hilarious mistake from the early days of software engineering, when programmers knew essentially nothing about human/computer interaction and foolishly believed that "efficiency" in a mathematical sense translates to efficient workflows. It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of functionality integration, not functionality separation. Email and calendars are often used together, that's why they belong in the same program. Similarly, it makes sense for a programmer's editor to have an integrated terminal, and for a web browser to have an integrated bookmark manager. "Small programs" is a bad idea that happens to sound like a good one. We don't really need to debate this, as reality has settled that debate long ago. Software serves people, not ideals of rational optimality. And default software must serve the greatest possible number of people well, else it's the wrong default.

Hendrikto 4y ago
Integration does not presuppose hard coupling. Different components can integrate and coordinate through standards. I would argue that having one big app is the one of the worst methods of integration.
- p-e-w 4y ago
  > Different components can integrate and coordinate through standards. We've tried that and for the most part, it doesn't actually work in practice. Hell, it doesn't even work between standard Unix programs. They don't "integrate and coordinate" at all. They just push unstructured text around, and in some cases that's sufficient to perform some very basic compound tasks. There is an upcoming project though that tries to make Unix pipelines work the way they are supposed to: Nushell[1]. It has real composability with strongly typed data that flows between commands. Guess how they're doing it? Yup, that's right: They're building it all as a monolithic system where the entire pipeline is supervised and interpreted by the shell. Unix is too fragmented and standards are too difficult to develop and implement for any other approach to be realistically feasible. "Small programs" are an evolutionary dead end. [1] https://www.nushell.sh/ https://www.nushell.sh/
benj111 4y ago
I think youre being uncharitable to the Unix way. the Unix way is more about having a data standard that all programs can use, rather than a front end that does everything. yes the everything as a stream of text model didn't really scale, but I don't think that disproves the concept. all of your examples could work as well as, if not better if you standardised a data format and/ or protocol. The current landscape for software isn't really that monolithic. software of any size implements plugins. If you look back to monolithic software of the 80s where there wasn't any expandability, wasn't things like tool kits or shared libraries. In a sense 'small software' didn't lose. it just moved up and down the stack a bit, and arguably still lives on quite successfully on mobile phones.
kevin_thibedeau 4y ago
Unix efficiency is all about saving time and paper on a teletype. It just happens to have side benefits on modern computers.
dolni 4y ago
> It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of functionality integration, not functionality separation. Yes, so much integration that despite JetBrains IDE functionality being first-class, we have still seen the rise of LSP over the last few years. That's more like the Unix philosophy, not less. And that's not even to mention that small, composable programs and libraries are NOT incompatible with integration. In fact, they help it.
- p-e-w 4y ago
  LSP took off because it was designed and heavily promoted by one of the most powerful technology corporations on the planet, who already had the ears of tens of millions of developers. The number of proposed "standards" for solving similar problems over the years that have failed or even been completely ignored is legion. LSP is one of only a handful of software integration standards that have ever found widespread adoption. Meanwhile, there are hundreds if not thousands of integration problems where no standard is in sight. This universal vision where micro-programs process and pass around standardized data is never going to happen, except on platforms that are completely controlled by a single vendor (see Apple).

by p-e-w 4y ago

Hendrikto 4y ago

Integration does not presuppose hard coupling. Different components can integrate and coordinate through standards. I would argue that having one big app is the one of the worst methods of integration.

p-e-w 4y ago
> Different components can integrate and coordinate through standards. We've tried that and for the most part, it doesn't actually work in practice. Hell, it doesn't even work between standard Unix programs. They don't "integrate and coordinate" at all. They just push unstructured text around, and in some cases that's sufficient to perform some very basic compound tasks. There is an upcoming project though that tries to make Unix pipelines work the way they are supposed to: Nushell[1]. It has real composability with strongly typed data that flows between commands. Guess how they're doing it? Yup, that's right: They're building it all as a monolithic system where the entire pipeline is supervised and interpreted by the shell. Unix is too fragmented and standards are too difficult to develop and implement for any other approach to be realistically feasible. "Small programs" are an evolutionary dead end. [1] https://www.nushell.sh/ https://www.nushell.sh/

benj111 4y ago

I think youre being uncharitable to the Unix way. the Unix way is more about having a data standard that all programs can use, rather than a front end that does everything. yes the everything as a stream of text model didn't really scale, but I don't think that disproves the concept. all of your examples could work as well as, if not better if you standardised a data format and/ or protocol. The current landscape for software isn't really that monolithic. software of any size implements plugins. If you look back to monolithic software of the 80s where there wasn't any expandability, wasn't things like tool kits or shared libraries. In a sense 'small software' didn't lose. it just moved up and down the stack a bit, and arguably still lives on quite successfully on mobile phones.

kevin_thibedeau 4y ago

Unix efficiency is all about saving time and paper on a teletype. It just happens to have side benefits on modern computers.

dolni 4y ago

> It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of functionality integration, not functionality separation. Yes, so much integration that despite JetBrains IDE functionality being first-class, we have still seen the rise of LSP over the last few years. That's more like the Unix philosophy, not less. And that's not even to mention that small, composable programs and libraries are NOT incompatible with integration. In fact, they help it.

p-e-w 4y ago
LSP took off because it was designed and heavily promoted by one of the most powerful technology corporations on the planet, who already had the ears of tens of millions of developers. The number of proposed "standards" for solving similar problems over the years that have failed or even been completely ignored is legion. LSP is one of only a handful of software integration standards that have ever found widespread adoption. Meanwhile, there are hundreds if not thousands of integration problems where no standard is in sight. This universal vision where micro-programs process and pass around standardized data is never going to happen, except on platforms that are completely controlled by a single vendor (see Apple).