Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CL and UML

114 views
Skip to first unread message

Tim Bradshaw

unread,
Jun 13, 2001, 3:10:31 PM6/13/01
to
Has anyone had any experience with describing CL systems with UML?
I'm not really familiar with UML, but it looks laughably too
restrictive to describe CLOS - I'd like hear any other experiences
though.

--tim

(Who suspects that one reason Lisp hasn't won is just because it is
too expressive to wedge into religious orthodoxies like UML and
therefore must be destroyed as heretical, this being about 1209.)

Raymond Toy

unread,
Jun 13, 2001, 3:46:04 PM6/13/01
to
>>>>> "Tim" == Tim Bradshaw <t...@tfeb.org> writes:

Tim> Has anyone had any experience with describing CL systems with UML?
Tim> I'm not really familiar with UML, but it looks laughably too
Tim> restrictive to describe CLOS - I'd like hear any other experiences
Tim> though.

Tim> --tim

Tim> (Who suspects that one reason Lisp hasn't won is just because it is
Tim> too expressive to wedge into religious orthodoxies like UML and
Tim> therefore must be destroyed as heretical, this being about 1209.)

Sorry, can't help with UML and CLOS, but I find it rather interesting
that with Rational Rose (a UML tool), the saved files look very much
like lisp. Don't know if it really is or not.

Ray

Craig Brozefsky

unread,
Jun 13, 2001, 10:45:42 PM6/13/01
to
Tim Bradshaw <t...@tfeb.org> writes:

Well, I've avoided UML up to this point, but this little thread
reminded me of a laughable bit of theory mongering on the topic of OO
programming:

http://www.nettime.org/nettime.w3archive/200106/msg00050.html


--
Craig Brozefsky <cr...@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci

Chris Double

unread,
Jun 14, 2001, 5:06:32 AM6/14/01
to
Tim Bradshaw <t...@tfeb.org> writes:

> Has anyone had any experience with describing CL systems with UML?
> I'm not really familiar with UML, but it looks laughably too
> restrictive to describe CLOS - I'd like hear any other experiences
> though.

The question pops up occasionally on comp.object about using UML with
generic function based languages (CLOS, Dylan, etc). You could try
searching the groups.google.com archives for them. A quick search
using 'UML CLOS' brought up quite a few articles.

Chris.
--
http://www.double.co.nz/cl

David Bakhash

unread,
Jun 14, 2001, 6:24:00 AM6/14/01
to
>>>>> "tim" == Tim Bradshaw <t...@tfeb.org> writes:

tim> Has anyone had any experience with describing CL systems with UML?
tim> I'm not really familiar with UML, but it looks laughably too
tim> restrictive to describe CLOS - I'd like hear any other experiences
tim> though.

I think that if you consider a Corba implementation in CL, such as one
in ACL or LispWorks, then UML is more applicable. Corba development
imposes restrictions on OOP that mesh well with UML, as far as I know.

dave

Tim Bradshaw

unread,
Jun 14, 2001, 6:45:57 AM6/14/01
to
David Bakhash <ca...@alum.mit.edu> writes:

>
> I think that if you consider a Corba implementation in CL, such as one
> in ACL or LispWorks, then UML is more applicable. Corba development
> imposes restrictions on OOP that mesh well with UML, as far as I know.

Yes, that's the problem. I want to be able to use a great deal of
what CLOS offers, not toe the priesthood's line.

--tim

Alain Picard

unread,
Jun 14, 2001, 7:33:01 AM6/14/01
to
Tim Bradshaw <t...@tfeb.org> writes:

> David Bakhash <ca...@alum.mit.edu> writes:

> > Corba developmentb


> > imposes restrictions on OOP that mesh well with UML, as far as I know.
>
> Yes, that's the problem. I want to be able to use a great deal of
> what CLOS offers, not toe the priesthood's line.
>

I wonder if UML has a special kind of box for :before
methods? for metaclasses? :-)

Seriously -- why would you want to do this? Are you trapped
in hell (i.e. real life) and need this to justify something
to a pointy haired boss? (I'm not being sarcastic -- that's
the best reason I can think of.)

Long long ago, in a galaxy far far away, I did the whole Rational Rose
thing. Put pictures in the repository, shared them with co-workers,
coded C++ to those interfaces, the lot. Now I think only quickly
drawn pictures, _in pencil_, in no `formal' pictorial language, are
useful, to communicate to others (and my future self) what something
was about. For the rest, "the source code is the design", aided, if
need be, by a 1-2 page technical memo.

Does _anybody_ here actually think UML like tools are _useful_?
If so, how?

--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>

Chris Double

unread,
Jun 14, 2001, 8:28:49 AM6/14/01
to
Alain Picard <api...@optushome.com.au> writes:

> Does _anybody_ here actually think UML like tools are _useful_? If
> so, how?

I personally believe tools like Rational Rose can be damaging if not
used correctly. They can slow development down, constrain the design
such that it fits into the limitations of the tool or UML and endless
hours are spent working around problems with code generation/reverse
engineering. I haven't really worked for a company that has honestly
made effective use of Rose. It is used but it provides little benefit
to the development process other than giving something to the auditors
when they ask for documentation and don't wish to accept hand written
notes or prototype/code as documentation.

I couldn't imagine using these tools for Lisp development without
destroying any chance of getting the productivity gains of Lisp.

Then again, Rational Rose data files seem to be s-expression
based. Write a lisp program to generate your UML models by producing
these data files. Or use the OLE AUtomation interface exposed by Rose
to generate the diagrams from Lisp. Probably work better than their
reverse engineering options anyway...

Rational used to have a tool (might still do) called Soda that
analysed Rose models and generated word reports base on templates. It
was written (I think) in word basic, or VBA, or something, and was
a tad flaky. I wonder if they used Rose to design it. Or if they use
Rose to design Rose.

One way for Lisp to succeed in the Rational universe is for a Lisp app
that uses Ole Automation to analyse rose models and spit out some
decent documentation/reports. Or rewrites the system all in Lisp ;-)

That said, I have had good success with Rose as a diagraming tool - no
code generation, no Rational Unified Process support. Just quick
pictures of the design to use in supporting documents - mainly because
my hand drawings, well, suck.

Anyway, enough ranting from me...you can tell I've been locked in a
Rational Rose/c++ development world for too long lately by the length
of this post.

Chris.
--
http://www.double.co.nz/cl


Tim Bradshaw

unread,
Jun 14, 2001, 9:01:56 AM6/14/01
to
Alain Picard <api...@optushome.com.au> writes:

>
> I wonder if UML has a special kind of box for :before
> methods? for metaclasses? :-)

Multimethods, user-definable method combinations?

>
> Seriously -- why would you want to do this? Are you trapped
> in hell (i.e. real life) and need this to justify something
> to a pointy haired boss? (I'm not being sarcastic -- that's
> the best reason I can think of.)

Not quite. I'm standing on the rim of hell, looking in, and watching
those trapped there hammer nails into their own heads and gouge each
other's eyes out with spoons, all the time insisting that they are in
heaven. Strangely the bosses have remarkably smooth & rounded heads -
it is the programmers themselves who are sharpening them to points, in
the pauses between the nail-hammering and gouging.


> Does _anybody_ here actually think UML like tools are _useful_?
> If so, how?

I think they might be useful if you are stuck with crap, rigid,
non-introspective languages like C++. For the life of me I can't see
why a Lisp system should not document itself - if you want a class
graph ask the system to draw you one, if you want to know what methods
there are for a GF, ask it. Trying to use UML to document a system
which is strictly more powerful than it, with no mechanism to keep the
UML design in sync with the code, is going to result in a huge
document which initially does not describe the system it purports to
model, and which drifts rapidly further away from it over time.

But I'm probably wrong - they won't even lend me a head-sharpener
after all.

--tim

Christian Lynbech

unread,
Jun 14, 2001, 11:06:03 AM6/14/01
to
>>>>> "Alain" == Alain Picard <api...@optushome.com.au> writes:

Alain> Tim Bradshaw <t...@tfeb.org> writes:
>> David Bakhash <ca...@alum.mit.edu> writes:

>> > Corba developmentb
>> > imposes restrictions on OOP that mesh well with UML, as far as I know.
>>
>> Yes, that's the problem. I want to be able to use a great deal of
>> what CLOS offers, not toe the priesthood's line.
>>

I think the main consideration is what to use UML for. UML is after
all to modelling as blank sheets of paper is to writing - just a tool.

Let me first note that I am speaking as a complete novice. I have only
read some of the UML books, so most of what follows will be pure
speculation.

However, I have a distinct feeling that UML could be usefull, at least
to us, as a tool for documenting various aspects of the system.

Alain> I wonder if UML has a special kind of box for :before
Alain> methods? for metaclasses? :-)

The crucial point would be to hit the right level of abstraction. Trying
to rewrite the actual detailed code in diagrams would be pretty pointless.

I do not remember seeing anything that would be directly insufficient
wrt. CLOS. I am for instance pretty sure that multiple inheritance is
explicitly supported, and it should also be remembered that UML is
designed to be extensible.

Alain> Seriously -- why would you want to do this?

For instance, if I wanted to write a tool that could display the class
structure of my lisp application, I would make it draw UML
diagrams. The usefull thing is that a) UML has the concept of
metamodels, so I could to some level of formality define what the
generated diagrams would mean, and b) since UML is (I think) a defacto
standard, it should give other viewers a warm fuzzy feeling when they
see it.

I wouldn't necessary want to use standard UML drawing tools, such as
rational rose. I would probably prefer to use some other (textual)
representration and have the UML diagrams generated from that. In
fact, I would consider to "define" the modelling or documentation
artifact through annotations in the actual code, such that the overall
software architecture would to some degree be embedded within the
program it was meant to document (yes, I think literary programming is
an extremely exiciting methodology).


------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: christia...@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)

Greg Menke

unread,
Jun 14, 2001, 11:20:27 AM6/14/01
to

> I personally believe tools like Rational Rose can be damaging if not
> used correctly. They can slow development down, constrain the design
> such that it fits into the limitations of the tool or UML and endless
> hours are spent working around problems with code generation/reverse
> engineering. I haven't really worked for a company that has honestly
> made effective use of Rose. It is used but it provides little benefit
> to the development process other than giving something to the auditors
> when they ask for documentation and don't wish to accept hand written
> notes or prototype/code as documentation.

A group nearby our lab made a huge investment in Rational Rose
Realtime with a view towards using it as The Development Environment,
and are running into huge problems; pretty much the typical thing,
poor/erratic support from RR, very few people who have done
complicated stuff, a couple somewhat misleading promises made by RR
salespeople.

We went thru their (very expensive, convientently vague) training
class, and the code generation features ook interesting, but I think
are only loosely suited to for really realtime work. The state
machine stuff seems pretty reasonable, but any user code in the state
transitions themselves will cause the Rational Realtime clock to slip,
and varying paths thru the user code will probably cause jitter as
well. Another issue relates to interfacing RR to other systems, it
wants to own everything around it- and its not entirely clear how a RR
program can be integrated as a subsystem that plays nice with
everything else. I think its also an oversimplification to force a
choice of either making all code a state machine or putting it outside
Rose's documentation domain.

>
> That said, I have had good success with Rose as a diagraming tool - no
> code generation, no Rational Unified Process support. Just quick
> pictures of the design to use in supporting documents - mainly because
> my hand drawings, well, suck.

I agree, I think it would make a great documentation tool; but not so
greate as development platform.

Gregm

Tim Bradshaw

unread,
Jun 14, 2001, 11:31:30 AM6/14/01
to
Christian Lynbech <christia...@ted.ericsson.dk> writes:

>
> For instance, if I wanted to write a tool that could display the class
> structure of my lisp application, I would make it draw UML
> diagrams. The usefull thing is that a) UML has the concept of
> metamodels, so I could to some level of formality define what the
> generated diagrams would mean, and b) since UML is (I think) a defacto
> standard, it should give other viewers a warm fuzzy feeling when they
> see it.

Well, I'd do this by asking the Lisp system what the class graph was,
and using one of the graphing tools - it's trivial in CLIM, LW comes
with a class grapher (as may Allegro - I use one I wrote in CLIM so
I've never checked), and psgraph will serve at a pinch for
non-graphically-endowed implementations. I guess this fails on the
warm fuzzines (being warm and fuzzy is very importent when your job
consists of hammering nails into your own head).

--tim

Thomas F. Burdick

unread,
Jun 14, 2001, 2:37:42 PM6/14/01
to
Christian Lynbech <christia...@ted.ericsson.dk> writes:

> (yes, I think literary programming is an extremely exiciting
> methodology).

I used to be a huge LP enthusiast. Then I wrote a significant Lisp
system without it, then tried to write another with an LP system, and
found it really constraining. So I ditched the LP system (noweb,
which I've found to be the least intrusive). I've found docstrings
and texinfo-generating scripts to be enough. Has anyone had good
experiences with LP and Lisp? I still find LP to be a life-saver with
C++. I'd bet it's because Lisp code tends to be an order of magnitude
more expressive, thus less need for LP. Not really sure, though ...

Tim Bradshaw

unread,
Jun 14, 2001, 3:07:19 PM6/14/01
to
t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> I'd bet it's because Lisp code tends to be an order of magnitude
> more expressive, thus less need for LP. Not really sure, though ...

Also, I think that because you can ask a CL system questions about
itself (what methods does this GF have?, what are the subclasses of
this class? and for many systems things like let me edit the
definition of this function) there's less requirement for an external
system which does it for you, except usually statically rather than
dynamically.

--tim

Ray Blaak

unread,
Jun 14, 2001, 8:52:18 PM6/14/01
to
Chris Double <ch...@double.co.nz> writes:
> Then again, Rational Rose data files seem to be s-expression
> based. Write a lisp program to generate your UML models by producing
> these data files.

I wouldn't do this. The data file format has a tendency to change from release
to release.

> Or use the OLE AUtomation interface exposed by Rose to generate the diagrams
> from Lisp. Probably work better than their reverse engineering options
> anyway...

A much more stable way of programmatically talking to Rose.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@infomatch.com The Rhythm has my soul.

Ray Blaak

unread,
Jun 14, 2001, 8:49:58 PM6/14/01
to
Alain Picard <api...@optushome.com.au> writes:
> Long long ago, in a galaxy far far away, I did the whole Rational Rose
> thing. Put pictures in the repository, shared them with co-workers,
> coded C++ to those interfaces, the lot. Now I think only quickly
> drawn pictures, _in pencil_, in no `formal' pictorial language, are
> useful, to communicate to others (and my future self) what something
> was about. For the rest, "the source code is the design", aided, if
> need be, by a 1-2 page technical memo.

Strong agreement here. My experience has been exactly the same in this
regard. Most of the time the UML tools are just a way to waste more time and
resources.

Letting the source code document itself, with only the very high level
architecture/design information in smallish easy-to-read documents lets
software be developed faster and be more maintainable, mainly because there
are less things to go wrong.

Of course, this only works if the source code is actually written in a
readable, maintainable way.

> Does _anybody_ here actually think UML like tools are _useful_?
> If so, how?

On big projects where *everything* needs to be tracked, your diagrams are
viewed by hundreds of people, your diagrams need tool support to verify, etc.

E.g. air traffic control projects.

Even then, I would still make try to make the source code king and use decent
reverse engineering tools to keep the models and code in synch.

Also, a proper UML model can include all sorts of requirements information and
related them to portions of your design, and can also include scenarios and
activity/state diagrams, deployment diagrams, etc. These kinds of things also
need to be decently tracked.

Smallish projects can often get away with not doing this, but the big ones
require tool support at every level.

Ray Blaak

unread,
Jun 14, 2001, 8:39:51 PM6/14/01
to
Raymond Toy <t...@rtp.ericsson.se> writes:
> Sorry, can't help with UML and CLOS, but I find it rather interesting
> that with Rational Rose (a UML tool), the saved files look very much
> like lisp. Don't know if it really is or not.

No it's not. It is just a hierarchical parenthesized data format, that's all,
with some wierd syntactical quirks.

To be really lisp, it needs to be evaluated by a lisp engine.

David Bakhash

unread,
Jun 15, 2001, 6:13:55 AM6/15/01
to
>>>>> "tim" == Tim Bradshaw <t...@tfeb.org> writes:

tim> David Bakhash <ca...@alum.mit.edu> writes:
>>
>> I think that if you consider a Corba implementation in CL, such as
>> one in ACL or LispWorks, then UML is more applicable. Corba
>> development imposes restrictions on OOP that mesh well with UML,
>> as far as I know.

tim> Yes, that's the problem. I want to be able to use a great deal
tim> of what CLOS offers, not toe the priesthood's line.

So what you're saying, based on all the posts, is that you're not
using Corba, but CLOS, and want something like a UML tool.

Unless you plan to use RR or some other piece of modeling software,
why not just augment the UML notation, adding whatever CLOS features
you intend to use and represent in your diagrams? This may not be
that easy, but given that you've already written your own class
browser in CLIM, you're probably comfortable enough to graphically
represent the CLOS ideas.

I admit that I don't think I would attempt something like that. I
feel more old-fashioned. I just wanna understand a problem enough to
write the code that solves it. UML? Whah?

dave

james anderson

unread,
Jun 15, 2001, 6:29:06 AM6/15/01
to Tim Bradshaw

i posted a query re UML/XMI a few days back.

i've yet to get an answer. i would have thought it useful to be able to
export descriptions in a "standard" form for visualization and/or import
them from other implementation environments.

...

Tim Bradshaw

unread,
Jun 15, 2001, 7:44:24 AM6/15/01
to
David Bakhash <ca...@alum.mit.edu> writes:

>
> So what you're saying, based on all the posts, is that you're not
> using Corba, but CLOS, and want something like a UML tool.

