I started thinking about the next computer language after C++. There are good things and bad things about C++. I wonder if it's possible to keep the good things and get rid of the bad things. Worth keeping is the expressive power of C++. Practically all the rest should be changed, syntax in particular. We can learn from the mistakes made in C++ as well as from the direction in which it is evolving.
This is just a record of my current thoughts.
1. Terseness is overrated if not harmful. Terseness is the legacy of C and has been slowly abandoned in the evolution of C++. Compare for instance the length of C keywords: int, char, long, etc., with the length of new C++ keywords: template, namespace, typename, etc. This is also true about the elision or complete absence of certain keywords--in KR C you could elide 'int', or the arguments to a function declaration. There is no 'define' keyword to distinguish definitions from forward declarations and usage. Note that the newer keyword 'template' distinguishes between definition/declaration and usage.
2. Symbol overloading is harmful. There are very few ASCII punctuation/sybmol characters and they are heavily overloaded in C++. Examples: *, &, >, etc.
3. Naming is limited to alphanumeric ASCII charaters. That is not even good enough for English speakers, not to mention others. A Boolean variable, for instance, would gain clarity if it could involve a question mark, and an exclamation could distinguish between verbs and nouns. Examples:
bool empty? ();
as opposed to
void empty! ();
or
int count () const { return _count; }
as opposed to
int count! (); // do the counting
4. Comments are limited to text. In many cases, including a picture would be much more useful. A full HTML comment would be even better.
5. Splitting code into files is not well integrated with the language. This is the legacy of UNIX. A more general database structure might be more appropriate.
6. C declaration syntax is counterintuitive. Pascal-like syntax, which is inverted C syntax, is easier to read.
7. Defining int to have compiler-dependent size leads to more trouble than it's worth.
Here are a few proposals addressing the above problems:
1. Use Unicode throughout. In particular, take advantage of the richness of symbols in Unicode. Symbols could still be input using a regular keyboard, but they would be immediately converted to Unicode. For instance the combination -> would turn into a single arrow. Similarly <-, turned into a left arrow could be used for assignments. Equality could then be expressed using a single = sign. Less-or-equal and greater-or-equal signs would also be single Unicode characters.
2. Introduce the 'define' keyword. Templates would be expressed as 'define' with arguments. Let's say:
define (X: type)
class A: public X {};
This way there would be no need for angle brackets and the related ambiguities.
3. Pascal-like declaration syntax
For instance:
define func (x: int4, y: complex8): complex8 {}
4. Sizes of integers and some other basic types would be specified in bytes. int4 is a 4-byte integer. float8 is an 8-byte float, complex8 is a complex number using float8.
This is just a record of my current thoughts.
1. Terseness is overrated if not harmful. Terseness is the legacy of C and has been slowly abandoned in the evolution of C++. Compare for instance the length of C keywords: int, char, long, etc., with the length of new C++ keywords: template, namespace, typename, etc. This is also true about the elision or complete absence of certain keywords--in KR C you could elide 'int', or the arguments to a function declaration. There is no 'define' keyword to distinguish definitions from forward declarations and usage. Note that the newer keyword 'template' distinguishes between definition/declaration and usage.
2. Symbol overloading is harmful. There are very few ASCII punctuation/sybmol characters and they are heavily overloaded in C++. Examples: *, &, >, etc.
3. Naming is limited to alphanumeric ASCII charaters. That is not even good enough for English speakers, not to mention others. A Boolean variable, for instance, would gain clarity if it could involve a question mark, and an exclamation could distinguish between verbs and nouns. Examples:
bool empty? ();
as opposed to
void empty! ();
or
int count () const { return _count; }
as opposed to
int count! (); // do the counting
4. Comments are limited to text. In many cases, including a picture would be much more useful. A full HTML comment would be even better.
5. Splitting code into files is not well integrated with the language. This is the legacy of UNIX. A more general database structure might be more appropriate.
6. C declaration syntax is counterintuitive. Pascal-like syntax, which is inverted C syntax, is easier to read.
7. Defining int to have compiler-dependent size leads to more trouble than it's worth.
Here are a few proposals addressing the above problems:
1. Use Unicode throughout. In particular, take advantage of the richness of symbols in Unicode. Symbols could still be input using a regular keyboard, but they would be immediately converted to Unicode. For instance the combination -> would turn into a single arrow. Similarly <-, turned into a left arrow could be used for assignments. Equality could then be expressed using a single = sign. Less-or-equal and greater-or-equal signs would also be single Unicode characters.
2. Introduce the 'define' keyword. Templates would be expressed as 'define' with arguments. Let's say:
define (X: type)
class A: public X {};
This way there would be no need for angle brackets and the related ambiguities.
3. Pascal-like declaration syntax
For instance:
define func (x: int4, y: complex8): complex8 {}
4. Sizes of integers and some other basic types would be specified in bytes. int4 is a 4-byte integer. float8 is an 8-byte float, complex8 is a complex number using float8.
4 comments | Leave a comment
