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

[Ben Bacarisse]

Explain please "second class nature of arrays".

The term has a standard meaning in this sort of context:
http://en.wikipedia.org/wiki/First-class_object

<snip>

 

[Ben Bacarisse]

August Karlstrom wrote:

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

Given the "dufus" remark, it's possible that you are not bothered about
having a debate, but assignment it very different from "making this
equal that". If the type of 'a' is int, for example, a = E; may leave
a != E in many cases.

This is, in part, an argument that quality and assignment should use
different symbols (and C complies with this) but because assignment is
asymmetric, it's a shame that the symbol isn't similarly asymmetric.
Both := and an arrow have that in their favour. It's also an argument
that assignment should not be so similar to equality that people forget
the difference, but this is almost a psychological point rather than a
programming one.

A couple of minor points: what you wrote is an expression not a
statement. It would be a statement if it had a trailing semi-colon.
Secondly, I presume that the xor b^2 is written in jest, yes? [For
anyone new to C reading this, C does not have an exponentiation
operator.]

 

[Felix Palmen]

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

Alright, I really forgot about casts. I tend to write tham like this:

T *foo = (T *)bar;

But of course, this is just some cosmetic. If one would remove these
attributes from the type in casting, the possibility to cast between
pointers and values would disappear. Is it really needed?

Regards,
Felix

 

[Keith Thompson]

#define Alias typedef

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

If I'm reading code that uses typedef, I have to understand how typedef
works.

If I'm reading code that uses your "Alias" macro, I still have to
understand how typedef works -- *and* that "Alias" means typedef.

It doesn't help.

 

[Tom Anderson]

Yes. A similar argument explains manicotti.

I have no opinions or knowledge to share on this, but i am genuinely
really hungry now.

tom

 

[Default User]

Yes. A similar argument explains manicotti.

The one that amuses me is "ziti". http://recipes.wikia.com/wiki/Ziti

It comes from a word meaning "bridegroom". One pasta book I had claimed not
to know why that was. I couldn't tell if the author was truly ignorant, or
couldn't, as they say, find a suitably delicate way of expressing the
relationship. A web search informs me that the original ziti were much
larger.




Brian

 

[Rui Maciel]

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

This is not up to debate: if you fail to understand how to assign values to variables in a
programming language then you simply don't know how to use it. You simply can't hack away Pascal
code in a text file with a .c extension and not only expect it to be C but also complain that the
compiler throws syntax errors.


Rui Maciel

 

[Rui Maciel]

That solution has been tried many times and has been found to be
inadequate as many times as it has been tried. It can't be fixed at the
library level because it's a language level problem.

Nonsense.


Rui Maciel

 

[BartC]

This is not up to debate: if you fail to understand how to assign values
to variables in a
programming language then you simply don't know how to use it.

Yes, when I sometimes fumble for the gear stick in a left-hand-drive car,
after normally using right-hand-drive, it means I don't know how to drive.

The project happened to be mixed language. Also, the problem wasn't so much
using ":=" in C, which is quickly picked up as a syntax error, as using "="
in the other language, which was still legal but did bad things that were
hard to track down.

Since I'd used the other language for many years (having invented it), I
don't think the problem was not knowing how to use it. Just getting muddled
(because the designers of C inconsiderately used the wrong assignment
symbol...)

 

[Nick]

The project happened to be mixed language. Also, the problem wasn't so
much using ":=" in C, which is quickly picked up as a syntax error, as
using "=" in the other language, which was still legal but did bad
things that were hard to track down.

Since I'd used the other language for many years (having invented it),
I don't think the problem was not knowing how to use it. Just getting
muddled (because the designers of C inconsiderately used the wrong
assignment symbol...)

I'm programming in a mixed environment of C, Javascript, a HTML
templating language with loop constructs and a home-brew scripting
language. Not to mention little bits of embedded SQL, make files and
similar.

It's not that uncommon to get an error because I've put a semicolon on
the end of a line in the scripting language, or used == in it.

 

[Michael Foukarakis]

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.

I don't know. I learnt C pretty young, and I was able to distinguish
between '=' and '==', thanks to three subtle notions:

a) They differ by one character.
b) I knew the quantitative difference between 1 (one) and 2 (two).
c) I was told they had different behaviour.

If one is not competent enough to be able to differentiate between
them, I weep for minds younger than mine. Or actually, I don't, screw
them.

