Gustavo Rios wrote:
> Hey folks,
> 
> sorry, but i found this on the web. May someone tell if it is serious,
> i myself could not believe it.
> 
> http://www.informit.com/articles/article.asp?p=424451&seqNum=1

The author is taking themselves seriously.  I don't recommend you make
the same mistake.


1) Everything Is a File (Unless It Isn't)
yeah, so?  The better solution would be to make somethings a file and
somethings not?  Hows' that different?  Or maybe the Plan 9 option which
is supposedly super-consistent, but lacking applications and usage in
real life.

2) Everything Is Text
I've worked on systems where some files are fixed records, others are
binary, some are text...thank you, I like the Unix approach.

3) No Introspection
Har.  MacOS as an example of what he wants?  Gee, isn't Apple DROPPING
that "feature" on OSX?  While it is great if you happen to be interested
in only talking to other Macs, it's a major irritant if you can't get
the ENTIRE REST OF THE WORLD to agree with you on how its done, and that
WILL NOT happen.

4) X11: Almost a GUI
a very weak, but almost valid point here.  I first saw this comment
about X almost 20 years ago.  X11 is kinda clunky in some regards, but
not so clunky that people have decided as a group on a good alternative.
    Propose an alternative, port it to a lot of platforms, port a lot of
software to it, and then we will talk.  Until then, enjoy X.

5) Standard Input, Standard Output
Without an alternative stated, this is complete bull.  Don't like STDIO?
 Don't use it.  Isn't appropriate for your app?  Don't use it.  Sheesh.

6) Synchronous System Calls
*yawn*
Hm.  If QNX is so much more efficient, why is Unix used on most
supercomputers now?  Obviously, the "issue" isn't big enough to cause
people to jump favorite OSs.

7) One-Way System Calls
Yes, this is clearly why there are so few applications written in Unix.
 *snicker*

8) C: Cross-Platform PDP Assembler
ok, this argument kills all credibility for the whiner..er..author in my
eyes.  C became the language of choice for because it WORKS and works
well for its intended purpose.  It was developed by people who used it
for their own use.  It was chosen by others because it worked for them.
 Yes, it was developed IN a Huge Company, but it was not pushed by them.
 Contrast that to a popular language right now which is being crammed
down the corporate world's throat.  I really suspect that ten years
after Sun Microsystems vanishes or quits pushing Java, Java will vanish
like scores of other proprietary languages, and C will still be actively
used.

ok, I may be a bit biased here.  I love C.  I fell in love with it
almost from the first article I read about it (Byte Magazine, early
1980s), and loved it when I first started programming in it (Software
Toolworks C on CP/M-80, later BDS C, also on CP/M-80.  BDS C could
produce "hello world" in a COMPLETELY self-contained 2k binary).  The
"White Book" was the ultimate programming language definition guide --
very complete, and very readable, and very slim.  You could feel the
bits and bytes flowing by in your programs.  Everything was an integer
-- pointers were integers, strings were integers, and even floating
point was just a bunch of bytes(=integers) you handled carefully.  Yeah,
obviously, it had some serious problems -- the "portable assembly
language" idea just doesn't work out for anything other than the most
basic of programs, so layers of abstraction were added in ANSI C.

The whole "C doesn't do strings" has always been complete Bull Sh*t in
my mind.  C does strings like the processor underneath does -- it
doesn't make complex operations involving moving thousands of bytes look
"simple".  While I do use Perl for some apps, the stuff it lets you get
away with in one line creeps me out horribly...knowing C and a few
(ancient) assembly languages, I know what is going on under the covers,
but I have sympathy for the new programmer (or very experienced
programmer who lacks certain bits of experience) who writes a ten line
program and wonders why it takes twenty minutes to run...

C isn't the ultimate language for all activities, but it is darned good,
it has been chosen through natural selection, not marketing money and
buzzword compliance.  Sure, I'd love to see a "better" language, but I
haven't seen it yet, and I have seen LOTS of "replacements for C" that
clearly will never take over.

Funny, many of the alternative languages to C are written in..C.  And,
they are available and were originally developed on Unix.

