Live data from Hacker News

Humans should think of sizeof() as a function, says Linus Torvalds

lkml.org

111–120 of 140 posts

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#111

Earlier quoted context omitted.

We would all be better off if semi colons had just been required in JavaScript. The problem is that semi colons are not actually optional in JavaScript. Instead JavaScript use ASI, automatic semi colon invasion, where the compiler attempts to determine where semi colons should go. Unfortunately the rules are complex, prone to certain errors, and I can't rely on everyone I ever work with understanding all of those rul…

http://blog.izs.me/post/2353458699/an-open-letter-to-javascr... Please stop spreading FUD.

If you have an argument to make, then make it.

The previous poster didn't say he was unwilling to learn JS semicolon rules, he was saying he couldn't trust everyone he ever works with to learn them. Replying with an accusation of FUD and a link to someone ranting that it's unprofessional for JS devs to not know these rules is unnecessarily inflammatory while missing his point.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#112
post #106

Earlier quoted context omitted.

Was there something factually incorrect in my comment?

Was there something relevant in your comment?

I was pointing out that if you can consider sizeof a function, you can consider return one too.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#113
I first learned that sizeof was an operator when I was confused about how it dealt with arrays compared to functions. After I learned it was an operator and not a function things made sense and were (relatively) consistent again. Several commentators here have given other examples where you will be completely thrown off if you believe that '"sizeof()" really is a function.'

The problem with "lies to children" is that they can pile up to the point where people end up becoming completely confused about what's actually happening. As the internal inconsistencies mount, the "simple" lie starts to become a lot more complex than the "complicated" truth.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#115

Earlier quoted context omitted.

The only problem with this is if/when someone comes along and doesn't notice the missing braces and does if (condition) Foo(x) Bar(x) Expecting Bar(x) to be part of the conditional. This can and does happen.

I hear folks say that, but don't encounter it in the wild. Maybe once in 20 years so far. That construct, reading it just now, just screams out at me "Indentation error!" Anyway it nicely illustrates the need to get braces out of there altogether. The programmers' intent is obvious; let the IDE 'make it so' by emitting braces in the generated code.

> I hear folks say that, but don't encounter it in the wild. Maybe once in 20 years so far.

It was the cause of the "goto fail" SSL bug that affected both of Apple's operating systems last year: https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got...

So I'd say it's rare, but it happens. And when it happens, the effects can be pretty big.

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#116

I respect Linus greatly but the way he to talks to his fellow 'humans' is insanely confrontational, rude and disrespectful. It overshadows his arguments (which are usually very good) and throws people on the defensive. I'm grateful for all he has accomplished and shared with us but I imagine working with him is 'hell'.

I quite enjoy his style, but i understand it's not for the newer "easily triggered" generations

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#117

Earlier quoted context omitted.

The only problem with this is if/when someone comes along and doesn't notice the missing braces and does if (condition) Foo(x) Bar(x) Expecting Bar(x) to be part of the conditional. This can and does happen.

I hear folks say that, but don't encounter it in the wild. Maybe once in 20 years so far. That construct, reading it just now, just screams out at me "Indentation error!" Anyway it nicely illustrates the need to get braces out of there altogether. The programmers' intent is obvious; let the IDE 'make it so' by emitting braces in the generated code.

I've never seen (in code I've worked on)

    if (condition)
        Foo(x);
        Bar(x);
But I have seen

    if(condition1)
        if(condition2)
            if(condition3 && condition4)
                Foo();
This upset the old ARM compiler I was working on and it decided to skip some of the conditions. I fixed the bug, related to this code, by adding braces:

    if(condition1)
    {
        if(condition2)
        {
            if(condition3 && condition4)
            {
                Foo();
            }
        }
    }
So this is why I always put braces to define scope. Although, in general, both of these types of bugs are uncommon.

Honestly, the more pervasive problem that comes up is the eventual addition of new code adds noise to diffs. Like if I have a condition with a single statement

    if (condition)
        Foo(x);
And I add something to it, I have to add braces and it pollutes the diff with stuff that isn't really related to what I'm changing.

    if (condition)
    {
        Foo(x);
        Bar();
    }

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#118

Earlier quoted context omitted.

I don't believe its equivalent. When I'm writing Scala code in the backend and have to switch to frontend I often find myself omitting the semi-colons but going back and fixing due to self-imposed coding conventions. For Javascript just as in Python or Scala, semi-colons are optional for a good reason.

We would all be better off if semi colons had just been required in JavaScript. The problem is that semi colons are not actually optional in JavaScript. Instead JavaScript use ASI, automatic semi colon invasion, where the compiler attempts to determine where semi colons should go. Unfortunately the rules are complex, prone to certain errors, and I can't rely on everyone I ever work with understanding all of those rul…

>Unfortunately the rules are complex, prone to certain errors, and I can't rely on everyone I ever work with understanding all of those rules.

Are they really complex? This recently released version 4.0.0 of the JavaScript Standard Style [1] suggests to never start a line with "(" or "[". This rule looks even simpler than the rules of operator precedence.

[1] https://github.com/feross/standard

Update: Now I learned about the JavaScript Semi-Standard Style [2] which accually enforces semi-colons. Quite hilarious.

[2] https://github.com/Flet/semistandard

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#119
post #31
post #6

IIRC, if the argument to sizeof is a type, the parentheses are mandatory, anyway, so using it like it was a function is more consistent. I think the reason it is not a function from the standard's point of view is that C does not have any builtin functions (unless my memory totally fails me in this case), all functions have to be either defined locally or #included.

Another oddity of C that amuses me is the do/while loop without braces: int i = 4; do printf("hey\n"); while (--i > 0); Even though do/while is a keyword bracketing pair in C, it still only lets you use a single statement (because nested whiles). So everybody uses braces, and thus it looks quite disturbing without them.

> Another oddity of C that amuses me is the do/while loop without braces: [...] > Even though do/while is a keyword bracketing pair in C, it still only lets you use a single statement (because nested whiles).

Ah, but don't forget you can still use the comma operator, so get several statements in before the semicolon:

    int i = 4;
    do
       printf("hey"), printf("Jude.\n");
    while (--i > 0);

Re: Humans should think of sizeof() as a function, says Linus Torvalds

#120
post #91
post #76

Earlier quoted context omitted.

The problem is that without a linter there's no punishment for missing semicolons. So really the argument should be that everyone should use a linter.

Oh, there's plenty of punishment. Avoiding the punishment in the difficult part. And you can do that the easy way or the hard way.

Well, sure, but it's probabilistic and delayed punishment. This makes learning habits and ensuring them difficult.
Post reply on HN