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)