Comment by anyfoo | Hacker News Reader

Comment by anyfoo | Hacker News Reader

> The premier example of the adverse effects of cleverness in programming language design (and one which is obvious to programmers at all skill levels) must surely be the C/C++ declaration syntax [10]. On the surface, it seems like an excellent notion: let declarations mirror usage. Unfortunately, the very concept undermines the principle of visually differentiating semantic difference.

Does it ever. From today's point of view, C's declaration syntax is just bizarre, especially if you spent some time with a "modern" type system[1]. The result of this declaration-mirrors-usage cleverness is not just the more encompassing insanity like the emergence of the "spiral rule", as found here: [2]. (Isn't it fun that that site promises to enable "any C programmer to parse in their head any C declaration!"? You know you have a problem when that's a novelty.)

It's also the emerging little paper cuts, like the fact that it should be "char* c" with the * hugging the char because * modifies the type and so is part of it, but because of the "mirror usage" concept you better actually write "char *c", because that's how the parser groups it, as part of the variable.

In effect, multiple declarations in one statement must have confused many novices, when they wrote something like "char* p, q", and surprisingly got a "char* p" and a "char q".

> Students have enough trouble mentally separating the concepts of declaration and usage, without the syntax conspiring to blur that crucial difference.

Yeah. I learned C in the 90s (and fortunately by now know exactly where to distribute my "volatile"s and "const"s in a complex type), but I still remember how confusing it was that the * practically did the opposite in declaration vs. usage. In a declaration it makes a pointer, in usage it dereferences it.

Consider the very important difference between those:

char *p = q; *p = q;

Fun.

[1] "Modern" in quotes, because one prime example, Haskell, is old enough to appear in this 1996 article.

[2] http://c-faq.com/decl/spiral.anderson.html

The problems caused by "*" in C/C++ declarations and also in expressions are caused mostly by the mistake that "*" is a prefix operator instead of being a postfix operator.

This mistake has already been recognized by Dennis Ritchie a very long time ago, but it could not be corrected as it would break backward compatibility.

In 1965, the language EULER by Niklaus Wirth & H. Weber was the first high-level language with explicit pointer variables (previous languages, e.g. LISP I, FORTRAN IV and CPL used pointers only implicitly) and with the 2 operators "address-of" and indirect addressing, the ancestors of C "&" and "*".

However in EULER the indirection operator was postfix, as it should be. Niklaus Wirth kept this operator as postfix in his later languages, e.g. in Pascal.

With a postfix indirection operator, when you write some element of a hierarchical organization of data, which can include an arbitrary number of the 3 operations, array indexing, structure/class member selection and pointer indirection, all the operations are written and executed from the left to the right, without any parentheses and without any ambiguities. (also the C operator taken from PL/I, "->", is no longer needed, as it has no advantage over writing "*.").

This simple change would have avoided most pitfalls of the C declarations.

I don't think prefix usage of * operator is a big flaw. I've learned C/C++ in high school and never had a an issue with it. I've understood that the operator is applied to the variable, not to the type and that declaring a pointer is not the same thing as dereferencing it .

Even if someone may have made a mistake when declaring a pointer in C or C++ it is something they can get over pretty fast.

I didn't understand it either. Than learned assembly for a few months for a project -- switched back to C and everything came as natural.

Dereference syntax in C++ is very, very fixable.

C++ could easily adopt a postfix operator^ as a synonym for prefix op*, even at this late date. Then (*p)->m could be written p^->m, or p^^.m. (The last is clearly best.)

Rust, too, could do the same, for the same benefit. And C could, too, if there were any point.

The only people to complain would be IDE vendors.

If you were then allowed to declare a pointer argument like "char p^", or even "char^ p", you could begin to dispense with use of "*" as a unary operator. Declaring "char^ p, q" would mean both p and q are pointers, eliminating another source of beginners' confusion.

Rust copied this misstake. Rust would have been neater if taking references and dereferencing were postix operators. At least they made await a postfix operator.

To Rust's credit, 90% of the time I find I don't need to dereference much at all. For example, when you make a method call on a reference, you don't have to dereference first, and there is no -> operator in Rust. The only time I ever really have to dereference manually in my experience is if I'm matching on some struct reference, and I want to take some field and put it in a new place.

