Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!seunet!news2.swip.net!plug.news.pipex.net!pipex!soap.news.pipex.net!pipex!dish.news.pipex.net!pipex!demon!galacta.demon.co.uk!rartym From: "Dr. Rich Artym" 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: Thu, 13 Jul 95 10:58:39 GMT Organization: Galacta Institute for Computer Rights Lines: 83 Message-ID: <805633119snz@galacta.demon.co.uk> References: <805548287snz@galacta.demon.co.uk> Reply-To: rich@galacta.demon.co.uk X-NNTP-Posting-Host: galacta.demon.co.uk X-Newsreader: Demon Internet Simple News v1.29 Xref: news.daimi.aau.dk comp.object:33446 comp.lang.beta:453 comp.lang.c++:128815 comp.lang.eiffel:9211 comp.lang.python:4998 comp.lang.sather:1920 comp.lang.smalltalk:24343 In article neil@aldur.demon.co.uk "Neil Wilson" writes: > Dr. Rich Artym (rartym@galacta.demon.co.uk) wrote: > : 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.] > > Why oh why do people insist on using the term Prototyping in conjunction > with Information System development? Do you intend to mass-produce it > afterwards? (Congratulations on mastering the 'cp' command). Are you > going to write a new system afterwards that is the same but on a larger > scale? (don't forget to change that bubblesort will you). Prototyping is > a horrible 'Humpty-Dumpty' word. Yes, I am aware of that view, but I was trying to avoid entering into discussions on that topic, for no reason other than to stay on-charter in these OO newsgroups. That's why I gave a specific definition, and was seeking feedback from developers that had been through the experience of using statically-typed OOPLs + R.P. in accordance with that definition. I had hoped in this way to bypass the severe advocacy that surrounds the subject, not because it's necessarily wrong but because it's usually less useful than the judgement of people relating their own experiences. > [lots of good stuff snipped] > The promise of O-O is more malleable structures that can withstand > massive changes. "Massive" changes? Different people use differing degrees of hyperbole when describing the ability of OO systems to adapt to change, but I've never heard anyone use the word "massive" in this context before. Extensibility, reuse, polymorphism, genericity, opacity, design by contract and all the other goodies in our OO toolkit, they all help minimize the impact of change on our designs, but if you suggest that they allow us to cope with "massive" change easily then I would question your use of the word "massive". Many of us are quite pleased to find that OO handles small-scale change more resiliently than earlier approaches, but that's as far as it goes --- we're not even fully at the "software-IC" level yet, which might conceivably allow good stability over medium-scale change. > [more snips] > Requirements and design are never fully known. They always continue to > evolve. Hopefully the rate of change will decrease over time, but don't > bank on it. Development never ends until the system is obsoleted. Nobody would dispute that, but it's a matter of degree. R.P. (as per the definition that I gave) deals with situations in which the uncertainties are so great that more traditional methodologies have almost nothing with which to work. No mention is made at all of whether the prototype code will be part of the final product, that being a completely separate concern. Indeed, it is often stated that to use the final implementation language in the R.P. stage is a huge hindrance, because it becomes difficult to avoid thinking about infrastructure details at far too early a stage. OK Neil, you don't like the word "Prototyping", but I'm flexible, so I'll rephrase my question for you. What have you found to be the major issues when using OOPLs in developments where the requirements and design details are varying so widely that no parent-child relationships remain stable, where containers bear objects that vary in type over time, where signatures and contracts are varying so rapidly that even "Do What I Mean" needs to be accompanied by crossed fingers, and where incremental development is so multi-threaded that partial implementation and global inconsistency are not a problem but an asset? It's feedback on this that I was trying to elicit, and specifically on the effect of static typing on such issues. The feedback so far suggests that there is a lot of useful experience in the field on such questions, and I hope we'll hear more of it here. ########### 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."