Live data from Hacker News

“It is never a compiler error”

blog.plover.com

271–280 of 280 posts

Re: “It is never a compiler error”

#271
post #218

Earlier quoted context omitted.

IBM has built several operating systems and programming languages and compilers over the years. Probably more than Bell Labs, actually. It's not so surprising.

Unix and C is more known, so that would be my assumption too. In fact I can't name any IBM made OSes or programming languages.

I can name a half dozen without googling. But, I'm kinda old and I remember when IBM was the dominant force in computing at nearly all levels.

Re: “It is never a compiler error”

#272
post #218

Earlier quoted context omitted.

IBM has built several operating systems and programming languages and compilers over the years. Probably more than Bell Labs, actually. It's not so surprising.

Unix and C is more known, so that would be my assumption too. In fact I can't name any IBM made OSes or programming languages.

RPG

Re: “It is never a compiler error”

#273
post #75

Earlier quoted context omitted.

K&R braces have approximately nothing to do with semicolon insertion...

Compare the values of these function bodies: return { }; and return { };

Yes, those are different, but K&R brace is a style of where you put the braces in a function body or a block. The braces in your example are creating an object literal.

The K&R brace style is not about putting an object literal on the same line with a return statement or on another line, but about how control structures are formatted.

The reason I said that K&R brace style has nothing to do with semicolon insertion is that it’s possible to write all your control structures with K&R braces and still be bitten by the places in the grammar where line breaks are not allowed, like after a return statement, if you’re unaware of it.

It’s also possible to use Allman braces everywhere and never have that problem with return statements.

Re: “It is never a compiler error”

#274
post #114
post #75

Earlier quoted context omitted.

K&R braces have approximately nothing to do with semicolon insertion...

if(foo) if(foo) { Edit: add this comment you have provided approximately nothing in support of your assertion, you can and should do better. I note this thread is JS and a whole lot of this kind of thing going on here I don't usually see elsewhere on HN. It's a shame, discussion is useful to learn things I don't already know. "Nyer, your wrong" not so useful to me, you or anyone else.

No, JS will never never insert a semicolon after “if(foo)” no matter what comes after it. Putting the braces on your control structures on the same or the next lines has no interaction whatsoever with the semicolon insertion rules.

I’ve written a ridiculously detailed blog post about automatic semicolon insertion if you want to know all the specifics.

http://inimino.org/~inimino/blog/javascript_semicolons

Re: “It is never a compiler error”

#275
post #116

Earlier quoted context omitted.

I took "clang/llvm may be reckless, but they're fast and have UBsan", to which I replied "gcc is still faster".

Oh, I thought the GP was accusing GCC devs of reckless optimizations. But UBSan is a clang project, so maybe you're interpretation makes more sense. Very confusing thread. :)

I mean, if you use GCC does recklessly optimize away (some) security/safety code. This is one of the reasons why we don't use it for code we ship. I work in a safety-conscious industry, where an overeager compiler can literally kill people.

Re: “It is never a compiler error”

#276

Earlier quoted context omitted.

I definitely found a compiler error in an early version of Julia, luckily the solution was to upgrade to the newer release that I'd been too lazy to bump to.

Good example. "An early version of Julia" is a less-tested piece of your stack than, say, "a recent version of Java". Especially if the feature in question is something absolutely everyone uses in Java.

And the feature with the bug is a little-used part of julia

Re: “It is never a compiler error”

#277
Depends on the language. Never encountered a C++ or C compiler bug, but I've hit 2 separate & nasty Python runtime environment bugs (one that caused a segfault because of some memory trampling from having too many file descriptors open, and one edge-case sorting bug).

Re: “It is never a compiler error”

#278
post #48
post #45

Earlier quoted context omitted.

That first one reminded me of the gripe at the top of perl's Configure script https://perl5.git.perl.org/perl.git/blob/HEAD:/Configure#l36 -- "SCO csh still thinks true is false. Write to SCO today and tell them that next year Configure ought to "rm /bin/csh" unless they fix their blasted shell. :-)" which only gets printed if the shell it's running in egregiously mishandles &&...

I think someone did a rm -f on SCO, so the problem is solved.

The court case is, of late October 2017, still alive, believe it or not.

Re: “It is never a compiler error”

#279
post #161

Earlier quoted context omitted.

You can avoid the second pass...

No, you can't, because at the end of the first pass you have no way to know that it is in sorted order. Go ahead and try to write the pseudocode for your bubble sort implementation that avoids the second pass.

you look back and see if you will need a second swap and set your "need another pass" boolean that you named "swapped" accordingly.

Re: “It is never a compiler error”

#280

You gotta through a lot of those sort of expectations out of the windows when working with js. . . imho

It is silly to kick JavaScript in this example because the bug* is in the library of a custom JavaScript interpreter not a common runtime. * https://github.com/code-dot-org/JS-Interpreter/pull/23

I'm kicking Javascript/Node because the entire stack is amateurish and one constantly runs across unexpected behaviours/build breaks in even fairly high profile libraries.
Post reply on HN