e.g.

  match &foo {
    Foo{bar} => Baz{quux: *bar}, 
    _ => (),
  }

(not valid Rust but you get the point)

Note that in C at least the '->' is completely redundant and the '.' alone would suffice. (C++ is a somewhat different story.)

Not without parentheses, which is why -> was introduced.

Only because of arbitrary precedence rules though. They didn't have to make . higher than *

*foo.bar() could be read as "dereference foo and then evaluate bar() on the result".

I think this was only considered acceptable because in early C you couldn't initialise automatic variables. So you would never be confused by an association like `char *p = q; *p = q;`, because you couldn't write that first part. And declarations were all separate at the front of the function.

The bigger mistake was to mix a prefix pointer operator in with the postfix [i] and (x). You end up with the spiraling-out parsing even for expressions, not just declarations. With Pascal's postfix ^ everything reads left to right.

While you are not wrong, the two major problems in C I would consider to be array-to-pointer decay (arrays should really have been a separate type), and assignments being expressions instead of statements.

Array decay means that pointers need the ability to point to different array elements, thus requiring pointer arithmatic - something that wouldn't have been needed at all without array to pointer decay.

And since assignments are expressions, they must return something, meaning they can be used in statements like 'if (a=b)...'. If they were statements they wouldn't return anything, so this mistake would be impossible. You'd lose assignment chaining, but the win here would be much greater than the loss.

If I had a third choice, it would be the mess around 'char'. At the very least there should have been two types: one for characters (where signedness is irrelevant), and one for the smallest type of integers (that can exist in signed or unsigned form). And in these modern times an additional type, something like 'byte', would be needed to deal with aliasing issues, so char (and things like uint8_t) can exist without that, allowing better optimisation for those types.

Arrays are a separate type.

Just in the exact scope in which they were declared, once they are passed as argument to any function they become a simple pointer.

Not from pointers, though.

I also dislike array-to-pointer decay, but I'm not sure why do you say that it is one of the two major problems.

Could you expand on "Array decay means that pointers need the ability to point to different array elements, thus requiring pointer arithmatic"? I don't see what you mean.

A point that comes to mind is that if array-to-pointer decay were really such a bad thing, the "struct of array" and "pointer to array" types would be used much more than they are (they are almost never used).

If arrays are separate types, pointer arithmetic becomes redundant: you can't add one to a pointer to get to the next element anymore. That would remove an entire class of problems.

Pointer to array would still be a thing, of course, but it would always only point to the _array_, without the ability to manipulate it to point to another part of the array.

Pointer arithmetic is not needed any more only when the programming language provides high-level operations with arrays, like APL, J, K and similar languages.

A very good optimizing compiler could generate a code for accessing the arrays that would use either indices or pointers, depending on the target CPU and on the desired operation.

Otherwise, if you have to write explicit loops and the compiler is not extremely clever, for optimal performance you might need to use pointers instead of indices in many cases. The optimal choice can differ between target CPUs, e.g. for Intel/AMD CPUs indices are often better than pointers, while for ARM or POWER CPUs pointers are more frequently better.

You can have both, as proven by languages like Modula-2 or Object Pascal.

Assignments being expressions is frequently very useful for avoiding to write the same expressions twice, which could also be a source of errors.

You are right about the errors caused by unintended assignments, but the root cause for these errors is not the fact that assignments are expressions, but the fact that in B & C they have replaced the operators inherited by BCPL from ALGOL, ":=" for assignment and "=" for equality test with "=" and "==". With the original operators, typos would have been very unlikely.

This misguided substitution was justified by less typing, but a much better solution would have been to not change the syntax of the language but to just modify their text editor to insert ":=" when pressing ":", because deleting the "=" when not needed would have been required very seldom, as ":" in labels or "?:" is encountered much less frequently than both assignments and equality tests.

If you have the same expression twice as part of a compound assignment, there's nothing stopping you from assigning the variable instead of repeating the expression:

    a = b = f();

vs.

    a = f();
    b = a;

