Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!seunet!news2.swip.net!plug.news.pipex.net!pipex!edi.news.pipex.net!pipex!dish.news.pipex.net!pipex!news.mathworks.com!gatech!hookup!noc.tor.hookup.net!news
From: hutch@RedRock.com (Bob Hutchison)
Newsgroups: comp.object,comp.lang.beta,comp.lang.c++,comp.lang.eiffel,comp.lang.python,comp.lang.sather,comp.lang.smalltalk
Subject: Re: Rapid Prototyping + statically-typed OOPLs?
Date: 13 Jul 1995 15:00:05 GMT
Organization: RedRock
Lines: 200
Message-ID: <3u3cdm$pu1@noc.tor.hookup.net>
References: <805548287snz@galacta.demon.co.uk>
Reply-To: hutch@RedRock.com (Bob Hutchison)
NNTP-Posting-Host: redrock.tor.hookup.net
X-Newsreader: IBM NewsReader/2 v1.2
Xref: news.daimi.aau.dk comp.object:33454 comp.lang.beta:455 comp.lang.c++:128842 comp.lang.eiffel:9219 comp.lang.python:5000 comp.lang.sather:1922 comp.lang.smalltalk:24348

In <805548287snz@galacta.demon.co.uk>, "Dr. Rich Artym" <rartym@galacta.demon.co.uk> writes:
>people's views on the use of statically-typed OOPLs in "real" rapid
>prototyping.  I'd better narrow down the intended meaning of R.P. with a
>definition consistent with that used by some of its advocates (my words):
>
>    Rapid Prototyping ::=  An iterative approach to the analysis of
>    requirements through production of an operational prototype in which
>    elements of design are also explored.  [Excludes the degenerate case
>    in which no significant changes to the first prototype are needed.]
>

I suspect that this thread is going to degenerate rather quickly, 
despite your best intentions, so I'll comment early :-)

In my experience the situation is rarely so severe that more
'controlled' (or less controversial) methods can be used.  But, 
however rare these situations may be, they do exist.

There are a number of situations where I have seen it recently, and 
they can be roughly characterised in the following way:

- the data available to the program is not understood in content,
correctness, consistency, or relevance to the problem, and the
relationships that can be *discovered* are not known.

- The algorithm to solve the problem is not known, or is known to be 
useless in real-life (e.g. exponential) and so heuristics must be 
developed, or it is unknown how much of the problem can be solved.

On occasion you run into the situation where it is the requirements
are not known, but in my case other more conventional methods can be
used that may take longer but do not require the involvement of R&D
staff, that is, I can let someone else handle it.  This, I think,
illustrates one the the biggest problems with rapid prototyping, and
that is the resources required to do it.

Now, given the characteristics I noted the kind of software tool I 
would want become more clear.

- the ability to explore data

- the ability to setup relationships, perhaps simple static ones or
sometimes programmatic ones, without having to start all over from 
initial load

- the ability to write little throwaway routines that can do some 
analysis or drudge data manipulation

- the ability to change an algorithm, perhaps in the 'debugger' (this 
can be quite a shock to people that hold certain 'truths' about 
software engineering... the first times I did this I experienced 
some queasiness :-)

The languages that let you do all of these are the ones like smalltalk
and various members of the lisp family -- they all have an environment
or image that can be manipulated programmatically and that is
persistant.  It is likely that the static typing of Eiffel or C++
would get in the way of data exploration, but I don't know since you
cannot do what I need to do in those languages anyway.

However, in my case the single most common problem is where I don't
know how to solve the problem.  In many cases the data isn't an issue,
though on occasion the time taken to load the data can be annoying.
Where this is the only problem I am trying to solve through the
prototypes then the requirement for an environment becomes a little
less important and flexibility of the language becomes much more
important.

Now, I am lucky because I find smalltalk (and lisp for that matter) 
quite flexible and I don't have any trouble expressing algorithms in 
it.  But there are alternatives.  C++ and Eiffel were specifically 
mentioned in your question, but there are still others.  Three among
many that are notable in my mind, are Clean, Erlang, and Dylan.

