Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!trane.uninett.no!nac.no!Norway.EU.net!EU.net!uunet!in1.uu.net!intrt50.interet.com!intrt7.interet.com!not-for-mail From: jim@interet.com (James C. Ahlstrom) 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 09:15:28 -0400 Organization: Interet Inc., Millburn, NJ USA Lines: 75 Message-ID: <3u5qlg$1k8@intrt7.interet.com> References: <805548287snz@galacta.demon.co.uk> <1995Jul13.154620.4333@rcmcon.com> NNTP-Posting-Host: intrt7.interet.com Xref: news.daimi.aau.dk comp.object:33521 comp.lang.beta:464 comp.lang.c++:129097 comp.lang.eiffel:9271 comp.lang.python:5045 comp.lang.sather:1937 comp.lang.smalltalk:24396 In article <1995Jul13.154620.4333@rcmcon.com>, Robert Martin wrote: >"Dr. Rich Artym" writes: > > >>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? > >I and my associates have been embroiled in a significant project for >the last couple of years. Prototyping is an important part of this >project because the customers does not have precise functional >specifications. They work out what the programs ought to do by >looking at our prototypes and then adjusting. We are commercial software developers. Most of out work is maintaining and rewritting a very large financial model. We also find prototyping valuable for the same reason. We find that the customer will know exactly what software they want right after they see it. If you don't get a prototype in front of them, you don't get any useful information back about what they want. >There may be better languages than C++ for operating in this kind of >environment, but we currently have no complaints. We are using > ... >The critical aspect of this ability to rapidly prototype is the afore >mentioned framework. This was a large effort on our part. It has >evloved and grown over the last couple of years to the point where the >prototypes can now be generated very quickly. However, at the outset, >when the framework did not exist, prototyping was very slow. >Purposely slow. We were investing more effort into the creation of >the framework, than we were into the prototypes. We agree. You must have a framework built up (we call it infrastructure) so that you can produce prototypes quickly and cheaply. Until recently we have been using C (not C++). Lately we have been exploring Python as a development language, and so far we are very pleased. Python has several advantages as a prototyping language. First, it is interpreted, not compiled. It really fast to make a change and then see what happens. This is especially important in GUI design, where we find that we throw away a lot of code because when we see it on the screen we don't like it. Second, it comes with a lot of "infrastructure" already built in. That is, it has built in networking, regex, string utilities, dictionaries, lists, cryptography, persistent objects, etc. which are absent in C. Also, though not relevant to this thread, but relevant to us as commercial developers, Python is easier to learn than C++. I feel more comfortable asking our C staff to learn Python than I would asking them to learn C++. The object-oriented nature of Python is more apparent. I do think a lot of Python's convenience comes from its lack of typing. For example, you can always add another data attribute (instance variable) to any object with just "self.new_attribute = something" and "something" can be anything at all, even a list or dictionary. The corresponding C would require a change in a structure and often extensive recompilation. Actually these Python objects do have types, but the types are only checked at run time. As commercial developers, we tend to think in terms of real languages rather than the concepts behind them, but in my mind, rapid prototyping is best done with interpreted very-high-level languages which lack strong compile-time typing. An alternative is a build up of C or C++ libraries devoted to your business area of expertise. We are in the early stages of converting a significant portion of our product to Python. Unknowns are speed (good so far, Python is pre-compiled) and the size and complexity which a typeless language can support. We will let you know how it turns out. Jim Ahlstrom