
All software sucks - danso
http://harmful.cat-v.org/software/
======
ANTSANTS
The author of this committed suicide a few years ago. To the people making fun
of the site for not being able to handle HN's traffic, it's kinda hard to
improve your software when you're dead.

[http://www.cs.bell-labs.com/wiki/plan9/Uriel/index.html](http://www.cs.bell-
labs.com/wiki/plan9/Uriel/index.html)

[https://groups.google.com/forum/#!topic/comp.os.plan9/xEb4wY...](https://groups.google.com/forum/#!topic/comp.os.plan9/xEb4wYzfaBc)

~~~
danso
That is terrible news and not something I was aware of when I posted this.
However, I would not have posted the OP had I not thought the site wasn't
being actively updated.

The link you post says the OP committed suicide in 2012. According to the OP's
update page, the site has been updated throughout December of 2013:

[http://webcache.googleusercontent.com/search?q=cache:VmDU1T1...](http://webcache.googleusercontent.com/search?q=cache:VmDU1T1DtbQJ:cat-v.org/update_log+&cd=1&hl=en&ct=clnk&gl=us)

Edit: for example, there was a page added recently on Node:

`2013/12/05: Added ‘harmful’ page about Node.js.`

(which unfortunately is down)

Edit 2: I think cat-v is now a series of sites, and each domain may be
maintained by a separate person (the one under discussion is
harmful.cat-v.org), so it may not all be the work and opinion of Uriel:
[http://webcache.googleusercontent.com/search?q=cache:JL12jkr...](http://webcache.googleusercontent.com/search?q=cache:JL12jkr42_sJ:cat-v.org/about+&cd=1&hl=en&ct=clnk&gl=us)

~~~
ANTSANTS
cat-v originally created by Uriel.

[https://web.archive.org/web/20140208043848/http://cat-v.org/...](https://web.archive.org/web/20140208043848/http://cat-v.org/about)

    
    
      Thanks
        Uriel for creating and building the site.
    

The page linked is part of a community wiki hosted on the site; while it has
accumulated changes since then, I'm pretty sure the original "considered
harmful" list was his creation.

EDIT: khm, you've apparently been hellbanned, for some reason.

~~~
khm
I don't know what "hellbanned" means, but I'm unsurprised I got banned for
posting about malloc() in a web programming forum.

~~~
dang
You definitely weren't banned for posting about malloc. Posts about malloc are
good! But yes, the account was banned, and I just looked through the log and I
can't figure out why. The IP was banned as well, which suggests to me that
your account might have gotten caught by a spam filter that had previously
tagged that IP. I'm sorry. We've unbanned the account, obviously.

(If it was a spam filter, I have an idea about how to fix the problem which I
haven't yet had time to get to.)

~~~
ANTSANTS
Could it be the link to the, um, somewhat incendiary blog?

~~~
dang
Definitely not. It has been posted 88 times here in 6 years.

------
parasubvert
If his primary criteria for "suckage" is non-reliability through unnecessary
complexity, he has some decent points.

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.

~~~
celebril
You do know Uriel has been dead for quite a while now?

~~~
parasubvert
I learned about it while I wrote the response to this thread. Many here didn't
know Uriel at all.

------
networked
I've been meaning to ask this about some of the less harmful software listed:

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/](http://www.plan9.bell-
labs.com/wiki/plan9/pq/) and [http://plan9.bell-
labs.com/wiki/plan9/Using_PQ/](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.

~~~
krick
> A downside to PostScript is that it is a Turing-complete programming
> language

I could be guessing, but why exactly do you say it's a downside?

~~~
nemo
PostScript is dangerous as a vector of attack. You can create an infinite loop
as a DoS. Way back in the NeXT days, you could get remote control a system
with an invisible block of postscript put in an email, turning on microphones
and cameras and dumping that data to hosts. It became a nightmare to secure.
The DOD physically destroyed those inputs on their black hardware to deal with
it. Apple moved to DisplayPDF for license cost reasons primarily, but security
and performance were also factors.

~~~
vilhelm_s
But the only one of those problems that is due to it being a Turing-complete
language is the infinite loops, the other ones are just a question of the mail
client exposing sensitive capabilities to untrusted code (which it should not
do, of course).

As for infinite loops, SVG allows you to make definitions and refer back to
them, so you can write documents which take exponential time (in the document
size) to render --- in practice that is as big a DoS attack. And the way to
deal with it is the same, you need to impose resource limits when rendering
files given to you by an untrusted attacker.

It seems that Postscript the language got an bad reputation for kindof unfair
reasons: the toolset was written assuming that files were generated by
friendly people, and then those tools were run an arbitrary code from the
internet. But it is totally possible to write a Postscript interpreter which
runs code in isolation, just as you can for Java or Javascript.

------
krick
I totally agree that all software sucks, but, unfortunately, we have to use
_something_ and the list of alternatives isn't really impressing (maybe
because it's outdated, idk).

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

~~~
eekee
>> GCC. ->> 8c, tcc. > clang, you mean? I think I'm safe in answering "No" for
uriel here. I think he was probably watching clang warily to see how it would
develop, but he didn't pay so much attention to software for a couple of years
before he died, and it's been a couple of years since then. For my part, Gcc
4.x has done a lot to put me off Linux development or even bug fixing, but
I've no experience worth mentioning with Clang. 8c is Plan 9's C compiler for
x86, along with 5c (ARM), 2c (68020), kc (SPARC), etc etc. The set was written
by Ken Thompson. It's stable, it's got some sensible extensions (which Gcc
didn't have until the GccGo project), and it doesn't kick up a fuss for
nothing. Tcc is a "tiny C compiler", and as such I assume it also doesn't
raise errors over nothing.

I'm pretty sure Rust didn't exist when uriel last touched that page, too.

I have to agree everything sucks in interfaces. Tk was one thing I never
agreed with uriel on. I suspect he only put it there to have something proper-
GUI-ish in the right-hand column.

>> 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? Because text editor freaks revile the mouse. Sam and Acme both
require a mouse. Did you know the mouse was invented for text editing? I have
fairly serious motor control issues; in non-medical terms I'm so clumsy they
call it a medical condition, but despite that I really can't understand why
some people can't just use a mouse to place the text cursor, or even select. I
wonder if they're put off by "proper" GUI programs, many of which require
really excessive switching between keyboard and mouse. Acme requires the mouse
for all editing operations other than inserting text but surprisingly I find
it doesn't require nearly as much switching between mouse and keyboard as many
"proper" GUI programs. Sam requires even less, it's basically a much-enhanced
ed with the option to place the cursor or select text by the mouse if you
want. Sam also has this funky feature of running the 'terminal' on a different
machine to the back end, so you can have mouse-based editing over slow
networks.

>> 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. You can use any
internal format you like without need for byte order marks, which I think is
what uriel particularly hated about UTF-32.

On document formats I have to agree with you, copying editing and reflowing
text do matter. I think pocket-sized devices just weren't a part of uriel's
world. Someone did buy him an iPhone at one point, but that was late in his
career.

------
lclarkmichalek

        Harmful things           Less harmful alternatives
    
        <thing that is popular>  <thing that is not>
    

With a few exceptions. Though their advice to not use HTTP is pretty
impressive (I never thought cat-v were capable of compromise!)

~~~
zorbo
That, or

    
    
        Harmful things            Less harmful alternatives
    
        <thing that is       >    <thing that is          >
        <not Plan9 / OpenBSD >    <Plan9 / OpenBSD        >
    

Most interesting thing which sheds some light on the list is: "At the moment a
detailed rationale is not provided for most of this, so figuring out why some
things are considered more or less harmful than others is left as an exercise
for the reader. Here is a hint: complexity is the bane of all software,
simplicity is the most important quality"

I do have to say I agree with a large part of the Harmful list, but I
recognize those things are not actually harmful but just personal preference.

~~~
zdw
Given that many of OpenBSD decisisons turn out to either be the right ones or
the de-facto best choices (sudo, openssh, pf, bounds checking string
functions, 64 bit time, etc.), it's hard to argue with the general concept.

(This applies to Plan 9, to a much lesser extent - concepts and people who
worked on Plan 9 tend to disseminate, but there's less direct code sharing).

~~~
kazagistar
I suspect that is selective memory at work to some extent. You are first to
arrive sometimes, and the rest of the time you can say "well, we just didn't
have the manpower" or something.

------
phaer
Google Cache:
[https://webcache.googleusercontent.com/search?hl=en&q=cache%...](https://webcache.googleusercontent.com/search?hl=en&q=cache%3Ahttp%3A%2F%2Fharmful.cat-v.org%2Fsoftware%2F)

------
sowhatquestion
Google cache version:
[http://webcache.googleusercontent.com/search?q=cache:harmful...](http://webcache.googleusercontent.com/search?q=cache:harmful.cat-v.org/software/)

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.

~~~
michh
Yeah, disappointing. It's just a "list of things I hate and you'll just have
to trust me I have good reason to". It's a bit childish, actually.

Some of the things have links to rants explaining why they apparently suck,
but that's just more adolescent ranting mixed with quotes.

I like a good rant occasionally, but those are well-written, make a point
worth making and actually show some effort to convince the reader. This is
just not it.

~~~
nailer
A lot of his rationale doesn't follow the simplicity argument he makes.

I'm not a Rubyist, but replacing Ruby with awk sounds like a terrible idea:
suddenly means you're treating things which are not strings as strings, which
can get very complex very quickly. Also: few people know awk beyond print $1,
and using two languages (bash and awk) is more complex than one.

~~~
copergi
>and using two languages (bash and awk) is more complex than one.

If the two languages are combined still simpler than the one language, then it
is not more complex. Note that bash is not what you would be using if
following his lists. Using rc+awk is way simpler and easier than ruby for any
typical unixy scripting stuff (text mangling, process wrangling, etc).

~~~
nailer
Really? I think any language with string methods, regexs, arrays, sets, and
hashmaps (which IIRC Ruby has) is a much cleaner approach than sed + awk +
(bash|rc). Data is serialized as strings in config files, but for simplicity's
sake, should be manipulated as actual data.

This is coming from someone who built an OpenDocument generator in bash that's
still in use at IBM today.

Also: who names something new on Unix 'rc'? Simplicity is not using existing
names.

~~~
copergi
You might want to learn awk and rc before making claims about them. In
particular, awk is significantly more powerful than you seem to realize, it is
not analogous to sed at all. It is a specialized programming language for
manipulating tabular text data.

And nobody names something new on unix rc. It is the plan 9 shell.

~~~
nailer
I've used awk extensively and am aware of everything you've told me. I never
said awk was analogous to sed, they're quite different, which is why you'd use
both, as I mentioned.

I've not used the rc shell, but have used Bourne shell, bash, csh, various
versions of ksh, and zsh. My comments apply to all of those, and unless rc is
significantly different to every other Unix-like shell I imagine they apply to
rc as well.

Also: plan 9 is Unix-like, rc shell is newer than the Unix concept of rc that
dates back to 1965
[http://en.wikipedia.org/wiki/Run_Commands](http://en.wikipedia.org/wiki/Run_Commands).
So yes, it's a new(ish) thing with a naming conflict with something already
well-known.

~~~
copergi
>I've used awk extensively and am aware of everything you've told me. I never
said awk was analogous to sed, they're quite different, which is why you'd use
both, as I mentioned.

I can't see any way to parse your statement such that it matches your claim of
being experienced. Either you feel sed is on the same level as awk and rc,
hence mentioning it together with them (unlike say, ls or grep or any of the
other commands you didn't mention) as being one of the tools you would use
instead of general scripting languge X. Or you meant using them together for
one specific task rather than as a general "sometimes you would use one,
sometimes you would use the other". In which case you don't realize that there
is no reason to ever do that since awk can already do everything sed can.

>I've not used the rc shell

That's precisely what I pointed out was a problem. "I have no knowledge of one
of the things I am comparing" is not a rebuttal to "you have no knowledge of
one of the things you are comparing".

>My comments apply to all of those

And all of those are listed in the same category. This makes it rather self-
evident that yes, he considers rc to be significantly different. Hence my
suggestion that you try it and find out how you feel about it, rather than
just assuming it is the same as bash.

>Also: plan 9 is Unix-like

No it is not. Linux is "unix-like". Plan 9 is a completely different OS,
designed as a spiritual successor to unix, which was seen as having been
corrupted. It is no more unix-like than windows is dos-like.

>So yes, it's a new(ish) thing with a naming conflict with something already
well-known.

I never said otherwise. You asked "who names something new on Unix 'rc'?". I
pointed out the obvious fact that it simply isn't the case. It is not
something new on unix. Being upset that an operating system has a two letter
command that another operating system also has is silly.

~~~
nailer
Twice now you haven't read the post you're responding to. I don't think sed is
the same thing as awk, nor do I think it is the same as bash, I have never
said that, in fact I have said quite the opposite: that you'd likely use all
of those together. This is incredibly common behaviour in Unix scripts: you
might not like stream editing but many find it cleaner than awk's less well
known language.

You seem to have gone out of your way to attribute some kind of conspiratorial
malice or gross incompetence to a simple, TESTABLE fact: shell scripts plus
text manipulation languages are frequently replaced by single language
scripts, which have a unified, consistent syntax and high level data
structures.

Since you're not reading my posts, I'm not going beyond your first sentence.
This is end of my participation in the thread.

~~~
copergi
I have in fact read them. I have even been very explicit and clear about my
reading of them in the hopes that you will either understand what I am saying,
or correct my misunderstanding. It is unfortunate that you wish to do neither.
I made a very simple point: you do not know rc, and are comparing bash to ruby
and then blindly assuming that comparison applies to rc vs ruby. It does not.

------
vezzy-fnord
Yes, cat-v. I've wasted plenty of time on there, as well as other werc sites.

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.

------
coldcode
Apparently whatever they use for web software can't cope with HN traffic,
which is fitting the title perfectly.

~~~
KhalilK
Speaking of which, how much traffic HN would generate? Has it been measured?

~~~
mschuster91
Shitloads. HN is iirc more "powerful" than slashdot when you're on the
frontpage.

~~~
thejosh
Nothing compared to reddit though.

------
damian2000
Google cache:

[http://webcache.googleusercontent.com/search?q=cache%3Aharmf...](http://webcache.googleusercontent.com/search?q=cache%3Aharmful.cat-v.org%2Fsoftware%2F&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-
US:official&client=firefox-a&channel=sb)

------
amboar
The table of harmful things and alternatives is fascinating. I'd love to see
the rationale for each row.

~~~
damian2000
The hint mentions "complexity is the bane of all software, simplicity is the
most important quality"

Seems right for C++ vs C, Go and XML vs JSON, CSV for example.

~~~
amboar
Yeah, I agree with your examples aside from the ability to validate XML; I'm
not a heavy user of json but I don't believe it's possible to tell whether a
document is well formed. Anyway, the lack of rational means it doesn't address
essential vs accidental complexity. Are the harmful items harmful because they
have lots of accidental complexity? Or are the problems they exist as a
solution for simply hard problems? If complexity of a harmful entry is mostly
essential it would be interesting to know why it was still considered harmful.
For instance, Bash is considered harmful but is nice as a user shell compared
with say, sh.

~~~
steveklabnik
> I don't believe it's possible to tell whether a document is well formed.

[http://json-schema.org/](http://json-schema.org/)

~~~
amboar
Fair enough! I'll keep that in mind :)

------
weinzierl
Why is head considered harmful?

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

~~~
bbanyc
Because it wasn't made in Murray Hill. grep is also a single command in sed,
but since it was in Unix v6 it's okay. There's an extreme case of NIH syndrome
that pervades the Plan 9 community.

------
danso
The OP was so opinionated about solid software principles that I kind of did
not expect his server to go down...Mostly, I thought his table of "Good" and
"Bad" (example, Python, Ruby, C++ is bad; Go is good) was amusing, and his
dedicated rants to the software I agreed with, in part.

------
zokier
How the heck DjVu is a replacement for EPUB? Even plain-text would be a better
fit.

Also wtf is wrong with _NetBSD_?

~~~
copergi
>Also wtf is wrong with NetBSD?

It is a bit questionable to have netbsd in there since it isn't that bad, but
I would assume the rationale is "it is more complex than openbsd".

~~~
celebril
By that logic MSDOS is less harmful than Plan9.

------
zemoth
I think quite a few people are missing the use of the term "harmful".

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/](http://suckless.org/)

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

------
LatencyKills
Wouldn't it be funny if the OP _intended_ for the server to be unavailable (as
proof of the post's title)?

~~~
gkya
Funny within the bounds of a sub-par cognisance of fun.

------
matheusbn
google's cached version looks weird. This seems better:

[http://web.archive.org/web/20140210085734/http://harmful.cat...](http://web.archive.org/web/20140210085734/http://harmful.cat-v.org/software/)

------
auvrw
upvoted based on the sentiment of the title (because what to do with things
that suck? make them better.) and domain name alone. there are similar
listings at [http://suckless.org/sucks](http://suckless.org/sucks) and
[http://suckless.org/rocks](http://suckless.org/rocks) . i found a pdf viewer
called zathura as a result of that site, and it's been really useful (despite
pdf sucking as a whole vis. djvu).

------
nly
Software complexity either comes from people not doing the hard work, or
contemplation, to pan down their _ideas_ to the simplest possible construct...
or later allowing cancerous developments. It has little to do with tools used
for implementation. Pretty much everything on the left side of that table can
be used to produce beautiful, simple, elegant software.

~~~
clarry
There are people who find that complexity and bloat matter across the entire
stack, from the lowest level to your piece of software on top of it all. With
such philosophy, it does not matter that your product might be simple and
elegant, if it stands on the shoulders of a wild behemoth.

~~~
monochr
Then those people better not be programming on x86 hardware because that
platform is so bloated the mov command is Turing complete by itself:
[http://www.cl.cam.ac.uk/~sd601/papers/mov.pdf](http://www.cl.cam.ac.uk/~sd601/papers/mov.pdf)

~~~
clarry
You are right. We actually have all the resources needed to overcome this
problem and we've fabbed our own chips in our garages. Some of us play with
sparcs, vaxen, arms, weird mips based toys and other such things to stay
inspired and maintain sanity.

~~~
monochr
Now you just need to design a balanced ternary computer which uses lambda
calculus instead of Boolean logic and you will be a quarter of the way to
getting rid of the gunk left over from the birth of computers when people were
arguing if relays or vacuum tubes were the way of the future.

The one thing I have noticed all the people with "philosophical" objections to
bloat have in common is that they are largely ignorant of the real hardware
and software they are coding on. This was brought nowhere better to the front
than in this video
[https://www.youtube.com/watch?v=Nbv9L-WIu0s](https://www.youtube.com/watch?v=Nbv9L-WIu0s)
where they showed that the tools written because gnu tools were too big when
measured in a running computer take up just as many resources.

~~~
copergi
>This was brought nowhere better to the front than in this video
[https://www.youtube.com/watch?v=Nbv9L-WIu0s](https://www.youtube.com/watch?v=Nbv9L-WIu0s)
where they showed that the tools written because gnu tools were too big when
measured in a running computer take up just as many resources.

At what time in the video does that happen? I didn't have time to watch the
whole thing, but it doesn't appear that what you are suggesting was even
brought up much less demonstrated?

~~~
clarry
They're just measuring code size and such. Kilobytes that do not really
matter, unless you're embedded.

Right near the end they present some minimal tools that are supposed to have
no bloat because they're written in assembly and don't need libc. Turns out
these aren't any better than gnu tools with dietlibc, after some shaving.

Not really worth watching through, if you were expecting discussion about real
bloat. I think they're just setting up a straw man, a bad one at that too.

------
hollerith
Since I have been using rc as my interactive shell since approximately 2001
and since I tend to have a PERFECTIONISTIC attitude towards the software that
I use every day like the OP has, I will give a list of what I like and dislike
about rc (relative to bash) in order of decreasing importance or significance.
(Specifically, since about 2001, I have been using the port of rc by Byron
Rakitzis on Linux and OS X.)

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

in summary, for me switching to rc was probably a waste of my time, and I
would have been better off sticking with bash (and better off starting sooner
on my slow mission to replace interactive uses of traditional Unix shells with
interactive uses of Emacs).

~~~
eekee
I agree interactive shells suck. I like to use Acme which has been called Plan
9's Emacs, but it uses the shell tools instead of Lisp. In Acme I can enter a
shell command -- I can write it directly in the appropriate dir list if I want
-- then to execute it either drag over it with the middle button, or select
the whole line (by double-clicking after the end; nice and easy) and then
middle-click. It's much nicer than groping around blindly in a regular shell
window. I've not found it so good when I wanted to use environment variables,
but I've just thought on Plan 9 I could edit the files in /env directly. Not
sure if that will work correctly though.

------
crashandburn4
Could someone explain the advantages of sam and/or acme over emacs or vim to
me? reading that it's from the plan 9 team I get the feeling there must be
something good there so I was wondering if someone could help me realise what
it is? extra points for a comparison of sam and acme or explanation about ed.
;)

~~~
astrange
Rob Pike created acme because he wanted an interface that would use the mouse,
unlike the regular vim setup.

[http://plan9.bell-labs.com/sys/doc/acme.html](http://plan9.bell-
labs.com/sys/doc/acme.html)

Meanwhile, traditional UNIX users all developed subconscious phobias of their
mice, because they use focus-follows-mouse and therefore moving their mouse
caused them to accidentally type in the wrong window. This is why they like to
so rabidly claim to be super-efficient typing wizards by using keyboard chords
for all their text selection needs.

Acme is also more UNIX-like (Plan9-like?) than EMACS, which is just an alien
Lisp image invading your machine and seeking to become an email reader/rampant
AI/planet conqueror. I always assumed Hurd failed as a project because, once
it ran Emacs, nobody ever really needed to develop the rest of the OS.

~~~
crashandburn4
hahaha. I love this answer! So rob pike wanted a vim that used the mouse? did
he follow the vim paradigm of having composable/repeatable/whatever you want
to call vim commands (you know what I mean) or the emacs version of "oh, just
throw a programming language in there and they'll be fine"? also is it modal
like vim?

Finally, don't speak ill of the emacs, I've got it on my machine and I worry
it's listening, I swear after I wrote that last lisp function I heard it
whisper, I grow more afraid every day. it can hear us. we are not alone, I
type three escapes and it merely laughs at my naivety these days.

------
untitaker_
Funny how he advises to use Mercurial, which is written in a language he
considers harmful.

------
funky_lambda
What's the definition of 'harmful' here? Unreliability?

------
zokier
So basically his advice is pretty much just "use plan9"

------
lucian1900
List of obvious facts, half-truths and hipster-like contempt.

------
andrea_s
So, apparently "SQL Databases" are harmful, and a less harmful alternative
would be to use "plain old hierarchical filesystems".

Sure, why not?

~~~
kelseyfrancis
Equally asinine: "plain old tarballs would be better than svn".

~~~
parasubvert
That's something Linus Torvalds has effectively said as well, so it's not as
asinine as you might think. Unduly harsh perhaps.

------
atraktor
This is most suckiest post on HN

