| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 4/7 |
| 2004/5/8-9 [Computer/SW/OS/Linux, Computer/SW/Unix] UID:30108 Activity:very high |
5/8 On the linux ls discussion from the other day, this is my take:
Using/learning linux specific flags is all fine and good, and
adding new features to old tools is too, but when I have to
switch between 5 different OSes in a given day, it's simply a
waste of my time. There are many ways to solve a given problem.
Linux's solution always seems to be "add another flag". If you're
a Linux only shop, have at it. Learn all the little idiosyncracies
of your favorite flavor. But god help you when you get an HPUX
box thrown at you. --scotsman
\_ Relax, you'll live longer. Learn how to use alias and edit
the default profile. -williamc
\_ You miss the point entirely. Sometimes this is not an option.
If you're not a sysadmin then this discussion doesn't matter.
I'm talking about efficiency in work situations. --scotsman
\_ Compare:
ls -S 6 keypresses
ls -l|sort -n +4 18 keypresses
Is that something you want to type for such a simple user task?
It's just arrogant and silly to not do it, for something so
common and easy. Including the date or name sort is no more valid.
On soda there is "dir" which has it. Go study UI principles.
\_ This is the stupidest thing I've seen on motd in weeks.
Comparing the number of keypresses? Christ, man, it's about
getting the job done as effectively as possible. When you're
down to counting keystrokes, you've lost touch with reality about
what constitutes a sane metric for efficiency.
\_ effective? What's more effective about piping to sort? it's
more limiting, and more obscure. And yes, it takes more effort
to type that shit out. It's not about "efficiency" so much as
simple ease of use and consistency. That's reality. Not some
elitist ubergeek deciding to simply put a note in the man page
about how it's not needed. Obviously the fact that it's in
the man page means it's a desired feature.
\_ What's more effective than piping it to sort? Could you
have missed the point any more? Jeeesus.
\_ Ever stop to consider you're the one missing the point?
\_ Yes, but I'm not. Have a cookie.
\_ It's not more obscure. In fact it's less obscure and more
consistent unless you're immersed in Linux. Why is this
point so hard to grasp? --scotsman
\_ Forget the status quo, it's more obscure from a
usability standpoint. I have to know about the sort
command and that I have to do ls -l and sort on that
4th column but oh I might need the -n for numeric
vs. lexical sorting. Honestly this is really really
basic. It's not consistent that there is built-in
date sort, or alphabetical sort, and not size sort,
\_ In 10 years, I think there still be be Windows and Mac OS.
the only other basic file property. It's not consistent
that I need the long detailed listing when with a
builtin it could just work like normal. And it's just
plain inconvenient. You don't have to be "immersed
in Linux" to see that. I barely even use Linux. It's
just common sense and refusing to worship status quo.
Oh and I'm just arguing about what's correct, not
the "least-common-denominator" factor of working with
15 different unixes.
\_ Did it ever occur to you that sometimes the status
quo *is* the status quo because it has worked well
since before you were born and is just plain better?
\_ The extension of the point is that when you have
learned to use sort appropriately you can then
apply it in other cases. Read the philosophy of
UNIX page partha posted below. If you don't work
on 15 different unixes then, as I said above, this
discussion doesn't apply to you. If I get pulled in
to help out a client to save a $100k sale, I have
to get the job done quickly. Knowing the least-
common-denominator allows me to get up to speed
quickly. It's not worshiping anything. It's doing
my job well. --scotsman
\_ you know, it's possible to know how to use
"sort," and still support the idea of
internalizing functions in Unix utilities in
appropriate ways. You don't need "find -nouser"
to be able to find files without a legitimate
owner, but it's clearly a functional enhancement
to the original "find" functionality. As for
the "philosophy of Unix", don't you think it's
a bit ironic that the person posting it is
mr. emacs? -tom
\_ Either you're following the unix philosophy or
you're trying to circumvent and short cut it
and that way leads to madness and windows
methodology and chaos.
\_ well, clearly there is a "merit of having -S in
ls" discussion going on, although the thread
didn't start with that. But it's devolved into
reiterating already-stated points.
\_ So rather than being obtuse you're merely off-
topic?
\_ Obviously? So if I write a man page that says you don't
understand the core concept of unix utilities then it
becomes obvious? Sigh, I shall explain for the unwashed:
the core concept you're missing is that unix is about
having lots of little utilities that each do one thing
really well. You create a stream of data from little
util to the next via pipes and out pops the right thing
at the other end. I know 'ls' and 'sort'. I know I can
pipe from one to other. I know this works on every *nix
system I might ever touch. This is called portability.
Linux is the bastard child here, not the non-Linux real
unixen you're deriding. Linux is following the Windows
style of over loading programs with things that seem neat
at the time but turn into bloated crap later. I like Unix.
I accept Windows. I do not want my Unix bloated up into a
half assed Windows a la Linux. Simplicity, son. KISS.
\_ you dolt, yes I know about all that shit. "son". my
point is simply about the usability issue. I don't care
what other unices are doing, I'm saying that they should
do this. Whoever wrote that man page obviously knew
about the option and knew there were poeple wanting it.
-S is not "bloated crap" any more than -t or -r. ls
is probably the most common command users run. Listing
files is what ls does, it should "do it well". I could
write a man page that says vi is unnecessary because
you have ED IS THE STANDARD!
\_ Sorting on a date with sort is not the same as
sorting on an integer such as size. Please explain
in what way I am a dolt. Is it that I read your mind
and understand what you don't understand to such a
degree that you have nothing left to say but insult
me? If that is the case, then yes, I am a dolt.
\_ It sure is the same, son. Sorting on a date isn't
algorithmically identical, so what, irrelevant.
You're ignoring the big picture. I'm done arguing
for today though. Btw ls could easily output the
date in a sortable manner. Unix philosophy doesn't
require factoring everything into as many programs
as possible.
\_ alias ls-S "ls -l | sort -n +4"
now you can type "ls-S" in 5 keypresses! for common tasks, you
can make the number of required keystrokes arbitrarily short or
long. non-issue.
\_ duh. of course you can make an alias. totally beside the
point. of course you'd have to do more work to make it work
just like a real "ls -S" would.
\_ This is why after 10 more years, there will only be Linux
and nothing else, because the other OS are simply too arrogant
to do anything about it. Take for example the man pages on
Solaris, I mean how much effort does it take to make it so that
it will format according to your screen and does not produce
the stupid 24 line page header every page? Everytime I look at
the man page on Solaris I curse it. The linux one is so much
better. One reason why SunOS is fading.
\_ You know, I HATE working on Solaris. Nothing works the way
that I'm used to without aliasing everything. However, when
we were running our server on Solaris it never once crashed in
the entire time I was in charge of it. I can't say the same
for any of the Linux installs I've set up.
\_ In 10 years, I think there still will be Windows and Mac OS.
Your arguments for Linux and against other Unix OSs are the
the same as the arguments for Windows/Mac OS and against Linux.
Every time I read a man page I curse it. Hyperlinked help files
are so much better.
\_ personally, I find the statement "after 10 more years, there
will only be xxxxx and nothing else... " to be pretty
absurd in the context of any technological question.
\- the amount of wrongheadedness in this thread is amazing.
but rather than agrue, the youth ought to read ... --psb
http://www.faqs.org/docs/artu/ch01s06.html
\_ excellent. --scotsman
\_ Yes! Finally! This should be mandatory reading before
geting into core CS classes or getting a Soda account.
\_ In 10 more years Linux will 'rewl' because the man pages format
better than on Solaris? If that's the best you can come up with
then just stick with Windows and reboot a lot. |
| 4/7 |
|
| www.faqs.org/docs/artu/ch01s06.html You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Fancy algorithms are slow when n is small, and n is usually small. Until you know that n is frequently going to be big, don't get fancy. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. Ken Thompson, the man who designed and implemented the first Unix, reinforced Pike's rule 4 with a gnomic maxim worthy of a Zen patriarch: When in doubt, use brute force. More of the Unix philosophy was implied not by what these elders said but by what they did and the example Unix itself set. Looking at the whole, we can abstract the following ideas: 1. Rule of Modularity: Write simple parts connected by clean interfaces. Rule of Composition: Design programs to be connected to other programs. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. Rule of Transparency: Design for visibility to make inspection and debugging easier. Rule of Robustness: Robustness is the child of transparency and simplicity. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust. Rule of Least Surprise: In interface design, always do the least surprising thing. Rule of Silence: When a program has nothing surprising to say, it should say nothing. Rule of Repair: When you must fail, fail noisily and as soon as possible. Rule of Diversity: Distrust all claims for "one true way". Rule of Extensibility: Design for the future, because it will be here sooner than you think. If you're new to Unix, these principles are worth some meditation. They come to accept blunt tools, bad designs, overwork, and bloated code as normal -- and then wonder what Unix fans are so annoyed about. Rule of Modularity: Write simple parts connected by clean interfaces. As Brian Kernighan once observed, "Controlling complexity is the essence of computer programming" 11 Kernighan-Plauger . Debugging dominates development time, and getting a working system out the door is usually less a result of brilliant design than it is of managing not to trip over your own feet too many times. Assemblers, compilers, flowcharting, procedural programming, structured programming, "artificial intelligence", fourth-generation languages, object orientation, and software-development methodologies without number have been touted and sold as a cure for this problem. All have failed as cures, if only because they succeeded' by escalating the normal level of program complexity to the point where (once again) human brains could barely cope. As Fred Brooks famously observed 12 Brooks , there is no silver bullet. The only way to write complex software that won't fall on its face is to hold its global complexity down -- to build it out of simple parts connected by well-defined interfaces, so that most problems are local and you can have some hope of upgrading a part without breaking the whole. Because maintenance is so important and so expensive, write programs as if the most important communication they do is not to the computer that executes them but to the human beings who will read and maintain the source code in the future (including yourself). In the Unix tradition, the implications of this advice go beyond just commenting your code. Good Unix practice also embraces choosing your algorithms and implementations for future maintainability. Buying a small increase in performance with a large increase in the complexity and obscurity of your technique is a bad trade -- not merely because complex code is more likely to harbor bugs, but also because complex code will be harder to read for future maintainers. Code that is graceful and clear, on the other hand, is less likely to break -- and more likely to be instantly comprehended by the next person to have to change it. This is important, especially when that next person might be yourself some years down the road. Once might be a one-shot fluke, but if you find yourself having to figure it out a second time -- because the first was too long ago and you've forgotten details -- it is time to comment the code so that the third time will be relatively painless. It's hard to avoid programming overcomplicated monoliths if none of your programs can talk to each other. Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats. Under classic Unix, as many programs as possible are written as simple filters, which take a simple text stream on input and process it into another simple text stream on output. Despite popular mythology, this practice is favored not because Unix programmers hate graphical user interfaces. It's because if you don't write programs that accept and emit simple text streams, it's much more difficult to hook the programs together. Text streams are to Unix tools as messages are to objects in an object-oriented setting. The simplicity of the text-stream interface enforces the encapsulation of the tools. More elaborate forms of inter-process communication, such as remote procedure calls, show a tendency to involve programs with each others' internals too much. A program on one end of a text stream should care as little as possible about the program on the other end. It should be made easy to replace one end with a completely different implementation without disturbing the other. Complex binary data formats are sometimes unavoidable by any reasonable means. But before writing a GUI, it's wise to ask if the tricky interactive parts of your program can be segregated into one piece and the workhorse algorithms into another, with a simple command stream or application protocol connecting the two. Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools. When a serialized, protocol-like interface is not natural for the application, proper Unix design is to at least organize as many of the application primitives as possible into a library with a well-defined API. This opens up the possibility that the application can be called by linkage, or that multiple interfaces can be glued on it for different tasks. In our discussion of what Unix gets wrong, we observed that the designers of X made a basic decision to implement "mechanism, not policy"--to make X a generic graphics engine and leave decisions about user-interface style to toolkits and other levels of the system. We justified this by pointing out that policy and mechanism tend to mutate on different timescales, with policy changing much faster than mechanism. Fashions in the look and feel of GUI toolkits may come and go, but raster operations and compositing are forever. Thus, hardwiring policy and mechanism together has two bad effects: It makes policy rigid and harder to change in response to user requirements, and it means that trying to change policy has a strong tendency to destabilize the mechanisms. On the other hand, by separating the two we make it possible to experiment with new policy without breaking mechanisms. We also make it much easier to write good tests for the mechanism (policy, because it ages so quickly, often does not justify the investment). This design rule has wide application outside the GUI context. In general, it implies that we should look for ways to separate interfaces from engines. One way to effect that separation is, for example, to write your application as a library of C service routines that are driven by an embedded scripting language, with the application flow of... |