Re: Consistency

[Jim Kempf <kempf%hplabsc@hplabs.HP.COM>]

In response to Gabrial's concerns:

>At this point I'm worried about a couple of new things: first, that
>the Common-Lisp-skeptics will accuse us of doing to object-oriented
>programming what we did to Lisp: obfuscate and ruin it;

This may happen, but I think it is too late to back out now. 
Application developers are waiting for an object oriented extension,
and there has been some grumbling that if a major application written
in Common Lisp (NOT an expert system shell) does not come out in
the next year or so, Common Lisp, itself, may be sunk. 

> second, that
>the proposal might be in jeopardy because it is too complex. 

Though this may sound trite, I think the quote from Einstein about
"everything should be made as simple as possible to understand,
but not simpler" is relevent here. If we are trying to do something
complex, then we should try to explain it as simply as possible.
If there is too much mechanism, then maybe some should be eliminated.
As I have not had a chance to look at the documents yet (scheduled
for this weekend) I can't yet say which may be the case.

>The people at Tektronix had no trouble understanding what I said, nor
>did they fail to understand CLOS. They were appalled at the complexity
>and questioned whether that complexity was necessary.

I think some of the complexity may be the result of a desire to
provide maximum flexibility. Certainly this is true of the 
Metaobject Kernel.


>I still believe that we are writing a specification, and it would be wrong
>to put fluffy, imprecise language into the document.  I think from my
>comments about Moon's errata you can still see this attitude.  And if you
>compared the draft material as of 2 weeks ago with the current draft you
>will see a major movement towards consistency and preciseness, even at the
>expense of pretty language - it may not be perfect, but a lot of
>what was there before was embarrassingly bad.
>
>When I decide to write things using mathematical notation, for example, it
>is because I cannot think of how to unambiguously express the concepts in
>English.  (Also, if the concepts were simpler, they could be expressed in
>prose more easily.)

I think there is a major problem here which CLtL itself faces, and
that is specifications of large complex software systems just simply
cannot be done accurately in English (or any other natural languge,
for that matter). Nobody expects to be able to built a bridge or
a jet airplane from an English description, why should the
same not be true of a complex software system? Specification
languages like Larch or OBJ are the only way to get a precise
design, in my opinion, but they are still largely experimental,
and therefore probably of little help to the task at hand.

As mentioned, I have yet to read the documents, but from my
experience working with PCL over the last couple months,
I think there is something worthwhile there and I would
not like to see it remain unavailable to applications developers
because some people are grumbling.

		Jim Kempf	kempf@hplabs.hp.com