Path: utzoo!attcan!uunet!know!news.cs.indiana.edu!ariel.unm.edu!unmvax!bbx!tantalum!tom
From: tom@eds.com (Tom H. Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Eiffel as a design language ?
Message-ID: <4309@tantalum.UUCP>
Date: 12 Dec 90 00:01:00 GMT
References: <1037@tetrauk.UUCP> <4106@tantalum.UUCP> <1045@tetrauk.UUCP> <4212@tantalum.UUCP> <1050@tetrauk.UUCP>
Sender: usenet@tantalum.UUCP
Reply-To: tom@ozmium.UUCP (Tom H. Meyer)
Organization: EDS Research
Lines: 72

>On this topic, I would be interested to hear the opinions of Eiffel users on
>it's capabilities as a DESIGN language.  The whole issue of how to get object
>oriented design right is far from resolved, but it's already clear that it's a
>much more iterative process than "conventional" (what ever that means!)
>methods.

I personally have found that using a programming language (any of them) as a
design language can lead to a somewhat insidious situation characterized by
the old phrase, "When the only tool you got is a hammer, every problem
looks like a nail." It is my belief that when you use a programming language
as the design language, you bias your design to the capabilities of
the language. I believe Dikstra said "One programs *into* a language, not
in it." (emphasis mine) An acquintence of mine, Dar Scott, refined this to
"One *should* program into a language, not in it." I believe this is closer
to being accurate. Therefore, I generally shy away from using any
programming language to do the abstract design.

>One of the reasons I'm using Eiffel in my current project is that I find I can
>use it to design as I go.  The style, as well as the simplicity of syntax,
>means that I can sketch classes in Eiffel, often leaving them incomplete until
>I've clarified other details which they depend on.

I will admit that, given that one is going to program in an object oriented
style, my more abstract language often maps identically into Eiffel classes.
I have also used Eiffel code literally in some correctness proofs. I believe
this is a direct result of the clean, simple design of Eiffel which is
something that I've always looked for in a programming language.

>Because I'm using a single language to do the design and implementation, I find
>that I can easily change the details when I discover that what looked right at
>an early stage turns out not to make such good sense once I get down to the
>nitty-gritty.  I don't have the problem of going back to what I wrote for the
>design and changing it because what I've coded isn't what I thought I was going
>to do.  The Eiffel code IS the design of the class.

I think that perhaps the 'short' version of the classes is closer to the
design. Detail omission (or hiding) seems to be a natural part of the
design process. Focus on the big picture and all that. Thus, the actual 
implementation of the features isn't necesarily relevant to the overall design.

>I don't in fact subscribe to the view that software design and coding are
>separable activities - the idea that software coding is somehow "manufacturing"
>a software product according to a design.  Software manufacturing is copying
>disks!  Designing and coding are all design in progressively greater detail.  A
>programmer is a designer;  if he's not, he's in the wrong job.

Obviously, I disagree. Programming is the manifestation of the design. The
design exists independant of its coding. For example, a single design can
be implemented in many different languages. Given that all the implementations
actually do the same thing (mod bugs, etc.), it's really still just one
design, not many. If you feel coding and design are the same thing, would
not that mean that each different implementation is a different design?

>Of course I'm not saying that the Eiffel code embodies the overall structural
>design of a complete system;  you still need something else at a high-level,
>but this can generally stop at the block-diagram level of detail.  It's at the
>individual class level that I find Eiffel is sufficient in itself.

I would agree that, at some point, the abstraction difference between the
design and the code is too small to want a different design language. Perhaps
we are just arguing differing levels of abstraction or focus.

This year's OOPSLA had quite a few papers and a panel on frameworks.
Do you think Eiffel is a good framework language? Do you think frameworks
are useful? The community was quite divided on the subject. Perhaps it's
too early to say much about it. I don't have any personal experience using
one or trying to adhere to one.

Comments?

tom meyer, EDS Research               | If I don't see you in the future
...uunet!tantalum!tom                 | I'll see you in the pasture