4 ms·

And then people wonder why other engineers smirk when they hear the term "software engineering" :-). We're not all fitted with the same Umbrella IntuCard Mk. I

And then people wonder why other engineers smirk when they hear the term "software engineering" :-). We're not all fitted with the same Umbrella IntuCard Mk. II Intuition card so that, relying on intuition alone, we can all reach the same results from the same inputs. Relying on intuition to figure out how a language works is about as smart as relying on intuition to figure out the limit of a series, how a telephone work or how a transistor works -- all three of which have been definitely designed for humans to use, since there were nothing but humans who could use them back when they were invented. I don't like it any more than you do, and my life would be much easier (and probably happier) if it weren't like this, but blaming it on the language is the equivalent of the turtle blaming calculus after losing the race to Achiles.

dbaupp 9y ago
I don't see how your series or resistor examples are particularly relevant: neither mathematical nor physical facts are human inventions. The packaging is, but I'd argue that the packaging for both is relatively intuitive for someone likely to be encountering them. For this example, there is a large amount of intuition both from C specifically and more broadly in programming (i.e. the background of people likely to be encountering this) that foo(bar) is a function call that evaluates all its various components. The syntax used for many "calls" of sizeof violate this intuition. The uniformity that leads to this corner case may indeed be the right choice (and probably actually is, IMO), but discarding intuition---and assuming everyone is a robot who's memorised all corner cases of their tools and never makes a mistake---is dumb, especially in a relatively restricted domain like programming where there is a reasonable set of common/shared assumptions to build on. Lastly, the "a good carpenter never blames their tools" sentiment is also dumb, as a universal guideline: tooling can be objectively bad and unhelpful, and, even if someone can make it work, there will be downsides. Taking things to the limit, it's clear that "C but instead of text, just write down the UTF-8 encoding of a file as one huge base-10 number" would be an actively bad programming language and lead to all sorts of problems over normal C. The same thing holds for, say, C compared to other tools: people make objectively more of certain particularly bad classes of errors when writing C because the tool isn't helpful enough.
- notalaser 9y ago
  > I don't see how your series or resistor examples are particularly relevant: neither mathematical nor physical facts are human inventions. Mathematical facts are a very human invention, just like the transistor. I picked calculus precisely because intuition based on physical observation gives the wrong answer nine times out of ten. > assuming everyone is a robot who's memorised all corner cases of their tools But this is not a corner case! I'm not talking about an obscure quirk (God knows how many C has!), this is literally syntax, the first thing you learn about a language!
  - dbaupp 9y ago
    > transistor (Whoops, but my point still stands just as much.) > Mathematical facts are a very human invention, just like the transistor. I picked calculus precisely because intuition based on physical observation gives the wrong answer nine times out of ten. I think I didn't convey my point very well: humans and their intuitions have no influence over the value of the mathematical series 1 + 1/4 + 1/9 + ... nor do we have any influence over the behaviour and interactions of certain doped (etc.) silicon. Both of these just are, outside the influence of humans. Certainly, for the former, we have control over the syntax we use ("the packaging")/how we write it down, but, say, changing what "1" means changes the series to a different object. In any case, control over the syntax is exactly like a programming language, and indeed, mathematical notation is very similar and it's great when people have sympathy for the reader's intuition (and their own) when designing new instances. (The ⌈x⌉ notation for the ceiling of x is a nice example of this working well.) Similarly for a transistor, humans can decide how we put the bits of silicon together, and what wires we connect up, but we absolutely cannot decide the fundamental principles that make them work. This means, if we want a certain behaviour, we're limited by what physics can do. > But this is not a corner case! I'm not talking about an obscure quirk (God knows how many C has!), this is literally syntax, the first thing you learn about a language! Yes, you're right `sizeof(foo)` is syntax... that looks a lot like `function(foo)` but behaves differently with respect to any side-effects in foo. As I said above, I do actually think this was a reasonable choice on C's part, but it seems silly to, seemingly, dismiss any possibility that it could be confusing & that maybe future languages/language designers should avoid doing this (or at least explicitly think about the choice they're making) and instead just repeat RTFM over and over.

dbaupp 9y ago

I don't see how your series or resistor examples are particularly relevant: neither mathematical nor physical facts are human inventions. The packaging is, but I'd argue that the packaging for both is relatively intuitive for someone likely to be encountering them. For this example, there is a large amount of intuition both from C specifically and more broadly in programming (i.e. the background of people likely to be encountering this) that foo(bar) is a function call that evaluates all its various components. The syntax used for many "calls" of sizeof violate this intuition. The uniformity that leads to this corner case may indeed be the right choice (and probably actually is, IMO), but discarding intuition---and assuming everyone is a robot who's memorised all corner cases of their tools and never makes a mistake---is dumb, especially in a relatively restricted domain like programming where there is a reasonable set of common/shared assumptions to build on. Lastly, the "a good carpenter never blames their tools" sentiment is also dumb, as a universal guideline: tooling can be objectively bad and unhelpful, and, even if someone can make it work, there will be downsides. Taking things to the limit, it's clear that "C but instead of text, just write down the UTF-8 encoding of a file as one huge base-10 number" would be an actively bad programming language and lead to all sorts of problems over normal C. The same thing holds for, say, C compared to other tools: people make objectively more of certain particularly bad classes of errors when writing C because the tool isn't helpful enough.

notalaser 9y ago
> I don't see how your series or resistor examples are particularly relevant: neither mathematical nor physical facts are human inventions. Mathematical facts are a very human invention, just like the transistor. I picked calculus precisely because intuition based on physical observation gives the wrong answer nine times out of ten. > assuming everyone is a robot who's memorised all corner cases of their tools But this is not a corner case! I'm not talking about an obscure quirk (God knows how many C has!), this is literally syntax, the first thing you learn about a language!
- dbaupp 9y ago
  > transistor (Whoops, but my point still stands just as much.) > Mathematical facts are a very human invention, just like the transistor. I picked calculus precisely because intuition based on physical observation gives the wrong answer nine times out of ten. I think I didn't convey my point very well: humans and their intuitions have no influence over the value of the mathematical series 1 + 1/4 + 1/9 + ... nor do we have any influence over the behaviour and interactions of certain doped (etc.) silicon. Both of these just are, outside the influence of humans. Certainly, for the former, we have control over the syntax we use ("the packaging")/how we write it down, but, say, changing what "1" means changes the series to a different object. In any case, control over the syntax is exactly like a programming language, and indeed, mathematical notation is very similar and it's great when people have sympathy for the reader's intuition (and their own) when designing new instances. (The ⌈x⌉ notation for the ceiling of x is a nice example of this working well.) Similarly for a transistor, humans can decide how we put the bits of silicon together, and what wires we connect up, but we absolutely cannot decide the fundamental principles that make them work. This means, if we want a certain behaviour, we're limited by what physics can do. > But this is not a corner case! I'm not talking about an obscure quirk (God knows how many C has!), this is literally syntax, the first thing you learn about a language! Yes, you're right `sizeof(foo)` is syntax... that looks a lot like `function(foo)` but behaves differently with respect to any side-effects in foo. As I said above, I do actually think this was a reasonable choice on C's part, but it seems silly to, seemingly, dismiss any possibility that it could be confusing & that maybe future languages/language designers should avoid doing this (or at least explicitly think about the choice they're making) and instead just repeat RTFM over and over.