efaref

I find that YAML (a JSON superset) for config and JSON/CBOR on the wire works quite well.

The protocol is an absolute nightmare to work with, even when you're only using it for your own internal systems and so control everything that's involved. I heard that WhatsApp stopped using it long ago, and if so, that wouldn't surprise me.

I vaguely recall reading about someone developing a chip that could run both ARM and x86 code. The idea being that it would run ARM code most of the time at low power, and then power up in order to run x86 code when necessary. I don't know if there was any clever sharing of the silicon, or if it was in fact just an x86 core and an ARM core glued together.

The only thing I can find on it though is this IEEE document reference: http://ieeexplore.ieee.org/document/6136696/

Yes, I think it was designed in particular for determining addresses of fields within structures and variables on the stack, for example if you had:

    struct foo
    {
       int field1;
       int field2[10];
    }

Then an access like:

    fooptr->field2[index]

Would compile to:

    fooptr + sizeof(int) * index + offsetof(struct foo, field2)

Which is:

    lea $4(fooptr,index,4)

LEA (load effective address) can perform computations of the form BASE + SCALE * INDEX + OFFSET, where scale can be 1, 2, 4 or 8. This allows optimisation of multiplications and additions into a single instruction, and the compiler takes advantage of that.

So if you write:

    a = 4 * b + c + 10;

It will be optimised to a single instruction like:

    lea    0xa(%rsi,%rdi,4),%rax

Rather than the more naive:

    imul   $0x4,%rdi,%rax
    add    %rsi,%rax
    add    $0xa,%rax

NB (or n.b.) is "nota bene": https://en.wikipedia.org/wiki/Nota_bene

> If you read "ect.", your brain automatically corrects it to "etc." because you're used to seeing it often. It's probably subconscious, right?

Not at all. Seeing errors like "ect", use of the wrong words like the all-too-common mix-up of "then" and "than", and even the omission of dots in things like "eg" and "ie" is very jarring to me. It usually pulls me out of automatic reading in order to consciously work out what the author actually meant. Even when I've worked it out, I find it hard to substitute the real meaning for what's literally there. Not that I necessarily blame the author, as I understand that mistakes do happen, but it does noticably harm readability for me.

I do find your description of your preference on assistive technology very interesting, as it differs from the preferences expressed by my visually impaired friends. They get varyingly amused and annoyed by their screen readers not understanding idiomatic things and reading them too literally. I wonder if the difference is that you're the kind of technical person that reads Hacker News, whereas they're both arty types who don't really do computers any more than the average person does. I suspect that were I to ever need to use a screen reader, I'd prefer the dumb ones like you do.

Presumably native latin speakers will feel right at home. :-)

It seems that a lot of style guides these days actually recommend "eg" and "ie" over the versions with dots in a misguided attempt at simplification. I guess with those guides out there, the damage is already done.

Personally I always try to re-write sentences that use "e.g.", "i.e." or "etc.", as I think they're symptomatic of lazy writing. There's usually a much better way to write what you're trying to say. Similarly with excessive use of parenthetical clauses.

No, the correct form is "e.g." and "i.e.", and screen readers cope with those fine. People also get "etc." wrong a lot, writing it as "ect", which presumably screen readers would fail at, too.

Since people get it wrong, and there are more natural ways of writing these, these guidelines seem quite reasonable.

Surely "Open the BankCo app on your phone and enter the code" is just as simple.

For banks, for example, I already have a banking app on my phone (which was originally authenticated via, ahem, SMS), so they could very easily put the OTP generator there.

How about "JS was a terrible mistake that can do everything"?

The compiler has heuristics for unrolling, and ought to do it automatically when appropriate. Sometimes unrolling hurts performance, as you make the code larger and therefore reduce i-cache performance.

Tabs make no sense to me as they're clearly control codes.

I maintain that if tabs are permitted, so are other ASCII control codes, like vertical tab, form feed (which is actually used in GNU code), and bell.

    int foo(void)
    {
    <TAB>/* <BEL><BEL><BEL> This bit is really important. */
    <TAB>...
    }
    <VT>
    int blah(void)
    {
    <TAB>...
    }
    <EOT>
    <EM>

