Re: Coding style - a non-issue

Stephen Satchell
2001-12-01T06:31:55Z

[cc list trimmed]

At 07:30 PM 11/30/01 -0800, Larry McVoy wrote:
>Yeah, right, Linus. We should all go home and turn loose the monkeys and
>let them pound on the keyboard. They'll just as good a job, in fact, by
>your reasoning they'll get there faster, they aren't so likely to waste
>time trying to design it.

You are confusing the production of Shakespeare with the production of good
OS code.

The high-level design aspect is that there is a problem to be solved or a
feature to be provided. That represents a goal. Some goals are good and
some goals are bad. In many cases, you learn which when you actually do
the code to implement the goal, and determine whether it helps, hinders, or
just bloats the OS.

The lower-level design aspect is planning how to achieve the
goal. Implementation of the lower-level design in code to achieve the goal
can contain flaws, flaws that don't appear on paper but raise ugly warts
when you actually try the implementation out. In this sense, this is like
a mutation to achieve a specific effect -- blue eyes, say -- that has a
disastrous side effect -- it causes the heart to have a single chamber
instead of four.

This assumes that your, um, mutation even lets the organism live. Many
don't. We call it debugging.

>I can't believe the crap you are spewing on this one and I don't think you
>do either. If you do, you need a break. I'm all for letting people explore,
>let software evolve, that's all good. But somebody needs to keep an eye on
>it.

I don't know you, so I don't know how long you have been in the
industry. I've watched Unix evolve from the beginning. AT&T streams
versus Berkeley sockets was a wonderful war, and we are all for the better
for the experimentation because we got the best of both -- especially as I
was involved in ARPAnet in the beginning and saw the influence of what
turned into TCP/IP in both environments. We have different styles of
system initialization, with some being better for manual management and
some being better for package management -- and we have both living in the
world today. The development of X-terminals was fun, too, to try to
divorce the requirements for a screen from the system that feeds it, and
yet today the two different processes run together in a single box without
too much problem.

These were the products of evolution, of system designers trying to meet a
need, and the process of getting there was painful and left a lot of
corpses behind it -- piles of dead code, for sure, but also dead companies
and burned-out development people. That's part of the business,
particularly in the commercial world.

"But someone has to keep an eye on it." Very true. After all, in this
process of natural selection, how do we weed out the mutations that don't
work? In the Linux development environment, we have several levels of
weeding going on. First, there is peer testing -- people downloading
patches and trying out new things, which weeds out the worst of the
mutations. Then, there are the maintainers who sit in judgement as the
patches roll by, picking out the deformed ones bodily and making sure that
two patches that change the same code play nicely with each other. We then
have the pre-releases, which for the 2.4 tree were patch-inspected and
maintained by Linux and by Alan Cox, which people can download and try on
playpen systems with applications to see if anything subtly nasty crept in
-- this weeds out a few of the mutations that harm the organism but doesn't
kill it outright. Finally, we have a production release into which people
throw all the varied and wacky applications -- and sometimes an ugly (like
the VM problem) finally is exposed to the light.

Interestingly, you see a similar development process at commercial software
vendors and with the successful Open Source projects. Some of the details
differ (especially the details on the review process) but the overall
process is similar. Why? It works.

I suggest you check out this site http://www.swebok.org/ and specifically
download this document
http://www.swebok.org/documents/stoneman095/Trial_Version_0_95.pdf AND READ
IT before responding further. While the Software Engineering Body Of
Knowledge does not use the exact concepts that Linus used in describing how
things are done, you will find interesting correlations between what is
described by this document and the idea that you have called "crap."

Pay particular attention to the section on Validation and Verification.

Stephen Satchell