Disclaimer: Of course I've had my fair share of 'if(a=0)' bugs. To err
is human.

 

[BartC]

I'm programming in a mixed environment of C, Javascript, a HTML
templating language with loop constructs and a home-brew scripting
language. Not to mention little bits of embedded SQL, make files and
similar.

It's not that uncommon to get an error because I've put a semicolon on
the end of a line in the scripting language, or used == in it.

I've tended to use my own syntax for the last 30 years, but as I said, the
problem was picking up C habits too well! Writing "=" in the wrong language,
as well as sprinkling semicolons everywhere as you mentioned (fortunately
the other language didn't care about extra semicolons, the only problem was
developing RSI sooner..)

Another problem was mistakenly using the "!" comment-to-end-of-line symbol
from the other syntax in C, where it often isn't a syntax error (and my
editor highlights it as comment, which doesn't help). However lines with "!"
in front of them still get executed in C, with unexpected results...

 

[BartC]

I don't know. I learnt C pretty young, and I was able to distinguish
between '=' and '==', thanks to three subtle notions:

a) They differ by one character.
b) I knew the quantitative difference between 1 (one) and 2 (two).
c) I was told they had different behaviour.

Until you also use a second language where the meanings of "=" and "==" are
reversed. Yet (a), (b) and (c) are still true for each language.

In fact, in the real world outside of C programming, "=" to mean equality is
pretty much universal.

 

[BartC]

...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...
(C) Type declaration syntax...
(D) Make-file syntax...

Perhaps one more can be added:

(E) Compiler options

(The gcc.info file that comes with gcc lists some 1300 options, with other
stuff inside a 27000-line file (about 500 pages when printed out..))

 

[Nick Keighley]

That solution has been tried many times and has been found to be
inadequate as many times as it has been tried. It can't be fixed at the
library level because it's a language level problem.

and what, pray tell, do you think they write, say, C++ std::string in?
I know std::string is actually a template but it doesn't have to be.
You can write opaque types in C.

 

[Rui Maciel]

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

After re-reading this particular branch of this discussion I have to say that not only my reading
comprehension skills failed me miserably but that also my replies were inappropriate. My apologies.

The truth is that, even with a bit of practice, it's quite possible for an experienced C programmer
to have, let's say, a moment of weakness and inadvertently mix up "=" with "==" in some point in the
code, which could in turn cause problems that can be a bit hard to find. There is a good reason why
programs such as lint were developed to check for this type of problem.

With that under consideration, adopting some other syntax for the assignment operator (i.e., ":="
for example) could have been a small step that would have go a long way to avoid this sort of
problems.


Rui Maciel

 

[Ben Bacarisse]

In fact, in the real world outside of C programming, "=" to mean
equality is pretty much universal.

I have no idea how far from universal "pretty much universal" is but I
can think of:

B C++ C# Objective-C D Haskell Java PHP (two equality operators
neither of which is =) Perl Python Fortran (again two, == and .eg.)
Ruby Lua Scala Erlang (two again) Algol 68 (one the two is not =)
Prolog TCL

and probably others. How many would make it not pretty much universal?

 

[Ben Pfaff]

The xBASE languages use the = sign for both assignment and equality by
examining the context in which it is used.

So does, for example, BASIC.

 

[Tim Streater]

On 10/15/2010 12:23 PM, Joe Wright wrote:
[...]

The xBASE languages use the = sign for both assignment and equality by
examining the context in which it is used. For example:

a = 42

is an assignment and..

if a = 42

is a test for equality.

But, you apparently can't do things like:

if ( f = fopen(filename,mode) )
or
while ( pt = NextItem() )

True, I would write them:

if ( (f = fopen(filename,mode)) != NULL )
or
while ( (pt = NextItem()) != NULL)

but it appears that there would be no equivalent in xBase.

And quite right too. I find it egregious that people think it OK that a
side effect of testing something is to put a packet on the wire. Keep
things nicely separated and we shall get on.

 

[Felix Palmen]

I have no idea how far from universal "pretty much universal" is but I
can think of:

You should probably widen your scope a little in order to understand
Bart's statement. This is not just about programming languages -- there
are of course quite a few borrowing this stupid idea from C. Oh, and I
don't mean to bash C ... it's just ONE really poor decision in the
language's syntax and this thread is all about hypothetical
improvements.

Regards,
Felix