Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!trane.uninett.no!Norway.EU.net!EU.net!gatech!news.uoregon.edu!news.bc.net!news.mindlink.net!vanbc.wimsey.com!ddsw1!news.mcs.net!usenet From: jim.fleming@bytes.com (Jim Fleming) 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: 12 Jul 1995 16:30:15 GMT Organization: Unir Corporation Lines: 99 Message-ID: <3u0tan$gj5@News1.mcs.net> References: <805548287snz@galacta.demon.co.uk> NNTP-Posting-Host: pc11.bytes.com Mime-Version: 1.0 X-Newsreader: WinVN 0.93.14 Xref: news.daimi.aau.dk comp.object:33397 comp.lang.beta:443 comp.lang.c++:128647 comp.lang.eiffel:9169 comp.lang.python:4968 comp.lang.sather:1910 comp.lang.smalltalk:24299 In article <805548287snz@galacta.demon.co.uk>, rartym@galacta.demon.co.uk says... > >The recent debacle about C hackers brought to mind the often-debated >distinction (or lack thereof) between hacking and rapid prototyping. >Without getting onto that topic, I WOULD be interested in hearing >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.] > >The area that interests me most is the effect of static typing on design >constraints. Since the requirements and design are not known fully until >the R.P. development is ended, it would appear that the benefits offered >by languages like C++ are not easily achievable in an R.P. environment, >or conversely, that use of such languages could hamper the R.P. effort >and so reduce the benefits of this form of development. > >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? > >PS. Mark Mullin's "Rapid Prototyping for Object-Oriented Systems" is >quite negative on C++ in this role, and doesn't address the above issues >either. Would anyone like to recommend a more recent book that does? > > >########### Dr. Rich Artym ================ PGP public key available @@@@@@@@@@@@@@@@@@@@@@@@@@@@ C++ was not designed for Rapid Prototyping (or Rabid Prototyping as some people call it). BTW, I am a big advocate of Rapid Prototyping and C+@ was designed from the beginning with that in mind. (There is an article on C+@ in the current issue of the German magazine iX). A similar situation exists between the "troff camp" and the "FrameMaker camp". I spent years at Bell Labs trying to convince people that Word and FrameMaker improved productivity because they offered instant feedback that troff did not provide. People still use troff, and in some cases I can understand their reasoning. In some cases, people just do not like change. I have come to the conclusion that there must be right brain and left brain people. One group uses troff and C++ and the other group uses tools which provide rapid feedback and do not subject the developer to long edit/compile/test cycles. Sometimes it appears that the West Coast approach (XEROX Parc) is visual and rapid while the East Coast approach (Bell Labs) is textual and slow. Both influences on the industry have been significant. In my opinion there is room for both approaches. One can see this same evolution with Windows NT. Basically, it is UNIX RTR with a pretty face. Bell Labs could have produced this in their sleep 10 years ago. Instead, they putzed around with the DMD terminals connected over thin serial links which made it difficult to develop software via rapid prototyping. Developers had to compile on a host, download, test, crash, reload, and try again. It was very tedious, just like C++. In fairness to the UNIX approach, I have found Windows NT to be tedious in its own way. Rather than pop up an ASCII configuration file, one has to point and click on a maze of screens and options to administer the system. I guess the bottom line is that "rapid" is not always tied to graphical user interfaces. When C+@ was designed, the decision was made that people could develop in the "troff model" or the "gui model". Both models support Rapid Prototyping and coexist to satisfy both kinds of developers. It is interesting that some of the most productive people used the "troff model" because they were more familiar with the tools from that era. New developers, find the "gui model" to be the way to go. There is room for both approaches...just keep in mind that Rapid Prototyping does not have to imply GUI interface...it should imply that productivity is improved and that the system is used to replace human brain power...with dynamic languages like C+@ and Smalltalk...the system is used as part of the development process from start to finish... reuse is encouraged and is part of the Rapid Prototyping process... -- Jim Fleming /|\ Unir Corporation Unir Technology, Inc. jrf@tiger.bytes.com / | \ One Naperville Plaza 184 Shuman Blvd. #100 %Techno Cat I / | \ Naperville, IL 60563 Naperville, IL 60563 East End, Tortola |____|___\ 1-708-505-5801 1-800-222-UNIR(8647) British Virgin Islands__|______ 1-708-305-3277 (FAX) 1-708-305-0600 \__/-------\__/ http:199.3.34.13 telnet: port 5555 Smooth Sailing on Cruising C+@amarans ftp: 199.3.34.12 <-----stargate----+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|