Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!news.msfc.nasa.gov!elroy.jpl.nasa.gov!lll-winken.llnl.gov!fnnews.fnal.gov!gw1.att.com!nntpa!not-for-mail
From: arw@mtatm.mt.att.com (Aaron Waters)
Subject: Re: Why is one OO language more productive than another?
Message-ID: <DEL955.7H4@nntpa.cb.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: mtatm.mt.att.com
Organization: AT&T
References: <808962188.12601@rugrat.demon.co.uk> <42dm1p$kks@goanna.cs.rmit.edu.au> <42fosn$i17@martha.utcc.utk.edu> <42joi1$aft@snlsu1>
Date: Fri, 8 Sep 1995 13:22:16 GMT
Lines: 41
Xref: glinda.oz.cs.cmu.edu comp.object:38075 comp.lang.eiffel:10766 comp.lang.c++:148009 comp.lang.smalltalk:28116

Patrick Frend <frend@ferndown.ate.slb.com> writes:
>mbk@caffeine.engr.utk.edu (Matthew Kennel) wrote:
>>
>>Yes: Smalltalk and CLOS are more productive than C++. 
>
>I don't doubt that you are more productive in generating code
>that more or less works. But are these languages more productive
>over the entire lifecycle of the system. (Maybe over 15 years!).
>...How can you 'prove' that you have caught the majority of type errors.

You can't. Just like in a strongly typed language you can't prove that
a correctly typed object has a valid value.  I agree that the static
typing is overrated, especially since it's so darn coarse (eg, just
because x is an int, doesn't mean it's prime, as it should be) and
since dynamic typing (eg, completely heterogeneous hash tables, or
lists of callbacks that generate an arbitrary something with a ".draw"
method) can be so darn useful.

>...How well do these languages integrate with other, more traditional
>type languages (i.e C C++ Pascal etc). Can't afford to throw all the
>existing code away. Would take another 15 years to re-write....

Some (eg, <a href="http://www.python.org">python</a>) integrate
very nicely, in fact portably across unices, ms-X, Mac...  Of course
integrating anything with C++ is harder than one would want...

>...How efficient is the software generated. Most software is not 'real-time'
>but much of it interacts with the user. Everything else being equal if
>'A' feels 'snappier' than 'B' that I'd go for 'A' every time. Too bad if
>you sell 'B'....

By using a more flexible language you can use techniques and
algorithms that would be too painful and expensive if implemented
exclusively in a more rigid language (like one that requires you to
explicitly manage dynamic memory, for example), and the end result may
be faster -- just like a recursive kwiksort in Lisp is faster than a
bubblesort in assembler.  Where there are bottlenecks you can
reimplement the slow part in a compiled extension module, still
leaving high level control to the interpreter.

		-Aaron Watters.
