|[32 earlier articles]|
|Re: language design tradeoffs email@example.com (1992-09-22)|
|Re: language design tradeoffs firstname.lastname@example.org (1992-09-23)|
|Re: language design tradeoffs email@example.com (1992-09-23)|
|Re: language design tradeoffs firstname.lastname@example.org.OZ.AU (1992-09-24)|
|Re: language design tradeoffs email@example.com (1992-09-24)|
|Re: language design tradeoffs firstname.lastname@example.org (1992-09-24)|
|Re: language design tradeoffs chased@rbbb.Eng.Sun.COM (1992-09-25)|
|Re: language design tradeoffs email@example.com (1992-09-26)|
|Re: language design tradeoffs firstname.lastname@example.org (1992-09-26)|
|From:||chased@rbbb.Eng.Sun.COM (David Chase)|
|Organization:||Sun Microsystems, Mt. View, Ca.|
|Date:||Fri, 25 Sep 1992 19:40:48 GMT|
|Keywords:||design, parse, storage|
email@example.com (Alvin Starr) writes:
>I just throw this out as a general question/statement.
> We found that when we were forced to stop developing software
> in Euclid/Turing and moved to C our productivity dropped
>Is there a study that correlates languages to types and frequency of
>errors? If not I am sure that it would make for an interesting study.
Rovner estimates (in Xerox PARC CSL-84-7, "On Adding Garbage Collection
and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent
Language", page 16, taped to my door) that programmer time spent on memory
allocation problems fell from 40% in Mesa to 5% in Cedar (the remainder
spent mostly dealing with management of large areas of VM).
My experience with C++ has been not altogether wonderful (*), and I often
find myself wishing for the benevolent heavy hand of Modula-3 (garbage
collection, checked casts, checked array indices). Friends who had much
experience in Modula-2+ or Cedar (similar benevolent features) weren't
very happy about programming in C. At least one chose a job based on "I
want to work someplace where I'll use a programming environment at least
as good as the one I had 10 years ago (at Xerox)."
(*) at least part of the problem seems to be social. Lacking a
dictatorial language, dictatorial coding styles are required to ensure
that various members of a project can read each others' code and
understand each others' conventions. We don't have a dictator, which
means that additional time is spent trying to figure out the other guy's
Return to the
Search the comp.compilers archives again.