:-)

I'm surprised he doesn't live in fear of one of his ex-convicts getting out and going full Dexter on him. Perhaps he really believes his made-up lies.

I desire a time machine.

Checkmate.

I don't think they're intentionally gamed, it's just part of human nature. If you don't have to defend your assertions (because more assertions is presumed better, as per the rules), then people are liable to err on the side of putting more in that they need to.

With the exception of assert(ptr != NULL) assertions, I think most of the ones I've hit have actually been completely duff, and with some thought could just be removed. I dread to think what would happen if I grepped the commit histories of all the projects I've worked on for "removed duff assert".

Bill Clinton turned off the deliberate errors back in 2000:

http://www.nytimes.com/2000/06/15/technology/pentagon-lets-c...

The errors you see in your mobile phone's positioning are due to signal problems (reflections, etc) and the relatively limited capabilities of the cheap GPS radio in your phone. A decent GPS receiver with a well-positioned antenna will get a highly accurate clock.

I thought the purpose of Ingress was to crowdsource location data and photographs of points of interest for Google Maps.

Well, forced-coffee-serving and forced-car-fixing also has a name: slavery. That's pretty traumatic, too.

C/C++ also have & and | in the wrong place, mostly thanks to their heritage as being overloaded for && and ||).

I've personally seen several (flags & MASK != VALUE) bugs make it to the field. Sometimes it's worked for ages as the 0th bit was part of what was being tested.

Whilst adding more brackets can be useful to explain things, there comes a point when you have too much parenthesis. You have to rely at least a little on operator precedence, so you really do need to learn it.

I hero-worship Knuth as much as anyone, but that document is frankly terrible.

Take a look at section 6. There's a flowery sentence that says no more than "Add word to vocabulary" (completely pointless if this were a method called "add_word" on a class named "Vocabulary") and then a dense chunk of completely unexplained code.

His comment sums up exactly my thoughts wrt literate programming. It sounds like a nice idea, but in practice it falls far short.

The worst program I've ever had to maintain was written in funnelweb. It was a large, complicated program, so the funnelweb-generated documentation was tens of thousands of pages long. Nobody was ever going to read that. Trying to find out what you needed to modify to fix a bug was impossible from that document. Most developers I know looked at the woven C code (after all, that's where the line numbers in the stack trace pointed to), and worked from there.

This is a good example of a pointless "optimization" making the code harder to read.

If he had indeed meant that, he should have written

    x = ~x + 1;

GCC, even with optimisation turned off, will turn that into a negl instruction.

It sounds like the trailer didn't have underrun guards, which I think are mandatory in Europe, but presumably not in the US.

http://www.transportsfriend.org/road/guards.html

I expect those would have helped in this situation, as the car would have impacted the guards (and thus it would be a normal collision), rather than having its top sliced off.

In the UK we introduced the A* grade as a "solution" to this problem; first at GCSE level (end of compulsory high school, age 15-16) and then at A level (pre-university, age 17-18).

Even that just postpones the problem, as grade inflation continues. I expect we'll see A* * before long, and then eventually grade sheets will look like eBay reviews, and students will just get a star count.

The European Union does not have a trade deal with Japan (https://en.wikipedia.org/wiki/European_Union_free_trade_agre...).

But some survived.

How many survived with zero food?

The only case it becomes problematic is if you delete a header file, as make won't know how to remake it and won't recompile the C file (removing the dependency) until it has done so. There are two options to resolve this:

Also specify -MP on the GCC command line, which causes GCC to emit an empty rule for all the header files, like this:

    foo.o: foo.c foo.h bar.h
    foo.h:
    bar.h:

Alternatively, you can write a generic empty header creation rule:

    %.h:

Which has the same effect.

I think these days you're better off using -MMD to generate header dependencies at the same time as compiling, rather than doing it in a separate rule.

    %.o: %.c
            $(CC) $(CFLAGS) -MMD -c $<
    -include $(OBJECTS:.o=.d)