On Fri, Nov 05, 1999 at 01:37:37AM +0200, Omer Zak wrote:
[lots snipped]
> Consider operating systems and programming languages which are becoming
> increasingly complicated and their implementations less trustworthy.
Permit me not to be impressed - or rather, not to be depressed - by
the figures brought in the quoted article.
That operating systems are becoming more complicated is merely a result
of the fact that the demands for software complexity are getting higher.
Those who maintain that in the "old days" software was *good* because it
was only written by Real Programmers are overlooking the fact that that
same good software was radically less complicated than comparable
software today.
A simple business application today is expected to do much more than
just crunch numbers. It is supposed to allow non-expert users to input
information in many ways - not in rigid 3270 forms - and issue complex
reports rendered beautifully in colour print.
But you know that.
Now the question I'm asking myself is this: where do I want my
complexity to lie? Should I have to write a scheduler of my own
every time I include a GUI in my application? Am I supposed to draw
bits and pixels to the printer by myself? Of course not! That's what
infrastructure is for, that's why there are layers in the model, and
that's why interfaces are complex! Too complex, you say? Well, bummer!
Maybe you want to give your just-hired novice programmer the task of
writing the asynch library for your 1/2 million LOC project? No? I
wonder why!
I think that the writer of the RISKS article is missing the point.
The Evil of Bloat does NOT lie in complexity in itself. Complexity is
inevitable, folks, and that's why we're supposed to work professionally
and handle it. The Evil of Bloat means /undue/ complexity, it means
incorrect layering, it means stupid design of infrastructures. The
numbers [I'm referring to the number of system calls from the original
article] in themselves mean nothing at all. I don't have a good metric
to offer as an alternative, but I guess such a metric will involve
breaking up the kernel into layers and seeing how many layering
violations there are. That conveys much more sense about the complexity
of the kernel than the number of system calls. Who cares how many of
those there are? Don't remember one? Look it up!
--
believing is seeing
[EMAIL PROTECTED]
http://www.forum2.org/gaal/
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
