Hacker News new | past | comments | ask | show | jobs | submit login

As someone that was alive during those UNIX days, I really don't get the appeal to live in the past.



I don’t believe it is "the past" which is appealing.

We live in a very graphical society, with (moving) pictures everywhere, all the time. But to "think", you need words. As Neal Stephenson put it in "In the beginning was the command line", Words are the only technology available to encode thoughts. While images and sounds convey more emotions. It’s not a coincidence that we are here exchanging words.

Command-line, is a way to exchange words with a computer. It is way more precise, more efficient. But it takes learning and thinking. It’s harder the same way it is harder to read a book than to watch a movie. Especially if you never learned to read in the first place which, for the command-line, is approximately everyone but a few geeks.

If your goal is to "think" precisely and convey this thinking into something tangible on a computer, then you probably want the command line. But, as it needs a lot of learning, you don’t want it for temporary job. You don’t learn to read because you want to read Harry Potter. You learn to read because you want to spend your life reading books.

In "UNIX As Litterature", Scoville argued that UNIX is done by literary people for literary people. People which have a strong "book" culture. People who probably enjoy books more than the movies because "there’s a lot more, it’s more subtle, I can imagine it like I want".

Those people, (disclaimer: I count myself in those) may even have too much "graphics" in their daily lives. Too many pictures. Billboards, movies, ads, colored and graphical t-shirts everywhere, branding.

Retreating to the command-line feels good, calm, zen. (see Stephenson book again).

But, I admit, those people are a minority. Graphical interfaces have the advantage of being intuitive. Intuitive literally means "you don’t need to think" (that’s what intuition is). You click randomly and, by trial and error, you learn some arbitrary rules that the designers decided to use. (when I was teaching basic Windows XP computer use to elders, I once got a very simple question: "how do I know if I need to click once or double click?". I never could answer that. There are no real rule. You learn it and never think about it afterward).

So the GUI is really about removing the thinking from the process. Which is good when you don’t care about the process or when you are not really sure what you want. Or when you want something to be quickly done once and for all.

Command-line forces you to clarify your thoughts all the time. It is hard. It is energy consuming. But this forces you to take real decisions.


Scripting languages and a REPL give exactly the same experience, if not better, without pretending to be stuck in emulating a 1970's text terminal.

Another thing that looks like books is paper, maybe for the ultimate experience we could write programs on paper and have the computer scan them somehow.


Also, TUI and hybrid UI's. MC it's both a shell, file manager, editor, viewer, VFS explorer and remote FS manager. mcedit -b or mc -b, much better. No colors, no distractions, just raw info. That's how I read lots of fortune files, books, novels and documentation back in the day.


Ah just like my first experiences in MS-DOS 3.3 and Xenix....


Unix CLI makes automation easy. The least you 'use' the computers for repetitive tasks, the better.

If you want fun, get Scheme or Common Lisp+Emacs and start hacking something cool.


A REPL and scripting languages make automation easy without having to live in a TTY emulation world.


Even with GTK/Lucid Emacs+Geiser/SLIME is not that easy.

Also, on speed... GNU's looks glacially frozen compared to slrn. Heck, GNUs runs fast if it's being bound to slrnpull's spool.

GNU's on Email and IMAP it's the same. If you use mbsync+msmtp, again, the speed it's literally 1000x better. by pooling a maildir. From hours parsing a remote folder, yes, hours, to seconds.

Also, compare elfeed vs sfeed. By the time elfeed renders a huge caché of news, I could write an elisp parser for the sfeed output and then display everything under Eww.

Emacs without Unix tools doing the hard job would be much slower even on fast machines. Yes, I know, the new JIT against libgccjit, blah... blah... still slow.


Emacs is hardly the example I would think of, it didn't got its nickname accidentally.


I just gave you multiple reasons.


Which is why I started as making the point I lived through it, when fancy graphics weren't even an option.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: