If you could change the C or C++ or Java syntax, what would you like different?

[Alexander]

Please share your oppinion on anything you do not like in the C or C++
or Java syntax (they're quite similar).

In order to maintain the integrity of the discussion (have everything
at the same place) please respond on comp.lang.c.

Cheers,
Alexander

 

[Stuart Golodetz]

Please share your oppinion on anything you do not like in the C or C++
or Java syntax (they're quite similar).

In order to maintain the integrity of the discussion (have everything
at the same place) please respond on comp.lang.c.

Cheers,
Alexander

....and thus began a long, pointless and heated debate

Doesn't sound like a good plan to me:

1) It will annoy the regulars in comp.lang.c with lots of off-topic
stuff about C++ and Java.
2) It won't be actionable -- if you were serious about changing the
syntax, you'd need to get on the standards committees and spend about a
decade of effort working on the details.
3) The syntax of each of the languages is different (despite a certain
amount they have in common) -- it's very hard to have a productive
discussion about three different languages at once.

If I were a betting man, I'd say you were a troll.

Regards,
Stu

 

[Dann Corbit]

Please share your oppinion on anything you do not like in the C or C++
or Java syntax (they're quite similar).

In order to maintain the integrity of the discussion (have everything
at the same place) please respond on comp.lang.c.

If I wanted to change the features of the language, I would post to
where the design of the language is discussed.

If I were to add any feature to C, it would be a totally safe string
type, that carries its length.

But that is neither here nor there.

 

[red floyd]

...and thus began a long, pointless and heated debate

Doesn't sound like a good plan to me:

1) It will annoy the regulars in comp.lang.c with lots of off-topic
stuff about C++ and Java.
2) It won't be actionable -- if you were serious about changing the
syntax, you'd need to get on the standards committees and spend about a
decade of effort working on the details.
3) The syntax of each of the languages is different (despite a certain
amount they have in common) -- it's very hard to have a productive
discussion about three different languages at once.

If I were a betting man, I'd say you were a troll.

Or else some guy posting his homework question.

 

[Lew]

I don't like the way people start flame wars about something that doesn't
amount to a hill of beans in this world.

*What* integrity?

Or else some guy posting his homework question.

I wouldn't bet against Stuart. The question doesn't really smell like
homework, but it reeks of troll doo-doo.

 

[Joshua Cranmer]

Please share your oppinion on anything you do not like in the C or C++
or Java syntax (they're quite similar).

Let me try int &c in C, List<List<Foo>> in C++, or int *x; in Java. Oh wait.

There is a not-insignificant amount of difference between C, C++, and
Java. The primary things that are really the same between the languages
is the use of curly braces for scope definition, semicolon-terminated
statements, the use of `\' as an escape character, and the function
calling syntax of func(args). The latter two are common even in those
languages which are not curly-braced delimited (e.g., python), and
aren't really anything that people would complain about.

That pretty much leaves the curly-brace-delimited and
semicolon-delimited natures as the only truly common parts of syntax
which are arguable, and probably anyone who would be inhabiting these
newsgroups are not going to be arguing against those.

I would like to note that many of my... issues with C++ and Java
syntaxes are of those constructs which are (more or less) unique to
those languages [1], so "they're quite similar" isn't good enough.

In order to maintain the integrity of the discussion (have everything
at the same place) please respond on comp.lang.c.

That sounds nice until you realize that many people on the other
newsgroups don't follow comp.lang.c, such as yours truly.

[1] Java generics and C++ templates are sufficiently different that I am
going to call them unique constructs.

 

[Keith H Duggar]

red floyd wrote:


I wouldn't bet against Stuart.  The question doesn't really smell like
homework, but it reeks of troll doo-doo.

I'd bet on a guy with "I'm gonna design a better
language and write a compiler" day dreams.

KHD

 

[James Dow Allen]

... anything you do not like in the C ... syntax.

I'll offer 2 cents worth:

(1) I happen to *love* C syntax. You might prefer
Pascal syntax but, at the risk of sounding rude,
why don't you just then go code in Pascal?

(2) Some will mention the second-class nature of arrays
as being bad. Some will mention the expression decay
(foo[0] becomes *foo) as being confusing. *I think these
facts result from a unique and wonderful elegance in
the C language*.

(3) That ==, etc. have precedence over & or | is annoying, but
easy to remember once you get used to it. (Ritchie explains
this is vestige of an early dialect which didn't distinguish
& and &&.)

(4) Declarations like char* a, b, c;
are confusing: a is a pointer but b and c are not.
(It's little problem for most of us, who write instead
char *a, b, c;
)

Problem (4) seems like a problem that might afflict any
linear language which, unlike Lisp, is not fully
parenthesized.

Uh oh. Someone's going to have the wonderful idea of
2-D languages where editing is done with a click-based
interface to open/close syntax nodes and get a "friendly"
2D-like effect. Fortunately I won't be around to see it.

James Dow Allen

 

[BGB / cr88192]

... anything you do not like in the C ... syntax.

<--
I'll offer 2 cents worth:

(1) I happen to *love* C syntax. You might prefer
Pascal syntax but, at the risk of sounding rude,
why don't you just then go code in Pascal?

(2) Some will mention the second-class nature of arrays
as being bad. Some will mention the expression decay
(foo[0] becomes *foo) as being confusing. *I think these
facts result from a unique and wonderful elegance in
the C language*.

(3) That ==, etc. have precedence over & or | is annoying, but
easy to remember once you get used to it. (Ritchie explains
this is vestige of an early dialect which didn't distinguish
& and &&.)

(4) Declarations like char* a, b, c;
are confusing: a is a pointer but b and c are not.
(It's little problem for most of us, who write instead
char *a, b, c;
)

Problem (4) seems like a problem that might afflict any
linear language which, unlike Lisp, is not fully
parenthesized.

Uh oh. Someone's going to have the wonderful idea of
2-D languages where editing is done with a click-based
interface to open/close syntax nodes and get a "friendly"
2D-like effect. Fortunately I won't be around to see it.
-->

the only notable syntax alteration I would likely want to make would be be
to make the syntax non-ambiguous in the face of missing prior type
declarations (say by using a more Java or C#-like declaration syntax, as in
effectively requiring a single 'type name' which effectively terminates the
type part of a declaration, and with no modifiers which may follow it). this
is not likely to much effect the general look of the language much, or
likely even impact all that much code (except obscure cases). however,
as-is, absent typedefs the syntax is ambiguous and there is no real good
solution within the confines of the standard (it would necessarily break
standard conformance and cause some subset of otherwise conforming code to
break).

another would be to not require that, semantically, headers always behave as
if they were lexically included (although this is less certain as there are
many nifty things one can do with #if and #ifdef, and headers in general,
which could be impacted...). (as is, there are only a few scenarios in which
precompiled headers may be safely used).

possibly, less ugly function pointers (especially when returning function
pointers), but it is unclear what would be a solidly better syntax (many of
my ideas could add ambiguities, or require backtracking, which is not good).

so, alas, there is no solid way to "improve" the syntax in a general sense,
as most possible changes would also come with many costs...

or such...

 

[Ian Collins]

(4) Declarations like char* a, b, c;
are confusing: a is a pointer but b and c are not.
(It's little problem for most of us, who write instead
char *a, b, c;
)

No problem at all for those of us who declare our variables at the point
of initialisation.

 

[Tim Streater]

(4) Declarations like char* a, b, c;
are confusing: a is a pointer but b and c are not.
(It's little problem for most of us, who write instead
char *a, b, c;
)

Doesn't stop it being rubbish syntax. Along with the crap preprocessor
it was one of the irritations I endured when first writing in C. It
makes no sense that when I think I'm declaring a char, it turns out that
some of the things I'm declaring are not, in fact, chars, but rather
pointers to char (or, possibly, far worse).

Too late to change now, though.

 

[Ben Bacarisse]

No problem at all for those of us who declare our variables at the
point of initialisation.

Eh? How does char* a = 0, b = 0, c = 0; make the syntax any less
error-prone? Did you mean "for those of us who declare our variables
one per declaration"?

For the record, I *like* C's declaration syntax and, left to my own
devices, I'd be very happy to declare

char buf[SIZE], *start = buf, c = *buf;

Part of the reason I like it is that it is compact. The more of the
semantically important code I can take in at once, the happier I am.

I don't recall any hard bugs being due to a mistaken declaration. I'd
imaging that most get found at the first compile. I agree that the
layout is important. I can't abide either char* a; or char * a;.

 

[Ian Collins]

Eh? How does char* a = 0, b = 0, c = 0; make the syntax any less
error-prone? Did you mean "for those of us who declare our variables
one per declaration"?

Maybe "at the point of first use (which happens to be the point of
initialisation)" would have been clearer?

 

[Ian Collins]

Did you mean "for those of us who declare our variables
one per declaration"?

That too!

 

[BartC]

Eh? How does char* a = 0, b = 0, c = 0; make the syntax any less
error-prone? Did you mean "for those of us who declare our variables
one per declaration"?

Perhaps he means at the point of first use. Although this doesn't help much
here:

fn(&a);

where fn is expected to initialise a which has not yet been declared.

For the record, I *like* C's declaration syntax and, left to my own
devices, I'd be very happy to declare

char buf[SIZE], *start = buf, c = *buf;

This is actually confusing; I wasn't sure what sort of pointer c was
supposed to be at first, as I read it as c = &buf..

Part of the reason I like it is that it is compact.

Not needing to declare variables is even more compact...

If you mean you can declare arrays, pointers and single characters all in
the same statement, then I suppose it might be. But not everyone would agree
it's a good thing.

 

[Rui Maciel]

If I were to add any feature to C, it would be a totally safe string
type, that carries its length.

You can always write a library that wraps all string-handling functions from the standard library so
that it can use a customized string data type (i.e., struct c_string {}. No matter how you cut
it, the solution to that issue (which isn't necessarily a problem) will always assume that form.


Rui Maciel

 

[BartC]

I'll offer 2 cents worth:

(1) I happen to *love* C syntax. You might prefer
Pascal syntax but, at the risk of sounding rude,
why don't you just then go code in Pascal?

The languages don't do the same thing. Some people want to have the same
coding freedom C provides, but with a different, perhaps more formal,
syntax.

I'm not a C programmer. But from attempting to compile other people's open
source projects, it seems to me that a C programmer needs to know 4
languages:

(A) The C syntax itself

(B) The preprocessor language, which at first looks ultra-simple, just a few
#-directives, until you start using macros. This can lead to code which is
no longer C, and horrendous to decipher if you are not the author.

(C) Type declaration syntax. I'm surprised no-one has mentioned this
elephant in the room. I find it utterly impossible once I go beyond the
basics. I always need to try random combinations with CDECL until I get what
I want, then safely lock the result away until I might need it again.

(D) Make-file syntax. If you're trying to build an application, and no other
instructions exist to assemble the project, then you're at the mercy of this
syntax. Especially if the make-syntax is not compatible with your compiler,
or you need to make changes.

Taken all together, the whole thing can look a mess to anyone who doesn't
deal with this every day and who thinks nothing of it.

These comments apply to C. For C++, you can probably add (E) and (F). In
other words, a nightmare.

Java I don't know anything about; I understand it's big (having once spent
ages downloading a 28MB version (as 20 chunks at 9.6Kbaud), then finding I
needed another 20MB to download the docs before I could do anything).

 

[Felix Palmen]

Maybe "at the point of first use (which happens to be the point of
initialisation)" would have been clearer?

Which would be -- in the general case of first using them somewhere in
the middle of a scope block -- illegal in C89.

In fact, I like this C89 restriction. The beginning of a scope block is
also a good place to document the variables that are needed inside with
an appropriate comment. I even employ this in languages that would allow
declarations anywhere, like C#.

Regards,
Felix

 

[Felix Palmen]

Doesn't stop it being rubbish syntax. Along with the crap preprocessor
it was one of the irritations I endured when first writing in C. It
makes no sense that when I think I'm declaring a char, it turns out that
some of the things I'm declaring are not, in fact, chars, but rather
pointers to char (or, possibly, far worse).

Well, I have to admit it surprised me, too, because I first looked at C
after programming some object pascal, so I was used to the concept that
the attribute "pointer" applies to the type. But I think the C point of
view, that the notion of a type only relates to the stored data and the
attribute "pointer" instead applies to the individual variable, is
equally valid.

Regards,
Felix

 

[Ben Bacarisse]

Maybe "at the point of first use (which happens to be the point of
initialisation)" would have been clearer?

I'm not sure. If the following line is

while (a != c) ...

then the "point of first use" is the declaration I wrote. Similarly, if
you need:

char buf[SIZE], *start = buf, c = *start;

I can't think of a form that is closer to declaring them at "the point
of first use" than this! I accept that some people don't like this
form, but I don't think it's related to initialising things just prior
to use.