I'm not a huge fan after a quick read - the new syntax adds too many new keywords for my tastes e.g. type, inherits, abstract, lang, obj, func etc. I'm of the school of thought that words with semantic meaning should be used as much as possible for expressing the logic and meaning of the program itself, rather than the language. Otherwise, it becomes harder to separate the actual program from the language - this is one of Java's problems.

Particularly take the class declarations as an example:

  type ListClass : class inherits public ListBase, private virtual ListImpl
  { /* member declarations */ }

adds nothing but verbosity to the C++ declaration:

  class ListClass : public ListBase, private virtual ListImpl
  { /* member declarations */ };

"Make everything as simple as possible, but not simpler" seems a good rule to design languages by. The common case should be expressible with as little syntactic friction as possible, without making the language ambiguous or unreadable.

": class inherits public" is just 23 characters of pointless line noise.

Perhaps inheritance shouldn't be the common case in the first place?

A couple of notes:

1. This paper is from 1996 (oh my! 14 years), and so does not consider the syntactic clean-up performed with C++0X.

2. The paper is co-authored by Damian Conway (http://en.wikipedia.org/wiki/Damian_Conway), perl legend, author of Quantum::Superpositions (http://search.cpan.org/~dconway/Quantum-Superpositions-1.03/...)

3. This seems to be part of research conducted on 'Human Factors in Programming Languages', which includes another paper on the design of SPECS (the syntactic clean-up mentioned in this paper), and another interesting-sounding one: 'Seven Deadly Sins of Introductory Programming Language Design' (see http://www.csse.monash.edu.au/~damian/papers/).

Changing the declaration syntax could be a big improvement, but changing assignment operators is a bad idea. (summary: a=b now tests for equality, a:=b is assignment). I know if I start using a language where a=b means equality test, I'm going to make that mistake in Javascript, Python, and every other language I use.

When designing a new language, remember that people spend most of the time using other languages. So don't be gratuitously incompatible in dangerous ways.

Yeah, := should be assigns, and == should be equal, and = should be an error.

Somebody needs to take a stand at some point. The C-style equality and assignment operator conventions are awful things.

That does happen to me. F# uses = for equality and <- for assignment, and I end up doing the same in C#. Fortunately in C#, only boolean expressions can be used in predicates so it hasn't caused me any more than a compilation error yet.

The most honerous case of that that I've run into is in the ChucK programming language (for audio synthesis, MIDI processing, etc.). In general it's quite nice, but the assignment operator is "=>" and the assignee goes on the right, e.g.:

  140 => int beatsPerMinute;

http://github.com/scotchi/Chuckery/blob/master/MidiDelay.ck

It's really close to all of the other Java-ish family of languages for the most part, but I find myself having to fix a dozen auto-piloted assign errors every time I try to run the code.

Go claimed := as the initialization operator, leaving = and == as before. Since you should avoid assignment after initialization when possible, anyway, I suspect = could be avoided altogether in a lot of code.

Unfortunately, most of the pathology of C++ lies in its semantics, not its syntax.

Yes. But it's better than nothing.

C++ could use both syntaxes, old and new, just as programmers can use any syntax coloring scheme when viewing a program in an IDE. Anything sitting above a language's AST is customizable by programmers. It's just for historical reasons why programs in different languages are stored as consecutive text in files, instead of, say, tree structures on disk.

I'm surprised and disappointed that this still requires a semicolon after each line, and parentheses around the conditions in for, if, etc. statements.

Yes, going closer to Python-style in this regard would have been nice.

(not the author)

Inside C++, there is a much smaller and cleaner language struggling to get out. - Bjarne Stroustrup

Clay is an attempt at creating that language.

Link: http://tachyon.in/clay/

This looks fairly interesting, at first glance. Is there a similar document for C by itself?

Looks sane to me.

seriously?