🚀 go-pugleaf

In article <4kat8s$2i6k@news.gate.net>, solution@gate.net says...
[ ... ] 

> C and C++ are one of the worst syntacticly designed languages around.

C and C++ - I believe that's two not one... <G>  I tend to disagree as to the 
meaning of your statement as well.

> There is nothing to be done about it without severe redesign (a new
> language) The only one I can think of that is worse is PL/1 where amost
> anything you write has some meaning, just not necessarily what you expect.

I'd have to guess that you've never used TECO then.  Nor FORTRAN.  For 
instance, in parsing FORTAN, you have to deal with things like this:

	do 10 i=1,10
vs.
	do 10 i=1

The first is a do loop, the second a simple assignment of the value 1 to a 
variable named `do 10 i'.  There's no way to know for certain which you're 
looking at until you find whether there's a comma after the `=', so you have 
to either use a backtracking parser, or else several symbols of lookahead.  
Worse, this not only has to be done in the parser, but in the lexer as well, 
since it changes from having three tokens before the `=' to only one token.  
In short, it's about as bad of syntax design as you can find.  IMO, nothing in 
either C or C++ even comes close.

> Maybe, as they keep adding features to fix something, the language will
> break from all the syntatic twisting and someone will define a new
> replacement language with a decent syntax covering all the concepts. (Algol
> 00 ?)

Hmm...how does one define when a language is "broken" ?  C++ is certainly a 
good deal harder to parse than C or something really simple like LISP, but is 
still quite a bit easier than many others such as FORTRAN or PL/I.  You 
mentioned PL/I above, but may have failed to give a proper idea of how 
difficult it really is to compile; though I suspect this has changed more 
recently, at one time it was claimed that IBM's PL/I level F compiler 
consisted of over 100 passes...  (I don't know how much of this was due to 
language complexity and how much to simply allow the compiler to run in 
minimal memory though.)  I'm not particuarly certain there's a direct 
corollary between difficulty of implementation, and "brokeness", though it 
seems likely that if a language is difficult to implement that individual 
implementations are more likely to be broken.  (Note that here I'm separating 
between the language being broken and the implementation being broken.)
    Later,
    Jerry.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]