I'll admit, my love of C kinda faded when it went from being a "PDP
assembler" to a "completely portable, abstract, high-level language"
that ANSI C is now.  Yeah, yeah, I know, all kinds of advantages to
portable code.  But no ANSI C compiler does a "hello world" in a 2k
stand-alone binary...and you can't "feel" the bytes in your fingers
anymore (and if you do, you are writing non-portable code, which is bad.
 See why I stay out of src/ ? :).


Some clues to what the alternative to C will look like:
* It will NOT be a committee designed language.  There will be no "IEEE"
or other "working group" standardizing it before it gets popular.

* It will NOT be a corporate pushed language.  Programmers will adopt it
because it is the best tool for the job, not because someone wined and
dined their boss.

* It will not be developed in the academic world.  Sorry guys, but the
real development in the computer world has been done in Industry, by
people who have to show results to get paid, not papers to get published
by people who couldn't get a job in the real world.

* It will not be tied up in copyrights and patents.

* It will be the work of a very few people who saw a problem, fixed it,
and said, "wow, this is cool", and they show it to their friends.

* It will be ported to platforms other than Windows and Linux
immediately, both because it is possible and because it is desired.

* The language definition will be very concise (like the first edition
of the "White Book" (_The C Programming Language_).  There may be some
ambiguities.  Deal with it.  It won't be a monster, unreadable text like
the C++ definition.

* It will self-build.  It has to.  If it is a replacement for the
primary OS development language on most mainstream platforms, what other
language could it be written in?  (well, one possible answer: the local
assembly language.  Well, that is unlikely to happen, though there could
be some benefits...)

* The basic language will be very simple, so it can be "completely"
debugged.  No one wants to chase bugs in the compiler, it's bad enough
chasing them in one's own (or someone else's) code.  Of course, it would
be nice if the libraries could be kept simple enough to be made
"perfect", too...don't wait up.  Modern C is clearly too complex now for
"perfect" (and maybe, not even "good") compilers to be made (much less
libraries), and I don't think I've seen anyone propose a simpler
language to replace it (this might be the "killer argument" that C will
never be replaced).

(btw: if anyone agrees with everything I said here, you are probably NUTS :)


9) Small Tools, Not Small Libraries
Well, no one does either anymore.  Bloat is where it is at on almost all
platforms.  This point is completely irrelevant in the real world.  (we
joke about bash being bloated, yet I have a Unix system with less RAM in
it than our current sh(1) takes to run.  Yes, our sh(1) does a lot more
than that machine's shell does....but I don't think *THAT* much more...)

10) In-Band Signaling as Standard
*yawn*

11) Time for U(NIX) 2 Retire
No.  It is time for the "Unix-should-retire" crowd to shut the fsck up
and DEVELOP and SHOW AN ALTERNATIVE (yes, "shut up and hack").  It
should be so clearly better that people port apps to it and move to it
because they just want to.

Don't wait up.


Hey, Unix has "issues", I'll happily admit it, I could easily name ten
things that most of you would probably disagree with.  However, don't
talk, fix.  Improve.  Prove.  While it would be nice to scrap and
rebuild from scratch the Ideal OS, it just won't happen any time soon --
it took Unix over 30 years to get where it is now...that's a lot of
inertia to overcome.  Most of the people qualified to actually create a
new OS's code base are busy doing other things.  Most of the people
talking about it are clearly NOT qualified to be developing this new
code base.

Why do OpenBSD developers hack on the BSD code base?  Because it is the
best available starting point.  Don't reinvent wheels.  Polish the
existing poorly implemented ones, because it is unlikely you will
actually build a better one from scratch.

Inertia can get in your way, but it is something we usually appreciate
in the long run more than we think in the short run...

None of the issues with the basic design of Unix are significant
compared to the issues within the development process of Unix (a
fractured and internally squabbling base like the many Unix variants
provide will never compete successfully for market share against a
focused competitor like Microsoft...assuming MS wishes to focus at some
point).  On the other hand...chaotic, competitive worlds are where New
Ideas will happen and be developed and progressed.  You don't come up
with new ideas when you are too focused in one direction.

Anyway...yes, this is way off topic.  You should see the stuff I deleted
before hitting "send".  Let's just say that yes, I'm sure most people
will disagree with at least something I said, and I'm sure most people
will even disagree with some of the "facts" I have stated.  Fine, I'm
wrong.  Draw your own conclusions.  And send comments off-list. ;)


Nick.

Reply via email to