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

[Jon]

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

That can be done in C? (I forget, because I use a C++ compiler), but, I
think your point of syntax/semantics is fundamentally elevatable akin to
raising locks to a higher level (but I have no handy example).

 

[Jon]

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.

What about loop vars? Same thing?

for (int i = 0; i < 100; i++)
// blah with i

Isn't that effectively the same as "in the middle of a scope"?

 

[Jon]

If they have a sensible name and are declared where needed, they don't
need a descriptive comment.

I wonder about people (their ability to program anything) that comment
profusely.

 

[Jon]

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.

It's never too late to learn an assembly language.

 

[Jon]

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.

The C one-upper (C++) has that unwritten rule of thumb.

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.

Sounds like another language and not C, not sure.

 

[Jon]

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.

I think it may be regular at the expense of being clear, and I'm leaning
toward the conclusion that the regularity is a defficiency:

int a[100]; // ugly
int[100] a; // nice

I understand that the ugly syntax may be a compiler-writer's friend, but
at this juncture I am drawing a line at a different place than the C
language does.

(In the above though, who uses primitive arrays anyway?).

(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.

Definitely undone work but I don't think anyone has implemented a good
solution. Some languages have "modules", for example, but supposedly they
are less scalable than C header files/source files.

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).

Java = play in the sandbox I give you/move to the cloud where we can
control you/be in power.

 

[Jon]

use typedef (which should be called typealias)

#define Alias typedef

If the preprocessor is not your friend, then C will be your enemy. You're
welcome.

 

[Felix Palmen]

What about loop vars? Same thing?

for (int i = 0; i < 100; i++)
// blah with i

Isn't that effectively the same as "in the middle of a scope"?

No, a loop is its own scope where the block delimeters /can/ be omitted
for a single-statement body (but this is often discouraged in coding
conventions).

Regards, Felix

 

[Felix Palmen]

I think it may be regular at the expense of being clear, and I'm leaning
toward the conclusion that the regularity is a defficiency:

int a[100]; // ugly
int[100] a; // nice

This is exactly the same discussion as for pointer declarations. Either
the attributes like pointer or array are considered part of the type, or
the type only applies to the actual stored data, leaving pointer and
array as attributes of the individual variable. You can't really
proclaim one of those "ugly", as long as it's consistent in the
language. It comes down to a matter of taste and, of course, of what
you're used to.

Regards,
Felix

 

[Jon]

OK.

a loop is its own scope

Hello, duh.

where the block delimeters /can/ be
omitted for a single-statement body

Advanced topics in language implementation and compiler design then, yes?

(but this is often discouraged in
coding conventions).

"they" are wrong and *I* am right on this one (it's worth it):

if(you_suck)
{
do_unnecessary_parenthetic_eww_parents_suck();
}

if (i_rock)
kiss_me_kate();

/*----------

Nuff said?

------ (now about this ugly comnent syntax...)
*/

 

[Jon]

The assignment operator `=' will confuse any newcomer with a basic
knowledge of mathematics. You can only imagine how many bugs it has
caused in C and C++ when being inadvertently used as an equality
operator instead of `=='. In code comments it also makes the usage of
the mathematical `=' slightly ambiguous which forces people to use
`==' instead. UGLY is the word.

It's a shame that a left arrow is not in the (7 bit) ASCII table. IMHO
`:=' is second best to the left arrow.

The litmus test (C syntax):

a = sqrt(b^2 + c^2)

Anyone suggesting anything is more obvious (about the equal symbol) than
the above is a dufus. a "equals what I tell you it equals", *I* am the
programmer. The STATEMENT (not a ponderance), says, evaluate that
expression and put the result where *I* wanted. (What all you
mathematicians are up about, I will consider).

 

[Jon]

That statement leads to believe that you delved into a "sizeable C
project" without even knowing how to program in C, which clearlly is
not a problem related to the design of the C programming language.

Gee, I wish I had a retirement plan too.

 

[Jon]

quite right

That's not the point of course, but... ?

the subject of the thread is "If you could change the C or C++ or Java
syntax, what would you like different?". If you aren't interested in
the topic then don't post to it.

IOW, shut up or put up?

I've programmed in Algol-60, CORAL and Pascal and I noticed no
problem. Doesn't Ada do it this way as well?

For us "posterity", what was the "problem" you referred to?

 

[Tim Streater]

It's never too late to learn an assembly language.

Indeed. And in my case its 68000 asm which I'm using at the moment.

 

[RedGrittyBrick]

On Tue, 12 Oct 2010 19:19:55 +0100, Tom Anderson wrote:

On Mon, 11 Oct 2010, Vincenzo Mercuri wrote:

Seebs wrote:

[...] I consider something spaghetti only if it's long, round, and a
bit thicker than Angel Hair.

[*] Pasta-shaped pasta, of course.

It sounds like you are suggesting the C Standard Committee to add the
"spaghetti integer" data type. Beware the oven-flows!

It's ideal for use in layered architectures. Along with plenty of ragu
and bechamel sauce.

Shirley, penne pasta is better for that.

You guys are nuts!

It's obvious that lasagne pasta is for layered architectures.

FYI 'penne pasta' == 'lasagna laminae' - or so a pasta recipe site said.

Oh OK. I thought penne were the "pen shaped" short diagonally-cut tubes.

It all makes perfect sense now.

 

[BartC]

I think it may be regular at the expense of being clear, and I'm leaning
toward the conclusion that the regularity is a defficiency:

int a[100]; // ugly
int[100] a; // nice

This is exactly the same discussion as for pointer declarations. Either
the attributes like pointer or array are considered part of the type, or
the type only applies to the actual stored data, leaving pointer and
array as attributes of the individual variable. You can't really
proclaim one of those "ugly", as long as it's consistent in the
language. It comes down to a matter of taste and, of course, of what
you're used to.

In some contexts, a pointer/array attribute is part of the variable, eg. in
declarations (and the dereference appears on the left).

In other contexts, a pointer/array attribute is part of the type, eg. in
casts (and the dereference symbol appears on the right).

So it's also inconsistent.

 

[BartC]

That statement leads to believe that you delved into a "sizeable C
project" without even knowing how
to program in C,

I don't know how you deduced that from my statement.

I can program C if I have to; it's a simple enough language, if you look
beyond the syntax. (Something that can't be said for C++, even if it's
syntax were to look more like Basic.)

which clearlly is not a problem related to the design of the C programming
language.

I think it was (though not necessarily the fault of C, since the choice of
"=" over ":=" or whatever was reasonable enough in the 1960s).

 

[BartC]

On 13/10/2010 17:43, Martin Gregorie wrote:

Oh OK. I thought penne were the "pen shaped" short diagonally-cut tubes.

They are.

 

[Tom Anderson]

A bad thing.

Bullshit. Justify this or strangle yourself immediately.

tom

 

[August Karlstrom]

The litmus test (C syntax):

a = sqrt(b^2 + c^2)

Anyone suggesting anything is more obvious (about the equal symbol) than
the above is a dufus. a "equals what I tell you it equals", *I* am the
programmer. The STATEMENT (not a ponderance), says, evaluate that
expression and put the result where *I* wanted. (What all you
mathematicians are up about, I will consider).

If you apply your reasoning to a = a + 1 you will see the problem.


/August