Well, I'm not quite at liberty to describe the situation as well as
I'd like to, unfortunately. I'm in no danger of having to use UML
*myself*, but I am interested if anyone else has had success doing so
to describe CLOS systems.

You are right that I'm dealing with programs written in unrestricted
CLOS (including some MOP stuff, though that's actually not a problem I
think), and not CORBA or some other subset.

> I admit that I don't think I would attempt something like that. I
> feel more old-fashioned. I just wanna understand a problem enough to
> write the code that solves it. UML? Whah?

My personal opinion is that this is right. Further, if I want to
understand a large CLOS program I'd do it by writing tools to get it
to describe itself (using the small amout of MOP stuff you need to do
that). I don't see any real point in using some modelling tool which
has no mechanism of ensuring that the model is consistent with the
program, still less one that does not seem to be powferul enough to
describe the program at all.

I suppose the problem with this is that the program might be full of
all sorts of low-level grut which is somehow not appropriate for the
model. I think this is indicative of other problems - if there is a
huge amount of stuff which is not described by the model, then the
model is not a very good view of what the program does, so it's not
really much use. I think the solution to this is stop wsriting in
COBOL, and find a language which provides tools that let you abstract
things at the level where a model makes sense.

So I don't, personally, think UML is useful for CLOS (and actually I
question its utility in general), but I'm interested to know if others
have succeeded with it. From the responses so far, it seems they have
not.

--tim

Alain Picard

unread,
Jun 15, 2001, 9:14:11 AM6/15/01
to
Ray Blaak <bl...@infomatch.com> writes:

> Alain Picard <api...@optushome.com.au> writes:
>
> > Does _anybody_ here actually think UML like tools are _useful_?
> > If so, how?
>
> On big projects where *everything* needs to be tracked, your diagrams are
> viewed by hundreds of people, your diagrams need tool support to verify, etc.
>
> E.g. air traffic control projects.
>

I believe you are correct. I think on those very large system,
the cost of producing quality software scales almost exponentially
with the size of the problem (and development effort). A colleague
worked on control systems for the F16 aircraft agrees that that
software ends up costing $10,000 per line of code.

Such tools probably _can_ help in those situations. I guess I'm
not saying they're utterly useless; I'm saying they imply a world
in which I have no wish to live. I'll stick with Lisp and small
teams for as long as I can, and work on making small teams more
productive (and able to tackle larger projects through higher
productivity) instead. I've found many of the methods used by
XP useful in this regards. But I wouldn't want my team responsible
for an air traffic or nuclear power plant control system...

I guess that makes me a coward... :-)

Paolo Amoroso

unread,
Jun 15, 2001, 10:58:27 AM6/15/01
to
On 14 Jun 2001 11:37:42 -0700, t...@conquest.OCF.Berkeley.EDU (Thomas F.
Burdick) wrote:

> I used to be a huge LP enthusiast. Then I wrote a significant Lisp
> system without it, then tried to write another with an LP system, and
> found it really constraining. So I ditched the LP system (noweb,

Did the literate programming tools you used let you interactively evaluate
Lisp code? If not, how did you deal with that?


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Kurt B. Kaiser

unread,
Jun 15, 2001, 12:30:29 PM6/15/01
to
Alain Picard <api...@optushome.com.au> writes:

> Ray Blaak <bl...@infomatch.com> writes:
>
> > Alain Picard <api...@optushome.com.au> writes:

> > <snip>


> > On big projects where *everything* needs to be tracked, your diagrams are
> > viewed by hundreds of people, your diagrams need tool support to verify,
> > etc.
> >
> > E.g. air traffic control projects.
> >
>
> I believe you are correct. I think on those very large system,
> the cost of producing quality software scales almost exponentially
> with the size of the problem (and development effort). A colleague
> worked on control systems for the F16 aircraft agrees that that
> software ends up costing $10,000 per line of code.
>
> Such tools probably _can_ help in those situations. I guess I'm
> not saying they're utterly useless; I'm saying they imply a world
> in which I have no wish to live. I'll stick with Lisp and small
> teams for as long as I can, and work on making small teams more
> productive (and able to tackle larger projects through higher
> productivity) instead. I've found many of the methods used by
> XP useful in this regards. But I wouldn't want my team responsible
> for an air traffic or nuclear power plant control system...
>

Here's an article on how NASA gets _one_ error in 420,000 LOC on each of the
last three releases of the shuttle SW. They seem to have spent more on the
order of $3000/LOC (WAG!); their budget is 35M$ per year, very small compared
to the program. They produce about 10 LOC per page of specification.

http://www.fastcompany.com/online/06/writestuff.html

KBK

Larry Loen

unread,
Jun 15, 2001, 2:56:28 PM6/15/01
to
Alain Picard wrote:

> Seriously -- why would you want to do this? Are you trapped
> in hell (i.e. real life) and need this to justify something
> to a pointy haired boss? (I'm not being sarcastic -- that's
> the best reason I can think of.)
>
> Long long ago, in a galaxy far far away, I did the whole Rational Rose
> thing. Put pictures in the repository, shared them with co-workers,
> coded C++ to those interfaces, the lot. Now I think only quickly
> drawn pictures, _in pencil_, in no `formal' pictorial language, are
> useful, to communicate to others (and my future self) what something
> was about. For the rest, "the source code is the design", aided, if
> need be, by a 1-2 page technical memo.
>
> Does _anybody_ here actually think UML like tools are _useful_?
> If so, how?
>

Is this the counsel of despair, the wisdom of experience, or the glorification of the inadequate?

I, too, have tried these things at various points of my career and have also found them wanting.

However, if we computer scientists want to be taken seriously as an engineering discipline, we're going to have to find a way to move beyond "the code
is the design" supplemented (if at all) by a few cave paintings that tend to get tossed in the trash by mistake sometime within the first five years
of the code's working life.

No civil engineer would say "the bridge is the design" and tell you (and often distainfully at that) to reconstruct its design girder by girder.

I've seen the other side of it. When I worked in a University many years ago, as a starving student, I ended up with the only surviving documentation
of an important business process I slightly upgraded for them. It somehow disappeared. I was sure I had returned it, but no matter. It was gone.
Over the next ten years, I got occassional letters begging me to look through my possessions to see if I had somehow, accidentally, retained it. Even
though I had, in fact, diligently searched for it twice before I ceased doing so.

Clearly, "the code is the design" was a miserable failure; problems recurred often enough that they wished for that original design doc.

Perhaps for LISP "the code is the design" works, but for COBOL, C, C++, APL, FORTRAN, and other languages I could name, it has been a miserable
failure in my experience of it. At the least, reconstruction from "the code is the design" is not the most productive exercise. At worst, no one has
a real understanding of what the code really does, or one lousy maintainer with a poor understanding wrecks the true intent beyond recognition and it
thereafter survives by kludges, guesses, and patches.

I don't know how to fix this, but after heaping whatever justified scorn on the current tools we care to make, someone, somewhere I hope will be
inspired with a useful and correct answer to this problem.


Larry

Thomas F. Burdick

unread,
Jun 15, 2001, 3:17:19 PM6/15/01
to
Paolo Amoroso <amo...@mclink.it> writes:

> On 14 Jun 2001 11:37:42 -0700, t...@conquest.OCF.Berkeley.EDU (Thomas F.
> Burdick) wrote:
>
> > I used to be a huge LP enthusiast. Then I wrote a significant Lisp
> > system without it, then tried to write another with an LP system, and
> > found it really constraining. So I ditched the LP system (noweb,
>
> Did the literate programming tools you used let you interactively evaluate
> Lisp code? If not, how did you deal with that?

Well, I pretty much use noweb and emacs with noweb-mode, so I'm in
LaTeX mode in the documentation sections, and ILISP mode in the lisp
sections. So you get the normal emacs support for this (except I had
to re-write the code to evaluate the whole buffer to run it through
notangle first, but that was simple enough).

Alain Picard

unread,
Jun 16, 2001, 1:36:53 AM6/16/01
to
Larry Loen <lwl...@rchland.vnet.ibm.com> writes:

> However, if we computer scientists want to be taken seriously as an
> engineering discipline, we're going to have to find a way to move
> beyond "the code is the design" supplemented (if at all) by a few cave
> paintings that tend to get tossed in the trash by mistake sometime
> within the first five years of the code's working life.
>

I'm not sure I want whatever it is I do to "be taken seriously as an
engineering discipline". That's not to say I don't want whatever it
is I do to be taken seriously.

I think terms "software engineer" and "software engineering" are
_dangerous_. What I mean by that is; they are a metaphor, and, as
all metaphors, they may direct your thinking along certain lines and
blind you from reality.

I read in Gabriel's book "Patterns of Software" a passage where he
uses a different metaphor for software: that of a plant, (or a
garden). The point is that the software is viewed as organic, alive,
with a mind of its own. Sure, you "design" your garden, arrange the
plants initially, water them, tend them, but, ultimately, some thrive
and some don't. Your job is to accommodate them. If you succeed, you
end up with a garden which is extremely beautiful, but has only a
passing relationship with what your original "design", though it may
indeed fulfill your original intent.


> No civil engineer would say "the bridge is the design" and tell you
> (and often distainfully at that) to reconstruct its design girder by
> girder.

No civil engineer would be told by their customer "Sorry mate, we just
moved the far bank back 50 metre, you don't mind, patching that up, do
you?" when the bridge is 90% complete. This happens to me in my work
all the time. I accommodate such requests.

How can this be so? Clearly, because software artifacts are
altogether different from engineering artifacts.

If we used the metaphor "Software Authoring", well, the request might be:
"Mind adding a few more chapters, or changing the ending?".
This would be much more in line with what we actually do.

Management types love the engineering metaphor, of course, because
they need to be able to draw up budgets, schedules, etc. Ask an
editor how he schedules his authors to deliver books on time...

>
> [Tale of woe and lost document snipped]
>

If we're going to be "taken seriously", as engineers or on our
own merits, we'll have to do better than that. Our profession,
craft, whatever you wish to call it, is very young. Most of what
we do is lousy. How many software masterpieces do you know about?
How many of us have written one? I sure haven't.

Apologies for ranting, but I think this engineering metaphor is _so_
destructive. I've done the big up-front design bit. Guess what --
all those documents we sweated over for months became obsolete the
moment we started coding. I don't think it's because we were
incompetent---I think it's _inherent_ in what we do that it entails
many small decisions, which have to be taken during the lifetime of
the process. So, when we actually had to fix or change something
months later, did we go to these documents?ı Of course not---we went
to the source code. And guess what: it sucked, because it was all
supposedly documented "elsewhere". I would have _much_ preferred a
1/2 page memo about the central ideas of a given subsystem, (the
_why_), and well written and commented code to tell me the _how_.


ıWell, some naïve people, like myself, did look up these documents
first, only to discover how useless they were in the face of harsh
reality.

Tim Bradshaw

unread,
Jun 16, 2001, 10:58:39 AM6/16/01
to
* Larry Loen wrote:
> However, if we computer scientists want to be taken seriously as an
> engineering discipline, we're going to have to find a way to move
> beyond "the code is the design" supplemented (if at all) by a few
> cave paintings that tend to get tossed in the trash by mistake
> sometime within the first five years of the code's working life.

> No civil engineer would say "the bridge is the design" and tell you
> (and often distainfully at that) to reconstruct its design girder by
> girder.

Although I think that becoming an engineering discipline - which
software `engineering' clearly is not - is desirable, I think it's
dangerous to take the analogy this far. Code is not like bridges:
bridges aren't amenable to being taken to bits and put back together
again at almost no cost, don't usually have comments, or
self-documenting features, aren't usually introspective, are made from
parts that wear out in unpredictable ways rather than ideal
mathematical constructs and so on. The whole notion of taking a
source description and then automatically transforming it into object
code which does the work is just not like bridge building at all.

--tim

Jochen Schmidt

unread,
Jun 16, 2001, 12:02:21 PM6/16/01
to
Tim Bradshaw wrote:

I fully agree!
And object code itself is only here for practical reasons - it is only a
better machine-interpretable notation of the same thing.
Programming is much more comparable to art than to engineering.

Regards,
Jochen

Andy Freeman

unread,
Jun 16, 2001, 6:10:06 PM6/16/01
to
> No civil engineer would say "the bridge is the design" and tell you (and
> often distainfully at that) to reconstruct its design girder by girder.

Tim Bradshaw wrote half of my response to this.

The other half is that "real engineers" have a useful design representation,
a representation that is not the artifact. For bridge designers, that
representation is a set of blueprints. They can analyse this representation
and extract almost any useful information.

I suspect that "not the artifact" is important.

In addition, bridges (and their components) are static.

Plus, we don't blame their designers for certain consequences. (No
one blames road designers for allowing the Nazis into Czechoslovakia.)

Note that we're just getting to the point where blueprints can be mechanically
transformed into objects.

-andy

Jochen Schmidt

unread,
Jun 16, 2001, 6:41:42 PM6/16/01
to
Alain Picard wrote:

> If we used the metaphor "Software Authoring", well, the request might be:
> "Mind adding a few more chapters, or changing the ending?".
> This would be much more in line with what we actually do.

Yes - this is a much better metaphor than the ridiculous "Software
Engineering" metaphor. Is this notion actually used somewhere? It sounds
familiar to me but I cannot remember hearing it anywhere else...

>
> Management types love the engineering metaphor, of course, because
> they need to be able to draw up budgets, schedules, etc. Ask an
> editor how he schedules his authors to deliver books on time...

That's exactly the fact!

ciao,
Jochen

Marcin Tustin

unread,
Jun 16, 2001, 8:16:40 PM6/16/01
to
Tim Bradshaw <t...@tfeb.org> wrote:
> Alain Picard <api...@optushome.com.au> writes:

>>
>> I wonder if UML has a special kind of box for :before
>> methods? for metaclasses? :-)

> Multimethods, user-definable method combinations?

>>
>> Seriously -- why would you want to do this? Are you trapped
>> in hell (i.e. real life) and need this to justify something
>> to a pointy haired boss? (I'm not being sarcastic -- that's
>> the best reason I can think of.)

>> Does _anybody_ here actually think UML like tools are _useful_?
>> If so, how?

> I think they might be useful if you are stuck with crap, rigid,
> non-introspective languages like C++. For the life of me I can't see
> why a Lisp system should not document itself - if you want a class
> graph ask the system to draw you one, if you want to know what methods
> there are for a GF, ask it.

Fair enough...

> Trying to use UML to document a system
> which is strictly more powerful than it, with no mechanism to keep the
> UML design in sync with the code, is going to result in a huge
> document which initially does not describe the system it purports to
> model, and which drifts rapidly further away from it over time.

Well UML is also for designing the system *before* you've built it.
If you're going to design using OO, you might as well describe that design
in UML. Clearly, the tool needs to be easy to use - the only tool I'd give
the time of day is Popkin System Architect. You can then implement in any
language you damn well like, such as lisp (not CLOS, though you could use
that). (If you really must you can give your functions names like
class::member).

To expand my point about why you might want to use UML - most of my
diagrams that I sketch capture much the same info as UML will, in a similar
kind of way. If an easy tool makes your diagram compliant to some standard
that anyone can grok, all the better. Even better, some one else can come
along design modifications once you've gone off to conquer the world (or
possibly in your case been forced off the team for sins such as actually
producing code before the cows home).

Kurt B. Kaiser

unread,
Jun 16, 2001, 7:34:42 PM6/16/01
to
Jochen Schmidt <j...@dataheaven.de> writes:

Yes! Software is unique, because once the description is complete in all its
detail, the desired object can be said to exist. There is no transformation to
a physical entity.

Compare this with a CAD/CAM design/execution. The design is, or could be, done
the same way as sw design/coding is done. Then there is a transformation to a
physical entity which can often be completely automated. This entity can be
customized to a greater or lesser degree before "instantiation". For example,
consider a modern auto assembly plant; every car can be different.

Bridges could be built this way but are not, probably because moving the
implementation hardware to the site is impracticable, and not enough bridges
are built to make it worthwhile.

It's interesting to consider a silicon compiler. It looks like software, but a
(customizable) physical entity is created. However, that entity is not the
desired object, merely a means to produce it.

With a sufficiently sophisticated toolset, most of the sw "design" could be
extracted from the "code" by automation. Perhaps only a top-level "intention"
is necessary, and that should be relatively small and maintainable.

Regards, KBK


Frank A. Adrian

unread,
Jun 17, 2001, 12:20:54 AM6/17/01
to
"Jochen Schmidt" <j...@dataheaven.de> wrote in message
news:9ggmvr$96935$1...@ID-22205.news.dfncis.de...

