Frederick said:
Skarmander:
OK, I'm with you so far...
Indeed, as a Westerner, I might find it quite strange that Malingua's
showers look like cars.
But here, of course, the analogy breaks down readily: Malingua, as we
presume it to exist, isn't man-made, and isn't meant to serve a purpose. And
even then, Malinguans familiar with cars may concede that it doesn't make a
whole lot of sense to them either.
What can I do about it? Well, before travelling to Malingua, I can say,
"OK, I going to disregard everything I learned in Ireland, and I'm going to
start afresh in Malingua without making any presumptions as to how things
work."
That is humanly impossible. Only computers can work without presumptions,
and that only because they cannot presume in the first place.
Is this a viable choice? No, not when talking about going to a different
country.
OK, I'm with you so far.
However, we're talking about a programming language. When you're learning a
new programming language, you can't really build on past experience. You
need to confirm and clarify everything.
Says who? The language? No. So what, then? Experience? Sure. Experience
tells us we cannot rely on our previous experience, but you see how that
only goes so far.
If I read
c = a + b;
it is not possible and not helpful for me to pretend that these are
meaningless symbols barring an explicit definition in a language standard
somewhere that will explain to me what exactly this sequence of symbols
means, if anything.
For sure, the language standard *is* the only authority on it. I cannot
*rely* on my assumptions about the statement's semantics, and a good many
may be wrong. I cannot with any definite justification shout "that's wrong"
if it shouldn't match my expectation. However, if "c = a + b;" turned out to
mean "perform a low-level format of all attached disk drives", I would have
reason to complain nonetheless, however formally precise and consistent the
definition might be.
The simple fact of the matter is that you have to be in the know when it
comes to a programming language. Some people may presume that you can pass
an array by value, but alas they're wrong. Was their intuition flawed to
think they could simply write:
void Func(int arr[5]) {}
Maybe, maybe not.
As long as we're willing to concede the possibility, that's enough. It's not
a black and white issue, and that's my point. "It's standard C so there's no
point criticizing it for what it isn't" is a reasonable attitude for writing
programs (indeed, the only reasonable attitude), but not when the point
precisely is criticism of C's design.
Is the intuition flawed? Consider this: in C, everything that can be passed
is passed by value, but arrays cannot be passed as values. This is not
reflected in the most intuitive attempt at doing it, since that is not an
error, but instead implements quite different semantics.
There are two separate issues here. First, should C have included passing
arrays by value? There are obvious and understandable reasons why it does
not (though whether they are sufficiently good reasons is a completely
different matter, which I will not go into here). Second, since C does not
include passing arrays by value, should it have included the syntax form
that it does, with the semantics that has? The latter decision is much
harder to defend.
At the end of the day though, the C Standard is the C
Standard. You can either come to terms with the fact (however much you
dislike it) that Malingua's showers look like cars, or you can rant on
about how backwards Malingua is.
Or, indeed, you can do both. Nobody said coming to terms meant keeping your
peace hereafter. What would become of activism?
This reminds me of the argument posed recently whereby the following was
deemed to be bad style:
Style is a lot murkier than even intuition.
SomeAggregateType obj = {0};
in place of:
SomeAggregateType obj;
memset(&obj,0,sizeof obj);
(Let's forget for the moment that the latter form is only guaranteed to
work with integer types.)
The argument posed was that the former form wasn't explicit enough, i.e.
that the programmer wasn't expected to know that all the members/elements
would be default-initialised.
This, in my own humble opinion, is BS. The semantics of the former form are
perfectly well defined by the Standard, and that's good enough for me. One
shouldn't censor one's code because they think a particular feature might
be a little too advanced for some people.
There are no clear insights on how intuition works, so these matters remain
thoroughly debatable. However, in my opinion, this is still quite a bit
removed from the opinion that it's counterintuitive that
void func(int arr[5]) {
...
does not declare 'arr' to be a parameter of type "array of five ints", and
that indeed what looks like a dimension is actually meaningless.
Both these things rely on intuition, and both can be chalked up to
inappropriate extrapolation: you thought it meant one thing based on what
you saw earlier, but you were wrong. How obviously jarring you might find
either is subjective, of course, but I do think most people would agree that
confusion about passing arrays is more "natural" than confusion about struct
initializers.
It is the implication of a flaw in C that I was dismissing.
It *is* a flaw in C. The syntax is confusing, and pointlessly so. The
language would be better if it did not include this particular syntax form
at all, and if array parameters looked as what they are: pointers.
Of course, the question of whether arrays should be first-class citizens
instead (which would be an alternate way of solving the problem) is a whole
'nother bag of beans, as it involves a lot more arguments and being a lot
more explicit about design goals.
And, obviously, now that the language is what it is there is no sense in
arguing that it should be different, as the mass of existing code is now a
very strong argument against. But then, that's not the argument in question
either.
S.
