🚀 go-pugleaf

In article <1990Sep18.150322.17690@pdn.paradyne.com>, locke@nike.paradyne.com (Richard Locke) writes:

>In article <33820@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>><We are interested in any rapid prototyping
>><environments currently in use. Environments that encourage the evolution of
>><prototypes into the final product are also of interest to us. We would like
>>
>>I am very much interested in hearing about this as well.  It seems to me
>>that the problem with many rapid prototyping environments today is that
>>you have to throw away the prototype and re-code from scratch in C or
>>something similar.
>
>Brooks, "Mythical Man-Month" is well known for suggesting that a
>prototype be thrown away.  Evolution of a prototype into a product
>is a BAD THING and has been intimately related to the failure of
>projects I've worked on in the past.  Conventional wisdom is to throw
>out the prototype.  This is not a bug, it is a feature.  It allows
>the prototype to be brutally hacked together in a short period of time,
>and then tossed away allowing the programmers to *really* do it right
>the first time.

I sort of agree and yet I sort of disagree.  I agree that most proto-
types are brutal hacks and should be thrown away.  However, if we had
the right prototype language, allowing us to generate prototypical
code one half of an order of magnitude quicker than C, then the code
in the right prototype language (RPL) could be modified, possibly by
an automatic translator, to C.

In my current environment, I have developed many prototypes in REXX and
some final versions in C.  REXX is a very high level language in which
you simply don't have to worry about data representation because of two
facts:


     *  Everything is a character string

     *  There are NO length restrictions on ANY string, and NO restric-
        tions on what a character string can contain


The genius of REXX is NOT that its syntax follows that of PL/I, as
Mike Cowlishaw seems to believe: it is that the above two laws obtain
in an uncompromising fashion.  Because of the above two facts, "brutal
hacks" are usually not required in REXX, because the typical brutal
hack imposes close to unacceptable considerations on the use or the
maintenance programmer in the name of getting quickly around some
representational constraint.  Things like string length restrictions,
undocumented array bounds, and mysterious relationships amongst
resource allocating constant values come to mind.

Although I lack a REXX to C translator and so in some sense recreate
everything when moving  from REXX prototype code to C code, in another,
stronger sense the same code (same algorithms) run both in the proto-
type and the final version.

Soooo....if you have REXX, use it.  I understand it's now available
in OS/2 Extended Edition, the Amiga and unix.