> Alain Picard wrote:
>
> > If we used the metaphor "Software Authoring", well, the request might
be:
> > "Mind adding a few more chapters, or changing the ending?".
> > This would be much more in line with what we actually do.
>
> Yes - this is a much better metaphor than the ridiculous "Software
> Engineering" metaphor. Is this notion actually used somewhere? It sounds
> familiar to me but I cannot remember hearing it anywhere else...
>
You're probably thinking of Knuth's "Literate Programming" (not necessarily
a model that I'd espouse). I do know that my first requirement, when I look
for a software engineer, is the ability to put two (or more) sentences
together in a natural language. Being able to write in an organized manner
tells me that they'll probably be able to write code in the same.

I do know at least two very experienced programmers who have told me that
they think of writing a program as "telling a story" to the computer and
other programmers. It's always made sense to me.

> > Management types love the engineering metaphor, of course, because
> > they need to be able to draw up budgets, schedules, etc. Ask an
> > editor how he schedules his authors to deliver books on time...
>
> That's exactly the fact!

And the sad part is that anyone who's ever worked on a major project can
tell you just as many horror stories about cost overruns, schedule
slippages, etc. (as can anyone who's ever remodeled a house). I'm beginning
to think that, outside the idea of trying to gather and meet some set of
user requirements, there is no such thing as engineering. There's really
only more or less formalized hacking. Engineering is a myth we tell each
other (and customers) to give everyone the courage to persevere through a
project that is frought with more imponderables than certainties.

faa


Kent M Pitman

unread,
Jun 17, 2001, 10:45:21 AM6/17/01
to
"Frank A. Adrian" <fad...@uswest.net> writes:

> You're probably thinking of Knuth's "Literate Programming" (not necessarily
> a model that I'd espouse). I do know that my first requirement, when I look
> for a software engineer, is the ability to put two (or more) sentences
> together in a natural language. Being able to write in an organized manner
> tells me that they'll probably be able to write code in the same.

I've not read Knuth's book, but it sounds interesting. I suppose I'll add
it to my "someday" list...



> I do know at least two very experienced programmers who have told me that
> they think of writing a program as "telling a story" to the computer and
> other programmers. It's always made sense to me.

Not only do I believe this, but as someone who sometimes writes
fiction I'm astounded by the impoverished state of tools for
story-writing. I think the fiction writing community could and should
use the nearly identical kinds of tools that programmers do, modified
to suit their domain, of course.

However, while drag-and-drop tools for writing and analysis tools for
assessing story structure/coherency/modularization, etc. might be useful
to the writer, in the end, I think the good writers (in either domain)
are not the ones who need these tools in order to write; they are the ones
who need these tools in order to write more efficiently. Some people
confuse those two concepts.

Drag and drop tends to "box one in" (to abuse a metaphor), because it will
tend to produce the set of things that are spatially nearby. A good fiction
writer, like a good programmer, knows when to use that spatial convenience
and when to complain that things are in the wrong place and to back off to
the use of longhand to express the idea that was there in their head
in any case.

I think the modern tendancy is to assume that the function of drag and drop
is not that, however, but rather it is an assertion that a million monkeys,
given such interfaces instead of typewriters, would produce something of
more sophisticated quality than they would with those million typewriters.
And I'm not so sure that's true.

> > > Management types love the engineering metaphor, of course, because
> > > they need to be able to draw up budgets, schedules, etc. Ask an
> > > editor how he schedules his authors to deliver books on time...
> >
> > That's exactly the fact!
>
> And the sad part is that anyone who's ever worked on a major project can
> tell you just as many horror stories about cost overruns, schedule
> slippages, etc. (as can anyone who's ever remodeled a house). I'm beginning
> to think that, outside the idea of trying to gather and meet some set of
> user requirements, there is no such thing as engineering. There's really
> only more or less formalized hacking. Engineering is a myth we tell each
> other (and customers) to give everyone the courage to persevere through a
> project that is frought with more imponderables than certainties.

In my experience, engineering project schedules divides itself into two parts:

(a) Things they ask you to do that you've done before. For example,
you're building a bridge for the Army or a set for your local
theatre or a chair for your dining room table. You've built one
before. You're trained to do it, so the activity is repeatable
and even something you maybe get better at through practice
effects. Time/Cost projection is therefore a memory exercise.

Building a new house falls into this category because you can level
the foundation and then work from a predictable state.


(b) Things they ask y ou to do that you've never done before. I call
this "research". To the extent I can make an isomorphism to
something that is similar, I try to project cost by analogy, and
sometimes that gets me close. Sometimes it's something that's so
obvious an extension of what I've done before that I can feel
comfortable guessing. Sometimes it's something where you have
someone who's done it as a resource to draw on. But beyond those
lucky cases, for the most, I think it's often a total guess how
long it's going to be. One allocates big chunks of time for the
forseeable obstacles, for the assumption you won't forsee all
obstacles, and for any belief that there might be big problems you
haven't anticipated. I think it's a good plan, where it can be
done, to allocate time to "research a space" with NO expectations
of time schedule before proceeding into it and before making any
external claims of its tractibility. If you fail to factor out
the research, you know it's not going away--it's jsut intertwined
within the engineering space, making all the estimates that could
have been done accurately less accurate.

Remodeling a new house, which I'm doing now, falls into this
category because though the person doing it may be skilled in each
of the required component activities, but they have still never done
your personal house.

I've heard it said you shouuld never take on risk without
corresponding pay. I think a corollary in engineering is that you
should never take on "research" without an acknowledgement of the
associated schedule risk. It bugs some managers when you call it
research because they want to define it, and the associated risk,
away. But so be it. The risk can't be defined away and better you
have a nice on-the-record argument on this BEFORE you go into it that
you can point back to later, than one that just arises out of the blue
because you didn't make a clear enough point about it early enough.

Tim Bradshaw

unread,
Jun 17, 2001, 12:35:18 PM6/17/01
to
* Marcin Tustin wrote:

> Well UML is also for designing the system *before* you've built it.
> If you're going to design using OO, you might as well describe that design
> in UML. Clearly, the tool needs to be easy to use - the only tool I'd give
> the time of day is Popkin System Architect. You can then implement in any
> language you damn well like, such as lisp (not CLOS, though you could use
> that). (If you really must you can give your functions names like
> class::member).

What is your definition of `OO'? Obviously it's different and more
restrictive than anything a Lisp person would like to use...

--tim

DJC

unread,
Jun 17, 2001, 5:26:17 PM6/17/01
to
On Sun, 17 Jun 2001 00:41:42 +0200, Jochen Schmidt <j...@dataheaven.de>
wrote:

>Alain Picard wrote:
>
>> If we used the metaphor "Software Authoring", well, the request might be:
>> "Mind adding a few more chapters, or changing the ending?".
>> This would be much more in line with what we actually do.
>
>Yes - this is a much better metaphor than the ridiculous "Software
>Engineering" metaphor. Is this notion actually used somewhere? It sounds
>familiar to me but I cannot remember hearing it anywhere else...

I think it is an analogy that is gaining ground. Knuth's "Literate
Programming" is only an initial step -- that still clings rather too
closely in my opinion to the notion of computing as a species of
mathematics. Knuth Literate Programs are like mathematics texts; an
informal mode exposition wrapped around formal statements of proof. In
this case the program code takes the place of a lemma.

I prefer to think of programming as a _rhetorike techne_ -- an art of
rhetoric -- that is a recognition of the power (and attendant dangers)
of literacy and consequently the necessity to acquire both a
practitioner's skill and the aficionado’s critical faculty. Jacqueline
de Romilly has written that the Sophists seemed as essential to
fifth-century Athens as physicists in our atomic age. [le grands
Sohistes dans l’Athènes de Périclès 1988]. Well, I would argue that
computing will be even more central to the science of the present
century than it was to physics in the last.

As was public speaking in Ancient Athens, so with the art of
programming. One hopeful benefit of greater public disclosure of code
(whether, 'free', 'open source' or software libre.) is that it may
encourage more public awareness and engagement with this essential
craft of software creation.

Not that the 'software engineering' approach will entirely go away of
course, there will be armies of hack coders in software factories,
just as there are similar opportunities for writers in the popular
press and Hollywood studios: but we should not confuse that with true
art.

--
David Clark
<http://www.orditur-telas.com/>

Tim Bradshaw

unread,
Jun 17, 2001, 6:09:46 PM6/17/01
to
* Jochen Schmidt wrote:
> Alain Picard wrote:
>> If we used the metaphor "Software Authoring", well, the request
>> might be: "Mind adding a few more chapters, or changing the
>> ending?". This would be much more in line with what we actually
>> do.

> Yes - this is a much better metaphor than the ridiculous "Software
> Engineering" metaphor. Is this notion actually used somewhere? It
> sounds familiar to me but I cannot remember hearing it anywhere
> else...


I agree that it's a better metaphor, but I think it's better because
we're living in a pre-scientific age as far as software production
goes. There's good reason to beleive that creative writing is not
something that you want to make scientific, but I think that, in the
case of software, it definitely is something that needs more hard
science.

In the same way I want a good deal of confidence that the wings will
not fall off a plane I'm flying in, I want a good deal of confidence
that the control system won't suddenly decide that vertically
downwards is the right way to fly. Mechanical engineering has made
enormous strides in this direction - anyone who thinks otherwise
should look at the kind of seat-of-the-pants awfulness that was the
rule in the 18th and much of the 19th centuries: things just blew up
or fell to bits sometimes, and that was just how it was. Software
development needs to make huge strides too, although I don't think
anyone has a clue how to do this (don't start telling me about formal
proofs of programs or some crap like that: no one is proving aircraft
wing designs formally).

In the meantime I think it would be better to admit that we're doing
magic, and treat us as magicians...

--tim

Lars Bjønnes

unread,
Jun 17, 2001, 9:57:23 PM6/17/01
to
Alain Picard <api...@optushome.com.au> writes:

> Does _anybody_ here actually think UML like tools are _useful_?
> If so, how?

Well, UML-diagrams can make a simple program look very expensive. :-)

--
Lars

Larry Loen

unread,
Jun 18, 2001, 12:46:49 AM6/18/01
to

Alain Picard wrote:
>
[snip]


> No civil engineer would be told by their customer "Sorry mate, we just
> moved the far bank back 50 metre, you don't mind, patching that up, do
> you?" when the bridge is 90% complete. This happens to me in my work
> all the time. I accommodate such requests.
>
> How can this be so? Clearly, because software artifacts are
> altogether different from engineering artifacts.
>

It is also because we can't give anyone a clue of the consequences.

Whereas, the engineer can say "Do that and the bridge will fall down" or else "add another span." We always think we can add the span
'cause we don't have enough real knowledge to say the former when a "clever manager" pressures us.

[snip]


> Apologies for ranting, but I think this engineering metaphor is _so_
> destructive. I've done the big up-front design bit. Guess what --
> all those documents we sweated over for months became obsolete the
> moment we started coding. I don't think it's because we were
> incompetent---I think it's _inherent_ in what we do that it entails
> many small decisions, which have to be taken during the lifetime of
> the process. So, when we actually had to fix or change something
> months later, did we go to these documents?ı Of course not---we went
> to the source code. And guess what: it sucked, because it was all
> supposedly documented "elsewhere". I would have _much_ preferred a
> 1/2 page memo about the central ideas of a given subsystem, (the
> _why_), and well written and commented code to tell me the _how_.
>
> ıWell, some naïve people, like myself, did look up these documents
> first, only to discover how useless they were in the face of harsh
> reality.

But, you've merely described the problem and given up. I'm sure the stone masons in the middle ages thought civil engineering, as a
real discipline, was impossible, too. So, they built flying buttersses, watched some of the bigger cathedral vaults collapse, and
basically muddled on. Then, some chap invented calculus. While that discipline didn't have Turing's Halting Theorum to overcome (nor
had they seen it recurr in so many nontrivial places so that it could not be readily set aside thanks to The Useful Halting Subset of
Programs we still can't find), they none the less have managed to put out a discipline that has enough predictive power that you can
actually sue one of them and have it a rational act.

I was told at a conference that a bill was introduced in Texas to make programmers no less liable than any other engineering
discipline. Never heard if it passed, but we won't forever get to call ourselves "artists" whilst our products cause airplanes to fall
out of the sky.


Larry

Jochen Schmidt

unread,
Jun 18, 2001, 5:24:34 AM6/18/01
to
Larry Loen wrote:

> I was told at a conference that a bill was introduced in Texas to make
> programmers no less liable than any other engineering
> discipline. Never heard if it passed, but we won't forever get to call
> ourselves "artists" whilst our products cause airplanes to fall out of the
> sky.

This is the classical misuse of the word "artist" - Being an "artist" does
not imply that what is produced is good or better than others. The
artist-metaphor for programmers was not chosen because programmers
produce so beautiful things but because programming is sometimes a similar
fuzzy discipline like Art (authoring, composing...) that demands similar
capabilities (abstraction, creativity...)

ciao,
Jochen

Alain Picard

unread,
Jun 18, 2001, 5:54:57 AM6/18/01
to
Tim Bradshaw <t...@cley.com> writes:

> I agree that it's a better metaphor, but I think it's better because
> we're living in a pre-scientific age as far as software production
> goes. There's good reason to beleive that creative writing is not
> something that you want to make scientific, but I think that, in the
> case of software, it definitely is something that needs more hard
> science.

Astoundingly well put. Bravo.

It does lead us, however, to the next question: to what extent
is it _possible_ to make softwaremore scientific (or, more like
engineering, if you prefer).

The NASA guys who wrote that shuttle software are obviously at the
extreme end of "engineericity", and the XP folks are at the other
end, let's call it the "craftsmanship" end. The third category
are cowboy coders, who don't study their own processes at all.

There's not doubt the NASA guys do a better job than the XP guys.
There's also no doubt that it's prohibitively expensive.
Evidence also suggest most commercial software is being developed
by the third category. :-)

Perhaps the real question is: can we make it economically feasible to
infuse our craft with science? What if, for instance, software came
with actual warranties? If the companies were liable for damages?
The software for pace-makers is of pretty darn high quality, after all.

>
> In the meantime I think it would be better to admit that we're doing
> magic, and treat us as magicians...
>

Yeah. As in: I'm Mickey Mouse in the sorcerer's apprentice. :-)
Or maybe rather we're alchemists: madly _trying_ to do scientific
things, but lacking the correct theoretical underpinning for our
work, it's just hocus pocus and doomed to failure, until the right
theories come along. People _can_ transmutate elements, now, after all.

Seriously though, the magician image is one of those lovely romantic
notions that I'd defend over a beer, after work, but which wouldn't go
far with my manager during a scheduling meeting (and rightly so).

Someone posted here a while back that all lispers were "Artists and
Philosophers": he should perhaps have added "magicians". I (half-heartedly)
tried to argue the other side to him, but he may well have been right.

Alain Picard

unread,
Jun 18, 2001, 5:57:19 AM6/18/01
to
Lars =?iso-8859-1?q?Bj=F8nnes?= <lars.b...@fredrikstad.online.no> writes:

That's funny: in my experience, it was the opposite, i.e.
it took a _very_ expensive programน to make a simple diagram. :-)

Hit space for spoiler:
น You guessed it: Rational Rose!

Alain Picard

unread,
Jun 18, 2001, 6:05:01 AM6/18/01
to
Larry Loen <lwl...@us.ibm.com> writes:

> But, you've merely described the problem and given up.

Darn -- you found me out! :-)

> I was told at a conference that a bill was introduced in Texas to
> make programmers no less liable than any other engineering
> discipline. Never heard if it passed, but we won't forever get to
> call ourselves "artists" whilst our products cause airplanes to fall
> out of the sky.

I wonder if that includes suing M$ for the gazillion number of $$$
wasted everytime some idiot releases something like the Melissa virus.
When that hit, I was contracting as a very, very large computer company.
The _entire_ floor was rendered helpless (but for one, happy, linux
using exception) for an entire day. I wonder how much money _that_
cost them? Now multiply by the number of companies...

Kent M Pitman

unread,
Jun 18, 2001, 6:10:09 AM6/18/01
to
Larry Loen <lwl...@us.ibm.com> writes:

> I was told at a conference that a bill was introduced in Texas to
> make programmers no less liable than any other engineering
> discipline. Never heard if it passed, but we won't forever get to
> call ourselves "artists" whilst our products cause airplanes to fall
> out of the sky.

It would be a severe error to do this.

This would be like introducing a bill to suggest that those who speak
should be no less liable for their words than lawyers. After all, we
won't forever get to call ourselves "poets" while our words cause
contracts to fail.

Programming is neither art nor engineering. It is just words with meaning.

When meaning is held to an engineering task, it should perhaps be done with
appropriate legal weight. But such a statement should not be confused with
saying that the only possible use of programming is engineering, without the
loss of other disciplines. Just as human language should not be limited
nerely to lawyering.

It will be a sad day when the inevitabilities you fear come true, because
indeed certain art will have died. And planes might as well have fallen
from the sky to express the gravity of that consequence.

Jochen Schmidt

unread,
Jun 18, 2001, 6:58:47 AM6/18/01
to
Tim Bradshaw wrote:

> * Jochen Schmidt wrote:
>> Alain Picard wrote:
>>> If we used the metaphor "Software Authoring", well, the request
>>> might be: "Mind adding a few more chapters, or changing the
>>> ending?". This would be much more in line with what we actually
>>> do.
>
>> Yes - this is a much better metaphor than the ridiculous "Software
>> Engineering" metaphor. Is this notion actually used somewhere? It
>> sounds familiar to me but I cannot remember hearing it anywhere
>> else...
>
>
> I agree that it's a better metaphor, but I think it's better because
> we're living in a pre-scientific age as far as software production
> goes. There's good reason to beleive that creative writing is not
> something that you want to make scientific, but I think that, in the
> case of software, it definitely is something that needs more hard
> science.

IMHO it is completely wrong to rule art as the contradiction of science.
If you take a look at composers you'll see that there's a huge amount of
math behind it. If you take authors you'll have to see that e. g.
linguistic is really "hard science". Being an artist does not mean being a
"cowboy" (using the notion as in "cowboy coder")
If you think of people like Goethe or Bach you'll see that art and science
have a *strong* relationship.
It is wrong too to mix "engineering" with "science". "Science" is about
finding _new_ things While "engineering" is more like combining old things
th right way. If we draw this picture further, this means that todays
programming has a rather big amount of "engineering" in it if the task to
be done is simply to build something that is well-understood. The
"engineering" ends if we come to topics that are not well-understood or
that may have better solutions if trying a completely other way. This means
too that there's not only "engineering" when thinking of tasks like
building aircrafts or cars. Building a conventional mainstream aircraft is
mostly "engineering". Trying to build a revolutionary new type of aircraft
goes much in the direction of art *and* science - you'll have to go ways
that simply are not allowed when working in an "engineering" scope.

ciao,
Jochen

Tim Bradshaw

unread,
Jun 18, 2001, 6:53:16 AM6/18/01
to
Alain Picard <api...@optushome.com.au> writes:

>
> It does lead us, however, to the next question: to what extent
> is it _possible_ to make softwaremore scientific (or, more like
> engineering, if you prefer).

I think it's clear that engineering is the right thing to go for. In
my world, science is asking questions like `does this set of equations
model the world?', and it doesn't really matter if it's very expensive
to establish that or anything, so long as it is possible to test the
hypothesis. Engineering is to do with questions like `can we do this
thing for this much cost?' where `this thing' is something like `build
a bridge' or `land a man on the moon'. Engineering is all about costs
and utility and things like that, and so, generally, is software. You
*need* science to do engineering, but engineering is not science.

>
> The NASA guys who wrote that shuttle software are obviously at the
> extreme end of "engineericity", and the XP folks are at the other
> end, let's call it the "craftsmanship" end. The third category
> are cowboy coders, who don't study their own processes at all.
>
> There's not doubt the NASA guys do a better job than the XP guys.
> There's also no doubt that it's prohibitively expensive.
> Evidence also suggest most commercial software is being developed
> by the third category. :-)

Well, by my above definition I'm not sure they do: they produce
something which is, I suppose, higher quality, but at a cost which
would be completely prohibitive for most projects. Of course running
a shuttle is not `most projects', so their approach might well be
appropriate for it.


I think that the thing that is missing from software is some
well-defined notion of risk. We write systems which are terribly
brittle in all sorts of ways: tiny errors can result in massive
failure. There's no useful continuous-in-the-limit map from changes
to the system to changes in behaviour - a tiny change can be a tiny
error which can induce catastrophic failure. Similarly systems are
brittle to their environment changing - if an input overflows an
arbitrary bound by an amount ever so tiny the system wraps, and the
output changes enormously. It's almost impossible to do engineering
with a system like this because it has such terrible characteristics.

Successful engineering structures don't look like this: if they get
slightly too stressed they have shorter lives; they wear out
gradually; parts fail without causing the whole to fail and so on.

I don't really have any good idea about how software could be made
more amenable to engineering. Clearly Lisp (& similar languages) have
some good ideas - it's hard in Lisp to have a tiny error trash random
memory, or to have a numerical overflow cause massive failure because
of wraparound. But these aren't really solving much of the problem, I
think.

--tim

Tim Bradshaw

unread,
Jun 18, 2001, 8:36:13 AM6/18/01
to
* Jochen Schmidt wrote:

> IMHO it is completely wrong to rule art as the contradiction of science.

Something I didn't do.

> If you take a look at composers you'll see that there's a huge amount of
> math behind it. If you take authors you'll have to see that e. g.
> linguistic is really "hard science".

Whether or not it's `hard science', very few authors know anything at
all about linguistics, or need to, any more than they need to know the
chemistry of inks.

--tim

Paul Wallich

unread,
Jun 18, 2001, 6:15:42 PM6/18/01
to
In article <nkj1yoi...@tfeb.org>, Tim Bradshaw <t...@tfeb.org> wrote:


>I think that the thing that is missing from software is some
>well-defined notion of risk. We write systems which are terribly
>brittle in all sorts of ways: tiny errors can result in massive
>failure. There's no useful continuous-in-the-limit map from changes
>to the system to changes in behaviour - a tiny change can be a tiny
>error which can induce catastrophic failure. Similarly systems are
>brittle to their environment changing - if an input overflows an
>arbitrary bound by an amount ever so tiny the system wraps, and the
>output changes enormously. It's almost impossible to do engineering
>with a system like this because it has such terrible characteristics.
>
>Successful engineering structures don't look like this: if they get
>slightly too stressed they have shorter lives; they wear out
>gradually; parts fail without causing the whole to fail and so on.
>
>I don't really have any good idea about how software could be made
>more amenable to engineering. Clearly Lisp (& similar languages) have
>some good ideas - it's hard in Lisp to have a tiny error trash random
>memory, or to have a numerical overflow cause massive failure because
>of wraparound. But these aren't really solving much of the problem, I
>think.

If you look, say, at mechanical engineering, one of their big wins is that
for the most part they use an extraordinarily limited vocabularly of
components, put together in a relatively small number of ways. All of
the above pretty exhaustively tested (there are people out there who
do nothing but break bolts, rivets or welds all day, every day). Stepping
outside that limited vocabulary increases cost by an enormous factor
(10x or more) and is generally understood to carry with it large and largely
uncertain risks. (DC-10, Hyatt Regency KC, and so forth).

So most buildings, cars, airplanes, chairs, tables and so forth don't
use anything like the "state of the art" in materials or construction
techniques. If you want something handcrafted, people will tell you
it can't be done, or they'll tell you a price tag that makes you go away.
Every once in a while, and slowly, the state of construction practice
changes.

Programmers (or their managers, rather) seem perfectly willing to
handcraft new toys out of untested components, put together
in extraordinarily complex, also untested combinations, and then
hang the lives of businesses or people on the correct functioning
of same.

One possibility is that Moore's Law will save us: stuff that needs to
work will run on enormously fast machines and consist of big chunks
of studgy, "inefficient," _bulletproof_ . The functionality available
will be limited, but it will be guaranteed (the really annoying thing
with software today is that giving up function doesn't buy you extra
robustness, except by coincidence). And all of the stuff that doesn't
have to work will still be written by artists.

paul

Raymond Laning

unread,
Jun 19, 2001, 11:18:05 AM6/19/01
to
At Wisdom Systems (ca 1992) we cobbled up an LP system that used macros
to wrap all our defuns, defmethods, etc. to generate a database which
was used by a LaTex generating system. So, i.e.,

(defun foobar (foo bar)
"Foobar does nothing interesting with integer foo and string bar"
&body)

became
(define-function foobar (foo bar)
"Foobar does nothing interesting with integer foo and string bar"
&body)

Which generated, with a generate-document call,

Functions

Name: Foobar

Description: Foobar does nothing interesting with integer foo and
string bar

Arguments: foo bar

(or some such - details are hazy with time/Alzheimer's)

"Thomas F. Burdick" wrote:
>
> Christian Lynbech <christia...@ted.ericsson.dk> writes:
>
> > (yes, I think literary programming is an extremely exiciting
> > methodology).


>
> I used to be a huge LP enthusiast. Then I wrote a significant Lisp
> system without it, then tried to write another with an LP system, and
> found it really constraining. So I ditched the LP system (noweb,

> which I've found to be the least intrusive). I've found docstrings
> and texinfo-generating scripts to be enough. Has anyone had good
> experiences with LP and Lisp? I still find LP to be a life-saver with
> C++. I'd bet it's because Lisp code tends to be an order of magnitude
> more expressive, thus less need for LP. Not really sure, though ...

Ray Blaak

unread,
Jun 19, 2001, 12:44:45 PM6/19/01
to
Larry Loen <lwl...@rchland.vnet.ibm.com> writes:
> However, if we computer scientists want to be taken seriously as an
> engineering discipline, we're going to have to find a way to move beyond
> "the code is the design" supplemented (if at all) by a few cave paintings
> that tend to get tossed in the trash by mistake sometime within the first
> five years of the code's working life.

We also (as an industry) need to stop writing such shitty code.

> No civil engineer would say "the bridge is the design" and tell you (and
> often distainfully at that) to reconstruct its design girder by girder.

Software is not bridge building. Most software is built with programming
languages designed to be written and read by humans, in addition to
instructing computers as to what to do.

There is no reason that those instructions can't describe clearly what is
going on to the human as well as the computer.

> I've seen the other side of it [...lost docs...]

This is a valid problem. Relevant documentation should be maintained as part
of the source code and should exist as soft copies in the same source code
control database as the code. That way it cannot be lost (out of date, and
obsolete, yes, but not lost).

> Clearly, "the code is the design" was a miserable failure; problems recurred
> often enough that they wished for that original design doc.

I don't think that anyone is (or should) be saying that good documentation is
not necessary. It is, but how necessary really depends on the complexity of
the project. Simple and conceptually "clean" projects can often get away with
a few pages of a "vision" and high-level architecture document. Complex
projects need documentation for each major portion, especially to describe how
it fits in with the other major pieces.

Even with good documentation, however, the code should still be well written,
such that a human can readily understand what is happening.

To date, I have found no magic bullet other than being careful as hell and to
write code with maintainence in mind.

> Perhaps for LISP "the code is the design" works, but for COBOL, C, C++, APL,
> FORTRAN, and other languages I could name, it has been a miserable failure
> in my experience of it.

It can work for Lisp, and it can work for C++ (I doubt it for APL,
though). The same discipline required to do good documentation also needs to
be in place to write readable and well thought out code. (It is a whole other
debate was to which languages support such goals well, of course.)

> I don't know how to fix this, but after heaping whatever justified scorn on
> the current tools we care to make, someone, somewhere I hope will be
> inspired with a useful and correct answer to this problem.

My observation is not so much that UML is useless, but that it is often used
inappropriately. I see far too much effort at putting large amounts of detail
in the model that should instead be properly in the code.

The model's purpose is to describe the design to other humans. Diagrams are a
poor medium for writing detailed logical steps. Diagrams are a great medium
for readily giving humans the essence of what a design is about. The details
needed make a project implementable should be delegated to the code.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@infomatch.com The Rhythm has my soul.

David Thornley

unread,
Jun 20, 2001, 11:22:50 AM6/20/01
to
In article <sfwofrm...@world.std.com>,

Kent M Pitman <pit...@world.std.com> wrote:
>Larry Loen <lwl...@us.ibm.com> writes:
>
>> I was told at a conference that a bill was introduced in Texas to
>> make programmers no less liable than any other engineering
>> discipline. Never heard if it passed, but we won't forever get to
>> call ourselves "artists" whilst our products cause airplanes to fall
>> out of the sky.
>
>It would be a severe error to do this.
>
From where I sit, any means to make commercial software vendors
accept more responsibility can't be all wrong.

>This would be like introducing a bill to suggest that those who speak
>should be no less liable for their words than lawyers. After all, we
>won't forever get to call ourselves "poets" while our words cause
>contracts to fail.
>

What's the difference between my words and a lawyer's words? If
either of us writes a contract, it's a contract, and the words are
important regardless of who wrote them. The lawyer is much more
likely to get the words right than I am, just as I'm much more
likely to get a program to work than he or she is.

>Programming is neither art nor engineering. It is just words with meaning.
>

A blueprint for a bridge, or a circuit schematic, is lines, symbols,
and words with meaning. These things are often considered part
of engineering. The guy who does the actual rivetting is often
not an engineer.

>When meaning is held to an engineering task, it should perhaps be done with
>appropriate legal weight.

Right.

But such a statement should not be confused with
>saying that the only possible use of programming is engineering, without the
>loss of other disciplines. Just as human language should not be limited
>nerely to lawyering.
>

I think we need to divide programming, here, into cases where there are
serious consequences of program failure (in a general sense) and cases
where there are not.

If there are serious consequences, then somebody needs to be held
responsible. The idea of a world where something can be commissioned
for a task, and that thing can fail and kill somebody, and nobody's
responsible, frightens me. We've moved away from that with the
idea of engineering responsibility in most disciplines, but if I
screw up in programming and kill somebody there's no legal way to
hold me responsible, and I think that's bad.

If there are no serious consequences, then what does it matter whether
we are held responsible or not? Suppose a mechanical engineer
builds a wagon for his son, and the kid is pulling it along the
sidewalk when a wheel falls off. People are going to snicker
and be amused, but what official body is going to go after the
engineer? If I write a game and give it away, and it crashes,
what could I be held responsible for, and what would punishment
or damages be like?

>It will be a sad day when the inevitabilities you fear come true, because
>indeed certain art will have died. And planes might as well have fallen
>from the sky to express the gravity of that consequence.
>

If you're saying it will be a sad day when programmers who make planes
fall from the sky are assigned some measure of responsibility, I
disagree. It would be a tragedy if all program were to be
strictly regulated, but that doesn't sound like it's in the bill.


--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

Jochen Schmidt

unread,
Jun 20, 2001, 12:06:55 PM6/20/01
to
David Thornley wrote:

You're right - but it is a bit more difficult to do that with software. If
Person A writes a little library that does nothing special but contains a
bug and some other developer B uses (besides of much much more other parts
this small library in the software of an aircraft - who should be
responsible?
I'm rather sure you'll now say A is responsible because he caused the bug,
but this means that you have to do _all_ work as if you would code for an
aircraft or a Space Shuttle because you never know if someone uses it later
for something like this.

ciao,
Jochen

Kent M Pitman

unread,
Jun 20, 2001, 12:16:12 PM6/20/01
to
thor...@visi.com (David Thornley) writes:

> In article <sfwofrm...@world.std.com>,
> Kent M Pitman <pit...@world.std.com> wrote:
> >Larry Loen <lwl...@us.ibm.com> writes:
> >
> >> I was told at a conference that a bill was introduced in Texas to
> >> make programmers no less liable than any other engineering
> >> discipline. Never heard if it passed, but we won't forever get to
> >> call ourselves "artists" whilst our products cause airplanes to fall
> >> out of the sky.
> >
> >It would be a severe error to do this.
> >
>
> From where I sit, any means to make commercial software vendors
> accept more responsibility can't be all wrong.

Rights ceded are never regained. Be careful here.



> >This would be like introducing a bill to suggest that those who speak
> >should be no less liable for their words than lawyers. After all, we
> >won't forever get to call ourselves "poets" while our words cause
> >contracts to fail.
>
> What's the difference between my words and a lawyer's words? If
> either of us writes a contract, it's a contract, and the words are
> important regardless of who wrote them.

But many words are not contracts. And many programs are not products.

> The lawyer is much more
> likely to get the words right than I am, just as I'm much more
> likely to get a program to work than he or she is.

No, a lawyer is more likely to get contract wording right. He is not
likely to write poetry better.


> >Programming is neither art nor engineering. It is just words with meaning.
> >
> A blueprint for a bridge, or a circuit schematic, is lines, symbols,
> and words with meaning. These things are often considered part
> of engineering. The guy who does the actual rivetting is often
> not an engineer.

No, "lines, symbols and words with meaning" are not considered engineering.

"Lines, symbols, and words with meaning" AND "offered with the intent of
being engineering" are engineering. This is not a subtle point. Every
person should be permitted to write things that "look like" engineering
without having that be confused with BEING engineering.

The mere act of programming, even programming about domains that engineering
covers, is not engineering. It might be the way I go about understanding
physics. I might come home and program up simulations just to play out loud
with ideas in my mind until they gel. This should not require a license, and
careless wording such as you are here advocating risks that it will require
a license.

> >When meaning is held to an engineering task, it should perhaps be done with
> >appropriate legal weight.
>
> Right.

But it isn't what you've said above. PLEASE be careful with your wording
since you are presently speaking in a forum where words advocate.
(Be careful, because if you claim to me that the mere fact that your words
look like you are trying to make or advocate law doesn't mean it's lawyerly,
you will have made my case.)

> >But such a statement should not be confused with
> >saying that the only possible use of programming is engineering, without the
> >loss of other disciplines. Just as human language should not be limited
> >nerely to lawyering.
>
> I think we need to divide programming, here, into cases where there are
> serious consequences of program failure (in a general sense) and cases
> where there are not.

Nonsense. The bug here is "implied warranty". People should get in the habit
of saying what their program does and in cases where they have sold the
program, standing by that warranty. But when the program is not sold, no
contract exists and so neither should a warranty. Moreover, if a program is
sold with no warranty, I think it's foolish to assume there's an implied
warranty.

If someone is using a program in a mission-critical situation without an
explicit warranty, it's that person, and not the program author, who has
screwed up!

> If there are serious consequences, then somebody needs to be held
> responsible.

That's a political claim. It's a legitimate position, and not even one
I wholly disagree with, though I utterly disagree with the "who" that you
are pointing to. But I also observe by way of fairness that there exist
people who don't think that the world has to always have someone responsible;
the world would not cease to exist if that were so.

> The idea of a world where something can be commissioned
> for a task, and that thing can fail and kill somebody, and nobody's
> responsible, frightens me.

You have shifted here to add "commissioned" (by which I'll infer $$). In
that case, you're talking about a sale. It's the sale that incurs the
responsibility, not the programming. If I had *found* the program and sold
it to you, rather than programming it, the sale should no less incur whatever
responsibility I attached. If I said "I found it in the street; no warranty"
then it's your problem, not mine. If I said "I programmed this but I'm
a lousy programmer; no warranty" then it's your problem, not mine. If we make
a contact that the money you give me is in exchagne for an item with an
attached contract, then that's fine. But that isn't a statement about
programming. Contract law ALREADY is powerful enough to achieve your end,
without mucking with attaching legal implications to our discipline.

> We've moved away from that with the
> idea of engineering responsibility in most disciplines, but if I
> screw up in programming and kill somebody there's no legal way to
> hold me responsible, and I think that's bad.

You don't screw up in programming and kill someone. You screw up in selling
stuff with excessive claims or too little qa.

If you blame the programmer, who are you going to blame if the programmer
is dead or if a program writes the program? Plainly, the blame has to go
with the sale.

> If there are no serious consequences, then what does it matter whether
> we are held responsible or not?

It matters because it is an obstacle to doing and SHARING things freely.
(That seems to matter more to you than to me, so I'm surprised I'd have
to remind you of that.)

> Suppose a mechanical engineer
> builds a wagon for his son, and the kid is pulling it along the
> sidewalk when a wheel falls off. People are going to snicker
> and be amused, but what official body is going to go after the
> engineer?

But if he shares it with a friend, and the friend is injured, you can be sure
these days that the friend will be suing against the "engineer". I don't
like that. It is not something we should seek to copy.

> If I write a game and give it away, and it crashes,
> what could I be held responsible for, and what would punishment
> or damages be like?

If it writes a data file over an existing system file? If it crashes
the system? If it locks up the system in a tight loop and keeps you
from saving and important file in another program running
simultaneously before the machine is booted? .... You CAN be sued,
but it is stupid. There should not be such liabilities. Saying "how
could it hurt me" is the stupidest reason I ever heard for allowing
someone to go ahead and make liabilities. Laws should not be created
by people who have a "how could this hurt me?" attitude.



> >It will be a sad day when the inevitabilities you fear come true, because
> >indeed certain art will have died. And planes might as well have fallen
> >from the sky to express the gravity of that consequence.
>
> If you're saying it will be a sad day when programmers who make planes
> fall from the sky are assigned some measure of responsibility, I
> disagree. It would be a tragedy if all program were to be
> strictly regulated, but that doesn't sound like it's in the bill.

What I am saying is that the act of making commercial airlines is or should
be a carefully monitored process where for each part and service you can find
a CONTRACT that establishes liability. And that is sufficient. Demonstrating
that "programming" was involved is and ought to be irrelevant.

Daniel Barlow

unread,
Jun 20, 2001, 12:31:03 PM6/20/01
to
Jochen Schmidt <j...@dataheaven.de> writes:

> You're right - but it is a bit more difficult to do that with software. If
> Person A writes a little library that does nothing special but contains a
> bug and some other developer B uses (besides of much much more other parts
> this small library in the software of an aircraft - who should be
> responsible?

Person B. The If Person A sells balsa wood, and person B uses this balsa
wood and other materials to make an aeroplane, and the wings snap off
in flight, whose fault is it? Unless the balsa wood came in a bag
labelled "warranted for aircraft wings", that is.

(Yes, I know, analogy is the rusty blunt hacksaw of Usenet)

It may presently be socially acceptable for the systems integrator to
blame the supplier of some component ("oh, it's microsoft windows, you
know what that's like") instead of admitting liability, but I don't
think that's the situation we want to be in.


-dan

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

Duane Rettig

unread,
Jun 20, 2001, 1:20:42 PM6/20/01
to
Jochen Schmidt <j...@dataheaven.de> writes:

> David Thornley wrote:
> > If there are serious consequences, then somebody needs to be held
> > responsible. The idea of a world where something can be commissioned
> > for a task, and that thing can fail and kill somebody, and nobody's
> > responsible, frightens me. We've moved away from that with the
> > idea of engineering responsibility in most disciplines, but if I
> > screw up in programming and kill somebody there's no legal way to
> > hold me responsible, and I think that's bad.
>
> You're right - but it is a bit more difficult to do that with software. If
> Person A writes a little library that does nothing special but contains a
> bug and some other developer B uses (besides of much much more other parts
> this small library in the software of an aircraft - who should be
> responsible?

It's no more difficult to do that with software than with hardware.

For eaxmple, what if Person A manufactures an O-ring that is faulty,
and Person B uses that O-ring in a spacecraft and that spacecraft
blows up in flight, who is responsible?

How about this one: If Person A manufactures a tire and Person B uses
that tire in the manufacture of an SUV, and that SUV crashes and kills
people, who is responsible?

Duane Rettig (Still-living owner of an SUV made by Person B)

Dorai Sitaram

unread,
Jun 20, 2001, 2:35:25 PM6/20/01
to
In article <4n173d...@beta.franz.com>,

Common Lispers drive SUVs...?! :-)

--d

Thomas A. Russ

unread,
Jun 18, 2001, 1:10:46 PM6/18/01
to
Tim Bradshaw <t...@tfeb.org> writes:

> Successful engineering structures don't look like this: if they get
> slightly too stressed they have shorter lives; they wear out
> gradually; parts fail without causing the whole to fail and so on.

But there are many cases where physical engineered systems do not follow
this description. Bridge resonance is one spectacular example of a
failure that in some ways mimics a lot of software failures.

Now one response to that observation is that bridge designers have since
learned that this is a particular problem that needs to be addressed in
the design phase. In a similar vein, experienced software designers
know enough to do sanity checks on input values to make sure that the
assumptions of the following code are being met. This is largely a
matter of design methodology rather than something the language itself
requires, but the same is true of resonance analysis of bridges (except
that the requirement may be more formally codified for bridges).

There are, however, some inherent problems in (a lot of) programming
language design. The silent rollover of integer arithmetic is one of my
least favorite (non-Lisp) language failure. It is too bad that Java
followed the standard route of those languages. I think it would have
been nicer (and certainly more upfront and obvious) to name the type for
which this occurs something like "intMod32" instead of "int" and reserve
the latter for a type which throws exceptions on overflow or underflow.
It would presumably be a bit slower, but having both of these options
would at least make the issue more visible, and give the programmer a
chance at making the speed/risk tradeoff.

I suppose another way that traditional engineering differs from software
writing is that one generally has a good idea of how to make something
stronger, and how to introduce redundancy. It isn't clear how to make a
program stronger (in the sense of less likely to break in a way that is
moderately independent of a careful analysis of the precise mechanism
which will cause it to break). Also, there is precious little language
support for any type of redundant coding styles -- such as voting.

I suppose that part of the problem is that much of the traditional
engineering techniques are designed to deal with the problem of physical
failure of the parts. This is something that normally isn't an issue in
software (although bit rot or hardware errors can occur which affect
software). In any case, it is generally solved by the same redudant
systems approach of traditional engineering -- fail-over systems,
duplicate databases, etc.

Most software failures probably correspond more to things that would be
design failures in traditional engineering. Obviously such things still
happen -- witness certain automotive safety problems and recalls -- but
they seem to be not quite as common. One reason may be that the designs
of most engineered structures are either not as complicated (although,
aircraft may be a counter example) and they are also not as
interdependent, so that a failure in the lavatory of an airliner doesn't
cause the aircraft to fall out of the sky.

Perhaps some (future) development of the agent architecture will allow
more de-coupling of software and reduce the degree of interdependence of
software. The most embarrassing thing about software failures is how
small mistakes in non-mission critical sections of the software can take
down the entire system.

--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu

Lars Lundback

unread,
Jun 21, 2001, 1:22:35 AM6/21/01
to
On 18 Jun 2001 10:10:46 -0700, t...@sevak.isi.edu (Thomas A. Russ) wrote:

>Tim Bradshaw <t...@tfeb.org> writes:
>
>> Successful engineering structures don't look like this: if they get
>> slightly too stressed they have shorter lives; they wear out
>> gradually; parts fail without causing the whole to fail and so on.
>
>But there are many cases where physical engineered systems do not follow
>this description. Bridge resonance is one spectacular example of a
>failure that in some ways mimics a lot of software failures.
>
>Now one response to that observation is that bridge designers have since
>learned that this is a particular problem that needs to be addressed in
>the design phase. In a similar vein, experienced software designers
>know enough to do sanity checks on input values to make sure that the
>assumptions of the following code are being met. This is largely a
>matter of design methodology rather than something the language itself
>requires, but the same is true of resonance analysis of bridges (except
>that the requirement may be more formally codified for bridges).

Another example is the introduction of welding in shipbuilding in the 30's. A
number of ship hulls cracked severely, and one even split in two while at
harbour. When it was discovered ... . I now correct myself, to stress what I
am getting at.

When _people_ discovered that the welding process caused brittleness in the
steel surrounding the weld, measures were taken. The process was modified -
excuse, I mean that people modified the process, new welding methods were
introduced (read: teachers held courses, experienced welders often had
apprentices etc).

Authorities - no, I mean _people_ employed by various agencies - required
inspection of constructions, eg by X-ray. And so on.

>There are, however, some inherent problems in (a lot of) programming
>language design. The silent rollover of integer arithmetic is one of my
>least favorite (non-Lisp) language failure. It is too bad that Java
>followed the standard route of those languages. I think it would have
>been nicer (and certainly more upfront and obvious) to name the type for
>which this occurs something like "intMod32" instead of "int" and reserve
>the latter for a type which throws exceptions on overflow or underflow.
>It would presumably be a bit slower, but having both of these options
>would at least make the issue more visible, and give the programmer a
>chance at making the speed/risk tradeoff.
>
>I suppose another way that traditional engineering differs from software
>writing is that one generally has a good idea of how to make something
>stronger, and how to introduce redundancy. It isn't clear how to make a
>program stronger (in the sense of less likely to break in a way that is
>moderately independent of a careful analysis of the precise mechanism
>which will cause it to break). Also, there is precious little language
>support for any type of redundant coding styles -- such as voting.

I'd say that your previous paragraph suggests one way of building robustness
into code (integer overflow).

Then why do not programmers use these and other techniques? Is it because
they are unaware of the need, have they done a cost analysis or are they just
lazy and think they can (hopefully) get away with it?

>I suppose that part of the problem is that much of the traditional
>engineering techniques are designed to deal with the problem of physical
>failure of the parts. This is something that normally isn't an issue in
>software (although bit rot or hardware errors can occur which affect
>software). In any case, it is generally solved by the same redudant
>systems approach of traditional engineering -- fail-over systems,
>duplicate databases, etc.
>
>Most software failures probably correspond more to things that would be
>design failures in traditional engineering. Obviously such things still
>happen -- witness certain automotive safety problems and recalls -- but
>they seem to be not quite as common. One reason may be that the designs
>of most engineered structures are either not as complicated (although,
>aircraft may be a counter example) and they are also not as
>interdependent, so that a failure in the lavatory of an airliner doesn't
>cause the aircraft to fall out of the sky.

The most complicated machine is probably a large phone network. Consider the
number of users, the variety and levels of the equipment, in the case of
mobile systems that all terminals move physically and must be tracked, the
services available that must be billed to someone - and all this happens in
real time.

>Perhaps some (future) development of the agent architecture will allow
>more de-coupling of software and reduce the degree of interdependence of
>software. The most embarrassing thing about software failures is how
>small mistakes in non-mission critical sections of the software can take
>down the entire system.

I'd say that software design methodology, for many application domains, is
reasonably well known. But compare the efforts put into building a successful
hockey, football, etc team with the resources used to build a project team
where the people are to design and implement a large, complex and sometimes
_very_ expensive piece of software.

Few responsible manufacturing plant managers would allow ad-hoc design and
implemention of new control systems, simply from bad experience and from not
daring to risk the concequences. Any manager or leader should today _know_
how to start and run a software project, how to write specs and deal with
documentation in the project stages.

Isn't then an embarrassing thing that software is discussed in terms as if
software happens all by itself? Alain quoted Gabriel about software as plant/
garden. Now, a farmer knows how to prepare his fields, and any seasoned
gardener knows how to plant so as _not_ to get weeds in it.

So, do educational institutions (read: people) teach how to build and run
software projects? Assuming that the technique is known of course ...

/Lars


David Thornley

unread,
Jun 21, 2001, 12:58:34 PM6/21/01
to
In article <sfwd77z...@world.std.com>,

Kent M Pitman <pit...@world.std.com> wrote:
>thor...@visi.com (David Thornley) writes:
>
>> In article <sfwofrm...@world.std.com>,
>> Kent M Pitman <pit...@world.std.com> wrote:
>> >Larry Loen <lwl...@us.ibm.com> writes:
>> >
>> >> I was told at a conference that a bill was introduced in Texas to
>> >> make programmers no less liable than any other engineering
>> >> discipline. Never heard if it passed, but we won't forever get to
>> >> call ourselves "artists" whilst our products cause airplanes to fall
>> >> out of the sky.
>> >
>> >It would be a severe error to do this.
>> >
>> From where I sit, any means to make commercial software vendors
>> accept more responsibility can't be all wrong.
>
>Rights ceded are never regained. Be careful here.
>
Oh, I am. I'm not saying that any idea would be all right.
I'm saying that the software industry, such as it is, is
disgracefully bad about accepting responsibility.

Nor do I know all that much about the contents of the bill.
It says "any other engineering discipline", and the engineers that
I know don't seem to think that their legal responsibility is
intolerable. (I did casually assume that "no less liable" probably
implied "no more liable", and based my comments on that. If this
is wrong, then the bill would be a serious mistake.)



>> >This would be like introducing a bill to suggest that those who speak
>> >should be no less liable for their words than lawyers. After all, we
>>

>> What's the difference between my words and a lawyer's words? If
>> either of us writes a contract, it's a contract, and the words are
>> important regardless of who wrote them.
>
>But many words are not contracts. And many programs are not products.
>

Bingo. Lawyers aren't liable for what they say at parties (no
more liable than I am, anyway). They are responsible for what
they say in their professional capacities. What I'm saying is
that there's no reason not to hold me legally responsible for
some things in my professional capacities.

I can write software that is defective and kills (the probability
of this depends on various things). When a member of a profession
can do this, there needs to be some sort of legal oversight.

>> >Programming is neither art nor engineering. It is just words with meaning.
>> >
>> A blueprint for a bridge, or a circuit schematic, is lines, symbols,
>> and words with meaning. These things are often considered part
>> of engineering. The guy who does the actual rivetting is often
>> not an engineer.
>
>No, "lines, symbols and words with meaning" are not considered engineering.
>

Right. Neither are words with meaning considered programming.

>"Lines, symbols, and words with meaning" AND "offered with the intent of
>being engineering" are engineering. This is not a subtle point. Every
>person should be permitted to write things that "look like" engineering
>without having that be confused with BEING engineering.
>

On the same principle, I should be able to tinker with my tools
without having this confused with mechanical engineering. It
seems to me that I can do that. As far as I know, my mechanical
engineer friend can do things in his basement that don't count
as engineering until he says they are. If we're talking about
programming being the same as engineering, then presumably the
stuff I write at home will be treated the same way.

>The mere act of programming, even programming about domains that engineering
>covers, is not engineering. It might be the way I go about understanding
>physics. I might come home and program up simulations just to play out loud
>with ideas in my mind until they gel. This should not require a license, and
>careless wording such as you are here advocating risks that it will require
>a license.
>

I am not a mechanical engineer. I own, and use, certain tools. (Well,
mostly I let them lie around collecting dust, to be honest.) I can
make machines with these tools. AFAIK, this is not a problem.

I don't think my mechanical engineer friend is liable for what he does
in his basement unless he calls it engineering, or sells it, or
something like that. Not being an engineer or a lawyer, my
understanding could be wrong; if it is, then I agree that the bill
is dangerous, and would instead propose a limitation to allow
nonprofessional programming, even if that is done by a professional.
(Presumably a mechanical engineer can set something up for his own
use that would be unacceptable as an engineering product, such as
when working on a prototype machine that may not meet safety
standards.)

>> >When meaning is held to an engineering task, it should perhaps be done with
>> >appropriate legal weight.
>>
>> Right.
>
>But it isn't what you've said above. PLEASE be careful with your wording
>since you are presently speaking in a forum where words advocate.
>(Be careful, because if you claim to me that the mere fact that your words
>look like you are trying to make or advocate law doesn't mean it's lawyerly,
>you will have made my case.)
>

What you thought you were reading does not appear to be quite what I
thought I was writing, and apparently I was unclear, and I apologize.
I didn't think I needed to write a disclaimer saying that I was
not giving legal advice, and may well have been wrong in that.

However, I will only have made your case if the proposed bill said
that all programs should be treated as if they were legitimate
engineering products, and in that case I will agree with you that
the bill is bad. If it tries to establish equivalence between
software intended as a product and machines intended as products,
rather than between software of all sorts and machines intended
as products, that violates my assumption (listed above) and then
I am wrong on specifics.

>> >But such a statement should not be confused with
>> >saying that the only possible use of programming is engineering, without the
>> >loss of other disciplines. Just as human language should not be limited
>> >nerely to lawyering.
>>
>> I think we need to divide programming, here, into cases where there are
>> serious consequences of program failure (in a general sense) and cases
>> where there are not.
>
>Nonsense. The bug here is "implied warranty". People should get in the habit
>of saying what their program does and in cases where they have sold the
>program, standing by that warranty.

And accepting responsibility in the legal sense. I agree. The fact
is that they do not, and this is a problem. The problem is going to
provoke legal remedies, and does have the potential to provoke
counterproductive overreactions. If I understand the Texas bill
correctly (which is not guaranteed), I don't consider it one of
those.

But when the program is not sold, no
>contract exists and so neither should a warranty. Moreover, if a program is
>sold with no warranty, I think it's foolish to assume there's an implied
>warranty.
>

Which results in no warranty in the vast majority of cases, except
that the CD-ROM will not turn back into a pumpkin for ninety
days.

>If someone is using a program in a mission-critical situation without an
>explicit warranty, it's that person, and not the program author, who has
>screwed up!
>

If it's in a potentially lethal situation, then I suggest that
voluntary warranties are not necessarily sufficient. Right now,
they aren't. For reasons I consider good, the government sets
its own standards for physically dangerous things. In the
current state of affairs, I don't see the market economy working
well. I generally assume that the market was insufficient to
assure safety in other fields, and that's why we have legally
recognized engineering disciplines.

>> If there are serious consequences, then somebody needs to be held
>> responsible.
>
>That's a political claim. It's a legitimate position, and not even one
>I wholly disagree with, though I utterly disagree with the "who" that you
>are pointing to.

I wasn't pointing at anybody in particular there. What I am saying
is that there has to accountability for the various components.
We don't expect a civil engineer to forge his own bolts, but
rather to put responsibility on somebody else to make those
bolts. There are, I believe, legal practices that can assign
blame.

But I also observe by way of fairness that there exist
>people who don't think that the world has to always have someone responsible;
>the world would not cease to exist if that were so.
>

My apologies, I have again been unclear. It is not necessary that
somebody be held responsible for every death; in some respects,
accidents will simply happen, and the cost of preventing those
accidents may be considered too high. Potentially lethal situations
do demand some sort of responsibility to be assessed. Sometimes
it will be determined to be just one of those things (man on amusement
park ride suffers a heart attack and dies - there may be some
causality there, but no responsibility attaches) or the fault of
the dead person (idiot ignores blizzard warning, decides to
explore wilderness in national park).

>> The idea of a world where something can be commissioned
>> for a task, and that thing can fail and kill somebody, and nobody's
>> responsible, frightens me.
>
>You have shifted here to add "commissioned" (by which I'll infer $$).

I understood that that was the case for engineering disciplines, and
therefore understood it to apply to the programming we were discussing.
This was not a shift so much as a failure to make an assumption clear.

Nor do I know exactly in what cases an engineer will be held liable
for the failure of one of his products; presumably a sale, and
exchange of money, is part of determination. I'm thinking of
some product offered as suitable for a task in some manner.

In
>that case, you're talking about a sale. It's the sale that incurs the
>responsibility, not the programming.

Sounds reasonable. I don't know exactly how this works in conventional
engineering disciplines; what I do know is that it does work, and
that my mechanical engineer friend finds it completely acceptable.
I'm going sailing with him next month; maybe I'll ask him about it
then.

If I had *found* the program and sold
>it to you, rather than programming it, the sale should no less incur whatever
>responsibility I attached.

Right.

If I said "I found it in the street; no warranty"
>then it's your problem, not mine.

Sounds reasonable.

If I said "I programmed this but I'm
>a lousy programmer; no warranty" then it's your problem, not mine.

That may not be, depending on the purpose. There are such things
as implied warranties, such as a warranty that a product is in
some way suitable for the use it is sold for. If you offer the
product as potentially suitable for a purpose, then it is
not necessarily the case, and should not necessarily be the case,
that you can disclaim all responsibility.

If we make
>a contact that the money you give me is in exchagne for an item with an
>attached contract, then that's fine. But that isn't a statement about
>programming. Contract law ALREADY is powerful enough to achieve your end,
>without mucking with attaching legal implications to our discipline.
>

In which case we don't need licensed engineers, do we? We can
do everything with contract law. There are reasons why we don't.
They may be bad reasons, but I'd need to be convinced.

>> We've moved away from that with the
>> idea of engineering responsibility in most disciplines, but if I
>> screw up in programming and kill somebody there's no legal way to
>> hold me responsible, and I think that's bad.
>
>You don't screw up in programming and kill someone. You screw up in selling
>stuff with excessive claims or too little qa.
>

QA can be considered as part of programming.

>If you blame the programmer, who are you going to blame if the programmer
>is dead or if a program writes the program? Plainly, the blame has to go
>with the sale.
>

I don't know, but I assume these are solved problems in engineering.
If I buy a machine from my friend, and he drowns in Lake Superior,
and then it turns out to be defective, well, there have to be
legal precedents.

>> If there are no serious consequences, then what does it matter whether
>> we are held responsible or not?
>
>It matters because it is an obstacle to doing and SHARING things freely.
>(That seems to matter more to you than to me, so I'm surprised I'd have
>to remind you of that.)
>

If the bill interferes with that, then, yes, I am opposed. It is
not clear that that will be the case.

And, yes, I don't understand why commercial enterprises aren't
using warranties as a counter to free software. There may be
companies that legally stand behind their software, but I haven't
dealt with any recently. If a company making operating systems
were willing to provide binding warranties that their operating
system will work, for certain values of work, you'd think that
company would acquire a potentially large competitive advantage
over a free product with no warranty. Right now, as far as I
can tell, Microsoft is as liable for Windows as Sandra Bullock
is for Linux, and Linux is more reliable.

>But if he shares it with a friend, and the friend is injured, you can be sure
>these days that the friend will be suing against the "engineer". I don't
>like that. It is not something we should seek to copy.
>
>> If I write a game and give it away, and it crashes,
>> what could I be held responsible for, and what would punishment
>> or damages be like?
>
>If it writes a data file over an existing system file? If it crashes
>the system? If it locks up the system in a tight loop and keeps you
>from saving and important file in another program running
>simultaneously before the machine is booted? ....

Which will not be the case in a well-designed operating system,
and I think that is important. If the game is misdesigned
and the operating system is lousy (there was a dispute about
a beta program working on MS Windows on the rec.* int-fiction
groups a while ago), then these things can happen.

I think it important to establish some sort of accountability
for operating system quality, and the market simply is not
doing that in most cases.

You CAN be sued,
>but it is stupid. There should not be such liabilities. Saying "how
>could it hurt me" is the stupidest reason I ever heard for allowing
>someone to go ahead and make liabilities. Laws should not be created
>by people who have a "how could this hurt me?" attitude.
>

Laws should be created by people who have a "how could this hurt
various people" attitude. Asking how a bill could hurt me, and
basing my attitude partly on that, is valid. Accepting liabilities
at random because they don't seem to have any immediate effect
is stupid, as you say.

>> If you're saying it will be a sad day when programmers who make planes
>> fall from the sky are assigned some measure of responsibility, I
>> disagree. It would be a tragedy if all program were to be
>> strictly regulated, but that doesn't sound like it's in the bill.
>
>What I am saying is that the act of making commercial airlines is or should
>be a carefully monitored process where for each part and service you can find
>a CONTRACT that establishes liability. And that is sufficient. Demonstrating
>that "programming" was involved is and ought to be irrelevant.

What I am saying is that this does not seem to be sufficient in the
general case, particularly in potentially lethal situations. There
are legal requirements for machines that are used for certain purposes,
no matter what a contract may say. I believe that there are good
reasons for these legal requirements.

Software is now a major component of many such machines, and the
trend will be to make it more and more important. I think it
probable that the same reasons for making requirements for
machines apply for making requirements for software.

It may be that the Texas bill is bad, but I haven't been given
any specific reason to think so, given the assumptions I've made,
which seem reasonable to me and which have not been contradicted.

Thomas A. Russ

unread,
Jun 21, 2001, 2:10:04 PM6/21/01
to
Jochen Schmidt <j...@dataheaven.de> writes:
>
> You're right - but it is a bit more difficult to do that with software. If
> Person A writes a little library that does nothing special but contains a
> bug and some other developer B uses (besides of much much more other parts
> this small library in the software of an aircraft - who should be
> responsible?
> I'm rather sure you'll now say A is responsible because he caused the bug,
> but this means that you have to do _all_ work as if you would code for an
> aircraft or a Space Shuttle because you never know if someone uses it later
> for something like this.

I think that this rather overstates the case.

In physical engineering there are various levels of quality and
certification. I can go to my local hardware store and buy some cheap
screws. These work well on small repairs and home projects, but Boeing
or Airbus Industries would not use the same parts in their aircraft.
They are required to use appropriately certified parts.

One could easily imagine a similar system for software. There are many
general purpose libraries with no particular guarantee, as well as some
others that have been appropriately certified. If you don't want to go
through the effort to have your library certified, then it would seem
that someone who uses it in preference to a certified library would be
taking on the liability.

The US Food and Drug Administration has guidelines for evaluating
software in life-critical medical devices. I'm not familiar with the
details, but there are ways of making certain software adhere to more
formal standards.

Marcin Tustin

unread,
Jun 22, 2001, 6:02:19 AM6/22/01
to
Tim Bradshaw <t...@cley.com> wrote:
> * Marcin Tustin wrote:

>> Well UML is also for designing the system *before* you've built it.
>> If you're going to design using OO, you might as well describe that design
>> in UML. Clearly, the tool needs to be easy to use - the only tool I'd give
>> the time of day is Popkin System Architect. You can then implement in any
>> language you damn well like, such as lisp (not CLOS, though you could use
>> that). (If you really must you can give your functions names like
>> class::member).

> What is your definition of `OO'? Obviously it's different and more
> restrictive than anything a Lisp person would like to use...

I don't think that it's restrictive - I mean a design involving
classes and objects, which may do whatsoever you design them to do. My point
is that you can design OO and use a non-oo language if you wish. The design is
(to the extent that it is possible and sensible) language independent.

> --tim

Tim Bradshaw

unread,
Jun 22, 2001, 6:04:52 AM6/22/01
to
Marcin Tustin <mt...@ugnode1.ecs.soton.ac.uk> writes:

>
> I don't think that it's restrictive - I mean a design involving
> classes and objects, which may do whatsoever you design them to do. My point
> is that you can design OO and use a non-oo language if you wish. The design is
> (to the extent that it is possible and sensible) language independent.

But if you can't model some major features that your language provides
(such as multimethods, method combination), your implementation is
likely not to bear much resemblance to the model.

--tim

Christian Lynbech

unread,
Jun 22, 2001, 9:30:15 AM6/22/01
to
>>>>> "Tim" == Tim Bradshaw <t...@tfeb.org> writes:

Tim> But if you can't model some major features that your language provides
Tim> (such as multimethods, method combination), your implementation is
Tim> likely not to bear much resemblance to the model.

It sort of depends on what you mean by "model". If what you want to do
is to describe the *architecture* of a system, it is not inconceivable
that the modelling will be done a such a high level of abstraction
that specifics of the programming language does not show up in the
diagrams.


------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: christia...@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)

David Thornley

unread,
Jun 22, 2001, 10:07:53 AM6/22/01
to
In article <of66dod...@chl.ted.dk.eu.ericsson.se>,

Christian Lynbech <christia...@ted.ericsson.dk> wrote:
>>>>>> "Tim" == Tim Bradshaw <t...@tfeb.org> writes:
>
>Tim> But if you can't model some major features that your language provides
>Tim> (such as multimethods, method combination), your implementation is
>Tim> likely not to bear much resemblance to the model.
>
>It sort of depends on what you mean by "model". If what you want to do
>is to describe the *architecture* of a system, it is not inconceivable
>that the modelling will be done a such a high level of abstraction
>that specifics of the programming language does not show up in the
>diagrams.
>
Agreed. However, this implies that the architecture is done in
something more abstract than UML, which is closely tied to the
implementation details of C++ and Java.

One problem I had was trying to come up with what sort of picture
I'd draw to express the architecture in the same way that UML
does for C++ or Java. Where do you put the methods? I never
did come up with a good way to draw it.

Bob Bane

unread,
Jun 22, 2001, 3:06:02 PM6/22/01
to
David Thornley wrote:
>

> One problem I had was trying to come up with what sort of picture
> I'd draw to express the architecture in the same way that UML
> does for C++ or Java. Where do you put the methods? I never
> did come up with a good way to draw it.
>

It's the multiple-inheritance problem, squared. I once dabbled with
constructing a class and method browser similar to the Interlisp/LOOPS
one for CLOS.

LOOPS is a single-inheritance, single dispatch OO langauge, so all the
class trees are real trees, and all methods are associated with one
owner class, so displaying the class tree and showing methods as menu
lists at each class node works. You can ask the browser questions like
"who implements this method" and get a visually useful answer when the
class nodes blink.

CLOS is a multiple-dispatch, multiple-inheritance OO langauge, so the
class tree is a DAG (at least) and methods are all over the map. I
thought about having a seperate method browser that would show a generic
function at the root of a tree and methods arranged in some inheritance
order beneath it (super-class methods closer to the root, :AROUND
methods above, :BEFORE and :AFTER at the same level as uncombined
methods), but it never really came together.

--
Remove obvious stuff to e-mail me.
Bob Bane

Reini Urban

unread,
Jun 23, 2001, 12:03:49 PM6/23/01
to
Chris Double <ch...@double.co.nz> wrote:
: Then again, Rational Rose data files seem to be s-expression
: based. Write a lisp program to generate your UML models by producing
: these data files. Or use the OLE AUtomation interface exposed by Rose
: to generate the diagrams from Lisp. Probably work better than their
: reverse engineering options anyway...

A colleague did that to produce his private CLOS extension classes and
methods, unfortunately not CLOS compatible (autolisp). It was quite useful,
esp for co-workers to get an immediate outline of the classes and for fast
prototyping.
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq

Marcin Tustin

unread,
Jun 23, 2001, 1:15:46 PM6/23/01
to
David Thornley <thor...@visi.com> wrote:
> In article <of66dod...@chl.ted.dk.eu.ericsson.se>,
> Christian Lynbech <christia...@ted.ericsson.dk> wrote:
>>>>>>> "Tim" == Tim Bradshaw <t...@tfeb.org> writes:
>>
>>Tim> But if you can't model some major features that your language provides
>>Tim> (such as multimethods, method combination), your implementation is
>>Tim> likely not to bear much resemblance to the model.
>>
>>It sort of depends on what you mean by "model". If what you want to do
>>is to describe the *architecture* of a system, it is not inconceivable
>>that the modelling will be done a such a high level of abstraction
>>that specifics of the programming language does not show up in the
>>diagrams.
>>
> Agreed. However, this implies that the architecture is done in
> something more abstract than UML, which is closely tied to the
> implementation details of C++ and Java.

> One problem I had was trying to come up with what sort of picture
> I'd draw to express the architecture in the same way that UML
> does for C++ or Java. Where do you put the methods? I never
> did come up with a good way to draw it.

Presumably "normal" methods would go where they do in UML - you
only need some way to deal with such things as multimethods
(All involved classes would be my choice).

Marcin Tustin

unread,
Jun 23, 2001, 1:28:38 PM6/23/01
to
Tim Bradshaw <t...@cley.com> wrote:

> anyone has a clue how to do this (don't start telling me about formal
> proofs of programs or some crap like that: no one is proving aircraft
> wing designs formally).

You seriously contend that no-one uses calculations to show that
the wings of a plane will withstand a certain level of stress in various
modes and directions?
Formal methods in software engineering I can't comment on: I've
yet to write (in my frankly short career of developing software, almost
none of it professionally) a program that it was easier to design with
attention to formal methods. Not that I don't want to try.

> In the meantime I think it would be better to admit that we're doing
> magic, and treat us as magicians...

> --tim

Tim Bradshaw

unread,
Jun 23, 2001, 6:36:01 PM6/23/01
to
* Marcin Tustin wrote:
> You seriously contend that no-one uses calculations to show that
> the wings of a plane will withstand a certain level of stress in various
> modes and directions?

Of course not. However I certainly contend that the calculations done
for mechanical engineering structures are *not* formal proofs of
correctness. Even if you aren't a mechanical engineer it's obvious
that this is so: occasionally entirely new behaviours of structures
are discovered, such as in the recent London millennium bridge
foul-up.

--tim

Kent M Pitman

unread,
Jun 24, 2001, 3:46:49 AM6/24/01
to
Tim Bradshaw <t...@cley.com> writes:

Moreover, calculations done on an aribtrary system are not ones I
would trust for building a plane. I'd want to know that there was
careful quality control of any system that was doing that number-crunching,
and I'd probably want to see it computed a couple of ways or cross-checked
in some way, just for security.

Will Deakin

unread,
Jun 25, 2001, 5:19:42 AM6/25/01
to
Jochen Schmidt wrote:

> IMHO it is completely wrong to rule art as the contradiction of science.

Che?

> If you take a look at composers you'll see that there's a huge amount of
> math behind it.

But how much of that maths is maths per se, and how much of that maths is
because the human brain is wired up to enjoy regular structured change --
as opposed to random change aka white noise or not-change aka a rather
annoying hum.

Bach is good examples of a composer who were also good at maths. However,
there are examples of composers who were to a lesser or greater extent
inumerate.

:)will


Andy Freeman

unread,
Jun 25, 2001, 1:32:11 PM6/25/01
to
> > You're right - but it is a bit more difficult to do that with software. If
> > Person A writes a little library that does nothing special but contains a
> > bug and some other developer B uses (besides of much much more other parts
> > this small library in the software of an aircraft - who should be
> > responsible?
> > I'm rather sure you'll now say A is responsible because he caused the bug,
> > but this means that you have to do _all_ work as if you would code for an
> > aircraft or a Space Shuttle because you never know if someone uses it later
> > for something like this.
>
> I think that this rather overstates the case.
>
> In physical engineering there are various levels of quality and
> certification. I can go to my local hardware store and buy some cheap
> screws. These work well on small repairs and home projects, but Boeing
> or Airbus Industries would not use the same parts in their aircraft.
> They are required to use appropriately certified parts.

This discussion started out when someone noted an effort to "certify"
programmers AND make them personally liable and made some comparisons
to engineering disciplines where such liability exists.

I'm confused. If a Braniff 747 drops onto my house, what's the point
of individual liability on the part of the guy who may have mis-designed
the rudder, the "certified plane refueler" who may have filled the tanks
with fire-retardant gell, the pilot who may have confused my street for
a runway, etc? Why do I care what caused the injury? What good will
it do for me to take some guy's house? Why isn't this completely Braniff's
problem?

KMP alluded to a similar question some time back and never really got
an responsive answer. We long ago figured out that end-to-end solutions
are the ones that work, that intermediate ecc is merely a possible
performance enhancer, so why the obsession with exposing these innards
to someone past the end?

-andy

Kent M Pitman

unread,
Jun 25, 2001, 2:41:54 PM6/25/01
to
ana...@earthlink.net (Andy Freeman) writes:

> I'm confused. If a Braniff 747 drops onto my house, what's the point
> of individual liability on the part of the guy who may have mis-designed
> the rudder, the "certified plane refueler" who may have filled the tanks
> with fire-retardant gell, the pilot who may have confused my street for
> a runway, etc? Why do I care what caused the injury? What good will
> it do for me to take some guy's house? Why isn't this completely Braniff's
> problem?

The fairest reading is to say that Braniff needs someone to sue, too,
recursively.

Eventually, it will be the person with the mis-designed part IF it was
sold with a warranty. What I'm suggesting is that it ought not be the
fact of having made a thing which implies a warranty, but rather a separate
step of having offered a warranty.

Pitman's Two-Bit Rule applies here:

Do not use a single bit to represent two bits worth of data.

(Explanation: It is a common design error to assume that two closely
correlated events happen enough that the presence of one implies the other.
Don't do this, if there is any chance at all that there might need to be a
divergence of the two. There is a definite need to separate the notion
of "writing a program" from "offering a program as suitable for a purpose".
The latter should not be something you do accidentally.)

> KMP alluded to a similar question some time back and never really got
> an responsive answer. We long ago figured out that end-to-end solutions
> are the ones that work, that intermediate ecc is merely a possible
> performance enhancer, so why the obsession with exposing these innards
> to someone past the end?

I'm assuming the innards are exposed to the company that's getting the
external suit, and that it has to resolve the problem. The part I find
non-responsive is that no one has answered as to why the act of writing
program text should, of necessity, imply a warranty. If it doesn't, this
whole discussion is moot.

Presently, lots of software is offered with "no warranty of any kind".
That practice is gradually changing in subtle ways, but it's only by
consumers refusing to buy it that way that it's likely to change much.
Geez, if you can sell it with no warranty, why NOT? Offering a
warranty will drive up the price and maybe the market doesn't want the
price driven up. Maybe it does trust the product and prefers the
price. Nothing wrong with that. Just don't let them talk out of both
sides of their mouth, saying they trust it but suing after the fact
anyway because an overactive legal system lets them.

George Neuner

unread,
Jun 25, 2001, 7:19:39 PM6/25/01
to
On 25 Jun 2001 10:32:11 -0700, ana...@earthlink.net (Andy Freeman)
wrote:

>
>We long ago figured out that end-to-end solutions are the ones that
>work, that intermediate ecc is merely a possible performance enhancer,
>so why the obsession with exposing these innards to someone past the
>end?
>

Duh! ... it provides more pockets for lawyers to fish in.


George

George Neuner

unread,
Jun 25, 2001, 8:01:17 PM6/25/01
to
On Thu, 21 Jun 2001 16:58:34 GMT, thor...@visi.com (David Thornley)
wrote:

>Bingo. Lawyers aren't liable for what they say at parties (no
>more liable than I am, anyway). They are responsible for what
>they say in their professional capacities. What I'm saying is
>that there's no reason not to hold me legally responsible for
>some things in my professional capacities.

This is not true [and not simply for lawyers].

The law recognizes the idea of a "conspicuous expert" and gives more
weight to the casual utterances of such a person when remarks having
basis in that person's expert knowledge are made in "mixed" company,
ie. in the company of non-experts.

Most of us here qualify as software "experts" in our little domains.
To a lay person, our utterances about how "foo" is great and "baz" is
crap could be considered "expert" opinions, even if we don't intend
them as such.


> KMP wrote:
>>
>>But when the program is not sold, no
>>contract exists and so neither should a warranty. Moreover, if a program is
>>sold with no warranty, I think it's foolish to assume there's an implied
>>warranty.
>>
>Which results in no warranty in the vast majority of cases, except
>that the CD-ROM will not turn back into a pumpkin for ninety
>days.
>

The problem here is that, for all products, there is implied
"merchantability" which includes the notion that the product performs
as advertised.

Clearly a program which crashes *should* violate that if it were sold.
This is clearly not the case in practice ... if it were Microsoft
would be out of business 8-)


> If we make
>>a contact that the money you give me is in exchagne for an item with an
>>attached contract, then that's fine. But that isn't a statement about
>>programming. Contract law ALREADY is powerful enough to achieve your end,
>>without mucking with attaching legal implications to our discipline.
>>
>In which case we don't need licensed engineers, do we? We can
>do everything with contract law. There are reasons why we don't.
>They may be bad reasons, but I'd need to be convinced.

The reason everything isn't settled by contract law is that people
have inflated opinions of their own worth.

Every time you step on a plane, you contract with the airline to limit
the airline's liability to you in the event of an accident. Do you
think for one minute that your life is worth the paltry sum they
offer? Would that contract you signed stop you (or your family) from
further sueing them if you were injured or killed?

The courts long ago decided that contract made in bad faith and those
whose provisions are 'contrary to "public good"' are not enforcible.
The problems we are left with are twofold - (1) it is very difficult
in general to discover and prove bad faith, and (2) there is no
agreement on the meaning of "public good". Consequently, no one can
determine a priori which contracts will be enforcible.


George

Kent M Pitman

unread,
Jun 25, 2001, 8:48:31 PM6/25/01
to
gne...@dyn.com (George Neuner) writes:

> The law recognizes the idea of a "conspicuous expert" and gives more
> weight to the casual utterances of such a person when remarks having
> basis in that person's expert knowledge are made in "mixed" company,
> ie. in the company of non-experts.

Laws are written by people. Laws can be changed. I happen to wonder
if this restriction was created not by lawyers in order to cause
lawyers to have to disqualify themselves from giving legal advice and
in order to force others from identifying themselves as charlatans,
with the ultimate end of making it hard to offer
commercially-efficient cut-rate lawyerly advice, something for which I
think the market has a strong need.

And I don't see why it would create a problem for both lawyers and doctors
to do that. The public would quickly learn that a warranty mattered, and
most would seek that. Those who did not would at least have acccess to
SOME service rather than none.

Consider the effect of restaurants which are forced to throw out food becuase
they cannot warranty it to be of safe value. Often that food is safe or
would be trusted in limited modes (especially bread and other such things
that are fairly self-inspectable...)

Upping the quality requirement sometimes just raises the price and has no
other commercial effect.

> Most of us here qualify as software "experts" in our little domains.
> To a lay person, our utterances about how "foo" is great and "baz" is
> crap could be considered "expert" opinions, even if we don't intend
> them as such.

But as long as our domain is "programming" and programming is
unwarrantied, then being an expert is irrelevant. If product-design
is what conveys warranty, then it would be businesspeople who would not
speak at cocktail parties, not programmers. Darned good thing secretaries
aren't revealed to be the main source of wisdom in offices, lest they not
be able to share copier repair advice with one another.



> > KMP wrote:
> >>
> >>But when the program is not sold, no
> >>contract exists and so neither should a warranty. Moreover, if a program is
> >>sold with no warranty, I think it's foolish to assume there's an implied
> >>warranty.
> >>
> >Which results in no warranty in the vast majority of cases, except
> >that the CD-ROM will not turn back into a pumpkin for ninety
> >days.
> >
>
> The problem here is that, for all products, there is implied
> "merchantability" which includes the notion that the product performs
> as advertised.

It's not that I don't underseatnd that. I just think that since we're
talking about changes to society, we should undersatnd that our only
option is not to evolve more of a sense of responsibility. Our other
option is to revisit the whole notion of what is implied and what is
not. I think implied warranties are crap.

> Clearly a program which crashes *should* violate that if it were sold.

NONSENSE. It depends on the price at which it was sold. It could be sold
at far less price without qa. If not being used for mission criticial
purposes, it's not clear. I OFTEN buy things saying "if this is junk, I can
afford to just throw it away". It's no different than buying something at
a yard sale. You don't sue the person if it doesn't work.

> This is clearly not the case in practice ... if it were Microsoft
> would be out of business 8-)

Odd to push me into the case of defending one of their business practices,
but so you've done it....

> >> If we make
> >>a contact that the money you give me is in exchagne for an item with an
> >>attached contract, then that's fine. But that isn't a statement about
> >>programming. Contract law ALREADY is powerful enough to achieve your end,
> >>without mucking with attaching legal implications to our discipline.
> >>
> >In which case we don't need licensed engineers, do we? We can
> >do everything with contract law. There are reasons why we don't.
> >They may be bad reasons, but I'd need to be convinced.
>
> The reason everything isn't settled by contract law is that people
> have inflated opinions of their own worth.

Then let them pay extra to have someone else offer them more advice.

> Every time you step on a plane, you contract with the airline to limit
> the airline's liability to you in the event of an accident. Do you
> think for one minute that your life is worth the paltry sum they
> offer? Would that contract you signed stop you (or your family) from
> further sueing them if you were injured or killed?

I don't stepinto their airline based on the money they offer. I step in
there based on the knowledge that the business would not stay in business
if it lsot many people, and that some errors they make are criminally
prosecutable. But in particular, small fly-by-night planes may offer the
same dollar amount promises and I don't fly those...

> The courts long ago decided that contract made in bad faith and those
> whose provisions are 'contrary to "public good"' are not enforcible.

"public good" is something the public needs to have periodic input on,
and we need to be organizing as a group to make amicus briefs on this
if necessary. I don't doubt that some will say it's good for us to take
responsibility, but my feeling is: no responsibility without pay.
Extra responsibility imposed without extra pay is a(n unwanted)
"gift" (no consideration on both sides). I don't buy that as part of
the "social contract"...

"courts" are not things that run (or should run) on autopilot with no
input from the citizenry.

> The problems we are left with are twofold - (1) it is very difficult
> in general to discover and prove bad faith,

So let's eliminate it as a requirement.

> and (2) there is no
> agreement on the meaning of "public good".

So let's make it irrelevant.

> Consequently, no one can
> determine a priori which contracts will be enforcible.

So let's make contracts not depend on this subjective analysis.

mikel evins

unread,
Jun 25, 2001, 9:23:35 PM6/25/01
to

"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwu214...@world.std.com...

> gne...@dyn.com (George Neuner) writes:
>
> > The law recognizes the idea of a "conspicuous expert" and gives more
> > weight to the casual utterances of such a person when remarks having
> > basis in that person's expert knowledge are made in "mixed" company,
> > ie. in the company of non-experts.
>
> Laws are written by people. Laws can be changed.

It isn't quite that simple. An awful lot of tort and contract law is not
written by people in the sense that someone deliberately writes laws to
accomplsih such and such a purpose. The majority of such effective law is
case law. 'The law' is arrived at by a sort of annealing process in which
duiputes are resolved by decisions. And when laws are actually written to
accomplish such and such a purpose, often as not they just change the
economics of existing decisions, setting off a new round of 'annealing',
with results that are somewhat hard to predict.


Kent M Pitman

unread,
Jun 25, 2001, 10:12:50 PM6/25/01
to
"mikel evins" <mi...@reactivity.com> writes:

I'm familiar with the case law process, but case law can grandfather in
contracts and their interpretations from before a certain date. Copyright
law was changed substantially with the Copyright Act of 1976 and the world
has more or less accomodated the major shift that it created, even if it
does mean split-by-case reasoning for things that occurred over the
transition.

I recognize the need for stability, but at the point where members of a free
society start saying there's no control over the path they've elected in the
past, even where that path can be called into question for its goodness,
it's gone too far. We need always to begin from the assumption that the
things we need to do collectively as a society can be done if we have the will
to do it. Everything else beyond that is "simple" economics.

mikel evins

unread,
Jun 25, 2001, 10:26:20 PM6/25/01
to

"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwofrc...@world.std.com...
> "mikel evins" <mi...@reactivity.com> writes:

> I'm familiar with the case law process, but case law can grandfather in
> contracts and their interpretations from before a certain date. Copyright
> law was changed substantially with the Copyright Act of 1976 and the world
> has more or less accomodated the major shift that it created, even if it
> does mean split-by-case reasoning for things that occurred over the
> transition.
>
> I recognize the need for stability, but at the point where members of a
free
> society start saying there's no control over the path they've elected in
the
> past, even where that path can be called into question for its goodness,
> it's gone too far. We need always to begin from the assumption that the
> things we need to do collectively as a society can be done if we have the
will
> to do it. Everything else beyond that is "simple" economics.

Sure; my only point was that it's not quite as simple as deciding what the
law ought to be. Deciding that the law ought to say such and such in order
to produce effect so and so does not necessarily mean that effect so and so
will be produced, even if the law does say such and such. It depends on the
economic effect of the law.


Christian Lynbech

unread,
Jun 26, 2001, 4:42:19 AM6/26/01
to
>>>>> "David" == David Thornley <thor...@visi.com> writes:

David> In article <of66dod...@chl.ted.dk.eu.ericsson.se>,


David> Christian Lynbech <christia...@ted.ericsson.dk> wrote:
>>>>>>> "Tim" == Tim Bradshaw <t...@tfeb.org> writes:
>>
Tim> But if you can't model some major features that your language provides
Tim> (such as multimethods, method combination), your implementation is
Tim> likely not to bear much resemblance to the model.
>>
>> It sort of depends on what you mean by "model". If what you want to do
>> is to describe the *architecture* of a system, it is not inconceivable
>> that the modelling will be done a such a high level of abstraction
>> that specifics of the programming language does not show up in the
>> diagrams.
>>

David> Agreed. However, this implies that the architecture is done in
David> something more abstract than UML, which is closely tied to the
David> implementation details of C++ and Java.

I see your point, but I am not quite convinced that can not use UML in
more abstract ways. After all, as I understand it, UML is primarily
just a set of boxes where most of the interpretation/semantics is done
through stereotypes, which one can extend as necessary.

Some constructs will be completely inadequate for Lisp, but I would
expect much of the more generic relationship stuff would be applicable.

David> One problem I had was trying to come up with what sort of picture
David> I'd draw to express the architecture in the same way that UML
David> does for C++ or Java. Where do you put the methods? I never
David> did come up with a good way to draw it.

How about modelling the method as entities in themselves rather than
as part of particular classes (as one would do for java or C++) and
then use a "relates to" arrow with a "dispatches on" stereotype
pointing to the classes the method dispatches on.

One could further have a box for the generic function and have the
methods display some sort of ancestral relation towards the gf.

And before/after methods could then perhaps be displayed as a sort of
decomposition of the gf object.


Anyway, I would not be at all surprised if my enthusiasm would fade
with actual hands-on experience.

Andy Freeman

unread,
Jun 26, 2001, 12:02:40 PM6/26/01
to
Kent M Pitman <pit...@world.std.com> wrote in message news:<sfw4rt4...@world.std.com>...

> ana...@earthlink.net (Andy Freeman) writes:
>
> > I'm confused. If a Braniff 747 drops onto my house, what's the point
> > of individual liability on the part of the guy who may have mis-designed
>
> The fairest reading is to say that Braniff needs someone to sue, too,
> recursively.

Iff that's the deal that Braniff made with its suppliers. Braniff may
well realize that being able to sue fuelers is a waste of time because
their resources are insufficient to cover the consequences of their
mistakes. In that case, Braniff may choose to require insurance, to
buy general coverage itself, or to self-insure.

> Eventually, it will be the person with the mis-designed part IF it was
> sold with a warranty. What I'm suggesting is that it ought not be the
> fact of having made a thing which implies a warranty, but rather a separate
> step of having offered a warranty.

Yup. There's a huge difference between Braniff's relationship with its
suppliers and my relationship (as the target of planes dropping out of the
sky) and Braniff, so it's rather silly that we play by the same rules wrt
supplier error.

> Pitman's Two-Bit Rule applies here:
>
> Do not use a single bit to represent two bits worth of data.
>
> (Explanation: It is a common design error to assume that two closely
> correlated events happen enough that the presence of one implies the other.
> Don't do this, if there is any chance at all that there might need to be a
> divergence of the two. There is a definite need to separate the notion
> of "writing a program" from "offering a program as suitable for a purpose".
> The latter should not be something you do accidentally.)

Of course, this is not software specific.

-andy

Kent M Pitman

unread,
Jun 26, 2001, 1:02:56 PM6/26/01
to
ana...@earthlink.net (Andy Freeman) writes:

> > Pitman's Two-Bit Rule applies here:
> >
> > Do not use a single bit to represent two bits worth of data.
> >
> > (Explanation: It is a common design error to assume that two closely
> > correlated events happen enough that the presence of one implies the other.
> > Don't do this, if there is any chance at all that there might need to be a
> > divergence of the two. There is a definite need to separate the notion
> > of "writing a program" from "offering a program as suitable for a purpose".
> > The latter should not be something you do accidentally.)
>
> Of course, this is not software specific.

Nor is the failure to apply billions of other lessons learned about
describing "process" or "information" to the real world. Such a pity
non-programmers don't at least have our vocabulary available when it's
relevant. :-(

George Neuner

unread,
Jun 27, 2001, 5:26:34 PM6/27/01
to
On Tue, 26 Jun 2001 00:48:31 GMT, Kent M Pitman <pit...@world.std.com>
wrote:

>gne...@dyn.com (George Neuner) writes:
>
>> Most of us here qualify as software "experts" in our little domains.
>> To a lay person, our utterances about how "foo" is great and "baz" is
>> crap could be considered "expert" opinions, even if we don't intend
>> them as such.
>
>But as long as our domain is "programming" and programming is
>unwarrantied, then being an expert is irrelevant. If product-design
>is what conveys warranty, then it would be businesspeople who would not
>speak at cocktail parties, not programmers. Darned good thing secretaries
>aren't revealed to be the main source of wisdom in offices, lest they not
>be able to share copier repair advice with one another.

It doesn't matter that your field of expertise is unwarrantied. The
law says that you may be held liable for harm simply by virtue of
"being an expert". The world is full of people who act on hearsay,
mostly to their own detriment. To their credit, most don't think to
sue.

You're right, the law can be changed.


>
>> > KMP wrote:
>> >>
>> >>But when the program is not sold, no
>> >>contract exists and so neither should a warranty. Moreover, if a program is
>> >>sold with no warranty, I think it's foolish to assume there's an implied
>> >>warranty.
>> >>
>> >Which results in no warranty in the vast majority of cases, except
>> >that the CD-ROM will not turn back into a pumpkin for ninety
>> >days.
>> >
>>
>> The problem here is that, for all products, there is implied
>> "merchantability" which includes the notion that the product performs
>> as advertised.
>

>> Clearly a program which crashes *should* violate that if it were sold.
>

<snip>


>
>NONSENSE. It depends on the price at which it was sold. It could be sold
>at far less price without qa. If not being used for mission criticial
>purposes, it's not clear. I OFTEN buy things saying "if this is junk, I can
>afford to just throw it away". It's no different than buying something at
>a yard sale. You don't sue the person if it doesn't work.

This is a personal value judgement with which others may not agree.
Many people, including me, deplore the throw-away society. There are
many times that I would glady pay more to obtain a quality item and
find that the level of quality I desire doesn't exist.

[Yeah, I know ... see a void - fill it. Well, life isn't long enough
to acquire all the necessary skills. Thus I am forced to depend on
others for certain things.]

There is an issue of trust in any purchase (or barter), the standards
of merchantability were developed so that the public could have a
minimum degree of trust in the conduct and ethics of merchants.

They were developed long ago at a time when the
producer/developer/supplier and the "merchant" were (usually) one and
the same. As the two personalities diverged, the laws have been
interpreted to place most liability with the producer, leaving the
merchant charged only with adequate delivery.

Versions of these laws exist in every modern country and, though
possibly uncodified, the idea is championed almost everywhere. That
these ancient ideas have survived basically unchanged for so long is
somewhat telling ... obviously enough people feel strongly about it to
keep the laws in place.

The empirical evidence seems clear that people don't think "caveat
emptor" is the right attitude for a merchant ... at least when those
people are wearing their "consumer" hats.

>> This is clearly not the case in practice ... if it were Microsoft
>> would be out of business 8-)
>
>Odd to push me into the case of defending one of their business practices,
>but so you've done it....

Wow!


George

Kent M Pitman

unread,
Jun 27, 2001, 5:48:28 PM6/27/01
to
gne...@dyn.com (George Neuner) writes:

> There is an issue of trust in any purchase (or barter), the standards
> of merchantability were developed so that the public could have a
> minimum degree of trust in the conduct and ethics of merchants.

Programming is not purchasing or bartering. Much software is given
away free, and appares to fall even under this implied warranty of
merchantability, since the disclaimers on much of it imply they are
disclaiming as much as they can of baggage that never should have been
there in the first place.

A core value I'm trying to protect is the right of people to think.
At its core level, programming is not much different from speaking
or thinking. It is just expressing a concise and clear thought about
a process or procedure. That there should be liability incurred in
such an act is deeply wrong, IMO.

Not all acts of creation are acts of exchange, nor are all acts of
exchange purporting to offer an item for the purpose that such implied
warranties might infer. For example, suppose I sell someone the
result of the obfuscated C contest? Probably there is some warranty
that it does *something*, but what if it had a bug and did not run?
Would it make it any less interesting to look at? I don't really
think so. (That it's virus free is maybe another matter.)

Tim Moore

unread,
Jun 27, 2001, 6:11:55 PM6/27/01
to
On Wed, 27 Jun 2001, Kent M Pitman wrote:
> A core value I'm trying to protect is the right of people to think.
> At its core level, programming is not much different from speaking
> or thinking. It is just expressing a concise and clear thought about
> a process or procedure. That there should be liability incurred in
> such an act is deeply wrong, IMO.

Agreed; it's also deeply wrong that such an act could be patented.

Tim


Andy Freeman

unread,
Jun 28, 2001, 8:31:15 PM6/28/01
to
> > A core value I'm trying to protect is the right of people to think.
> > At its core level, programming is not much different from speaking
> > or thinking. It is just expressing a concise and clear thought about
> > a process or procedure. That there should be liability incurred in
> > such an act is deeply wrong, IMO.
>
> Agreed; it's also deeply wrong that such an act could be patented.

Do you also object to patents that result from someone drawing something,
say a novel fluid pump?

-andy

Andy Freeman

unread,
Jun 28, 2001, 8:38:54 PM6/28/01
to
gne...@dyn.com (George Neuner) wrote

> It doesn't matter that your field of expertise is unwarrantied. The
> law says that you may be held liable for harm simply by virtue of
> "being an expert". The world is full of people who act on hearsay,
> mostly to their own detriment. To their credit, most don't think to
> sue.

and previously

> The law recognizes the idea of a "conspicuous expert" and gives more
> weight to the casual utterances of such a person when remarks having
> basis in that person's expert knowledge are made in "mixed" company,
> ie. in the company of non-experts.

Umm, did Neuner also previously write that independent yet subsequent
invention is a viable defense against patent infringment? (It isn't
in the US or any of the major European countries, or Japan. It may
be somewhere else.) If so, I'd look elsewhere for legal advice ....

-andy

Tim Moore

unread,
Jun 28, 2001, 9:12:13 PM6/28/01
to

I'm not a great fan of patents in general, but let's say: No, I don't; as
far as I know, drawing a pump can never be grounds for patent
infringement.

Oh, you mean building a pump after drawing it :) Well, I dunno. My
personal feelings towards it would depend on how novel the pump was and
how vital the patent disclosure was in understanding the design.

But, I'm not a machinist so building a pump doesn't approach, in my mind,
anything like a thought process. Writing software does, so for the same
reasons KMP finds the concept of liability applied to programming
offensive I find restrictions on the process, including patents,
offensive.

Tim, who'd really rather flame about Lisp or something


Kent M Pitman

unread,
Jun 28, 2001, 9:31:35 PM6/28/01
to
ana...@earthlink.net (Andy Freeman) writes:

Btw, I think the key here is that the "patent" should allow those with a
brain to independently derive the thing. If I say "think of a way to do x"
and you think somehting up that's patented, that should be not preclude you
from using the thing, it should invalidate the patent--at least for you.
It works that way for copyright.

Back on the subject of whether programmers should be liable, whoever invents
the first thinking droid might as well just commit suicide rather than face
the lawsuits that will ensue...

Andy Freeman

unread,
Jun 29, 2001, 10:07:04 AM6/29/01
to
> > Do you also object to patents that result from someone drawing something,
> > say a novel fluid pump?
>
> I'm not a great fan of patents in general, but let's say: No, I don't; as
> far as I know, drawing a pump can never be grounds for patent
> infringement.
>
> Oh, you mean building a pump after drawing it :) Well, I dunno. My
> personal feelings towards it would depend on how novel the pump was and
> how vital the patent disclosure was in understanding the design.

The first person received a patent after filing a drawing, the second
did a drawing and built it, eventually resulting in infringement.

By definition, the drawing makes it possible for someone skilled in the
art to make use of the novelty. Patent law doesn't reward infringers who
maintain ignorance, so the "did they use the drawing in the patent"
question doesn't come up. (Patent law doesn't do a good enough job
in punishing applicants that maintain ignorance.)



> But, I'm not a machinist so building a pump doesn't approach, in my mind,
> anything like a thought process.

I'm sorry for your loss. Architecting/designing a complex system that happens
to include pumps is, as is designing or figuring out how to build a pump.
Mechanical stuff is a lot like programming. (One difference is that the
folks doing mechanical drudgery, such as most assembly, often use different
tools than people doing non-drudgery. That difference isn't as common
in programming.)

The "I dislike all patents" position makes sense - I'm trying to find a
coherent explanation of why software patents are different than other
patents.

Yes, we execute our "drawings", but no one has suggested that mechanical
inventions described by drawings that can be "automatically" transformed
into objects are somehow less novel because of the that transformation.

-andy

Andy Freeman

unread,
Jun 29, 2001, 10:36:56 AM6/29/01
to
> > Do you also object to patents that result from someone drawing something,
> > say a novel fluid pump?
>
> Btw, I think the key here is that the "patent" should allow those with a
> brain to independently derive the thing. If I say "think of a way to do x"
> and you think somehting up that's patented, that should be not preclude you
> from using the thing, it should invalidate the patent--at least for you.
> It works that way for copyright.

Independent creation is a statutory defense against copyright infringement
liability, but I wonder how often it works in practice.

For what it's worth, US patent law doesn't seem to actually care about
"with a brain" when it comes to granting applications. There's a personhood
requirement (unlike with copyright), which will eventually result in
some significant legal expenses, but I suspect that initial ownership of
machine-made inventions will rest with "the operator" and assignment
contracts will do the impedance match to reality. (We've almost
certainly seen something similar before, as some inventors delegate
certain activities and then use the results as part of an invention.
The question is always whether the delagee contributes to the novelty
of the invention, not whether they did something novel to contribute;
the latter would be the subject of their invention.)

With copyright, the corporate overlord in charge of the million monkeys
at typewriters for a very long time already gets the copyright. With
patents, that option isn't available, but operator pass-through works.
It's unlikely that a "the invention doesn't belong to anyone" result
will ensue, if for no other reason than we'll approach "operator pass-through
via precedents as the operator contributes less and less to the process.
(Some will note the invention comes from the person who established
the system, not the person who put the cards into the machine, but I'm
looking towards the truely autonmous invention machine.)

> Back on the subject of whether programmers should be liable, whoever invents
> the first thinking droid might as well just commit suicide rather than face
> the lawsuits that will ensue...

It depends on what the droid does. For example, if the droid was the
CAD equivalent of the million monkeys at typewriters for a very long
time, and there was an attached filter to recognize utility & novelty
for function, you don't have to file, you could just publish, which
bars filing by subsequent inventors.

-andy

Craig Brozefsky

unread,
Jun 29, 2001, 12:15:19 PM6/29/01
to
Kent M Pitman <pit...@world.std.com> writes:

> > > Agreed; it's also deeply wrong that such an act could be patented.
> >
> > Do you also object to patents that result from someone drawing something,
> > say a novel fluid pump?
>
> Btw, I think the key here is that the "patent" should allow those with a
> brain to independently derive the thing. If I say "think of a way to do x"
> and you think somehting up that's patented, that should be not preclude you
> from using the thing, it should invalidate the patent--at least for you.
> It works that way for copyright.

The core purpose of patent is to encourage the sharing of ideas with
the public. This is why patents are available for public viewing.
One way it enocurages this publication is by granting temporary
monopoly on the idea or process. If someone could come along and copy
your process, but claim they never saw your patent, then it would
severely undermine patent's intent to grant temporary monopoly.

Patent and copyright protect two different things. Your idea is
feasible for copyright, because copyright protects the expression of
an idea or proces, whereas patents protect a particular idea or
process.

Mind you, I think patents should be irradicated or SEVERELY reformed.

--
Craig Brozefsky <cr...@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci

Kent M Pitman

unread,
Jun 29, 2001, 12:50:20 PM6/29/01
to
Craig Brozefsky <cr...@red-bean.com> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > > > Agreed; it's also deeply wrong that such an act could be patented.
> > >
> > > Do you also object to patents that result from someone drawing something,
> > > say a novel fluid pump?
> >
> > Btw, I think the key here is that the "patent" should allow those with a
> > brain to independently derive the thing. If I say "think of a way to do x"
> > and you think somehting up that's patented, that should be not preclude you
> > from using the thing, it should invalidate the patent--at least for you.
> > It works that way for copyright.
>
> The core purpose of patent is to encourage the sharing of ideas with
> the public.


Yes, certainly. Same as with copyrights. But what I'm saying is that at
the same time, if you share something with the public and they immediately
"get it", that's some evidence to me that what you shared is of less value.

The simplest way to fix all the fights likely to occur over this, IMO,
is just to keep patent rights short. I think patent should protect
time to market--saying that if you put something out and it's
interesting and cool, you get a brief duration during which you can
recover your costs of development, but not an infinite monopoly. Since
most software is obsolete in 3 years or less, it seems hard for me to
see a justification in any software patent lasting longer than that.
In 99% of cases, if you haven't made your fortune by that time, it
wasn't the big deal thing you thought...

> Patent and copyright protect two different things. Your idea is
> feasible for copyright, because copyright protects the expression of
> an idea or proces, whereas patents protect a particular idea or
> process.

Er, I don't *think* you can patent an idea. I think it has to be a process.



> Mind you, I think patents should be irradicated or SEVERELY reformed.

Yep.

Kent M Pitman

unread,
Jun 29, 2001, 12:34:29 PM6/29/01
to
ana...@earthlink.net (Andy Freeman) writes:

> The "I dislike all patents" position makes sense - I'm trying to find a
> coherent explanation of why software patents are different than other
> patents.

They are different because we live in a "rational" world; that is, you
can't, by some Cantor-like diagonalization end up in a place in the
address space called the "real" world that isn't one of the finitely
enumerable states of the machine. A great deal of the "purpose" of
software, at least at this stage of evolution, is convergent
technology; to enumerate and control those important things that can
be expressed in a small number of bit patterns. The idea of doling out
pieces of that finitely enumerable world like .com names until they
are all gone is what bugs programmers, perhaps more than other artisans
because they haven't honed their craft to the point that they are within
striking distance of an actual, real, mathematical proof that there can
be no other way to achieve a certain end (worse if you add the word
"efficiently"). We are all hyperconscious of just how tiny our world is.

Maybe if engineers had their work reduced to digital formulas, they would
become similarly incensed. Or maybe most of the really good things in
engineering happened so long ago as to no longer be either patentable or to
have a patent applying, such that they don't feel the stranglehold we do
for having had patents applying (and stretching) at the moment of trying
to bring the emergent information industry into life. (It's hard to look
at something as ubiquitous as it is now and remember how brand new it all is.)

Worsee still, the computational aspect of has probably aided in the
escalation of some areas, where filing patents by hand was once expensive
and I bet now there's escalated glut due to automation, extra overhead due
to larger searches required, extra confusion due to ever-smaller gaps between
the edges of one technology and the edges of another, etc.

George Neuner

unread,
Jun 29, 2001, 1:54:19 PM6/29/01
to
On 29 Jun 2001 07:07:04 -0700, ana...@earthlink.net (Andy Freeman)
wrote:

>By definition, the drawing makes it possible for someone skilled in the


>art to make use of the novelty. Patent law doesn't reward infringers who
>maintain ignorance, so the "did they use the drawing in the patent"
>question doesn't come up. (Patent law doesn't do a good enough job
>in punishing applicants that maintain ignorance.)

Patent law deliberately *protects* those who "maintain ignorance".
Both the so-called "clean room" design in which the competing product
is designed from scratch without reference to the patented one, and
the "black box design" in which the competitor uses the patented
product as a functional model (but does not take it apart) ARE LEGAL
and, if done correctly, non-infringing.

Patent law has been abused to create monopoly, but its original intent
was to foster innovation and competition by encouraging inventors to
make their inventions public rather than hide them.


George
------------------------------------------------------------
Disclaimer: I am not a patent attorney. My father, sister,
and a dozen or so family friends are.

George Neuner

unread,
Jun 29, 2001, 1:58:35 PM6/29/01
to
On 28 Jun 2001 17:38:54 -0700, ana...@earthlink.net (Andy Freeman)
wrote:

>gne...@dyn.com (George Neuner) wrote

I have contacts for about 30 patent attorneys if you'd like to talk to
one.

By sure to ask about "clean rooms" and "black boxes".

George Neuner

unread,
Jun 29, 2001, 2:07:36 PM6/29/01
to

And if you had paid attention you would know that I recommended that
anyone with questions should talk to an attorney.

George Neuner

unread,
Jun 29, 2001, 2:12:14 PM6/29/01
to
On Fri, 29 Jun 2001 16:50:20 GMT, Kent M Pitman <pit...@world.std.com>
wrote:

>


>Er, I don't *think* you can patent an idea. I think it has to be a process.
>

Technically that is true, but IMO a lot of recent patent grants walk a
razor thin line ...


>> Mind you, I think patents should be irradicated or SEVERELY reformed.
>
>Yep.

Not eradicated, I think, but most definitely reformed.


George

Andy Freeman

unread,
Jun 29, 2001, 7:30:09 PM6/29/01
to
> Yes, certainly. Same as with copyrights. But what I'm saying is that at
> the same time, if you share something with the public and they immediately
> "get it", that's some evidence to me that what you shared is of less value.

I think that the various incompleteness theorems, NP-completeness,
and even diagonalization are counter-examples. Lots of things are
blindingly obvious in retrospect; I don't see how that correlates
with value.

In any event, patents aren't a guarantee of value, they're a reward
for revealing novelty. One might argue that obvious in retrospect
is evidence against novelty, but it seems weak at best.



> most software is obsolete in 3 years or less, it seems hard for me to
> see a justification in any software patent lasting longer than that.
> In 99% of cases, if you haven't made your fortune by that time, it
> wasn't the big deal thing you thought...

Consider linear programming. A given program may well be obsolete
in 3 years, but a significant advance in linear programming would have
benefits that lasted long after its first implementation was obsolete.

Heck - programs fail to make money for lots of reasons; why should
protection lapse just as rev 3.1 hits the market?

It's somewhat surprising to see KMP claim that an algorithm developer's
livelyhood should be tied to the success of a software product....

Remember, trade secrets are the alternative to patents. TSs can
live forever.... (Independent development is a defense, but if
a Microsoft executes a well-designed plan of exploitation, it can
be extremely difficult to find competent independents.)

> Er, I don't *think* you can patent an idea. I think it has to be a process.

mechanism/process for function

-andy

Andy Freeman

unread,
Jun 29, 2001, 7:41:28 PM6/29/01
to
> They are different because we live in a "rational" world; that is, you
> can't, by some Cantor-like diagonalization end up in a place in the
> address space called the "real" world that isn't one of the finitely
> enumerable states of the machine. A great deal of the "purpose" of
> software, at least at this stage of evolution, is convergent
> technology; to enumerate and control those important things that can
> be expressed in a small number of bit patterns. The idea of doling out
> pieces of that finitely enumerable world like .com names until they
> are all gone is what bugs programmers, perhaps more than other artisans
> because they haven't honed their craft to the point that they are within
> striking distance of an actual, real, mathematical proof that there can
> be no other way to achieve a certain end (worse if you add the word
> "efficiently"). We are all hyperconscious of just how tiny our world is.

Like I said, I don't see what distinguishes software patents. I could
argue that the theoretical ability to enumerate doesn't make the space
usefully small. (The "efficient" constraint does reduce the size of
the result set, but its filter is quite expensive, so I don't think
that it has the effect that KMP claims.) I think that the space is
incredibly large, that the sun will go nova before a google of KMP's
would hit its boundaries.

Instead, I'll point to history, namely an assertion that the patent
office should be shut down because "everything had been invented".
That was a reference to physical artifacts and it happened early this
century.

They got over it.

-andy

It is loading more messages.
0 new messages