

Free Your Technical Aesthetic from the 1970s - davatk
http://prog21.dadgum.com/74.html

======
mseebach
To me, the aesthetic of *nixes is the way everything is neatly arranged around
the same set of relatively simple abstractions: executables, shell scripts,
processes and text files. Yes, there's a learning curve, but once you're
around the bend it's pretty flat. Skills are generally general -- once you
know how to do X, chances are you've touched a great deal of the tools you
need to Y.

Windows is somewhat simple (but unreliable) on the outside, and completely
inaccessible on the inside. If you want to interact with the innards of
Windows, there's somethings you can do in the registry, some things you need
Scripting Host for, some things can be done in .NET, others you need COM for.
Documentation for these things are spotty (you might find a guide for doing
something in COM, in C++, and need to pair that with another guide on how to
do COM in .NET). The learning curve maybe isn't as steep, but it keeps its
inclination all the way to the wall you're bound to hit. There's little
generality in skills -- once you know how to do X, you're still almost all the
way back to square one on how to do Y.

~~~
0bfusct3
The same can be said for *nixes, in order to create something in sh using
programs you need literally days of reading man pages for switches, etc or use
perl, python, etc.. but even then many tools don't have bindings so you're
back to use sh.

All operating systems currently popular are crap except for the most popular
one in it's usage domain.

~~~
ams6110
This assumes you aren't online, where nearly any shell script example you can
think of is likely only a google search away. I don't think that anyone really
spends days studying man pages anymore. Though it's nice that they are there
when you need to look up something system-specific.

~~~
0bfusct3
That's like saying language y is fine because I can just search and copy and
paste... no you cannot. If you do anything beyond a simple [[ -f somefile ]]
&& do something sh turns into a nightmare.. case in point autotools.

------
_delirium
There seem to be two sort of unrelated criticisms here. One's a preference for
GUI (or at least full-screen console-mode) interfaces over CLIs, and generally
for fewer config files and command-line options. The other is a dislike of
chaining piped commands, and a suggestion that integrated scripting languages
like Perl are the replacement. But those seem like two pretty wildly different
directions to go in. And there doesn't seem to be any argument for either of
the points, just personal preference ("I don't like the Unix aesthetic, and
you shouldn't either").

The more specific examples are pretty weird, also. Just about every Unix comes
with a full-screen text file viewer ('nano' is a decent one). If you don't
like bash, you can use a different shell; I mean, he was willing to use a
third-party shell on Windows, why not on Unix? One option:
<http://fishshell.org/>

~~~
commandar
This may be totally unfair to author, but the impression I got was that he was
using *nix without really understanding it.

------
matthewn
"By way of comparison, on my home PC I used a third-party command shell called
4DOS [...] It had a wonderful command line history mechanism: type part of a
command, then press up-arrow."

Want in bash? Add to ~/.inputrc:

# up and down arrows do _incremental_ history search

"\e[A": history-search-backward

"\e[B": history-search-forward

~~~
chipsy
Why do old Unix programs always have bad defaults?

~~~
zokier
Because the defaults come from 70's, and lots of nice stuff has added since,
but nobody dared to touch the defaults.

------
arethuza
I used Suns as my primary development environment from '89 to '96 and I really
don't recognize most of those complaints - just about everyone I knew used
emacs, xman was pretty handy for reading man pages and the supplied Sun
manuals were awesome.

I'm pretty sure I used ksh that had interactive command line history as well.

I've used a lot of different Unix variants (BSD, Ultrix, OSF/1, SunOS, various
Linux distros) and while they were all quite different they all had and
continue to have common logical structure that eludes some newer operating
systems I could name.

~~~
ams6110
I used ksh on HPUX in the early '90s and it definitely had searchable command
history

------
djacobs
I just finished reading _The Art of Unix Programming_. Eric Raymond gives
insight into exactly why this is a bad analysis.

Regarding the anti-CLI argument:

GUIs are helpful for one-time tasks... things that don't require much
repetition. They are discoverable (i.e., the learning curve can be easier) and
easier for non-technical users.

However, as one understands the CLI and the power of DRY code, one gravitates
towards it for its power, simplicity, reusability, and transparency.

Commandline options only make the programs more versatile and scriptable,
further boosting productivity.

Of course we could do a bug-by-bug comparison of standard Unix tools to
standard MSFT tools, but I'd rather not go there.

------
njonsson
Looks like somebody's gone off his meds.

------
0bfusct3
Unix is bad, crusty and getting less relevant due to how computers are
becoming more distributed and less as a single system. Linux may be the top of
the herd right now but sooner rather than later there is going to be a huge
paradigm shift into distributed computing. Linux will have no place in
distributed computing without either layers upon layers to the POSIX API (aka
backwards compatibility) or well a new operating system.

~~~
moomba
I'm wondering why you're saying linux has no place in distributed computing.
Most supercomputers and distributed systems run linux. Not sure what paradigm
shifts are going to have a significant impact on the OS. The only changes I've
seen are in hardware/programming syntax as of late.

~~~
0bfusct3
Sure they do but they use extremely specialized software that probably took
years to apply to the platform let alone developing the software. Linux is the
top in distributed computing because it filled a niche (free) and has momentum
if BSD, L4, etc was created then / didn't have some sort of issue we'd all be
using kernel x instead of linux

~~~
djacobs
What, specifically, about the Linux kernel and Unix structure makes them bad
for distributed applications, again?

~~~
0bfusct3
c, capabilties (or lack there of), self healing, runtime based optimizations,
concurrency, locking, threading and just generally the way it's structured
it's not meant to be a distributed operating system the applications developed
for it show this. Have you seen how glusterfs, lustre or any other distributed
FS works? They bend over backwards trying to implement a POSIX API usually
with hideous hacks.

