Re: [PLUG] Challenges with "The Unix Way"

[Steve Litt <slitt@troubleshooters.com>]

On Fri, 27 Oct 2017 06:03:52 -0400
brent timothy saner <brent.saner@gmail.com> wrote:

> On 10/27/2017 02:23 AM, Steve Litt wrote:
> > 
> > You're right: It's not always the best. But when it is, for gosh
> > sakes use it, because it's trivially easy and it was fully debugged
> > decades ago.
> >   
> 
> it's (almost) always the easiest, for sure!
> 
> >   
> >> especially in
> >> modern context -UNIX itself frequently strayed from the so-called
> >> "UNIX Way"  
> > 
> > You wouldn't by any chance be talking about Nautilus, Gnome3, KDE,
> > and Firefox, would you? You can't blame the Unix way for those: They
> > simply abandoned every shred of the Unix way.
> >   
> 
> oh goodness, no; at the very least i try to be fair in my criticisms.
> CDE (KDE's predecessor) certainly even exhibited some of the issues
> that recent releases of KDE had, etc. but these definitely weren't
> things that set out to follow that philosophy.
> 
> the philosophy as documented, in full, is this:
> 
> 
> 1.)    Make each program do one thing well. To do a new job, build
> afresh rather than complicate old programs by adding new "features".
> 
> 2.)    Expect the output of every program to become the input to
> another, as yet unknown, program. Don't clutter output with extraneous
> information. Avoid stringently columnar or binary input formats. Don't
> insist on interactive input.
> 
> 3.)    Design and build software, even operating systems, to be tried
> early, ideally within weeks. Don't hesitate to throw away the clumsy
> parts and rebuild them.
> 
> 4.)    Use tools in preference to unskilled help to lighten a
> programming task, even if you have to detour to build the tools and
> expect to throw some of them out after you've finished using them.
> 
> 
> now, every --verbose flag/switch breaks #2 right off the bat. (of
> course, there aren't many of those flags in SysV if memory serves,
> but...)

Yeah, but those are just switches and don't prevent the tool from being
used in a more "Unixlike" way.

> 
> however, SysV's grep is a pretty good example of breaking #1:
> 
> http://man.cat-v.org/unix_7th/1/grep
> 
> sed's -n outout, combined with a negation regex, duplicates grep's -v
> option, wc -c duplicates grep's -c option, awk duplicates grep's -l,
> and so on.
> 
> now, i'm not saying grep shouldn't *have* those options, but i
> certainly am saying that there's a reason that the philosophy was
> broken, even in the best-known version of UNIX. they started to
> realize "hey, if i'm ALWAYS piping to this certain program most of
> the time, and loading that entirely new process into memory just for
> this one particular function of that program, then it's probably
> better to just roll that particular functionality into the initial
> program". which i do agree with; it makes for a more efficient and
> usable system for operators and a smoother-running system from the
> resource consumption standpoint.

If I correctly interpret your last few  paragraphs, you're saying that
Unix doesn't use The Unix Way as a specification, it uses it as a
guideline. I never thought of it that way, but yeah, that's true.

The guys from the Unix Hater's Guide have a completely different
viewpoint: They just don't like it, and they justify that dislike with
various reasons.


> 
> so i think a lot of the exaltation of the "UNIX Way" is generally
> pretty idealized. 

Yes. It's an ideal. I think it was even written to be an ideal.
Frictionless pucks, ideal engines, exact half-splitting in
troubleshooting, and the Unix Way. None can be achieved, all are worth
working toward. Or, as you say in the sentence below....

> does it makes for a good *guideline* for writing
> programs? sure! but one oughtn't be afraid of deviating from it for
> the sake of e.g. performance or usability. 

Zactly.

> the original philosophy
> was put in place almost hostile to these things (much like how we
> still by and large use QWERTY in the US, despite it being originally
> designed to *slow* typists down to prevent keys from jamming on
> typewriters).

Sometimes. I once made a website log
evaluator whose first few steps were various greps to get rid of as
many lines as early as possible. Then, with sort as well as my personal
Perl code, I molded the greatly reduced data set into results. The Unix
Way served me well. On the other hand, my first implementation of a
compiler for menu language EMDL was a chain of processes writing
intermediate files. 30 second compile. I rewrote it as a node tree, and
it compiled in less than 2 seconds. So in that case you're absolutely
right.

Here's where *I* am coming from. 1984-1998 I kicked around using RT-11
and TS/x and CPM and DOS and Windows. You wanted something done, you
programmed it yourself, at the source code level. Re-useable code was
some holy grail in the trade mags, but except for a few printer
formatter classes I made, and stuff like Turbo Async, I wrote everything
pretty much from scratch, by myself.

Then I came upon Linux in 1998, and wow, you could do big chunks of the
program with commands like grep, sed, cut, sort, cat and the like. In
1/100 the time,  with no errors because all these commands had been
completely debugged a decade before. It was like a miracle. I had a
saying back then: Linux is a Wishing Well. Wish for something, look
around Linux, and you could probably find it. Here are some articles
about that:

http://www.troubleshooters.com/tpromag/199910/199910.htm#_editors_desk

http://www.troubleshooters.com/lpm/200212/200212.htm#_lifeAfterWindows

Some folks might have quibbles with The Unix Way, but when you did hard
time in Windows 1990-1998, The Unix Way, implemented as imperfectly as
it might be, is nothing short of a miracle.

SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug