Re: The Decline of C/C++, the rise of X

From: Eric (anon21h_at_yahoo.co.uk)
Date: 07/24/04 

Date: 23 Jul 2004 23:27:05 -0700

jimmaureenrogers@worldnet.att.net (Jim Rogers) wrote in message news:<82347202.0407230911.1dea1ae9@posting.google.com>...
> anon21h@yahoo.co.uk (Eric) wrote in message news:<5ed9ec27.0407222126.51581373@posting.google.com>...
>
> > I think underlying your simple example is a common difficulty people
> > encounter with C++ as they work with it in the early days - getting it
> > (the syntax) to work within a few tries is rather difficult.
> >
> > I'm beginning to think that when people complain about the C/C++
> > syntax, it's not so much the curly braces and semicolon that are the
> > problem (the rules for those are simple enough), rather, it's that
> > depressing feeling you get when the compiler beats you to a pulp with
> > 50+ error messages, everytime you encounter one of the many
> > syntactical pitfalls. X will really need careful definition of the
> > syntax rules, so people can quickly get comfy and stop relying on the
> > language manual sooner.
>
> I am not quite clear on your point.
> Are you simply saying that X will need a clear syntax, or are you
> saying that X compilers should not complain about syntax errors?

Sorry for the lack of clarity. I meant that X will need a clear syntax
such that the probability of syntax errors is reduced. X's compiler
must always complain about syntax violations (I would shudder if it
didn't!). It should however, be geared to detect the kind of errors
that a C/C++ programmer may make and suggest corrections based on how
X differs (e.g "The '+=' operator is not supported. Please use the
'Incr' statement instead.")

The term "clear syntax" here should also mean "clear to the compiler",
so that error recovery after a syntax error is much improved (this
sort of rules out the use of "{}" as block delimeters in X's syntax).
This allows the compiler to give a few relevant messages upon a syntax
error, instead of the numerous ones you sometimes get when you slip up
in C/C++.
 
> I agree that a quickly understandable syntax is, in general, a good
> goal. I also believe that a compiler should complain about syntax
> violations.

Yes, that is what I meant to say earlier.

> This does lead to another question, however.
> If X syntax must be clearer than C or C++, then it must be different
> than C and C++ in some manner. How much difference is good? When is
> a difference unacceptable?

That, my friend, is the million dollar question :-). I guess the C/C++
folks on here would be able to answer how much change they can
tolerate before they decide to get into lynching mode.

One thing that should be thought about when designing X's syntax is
the argument of brevity that is often given in favour of the C/C++.
The syntax often *looks* brief but *is* it brief? and if so, how much
more? Consider this bare bones If-statement:

    if then
    end if

On my QWERTY UK keyboard, that takes 14 keystrokes (minus the tabbing
needed for indentation, but including the carriage-return). The
equivalent in C/C++:

    if(){
    }

takes 11 keystrokes (again minus the tabbing needed for indentation,
but including the carriage-return). How? It's because the "()" and
"{}" require the use of the Shift key. So the programmer saves 3
keystrokes but pays for that saving in greater chance for error (e.g
by forgetting a curly/rounded bracket), poorer and spurious error
messages from the compiler (because error recovery is harder for the
compiler to do), and decreased typing speed (try it, see which version
you can type the fastest).

Other examples where the C/C++ syntax needs more effort:

**scope resolution operator

  "::" takes 4 keys, whereas "." takes 1.

**member access on a pointer

  "->" takes 3 keys, whereas "." takes 1.

**the equality operator

  "==" takes 2 keys, whereas "=" takes 1.

**statement termination

  ";" followed by CR takes 2 keys, whereas just CR takes 1.

**dereferencing a pointer

  "*" takes 2 keys, whereas using references takes 0.

**importing a module

  "#include "foo.h"" takes 18 keys whereas
  "imports foo", takes 11.

**switch statement

  a barebones "case" clause takes an extra 8 keys, 2 for the
  mandatory ":" and 6 for the "break;".

**logical operators

  "||" takes 4 keys whereas "or" takes 2, "&&" takes
  4 keys whereas "and" takes 3.

**infinite looping

  "while(1){}" and "for(;;){}" take 14 and 13 keys
  respectively, whereas "do...loop" takes 7 keys.

**iterating through an entire collection

  "for(int n = 0; n <= MAX; n++){}" takes a lot more
  keys than a "for..each" statement. Sure C++ has the
  STL "for_each", but that's even more verbose since
  you need to setup those iterators.

**by-reference argument passing

  "foo(&bar);" costs an extra 2 keys compared to "foo(bar)".

The RSI is kicking in now, so I think the above list will do! As can
be seen from the above examples, C/C++ tends to require a lot more
typing effort in the most common coding activities. It does get away
with this though because it *looks* brief. It seems X will have to
make use of this trick of perception to win over the C/C++ programmer.

> Jim Rogers

Cheers,
Eric Mutta :-)

Relevant Pages

  • Re: Any plans to remove obsolescent features?
    ... I remember it being fairly common. ... declare a fuction in C. ... violation if it implements it, but a compiler ... others could report syntax errors (due to not having bothered to implement ...
    (comp.std.c)
  • Re: Tcl Switch case
    ... My thesis is that there could be a good reason to change the syntax of ... a command, and one reason is to align with what the byte compiler ... bug has persisted for 15 years, but has never kept anyone from writing ...
    (comp.lang.tcl)
  • Re: Handling error/status messages by interface to C++ programs
    ... about how to design a compiler, please tell me where I can find ... exceptions for managing the error detection is rather a bad idea. ... I have to say I have seen a simple example of an object-oriented parser design in some book (unfortunately I forgot ... It would trigger user notification and do recover housekeeping like reseting the current syntax row's token stack because one wants to continue parsing and detect any other errors w/o aborting. ...
    (comp.object)
  • Re: Syntax (was: Perfrom Thru
    ... "This statement has violated the limits of this compiler" ... these are syntax violations in the Standard's definition of them. ... > whether the problem is a compiler limitation or it is a syntax error, ... >> Then not "source violates the SYNTAX rules of the Standard" ...
    (comp.lang.cobol)
  • Re: Source to Source compilation - targeting C?
    ... high level language (syntax and semantics) to target C as the output? ... Does the ROSE compiler framework do this? ... you don't really need "code generation knowledge" to target C, ... and mostly "unwinding" this into C style syntax and semantics ...
    (comp.compilers)