Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!vrdxhq!bms-at!stuart
From: stuart@bms-at.UUCP
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <393@bms-at.UUCP>
Date: Fri, 15-May-87 23:57:05 EDT
Article-I.D.: bms-at.393
Posted: Fri May 15 23:57:05 1987
Date-Received: Sat, 16-May-87 21:26:35 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP> <293@osupyr.UUCP> <18598@sun.uucp>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 32
Summary: Small is beautiful


The only way new features are going to make 'C' better is if they
are consequences of simplification.

E.g. The 'D' language where all operators are defined at  compile
time.  (A default definition file is included for compatibility.)
This  makes  the  compiler  smaller  (but  slower)  while  adding
overloaded operators and then some (like supporting your favorite
processor  features  not  in  'C').   One  reason  that   current
operators are fixed is to improve compiler performance (you don't
have to interpret the machine templates for  operators  at  every
compile).   With  the  next generation of CPU's, an approach like
this may be practical.  For now, let's not let creeping featurism
turn 'C' into an electronic beaurocracy.

Overloaded operators is better than adding just the complex type,
but  it still doesn't measure up to standards of elegance.  (Mine
anyway.)

We need new concepts, not new features.

NOTE, the best question to ask is not

        "What features can we add"

but,

        "What features are  absolutely  essential  and  what  can
        be  taken away?  Does a feature have a fundamental basis,
        or is it arbitrary and a candidate for user definition?"
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>