From: Eric Armstrong <eric.armstrong@eng.sun.com>
John \"sb\" Werneken wrote:
>
> Eric, my thanks for all the work you put in to your presentation!
>
Thanks. Great to hear from you.
> I am NOT a computer person (except in the sense that a fairly good
> driver might be a "car person", lol). But I have done DOS keystroke
> macros that went on to several thousand lines, so I have some idea
> of what you are talking about when you discuss linking design
> decisions comments and so forth in to the code in an acceptable way.
>
I disagree. You ARE a computer person.
Quite a good one at that.
The impetus to automate difficult tasks, and the tenacity to learn
a language necessary to do it, are all it takes. Plus the persistence
to get the d**** things working. You obviously have *all* the
required characteristics.
:_)
> And the Doug had to say what he seems destined to say about
> EVERYTHING: "I was doing it in the 1960's".
>
Yeah. You gotta love him or hate him.
If you're not inclined towards jealousy, there's only one option.
:_)
> Maybe he was. Maybe he's an RMS who never found his ESR.
>
Now you got me. What's an RMS? What's an ESR?
> By analogy, to Microsoft and to Apache: Microsoft made it possible for
> people like me to learn how to do mundane tasks with a computer. A
> 'faster-better-cheaper' by order(s) of magnitude, as far as how much
> training I needed before I could figure out how to get some kinds of
> things done. All of a sudden, Microsoft is everywhere; I think that is
> why.
>
Good observation. I think there attention to user interface issues is
responsible for their wide public acceptance, too. They were the first,
and still possibly the *only* software company to fully understand the
importance of the user interface. To otherwise is to disregard the
importance of *my* time, but Microsoft appeared (appears?) to be the
only company that "gets it". They invested millions in an interface
department, and gave them veto power over product shipment. The result
was a set of consistent interfaces previously unknown in the industry.
Since then, I've found they have a seriously impaired sense of ethics,
so I cannot in good conscience be an MS supporter, but up until then
I was an MS-rooter all the way.
> Then Apache and Eric S Raymond et al evangelizing open source. Apache
> makes it possible for the majority of world web sites to have a server
> that is beyond doubt cheaper and is apparently at least as stable and
> capable, maybe more so. Now Apache is everywhere. "faster-better-cheaper'
> by order(s) of magnitude.
>
Definitely a strong proposition. However, their revenue-proposition
lacks a little. I think there must be a way to combine "open source"
with a "profit proposition", but I'm not sure what it is just yet.
> Somehow using links to comment code does not strike me the same way.
> I don't see a ten or more fold expansion in the number of people able
> to do significant programming. Or a ten-fold increase in programmer
> production.
>
Another very good observation. I agree with this, to a point, but there
are some other aspects...
> So is the first "breakout" use really this?
>
> I WOULD agree that if programmer productivity COULD be increased
> ten-fold, that that WOULD be a real breakthrough killer use of the
> concept. I just don't see this, doing that. Perhaps because as I
> said I don't program.
>
In my book, you *do* program, and you are making astute observations.
Now for the counter points:
1) When it comes to coding a problem you understand, no, I don't
think this is a "killer" app.
2) But when it comes to arriving at a consensual understanding of
a problem you aren't sure how to tackle, I think the kind of
system we are talking about will prove to be worth it's weight
in gold.
Example: There are many parts of the application that I am
really unfamiliar with: mail protocols, for example. We have
dozens of people with expertise in different areas, and we need
to hammer out a design that works. That kind of collaborative
design should be enhanced with this kind of system.
3) The Open Source environment currently does *not* work for such
problems. Open Source works when you put out a small kernel
early, so people begin to grasp how it works. Then they start
improving it. Over time, it grows in complexity and scope, but
at a body of expertise grows at the same time. When someone new
jumps in, their email is answered by one or more knowledgable
individuals, which allows them to come up to speed.
Open Source currently does *not* work when a) There is no code
to start from, and b) When a huge body of code which no one
understands is put out all at once. (I'm indebted to "The Cathedral
and The Bazaar" for making that clear. It's available in book
form these days.)
When no code exists, there is nothing that "brings it all together"
for developers. An email/document that allows for *reduction* into
new document versions would allow developers to a) explore the
design space, b) record design decisions, c) save alternatives, and
d) create a uniform "design picture" out of rambling discussions.
To date, open source efforts have been limited to extending and bug
fixing. This system could make it possible to initiate an open
source design in an open source way.
When a large body of code is released all at once (like Netscape's
mozilla), the opposite problem exists -- no one can "wrap their
head around it". You look at code and ask "Why is that there?" and
there is no one around to answer the question. Linked explanations
provide the possibility of answering "why", which means makes the
code that much more accessible to new people. (Interestingly, open
source code has much *more* documentation than is typical for the
industry as a whole. This system provides better mechanisms for
capturing the information.)
4) For large commercial projects, maintenance costs over the life the
project *dwarf* the initial cost of development. A company can spend
as much as 5 times on maintenance as it cost to build the project
originally. The *majority* of the time spent by maintainers is in
"getting up to speed". Any system which allows system understanding
to be recorded in an usable way stands to greatly improve the speed
and cost of maintenance.
So, even if initial coding is not dramatically improved, the ability
to explore the design space intelligently and augment maintenance
capabilities should more than justify an investment in installing and
learning to use such a system. In addition, I suspect that most
developers won't miss having to find misplaced braces!
Thanks for the opportunity to further clarify some of my thinking!
:_)
--------------------------- ONElist Sponsor ----------------------------
Valentine's Day Shopping Made Simple.
<a href=" http://clickme.onelist.com/ad/SparksValentine7 ">Click Here</a>
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:44 PDT