Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!uw-june!jmaloney
From: jmaloney@june.cs.washington.edu (John Maloney)
Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk and C: A Case Study
Message-ID: <5827@june.cs.washington.edu>
Date: 26 Sep 88 06:29:50 GMT
References: <5797@june.cs.washington.edu> <10424@reed.UUCP>
Organization: U of Washington, Computer Science, Seattle
Lines: 32

>my conclusions have been very similar to yours.  However note that point 1
>really isn't too terribly indicative:  I've found that the second time I
>write anything in any reasonable language it's likely to take me 1/4th or
>less of the time...

You are absolutely right, Bart, the second time a given person writes
the same program the coding usually goes faster. Of course,
there are also other problems with this "experiment,"
such as the difference between a Mac+ with a 68000, a tiny screen, 1 mbyte,
and a slow disk and a Tek 4405/06 with a large screen, 68020, fast disk,
and loads of memory. It would be great if someone collected some data
on program development time for the two language
under more controlled conditions with larger
sample sizes. I suspect there would be a lot of variance in the numbers.

I also believe that different programming languages work better for
different people. I think the object-oriented approach works well for
me in a C environment or in Smalltalk. I also think the Smalltalk enviroment
supports my working style nicely and I hope that C++ develops a similar
environment. My wishlist includes run-time binding, type declarations
optional or inferred, a code "browser" with intelligent search functions
(e.g. "senders" and "implementors"), garbage collection, incremental
compilation, the compiler available in the environment, object level
debugger and inspector, large library of classes, inheritance, and
possibly a change management system. I would also like things that
Smalltalk is lacking such as better packaging of systems to avoid
potential name conflicts and for tracking dependencies on system
facilities, optional static type inference and checking when possible,
and the ability to produce an optimized, object-code only packaging of
a final product.

		-- John Maloney (jmaloney@june.cs.washington)