Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!news.luth.se!eru.mt.luth.se!bloom-beacon.mit.edu!gatech!darwin.sura.net!martha.utk.edu!caffeine!mbk From: mbk@caffeine.engr.utk.edu (Matthew Kennel) 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? Followup-To: comp.object,comp.lang.beta,comp.lang.c++,comp.lang.eiffel,comp.lang.python,comp.lang.sather,comp.lang.smalltalk Date: 12 Jul 1995 18:20:00 GMT Organization: I need to put my ORGANIZATION here. Lines: 77 Message-ID: <3u13og$ehd@martha.utk.edu> References: <805548287snz@galacta.demon.co.uk> NNTP-Posting-Host: caffeine.engr.utk.edu X-Newsreader: TIN [version 1.2 PL2] Xref: news.daimi.aau.dk comp.object:33402 comp.lang.beta:445 comp.lang.c++:128664 comp.lang.eiffel:9176 comp.lang.python:4978 comp.lang.sather:1913 comp.lang.smalltalk:24307 Dr. Rich Artym (rartym@galacta.demon.co.uk) wrote: : 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? This sounds like my set of numerical programs, which have been evolving over a couple of years. Now they do things that were totally unplanned for 2 years ago. : Was there an important negative impact when : major internal class surgery was needed? No. The combination of system-wide bulletproof strong compile-time typing and garbage collection helped make the transition go without many problems. In fact, I've had far fewer problems performing "major brain surgery" on programs---and getting them working again---than I ever did with C. This circumstance is where I've found strong, compile-time checked typing is the *most* useful. During initial development of some subsystem I have a good idea of what the various parts of the program should be doing; I feel that dynamic typing wouldn't be much a problem then as I have most of the knowledge "in my head" already. It's when I go back and make big changes on one part which have bad consequences on other, previously working sections, where the strong type checking saves my butt. It has pointed out details that I totally forgot about which would have caused 'submerged' bugs. Garbage collection also helps because I've found that the typical memory access patterns of subsytems are hard to predict 'a priori': doing manual memory management often precludes getting old code from working right in the new framework. For example, I've sometimes ended up creating "memoized" versions of classes which Decorate (in D.Pattern sense) various original ones. If the original one had either specified that clients must free allocated memory, or, if the original class freed memory on its own, then it would be harder to create a drop-in-replacement memoizing Decorator of the old one, as the memoizing version has to retain some state. If you think about it, either choice for manual memory management made by the original class can screw up trying to make this Decorated version work in exactly the same context. Issues like this come up frequently. {That last example just came up yesterday: I made a decoration of a phase-space embedded data set class that represents a consecutive subset of the original phase space that I use in a bootstrap statistical procedure. The bulk of the algorithm's time is spent searching for state-space neighbors with a k-d tree. The memoization comes about realizing that the set of a few neighbors in the whole set is likely to contain the set of nearest neighbors in a subset, so 200 successive re-segmenting and re-neighbor-searches can be done faster by accumulating neighbors of the superset and memoizing these. This involved some middling 'brain surgery' but was working perfectly without interaction in 90 minutes.} With GC, (and suitable run-time assertion checking) if you get the explicit interfaces to compile you're quite likely to continue to have a working program despite major brain surgery. : Do you have any specific advice : for others that may wish to carry out R.P. using (say) C++ or Eiffel? In sum, I've found that a strongly typed, GCing language has personally let me write programs that have evolved quite significantly without causing the usual accretion of Deep Voodoo and fragility. : ########### 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."