Clean is a statically typed functional non-OO language with type
inferencing.  It has a very clean (pun un-avoidable, that is, it is
intentional, but on someone else's part :-) syntax and a number of
features that I find attractive.  I have not used it for this kind of
thing, yet.  (If you are familiar with Haskel or ML you will know what
kind of language Clean is).

Erlang is very much like Clean but is typeless.  It has a few really 
interesting features from both a debugging and an implementation point
of view.  First, it is a concurrent language and has implemented its 
debugger as just another process.  Second, it supports the dynamic 
loading of updates to functions.  The combination of these two things
effectively provide an environment as I mentioned above, but one that
is not persistant (I may be wrong on this persistancy bit). 
Unfortunately, I have not had the opportunity to use Erlang yet.

Dylan is a dynamic object oriented language.  It has the potential to 
address all of my rapid prototyping requirements and be a final 
implementation language.  Unfortunately, this language is not 
available and so can only be the subject of speculation.

OK, so we have some options now (C++, Eiffel, Erlang, Clean,
smalltalk, and say CL (Common Lisp)) for consideration.

As I write this, I am taking a break from a tedious process of trying 
to create a heuristic to solve a particularly nasty problem using 
known OR (operations research) techniques.  Unfortunately, this thing 
is done in C++ (I must quickly add that I 'inherited' this project, I 
didn't choose C++ for this).

There are two issues I am faced with:

- the compile-test-tinyChange-compile cycle
- memory management

I have the types/objects well established so that isn't an issue, I'm 
just tinkering with a few methods.

I will never voluntarily do this kind of thing where automatic garbage
collection is not present.  And I will make every effort to never have
to sit through another compile and link that takes more time than it 
takes to pour a cup of coffee (and I keep a thermos at my desk :-).

C++ isn't doing it for me.  I've done this kind of thing many times in
C and C++ and would rather not do it again.

Eiffel has the memory management, but it makes the C++ compile-link
look instantaneous.  I've used Eiffel in a situation where I am adding
features incrementally, aside from the turnaround it works very well.

Clean has memory management, and it has a really quick compile-link
time.  It has no way of simulating an environment so its only 
advangage over Eiffel is the quick turn around and a particularly nice
syntax (and powerful features supported by that syntax).

Erlang has memory management, really fast compile-link, a simulated
environment, and concurrency.  It also has a really nice syntax (much
like Clean).

Smalltalk has memory management, no compile-link time that you'd 
notice, a truely useful environment, lots of tools, a nice class 
heirarchy.  I've used this for rapid prototyping and it is currently 
my tool of choice for this.  I've also noticed that I have so far been
able to take the results of the prototype and implement them in Eiffel
with very little difficulty, much less than I expected.

CL is like smalltalk for the purposes of this discussion.  I don't 
think the criteria to choose between it and smalltalk will be found in
their use in rapid prototyping.

In summary, I don't think it is the 'static typing' of C++ or Eiffel 
that cause difficulty for their use in rapid prototyping, it is their 
compile-link times and static runtime functionality.  In the case of 
C++, its requirement that new/delete be properly used at all times is 
its biggest problem (w.r.t rapid prototyping).  In the case of Clean, 
it has a small compile-link time, static runtime functionality, but 
some other features (like clarity of expression) that I think could 
make up for this.  Erlang, smalltalk, and CL have everything I need 
for rapid prototyping.

It is clear to me that smalltalk, Erlang, and CL may not represent the
best possible tools for rapid prototyping, but they represent the best
I have available to me at the moment.

>The Smalltalk community often claims that unconstrained object handling
>is excellent for R.P., but I would like to hear from C++/Eiffel/Sather
>(or other) practitioners how their languages fare in an R.P. environment.
>For example, has anyone developed a genuine prototype in C++ using a very
>coarse or minimally-specific class organization, and then repeatedly changed
>it, and how did this work out?  Was there an important negative impact when
>major internal class surgery was needed?  Do you have any specific advice
>for others that may wish to carry out R.P. using (say) C++ or Eiffel?

In the course of iterative feature addition I have noticed one main 
problem in using C++, and that is memory management.  When refactoring
classes in C++ you are additionally burdened with the reassignment of
the responsibility for creating and deleting objects.  I have found
this to be a good source of memory leaks.

Between Eiffel and smalltalk I have more experience with smalltalk,
but I've found that refactoring is about equally difficult (I do not
find it particularly easy in smalltalk).  Smalltalk takes advantage of
its typelessness and by providing the ability to test the refactoring
as you do it.  Eiffel helps through its type annotations and its
refusal to compile until the types are correct.  In the case of
smalltalk, there is a refactoring tool available from the archives
that I have not used, but is said by reliable sources, to provide
support for common refactoring problems (e.g.  moving methods up or
down the class hierarchy, inserting/removing a class from the
hierarchy and so on).

>###########  Dr. Rich Artym  ================  PGP public key available
># galacta #  Internet: rich@galacta.demon.co.uk     DNS 158.152.156.137
># ->demon #            rich@mail.g7exm[.uk].ampr.org   DNS 44.131.164.1
># ->ampr  #  NTS/BBS : g7exm@gb7msw.#33.gbr.eu
># ->nexus #  Fun     : Unix, X, TCP/IP, OSI, kernel, O-O, C++, Soft/Eng
># ->NTS   #  More fun: Regional IP Coordinator Hertfordshire + N.London
>###########  Q'Quote : "Object type is a detail of its implementation."
>


--
Bob Hutchison, hutch@RedRock.com
RedRock, 135 Evans Avenue, Toronto, Ontario, Canada M6S 3V9
(416) 760-0565