CL and UML

97 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