If I could change the C language...(phil.ipal.org)

4 pointsby nkurzvor 16 Jahren9 comments

phil.ipal.org

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

6 comments

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.

wickedchickenvor 16 Jahren

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?

wlievensvor 16 Jahren

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

rbonvallvor 16 Jahren

  > 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_erikvor 16 Jahren

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.

mooism2vor 16 Jahren

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_erikvor 16 Jahren

> 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.

boutchervor 16 Jahren

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

zephjcvor 16 Jahren

What, no primitive string type?