Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!yale!yale.edu!spool.mu.edu!howland.reston.ans.net!news.sprintlink.net!noc.netcom.net!netcom.com!brockman
From: brockman@netcom.com (daniel brockman)
Subject: Re: Why is one OO language more productive than another?
Message-ID: <brockmanDE7xGL.4or@netcom.com>
Organization: Life, Liberty, Love, Money and Art
References: <26fRWt$02m@zoe.pcix.com> <dqua.809168272@dqua> <26ftX4$02n@zoe.pcix.com>
Date: Fri, 1 Sep 1995 08:41:09 GMT
Lines: 56
Sender: brockman@netcom13.netcom.com
Xref: glinda.oz.cs.cmu.edu comp.object:37789 comp.lang.eiffel:10710 comp.lang.c++:147076 comp.lang.smalltalk:27890

In article <26ftX4$02n@zoe.pcix.com> traymond@pcix.com (Terry Raymond) writes:
>In <dqua.809168272@dqua>, dqua@earthlink.net (Derick J.R. Qua-Gonzalez) writes:
>>traymond@pcix.com writes:
>:
>::In <41d43j$1h20@tigger.cc.uic.edu:, dhanley@okeeffe (David Hanley) writes:
>:::traymond@pcix.com wrote:
>:::: Because there is a cost associated with trying to catch them.
>:    [type errors, that is]
>:::
>:::: It would be more difficult to do this if Smalltalk were type-checked
>:::: because frequently the type of a variable is not determined until
>:::: later via the refinement process.
>:::
>:: ... it means I know I have an object but I have not yet defined it.
>::I do know roughly what it is going to do, but that is it.  
>:
>:So what happens when you send a message to the object, one that it does
>:not understand?
>
>Testing is still required.  No program is correct just because it type checks.
>This question is frequently bought up by people with no experience
>with good Smalltalk development.  Simply put, it does not happen
>later in the development cycle.  I may not have been clear but
>the objects that I use this way are not simple object like integers,
>strings, arrays or other collections.  They are objects that I define.
>

(my 2 cents) The insufficiency of typechecking is generic and 
not limited to Smalltalk.

>::On this point I agree.  But, not all projects require large project
>::development methodology.
>:
>:The question becomes how do we train people to work on big projects if
>:they don't apply the methods to small projects that are more easily
>:controlled? (And with far smaller costs and risks). Do you just throw
>:them into a large project and hope that the theory---with little
>:practical experience---pans out? By being conscious and aware of the
>
>No, you need to have some people with large system development
>experience.  Believe me, I would not develop a large system the
>same way I develop small ones.
>

(2 more cents, or maybe 1 cent) In the american commercial model,
you spend no resource on training.  Instead, you lay off all the 
people from the older projects because they don't have the 
experience for the technologies of the new project, because
they worked hard on the old project and got no training.  Then
you hire people with experience.  Somehow, someway, somebody
else has paid for their training.  Then you push them hard till
their knowledge becomes obsolete and you lay them off...
-- 
-------------------------------------------------------------------------
Daniel Brockman San Francisco brockman@netcom.com 
-------------------------------------------------------------------------
