Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C)

Arch Robison <robison@kai.com>
21 Feb 1996 12:23:07 -0500

          From comp.compilers

Related articles
Possible to write compiler to Java VM? (I volunteer to summarize) seibel@sirius.com (Peter Seibel) (1996-01-17)
Re: Aliasing in ISO C rfg@monkeys.com (1996-02-16)
Re: Aliasing in ISO C jplevyak@violet-femmes.cs.uiuc.edu (1996-02-16)
Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) rfg@monkeys.com (1996-02-19)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) jgm@CS.Cornell.EDU (1996-02-19)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) Martin.Jourdan@inria.fr (1996-02-21)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) robison@kai.com (Arch Robison) (1996-02-21)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) hbaker@netcom.com (1996-02-22)
Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-02-22)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) gasser@ilw.agrl.ethz.ch (Laurent GASSER) (1996-02-23)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) fabre@gr.osf.org (Christian Fabre) (1996-02-23)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) WStreett@shell.monmouth.com (1996-02-23)
Re: Languages: The Bigger the Uglier (was: Re: Aliasing in ISO C) hbaker@netcom.com (1996-02-23)
[15 later articles]
| List of all articles for this month |

From: Arch Robison <robison@kai.com>
Newsgroups: comp.compilers
Date: 21 Feb 1996 12:23:07 -0500
Organization: Kuck & Associates, Inc.
References: 96-01-037 96-02-171 96-02-187
Keywords: design, standards, comment

>How thick will the COBOL standard of the year 2015 be? Five thousand
>pages? Ten thousand? More?


Formal specifications will not solve the problem. The root problem is
design by a group, and *use* by group. A committee can collectively
design and comprehend something that no single person can understand.
Even a formal specification. The users of a bloated language can each
write in their own subset. If the compiler writers forget a feature,
the users of that feature complain. Thus a language becomes the union
of anything anyone can remember.


Here's a solution:


        1. Every year, put N language judges in a separate room. The
judges would be good programmers, but not language lawyers. I
leave this distinction to the reader.


        2. Give each judge T hours to write down their description of the
language.


        3. Remove any feature from the language that K or more judges
forgot to describe.


If K=1, this is the extreme of making the language the intersection of
what people remember.


To add the comp.compilers angle, has anyone seen a language
implementation that would allow people to buy and use features a la
carte? Many other products seem to be developing "plug-ins". Why not
compilers? If people actually knew how much they were paying for each
feature (in $$, compilation time, code bloat, and bugs), they might be
more reluctant to ask for everything.


Arch D. Robison Kuck & Associates Inc.
robison@kai.com 1906 Fox Drive
217-356-2288 Champaign IL 61820
[There may be Cobol compilers that price some of the modules, e.g. the Report
Writer, separately. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.