From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fe82bd3a72926e1a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-16 22:36:32 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: Richard Riehle Newsgroups: comp.lang.ada Subject: Re: "Size" of Ada vs. C++ Date: Tue, 16 Oct 2001 22:39:55 -0700 Organization: AdaWorks Software Engineering Message-ID: <3BCD19AB.4C9F3707@adaworks.com> References: <9q223u$lap2j$1@ID-77397.news.dfncis.de> <87ofn8a9dv.fsf@deneb.enyo.de> <87y9mcoz6s.fsf@deneb.enyo.de> Reply-To: richard@adaworks.com NNTP-Posting-Host: 9e.fc.cc.9c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 17 Oct 2001 05:37:31 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:14776 Date: 2001-10-17T05:37:31+00:00 List-Id: Florian Weimer wrote: > Anyway, I think it's rather strange to judge a language by the "size" > of its definition. Absolutely correct. I have seen people compare languages based on the number of reserved words (less is better), the size of a "hello world" program's executable (less is better), the number of predefined libraries (more is better), the number of people who use it for programming (more is better), the number of ads in the help wanted section (more is better), and on and on and on. There is no end to the silliness that people use to compare programming languages. The Modula-3 exercise that attempts to define a language in some number of pages of the reference manual also approaches absurdity. A programming language needs to be judged on its expressiveness first. One factor in this judgement is, how well it expresses the software problems it is intended to solve. We could reframe this as, how well does the solution space (represented by the language and its corresponding tools) map to the problem space? Another factor derives from Donald Knuth's notion of "Literate Programming." This notion suggests the question, how well does the language support the human process of developing software? There are other factors, but this margin is too small to enumerated them all. In evaluating a programming language, we need to define qualitative criteria as well as quantitative criteria. Sadly, most of quantitative criteria are flawed due to the immature reasoning that leads to their selection. Sadder still, such reasoning is likely to prevail for a very long time, given the current state of software engineering practice. Sorry for my pessimism. Richard Riehle