And tangential, but editors really shouldn't be mangling text as you type. Whenever I install Visual Studio anywhere, it's the first thing I turn off...

> Students have enough trouble mentally separating the concepts of declaration and usage

I wonder if this is an argument in favour of Python’s implicit declarations (“there are no declarations, only usages”) or against them (“there are still declarations, but they’re invisible”)?

python is dynamically typed though, so most explicit declarations would be boring and pointless (hence the easy omission).

More to the point is probably type inference in statically typed languages, e.g. in Haskell you can often omit the type, or in C++ you can just call it "auto".

I'd say to learn a language it's better to explicitly specify your types in order to understand them, but I'm not sure it's necessarily "confusing" to omit them. I.e., "it has a type but I don't know it" is much easier to deal with than "what in the world is that type supposed to be".

> most explicit declarations would be boring and pointless

Not pointless - in similar languages (e.g. JavaScript's `let` and Lua's `local`), although declarations don't indicate a variable's type, they do indicate its scope.

Without explicit declarations, Python needs to make an assumption about scope - specifically, that each variable's scope is the innermost containing function. This makes the language easier for beginners, but more complex overall because it requires special features to support closures.

It's also a lot more error prone in large programs because misspellings introduce new variables instead of causing an error.

The fact that you can “declare” variables inside logic branches also leads to runtime exceptions when the code flow doesn’t touch any of those branches, but still expects the variable to exist later.

Couldn’t agree more. Every time I need to write/read C I’m forced to refer to some documentation just to recall what the right syntax is depending on whether or not I’m declaring or using pointers.

I think go is a good example on how to turn “cleverness” into clear conventions, which usually yield the benefits of cleverness without the headaches.

Semantic cleverness becomes problematic too at times. There’s a fine line between developing a useful abstraction and doing something so obtuse your users are scarcely able to discern what’s going on once they run into a problem and run in circles trying to debug weird underlying language design decisions.

Makes me wonder if using keywords like

var char foo; // foo is a char pointer char boo; // pointer to a boo type

or something I want.

alias baz = boo.foo; // bas is actually just an alias for boo.foo

I was so confused as a student because I has roughly the same objections as you have here, but I thought it was I who was missing something.

Also: In an hour I'm teaching pointers to novices haha

Haskell does not really have pointers, but let's say it does (or that ioref fulfills it). How would you then (as an example) declare an array of pointers pointing to functions accepting int and returning float declare in Haskell?

Like How Rust does it? via Box or using &

It would be `[fn(i32) -> f32; N]` for the reference (equivalent to `float (*[N])(int)` in C). Box or & would be only required for also allowing function-like values, as in `[Box<dyn Fn(i32) -> f32>; N]`.

Array Int (IORef (Int -> Float))

The first "Int" is the type of the array's index, which in C is always "int" and hence not specified.

(As you note yourself, pointers, or even just arrays, are not very much of a Haskell concept, but I still think this is pretty readable and very obviously parseable if you know the involved types "Array i e" and "IORef a".)

For a C-like take, D: float function(int)[], or if you genuinely wanted an array of pointers to function pointers, float function(int)*[].

Thanks. Yes I wanted array of pointers. So then how would you do a pointer to an array of functions in D? * float function(int)[] ? Edit: or float function(int)[] *

float function(int)[]*, yes.

In Rust, an array with 10 elements that are function pointers whose functions receive i32 and return f32 is like this:

    [fn(i32) -> f32; 10]

https://doc.rust-lang.org/reference/types/function-pointer.h...

That's maybe cheating because this type doesn't use Rust raw pointers; C's char* in Rust is something like const char or mut char. But, if you wanted a raw pointer (and were ok with a double pointer: an array of pointers to function pointers), it would be like this:

    [*mut (fn(i32) -> f32); 10]

Which I think we can drop the (), since there is no ambiguity

    [*mut fn(i32) -> f32; 10]

ok, so HN formatting ate a couple * here and there. I meant that

    char* something;

in C is like

    let something: *mut char;

or

    let something: *const char;

In Rust. So complex pointers are easily expressible: they are just *mut something complex

Reply on news.ycombinator.com