Hacker News Reader

Comment by dig1 | Hacker News Reader

If you look at how other (console) programs on the system work, Vi(m) is more consistent than Nano. ed, sed, awk, readline, even perl... knowing one of them, you know how to use vi. Likewise, know vi, you know how to use most of these tools (sans visual/modal editing abstraction).

Also, it follows the Unix spirit of making small programs (in Vi(m) it can be seen as "a small number of key presses") and composing them for more complex actions. In Vi(m), almost everything is composable with everything: jumping to the line, deleting line ranges, joining ranges, etc. In Nano (and in Emacs), you end up with tons of Ctrl-keyX-keyB-keyC presses or cursor movements.

Example: delete a line - you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k. In vi, it is just "dd", no matter where your cursor is. Or, delete 5 lines from the beginning with vi: "gg5dd". Not sure how you can get more unixy than that ;)

View on HN

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.

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.

> 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/

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.

> 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.

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).

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

Nowadays, most people are going to know the standard Mac/windows GUI shortcuts before they touch a command line.

In my experience, many student's first experience of a command line editor is "git commit", or a similar command, which springs the default editor on them. Learning vim because it just popped up as the default editor is almost impossible.

Beginners don't care about deleting a line, you can press DEL 80 times and get it done. They care about quickly typing something in or changing a config, saving and quitting. Easy to instruct with Nano without having to introduce the concept of mode editing, which is totally foreign to most beginners.

>you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k.

This is not correct, ctrl+k works anywhere on the line?

It deletes to end of line.

Just tested in GNU nano, version 3.2, the default on Debian Buster, with default settings. Ctrl-K deletes entire line no matter where in the line you use it.