All software sucks

http://www.cs.bell-labs.com/wiki/plan9/Uriel/index.html

https://groups.google.com/forum/#!topic/comp.os.plan9/xEb4wY...

But such lists are a slippery slope from insightful reflection to axe grinding. It's one thing to debate simplicity and the qualities that emerge in simple software solutions. That is valuable. It is quite another to say that all software sucks and "features" are useless. That's in the eye of the beholder.

Perfectionists tend to be frustrated by the observation that if you want to get paid to build software (as opposed to coding for artistic purposes), the market really doesn't care about internal simplicity, they care about features and qualities. Even more frustrating, the market doesn't value reliability over all other qualities: people have, can, and will pay for something that only works some of the time. Otherwise we wouldn't have had much of an automobile or early PC market.

I am saddened to hear the author is no longer with us, due to suicide. I would have enjoyed him debating his claims on HN.

1. What advantages and disadvantages would you say rc has for daily use as an interactive shell over {ksh,bash,zsh}? How does it compare for scripting to those shells and Tcl? I don't know if this is historically true for the latter but both rc and Tcl strike me as regularizations of the Bourne shell syntax and semantics, albeit ones that went different ways (everything including code is a string in Tcl but not in rc, which leads to further differences).

2. What is the the closest equivalent of PQ for Linux/*BSD? Best if it also supports updates. There is surprising little about PQ on the Web, basically just http://www.plan9.bell-labs.com/wiki/plan9/pq/ and http://plan9.bell-labs.com/wiki/plan9/Using_PQ/.

Edit: 3. A downside to PostScript is that it is a Turing-complete programming language. Defining a subset of it that gets rid of flow control would make it too verbose and harder than necessarily to write by hand. By contrast, in SVG it's easy to never use the <script> tag unless you want animation. Is there a (semi-)standard vector graphics markup format simpler than SVG that's purely declarative? I couldn't find one.

> C, Go, Limbo.

It reminds me of some story about OpenSSL and… well. Yeah, Python sucks, Ruby sucks, but we have to use something for scripting and everything else sucks more, so… Also, Rust is more appropriate in list of alternatives, I guess.

> Perl, Ruby. ->> rc, awk.

I guess it's only about text processing inside of shell, so, ok, but it's only because our best shells still are awful. I guess shell of the future is something more like iPython, that is, something that allows to do real programming, so there won't be need for cryptic-syntax text processing tools. Yeah, not unix-way. Rc? I doubt.

> GCC. ->> 8c, tcc.

clang, you mean?

> Tk, textual interfaces.

Just no. Textual interfaces are the best, surely, but not always enough. And Tk is simple, sure, but cannot do everything Qt can. So, again, everything sucks.

> Vim, Emacs, nano, Eclipse, ->> Acme, Sam, ed.

So why it happens I never heard of Acme or Sam before? Maybe "ed" in that list could provide some insights?

> UTF-8.

Sure, but unfortunately it's slow as you don't have static offsets, so sometimes you have to use UTF-32 while processing.

> IM

Everything sucks, alternatives aren't any better. Well, may be only a little.

> PDF --> PS(PostScript), DjVu.

What about copying text?

> EPUB --> DjVu.

Really? What about editing? What about reflowable content? What was he thinking wen writing it? FB2 is an "alternative" (but sucks too).

> sed 11q

11q yourself.

    Harmful things           Less harmful alternatives

    <thing that is popular>  <thing that is not>

The title drew me in, but I didn't find this very insightful. I clicked on it expecting a righteous rant; instead, I found a list of things the author likes and dislikes, framed by some clever quotes.

As a previous poster pointed out, these guys are hardcore Unix elitists and so their perspectives on software are written from a standpoint of an ardent follower of the Unix philosophy, and one who values minimalism and simplicity over all. The real form of simplicity, not the one of dumbing things down.

It's just a totally different world from your average HN user, or even Bay Area "techie", for that matter.

Their IRC channel is also pretty amusing to lurk around, though of not much use unless you're involved with 9front to one degree or another.

http://webcache.googleusercontent.com/search?q=cache%3Aharmf...

>Here is a hint: complexity is the bane of all software, simplicity is the most important quality.

Isn't head one of the simplest tools one can imagine? Certainly simpler than sed.

Also wtf is wrong with NetBSD?

His words are from a developer standpoint with unix philosophy.

One tool does one thing well, those tools are licensed in a way that means you can contribute safely without being a lawyer and the code is not needlessly complex.

The Suckless crew have software that suits such philosophies perfectly, check out dwm and ii.

http://suckless.org/

His ideas are not for your grandma, they're for elitists.

http://web.archive.org/web/20140210085734/http://harmful.cat...

If you like Unix shells, then you probably want to skip this comment since it is my opinion that all unix shells including rc suck for interactive use.

The original meaning of the word "shell" was a interface layer between the core Unix system and the user. I now consider Emacs my shell, and I try to replace interactive use of rc, bash or other traditional Unix shells with interactive use of Emacs whenever practical.

E.g., to escape from the hassle described below caused by equal signs in Youtube URLs, I defined an Emacs Lisp function M-x youtube-dl so that I no longer need to use a Unix shell to interact with the command-line program youtube-dl. (This works for me because 99.9 percent of my interactions with rc are through Emacs. Consequently, I do not need to switch from Terminal.app to Emacs.app to type M-x youtube-dl because Emacs.app already has the focus even when I am interacting with rc, and Terminal.app is not even running most of the time on my system.)

I tend to define new commands and wrap/redefine existing commands like ls a lot, which of course means writing some code. Consequently, the list below includes problems I encountered (in bash and in rc) in writing and maintaining code that defines new interactive commands and defines wrappers around existing interactive commands. (My .rcrc file -- which is rc's analog to .bash_profile and .bashrc -- is currently 704 lines long and contains 112 definitions of rc functions, but about half of those 112 are "of historical interest only". I.e., maybe I should have deleted most of them by now.)

Here starts the list.

Backslash does not quote the next character in rc like it does in bash.

Consequently, to refer to a file name with space in it, you have to do it 'like this' rather than like\ this.

Unfortunately, all the softwares I am aware of that do tab completion of file names quote spaces and pound signs like\ this, which makes it tedious in rc commandlines to type file names with spaces and pound signs in them. This has been for me the biggest disadvantage of rc relative to other shells. It has been especially painful OS X where spaces in file names are not rare, but even on linux it was painful for me to specify file names like #long_name_here# which Emacs was in the habit of leaving around until I figured out how to get it to stop doing that.

Parenthetically, I ran into the same basic problem with all the Plan-9 and Plan-9-inspired software I tried to embrace (e.g., Wily, Acme via plan9port): namely, although the design decisions work okay for people who use only Plan 9, the mismatch between the Plan 9 way of doing things and the OS X or Linux way of doing things makes it unworthwhile to use a Plan-9-inspired tool or a tool ported from Plan 9 on OS X or Linux. E.g., on Plan 9, file-name completion via the tab key is simply unavailable, which works on Plan 9 because everyone including the providers of the basic system keeps path names nice and short.

In bash et al, you can have an equal sign in a file name or a URL without needing to quote it. In contrast, in rc, you need to quote it. this is a hassle for me since youtube URLs have equal signs in them, and I am in the habit of pasting them into shell commandlines a lot.

The thing I like most about rc relative to bash is that a function definition begins with the characters "fn foo" where "foo" is the name of the function. This makes it easier to use plain old "find in page" functionality to navigate to a function definition in a file full of function definitions. In other words, in bash et al, you have to type "foo()" to search for the start of the definition of the function foo whereas in rc you can type "fn foo " which is easier to type.

Moreover, in the process of writing this, I used grep to determine the number of function definition in my .rcrc file (rc's analog to bash's .bashrc file). specifically, I used "grep '^fn ' .rcrc". the analogous operation for bash is harder to express.

Since this thing I like most about rc is a relatively small thing, you would be correct in concluding that I do not believe it is worth it to switch from a normal shell like bash to rc.

Another thing I like about rc: unlike bash, newlines are not somehow in subtle ways significant in "multi-line constructs" like if statements. in other words, if statements, switch statements and for statements in rc resemble statements in normal languages like C more than if statements, etc, in bash do.

The quoting rules are simpler in rc than in bash. Although I found that very appealing in theory before I started using rc, in practice, I still struggled with "quoting-related issues" in rc. for example, the definition of the rc function I used as a wrapper around /bin/ls contained the following code whose purpose is to "print" (cat to stdout) its contents whenever there exists a file named .hdr in the directory being listed.

the code loses whenever the full path to the directory I want to list contains a space. in particular if I cd somehow to /0/library/saved application state, then invoke my wrapper command, the error message

test: application/.hdr: unknown operand

test: application/_darcs: unknown operand

test: application/.alpha: unknown operand

appear in the output, and the .hdr file is not printed. For those readers who know how to fix that bug in the code below, please do not feel you need to educate me about the fix. To write code in rc you have to know some "shell lore", and although some people might take pride in learning shell lore, I'd rather avoid the need to learn it. In most languages (e.g., Python, Ruby, Lisp), there is no special lore one has to learn to ensure that path names with spaces in them are handled correctly.

    # set dirname2 to the directory portion of the last argument.
    # make that directory name an absolute file name.
    # make sure it ends in a slash.
    if (!test -d $*($#*)) {
        dirname2 = `{cd `{dirname $*($#*)}; pwd}^/
    } else {
        dirname = `{cd $*($#*); pwd}
        switch($dirname) {
        case */
            dirname2 = $dirname
        case *
            dirname2 = $dirname^/
        }
    }
    # if a .hdr file exists, print it now:
    if(~ $#* 1) {
        if(test -d $1) {
            if(test -r $dirname2^.hdr) {
                cat $dirname2^.hdr
                echo
            }
        }
    }

Sure, why not?