

If I could change the C language... - nkurz
http://phil.ipal.org/c/if-i-could-change-the-c-language.txt

======
drallison
It is an interesting list, worth reading, but in the end I did not find
anything compelling. Most of the wishlist of features are concerned with
syntactic sugar that would clutter up the language, not with anything that
makes the language a better way to express programs/algorithms. It would be
nice to see use cases and some arguments about why adding a feature will make
some significant change in the quality of programs coded in the augmented C
rather than standard ASCII C.

C has its share of design flaws, but it is relatively clean and elegant
language. Much of it's power and efficiency comes from its simplicity.

Programming language design easily gets lost in special case syntax and
enumeration of syntax for special cases rather than adding new composable
syntactic elements. Modifying or extending an existing language is very
difficult because it requires a deep understanding of the rules and concepts
used in the original language and its implementations. Some of the rule and
concepts are documented, but others are part of the folk knowledge shared by
implementors and users. As a case in point, consider the transition from C to
ASCII C.

The range of languages that a programming language designer would find helpful
to understand in detail is very large. My personal list of favorites includes
FORTRAN, COBOL, PL/I, C, C++, Python, Perl, Lua, Lisp, Scheme, Clojure,
Prolog, Erlang, Haskel, ML, BASIC, Algol, BCPL, Bliss, Smalltalk, SQL, Snobol,
BASH, and, of course, a handful of assemblers and macro-processors. It also
helps to have a good understanding of machine architectures and the theories
of machine independent (and dependent) optimization. Programming language
design for general purpose use is one of the most difficult of human
intellectual tasks.

Suggested reading: _Elements of Programming_ , by Alexander Stepanov and Paul
McJones, published by Addison-Wesley Professional in June, 2009.

------
wickedchicken
A lot of these are (as drallison mentioned) either syntactic sugar or 'missing
the point of C.' The author would like an exponent operator but this is
something complex enough to require a true library function. Almost every C
operator can be implemented in a handful of opcodes -- add, subtract, function
call and memory dereference. Why include such an expensive function as a core
operator instead of the library?

~~~
wlievens
And conversely, translating a library function into simple opcodes (rather
than a real call) should be any decent compiler's responsibility, using
intrinsics.

------
rbonvall

      > I would have an exponentiation operator.
      > That operator might be:  **
      > [...]
      > It might be possible to add this to existing C now
      > since the operator is not already used.
    
      a ** b == a * (*b)

~~~
prodigal_erik
As I recall, a C compiler is not required to realize that

    
    
      a -- b
    

would be valid if parsed as

    
    
      a - (- b)
    

so creating this operator would be equally feasible. Though I don't think
exponentiation is common enough to need one, especially in C where you
couldn't overload it for rationals or bignums.

~~~
mooism2
The point is that

    
    
        a**b
    

may occur in existing code, and mean

    
    
        a * (*b)
    

Introducing a double-star operator would break this code.

------
prodigal_erik
> I would have literal sizes be interpreted based on the first requirement of
> their usage, rather than having an implied default size.

That's a good idea, Ada and Haskell both do that.

------
boutcher
This is the same kind of thinking that lead to C++. Most of these changes
would add complexity (while at both ends of a loop????) for very little
benefit

------
zephjc
What, no primitive string type?

