| Andrew 2006-06-13, 1:23 pm |
| Xah Lee wrote:
> The Nature of the "Unix Philosophy"
>
> Xah Lee, 2006-05
>
> In the computing industry, especially among unix community, we often
> hear that there's a "Unix Philosophy". In this essay, i dissect the
> nature and characterization of such "unix philosophy", as have been
> described by Brian Kernighan, Rob Pike, Dennis Ritchie, Ken Thompson,
> and Richard P Gabriel et al, and in recent years by Eric Raymond.
>
> There is no one definite set of priciples that is the so-called "unix
> philosophy", but rather, it consistest of various slogans developed
> over the decades by unix programers that purport to describe the way
> unix is supposed to have been designed. The characteristics include:
> "keep it simple", "make it fast", "keep it small", "make
> it work on 99% of cases, but generality and correctness are less
> important", "diversity rules", "User interface is not
> important, raw power is good", "everything should be a file",
> "architecture is less important than immediate workability". Often,
> these are expressed by chantible slogans that exhibits juvenile humor,
> such as "small is beautiful", "KISS (Keep It Simple, Stupid)".
>
> Suppose, we take a team of student programers
Can all "student programmers" be lumped into one homogeneous category?
With one particular level of skill and talent, applicable to your
example? What would that skill level be, roughly speaking?
> to produce a large software system.
....such as an OS? (just longing for specifics here) What is "large"?
(longing for more exact quantifiers)
> When the software is done, give it to software critics
But it's never really "done", is it? A part of the unix philosophy (or
unix practice, at least) is an ongoing perfecting/enhancing process
that involves a whole community of developers and users, isn't it? Or
do you mean "when the project reaches its [alpha/beta/rc1/etc.] stage"?
(again, wanting specifics - these development markers exist and are
well entrenched in the unix world -- why not use them here?)
> to analyze and come up with some principles that characterize its
> design decisions, without disclosing the nature of the programers. The
> characterization of such software, will more or less fit the
> descriptions of the "Unix Philosophy" as described in different
> ways by various unix celebrities.
Just to be sure, are you referring to the names you listed at the
beginning of your article? ("Brian Kernighan, Rob Pike, Dennis Ritchie,
....") If so, I'd make a more explicit tie, by means of such word as
"such as those mentioned above". If not, listing a couple of celebrity
names here would help the reader connect more dots.
> For example, it would focus on implementation simplicity as opposed to
> interface simplicity. It will not be consistent in user interface,
inconsistent across versions (over time), or inconsistent from platform
to platform (OS to OS), or, say, among various linux distributions? Or
among window managers and various API's?
and I don't understand what "implementation simplicity" is exactly.
(I'm not trying to be subversive here; just trying to understand.)
> but
> exhibits rawness. It would be correct only for most cases,
how is software "correct"? Do you mean "the software would work"?
(without errors, as expected)
what is a "case"? Do you mean, it would work under most *conditions*,
in most *environments*? I don't understand
as opposed
> to mathematically correct or generic. It would employee simplistic data
> structures and formats such as text-files, as opposed to a structured
> system or binary format that requires a spec. It would be speedy, but
a text data structure can require a spec.
And are you talking about quick-and-dirty, slapped-together, makeshift,
short-term-fix tasks? If yes, why not say that!
> less on scalability. It would consists of many small programs, as
> opposed to one large system with inter-dependent components.
How would such software rate on the "modular is good" scale?
"many small programs" seems to suggest modularity. If so, what makes
this "student software" undesirable, in spite of its (perhaps pseudo-)
modularity?
> It would
> be easy to patch and port, but difficult to upgrade its structure or
> adapt entirely new assumptions.
why?
> The essence of this theory is that when a software is produced for real
> world use,
By "real world", do you, by chance, mean the commercial/business world?
(Since it is /that/ world that seems to operate more on rigid deadlines
and bottom-line $$ constraints)
> it is necessary that it works in some acceptable way,
"some acceptable way"? Please quantify/define "acceptability" here
(the "some" doesn't help with the quantifying either)
> otherwise the software will be continuously debugged and refined. A
> software system written by a bunch of student or otherwise
> under-educated programers, but refined long enough for acceptably
another dangerously undefined term -- "under-educated". Some of your
readers may perceive this to be a reference to "accreditation"
(diplomas), which -- i believe most would agree -- would make your
assertion a gross error.
I personally know a highschool dropout programmer who, although
self-taught, exerts such diligence, thoroughness and ingenuity in his
work, that his products are state-of-the-art, to the extent that huge,
global, tycoon software corporations, fearing the undisputed
superiority of his product to theirs, have EXTENSIVELY attempted to buy
him out (with carrots, threats and all other means possible). Yes, a
guy with barely any official accreditation, whom an indiscriminant,
carelessly generalizing observer might pidgeon-hole into the
"under-educated" category.
> practical, real world use, will necessarily develop characteristics
> that is known as the Unix Philosophy.
Overall, when I read the article i wish for more specifics and for more
exact and understandable quantities, particularly when the very measure
of a quantity is used to make some argument (the chosen words create
only a *semblance* of measurement, and, in the end, leave the reader
with only a vague idea about the quantities entailed)
As is the point of your article to bemoan the shortcomings of student
programmers? This group is at first presented as an example, but then
seems to become the focus.
If so, should we not give any consideration to the stringency
*inherent* in student life, resulting from things like: shortage of
time (to do things methodically, with long-term planning), a variety of
insecurities, high competition pressure, lack of real-world practice?
andrew
|