Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!trane.uninett.no!Norway.EU.net!EU.net!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: 14 Jul 1995 02:59:08 GMT Organization: RedRock Lines: 98 Message-ID: <3u4mht$5sq@noc.tor.hookup.net> References: <805548287snz@galacta.demon.co.uk> <3u3cdm$pu1@noc.tor.hookup.net> 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:33505 comp.lang.beta:463 comp.lang.c++:129024 comp.lang.eiffel:9252 comp.lang.python:5036 comp.lang.sather:1936 comp.lang.smalltalk:24383 In , Neil Wilson writes: >Bob Hutchison (hutch@RedRock.com) wrote: >: 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. > >It is this translation step that bothers me. What is the magnitude of >effort required to translate from experimental system to production >system? Translation usually introduces defects if done by humans (and >sometimes even if done by computer). How is the level of quality >maintained? This translation step has been something that I was worried about for a time as well. There are a few things to note. First, the direction is from prototype to real-thing and it is one way -- there has been no need for me to go the other way (not that this could not happen, just that it hasn't and I suspect it is unlikely to). Second, translation from smalltalk to eiffel is no more error prone than translating from a design (for argument lets say it was done in an OO design notation) to implementation, in fact it may be easier since there is more implementation detail included. Third, I think your concern with level of quality may not be an issue since I am *not* trying to keep the two in sync. > >Does using an exploratory language instead of a production language >actually save the time required for subsequent translation? Why bother >translating at all? Definitely it saves time. My argument is that I don't know how to do something and so I must find out, and I'm going to find out by prototyping. In my experience it is faster to do this kind of thing when I have a programming language where I can change the program when it is running, when I don't have to read the data in every time I want to try something, and where I can write little routines to munge/analyse the data. Why bother translating at all is a very good question. When you use smalltalk you can very often get pretty reasonable performance out of the prototype. However there are cases where some of the disadvantages of smalltalk must be considered (image size, perhaps performance, runtime licences) and where there is an existing code/tool base that could be used to implement the rest of the system. Another point is that sometimes when I'm doing this kind of thing I have no interest in writing software that is maintainable, or even works in all cases -- I am often in a hurry and am content to write throw-away code. I should note, that I would think that you must separate this prototype from 'real' code. This does not mean that the 'real' code cannot be in the same language as the prototype. > >When you're experimenting with the exploratory language is it the entire >system or just a sub-section you usually work on? I almost always am only concerned with a subsystem. On occasion I am interested in devising a model of the problem, and this would be ultimately for a larger part of the system, but again, I'd only be prototyping what I couldn't understand so this is still more of a sub-system (just sliced in a different way). > >I suppose I ought to consider myself lucky, but I've never been in a >situation where I couldn't at least identify the generic pattern the >system or at least part of the system conforms too. I've been in some >chaotic situations (Black on Monday, White on Tuesday, etc.) but never >where I felt the need to alter a program or an inheritance structure in >mid-execution. It can be fun, given the right tools. It can also be very unpleasant slow work that frustrates and magnifies every little problem, like compile-link times :-) > >I do appreciate that there are times a quick turnaround time is top of >the list of requirements and is a lesson that many implementations of >statically-typed languages have yet to learn. Another thread on >comp.lang.eiffel is (hopefully) addressing this very issue w.r.t Eiffel. I agree, reasonable turn-around is important. I can easily live with slower turn-around when writing real code, but smalltalk really spoils you. Eiffel's turn-around can be something else -- it reminds me of C++ when cfront was still around, or when templates were new. I'm not sure that static type checking is necessarily the reason, especially when you consider Clean (static type checking and type inferencing). > >-- >Neil Wilson (neil@aldur.demon.co.uk) ...Arrive without travelling, >Ossett, Yorkshire, UK see all without looking... -- Bob Hutchison, hutch@RedRock.com RedRock, 135 Evans Avenue, Toronto, Ontario, Canada M6S 3V9 (416) 760-0565