PDoyle

Nonsense. Graph databases pre-date SQL. The relational model was created to overcome the limitations of graph databases.

Uh, that's not what NIMBY means. "NIMBY" means we all agree that something a Good Thing™, but I want it placed in someone else's neighborhood instead of mine. It doesn't apply to any possible objection to one's neighborhood.

That depends on whether you think "unscrambling" counts as "solving".

Yeah, they're using a rather naive human-oriented algorithm. It would be straightforward to improve this with a software upgrade.

No, to me it looks like it did CFOP with an orange cross on the table, and the white cross when he held it in his hand.

Mill is awesome. I'm afraid it has too many revolutionary ideas in one package, though, which could impede its widespread adoption.

Your proof is flawed. The CPU has access to the complete current program state, and also complete knowledge of its own hardware. A static compiler has neither. Therefore, it's not at all clear that a compiler can do whatever the CPU can do.

Example: the best order to run a sequence of instructions could depend on which inputs happen to be in the L1 cache at the time. This could differ from one execution to the next. There's no way for a static compiler to get this right.

Nice, I hadn't looked at RISC-V before.

The operation of FENCE.I scares me a little:

> FENCE.I does not ensure that other RISC-V harts’ instruction fetches will observe the local hart’s stores in a multiprocessor system. To make a store to instruction memory visible to all RISC-V harts, the writing hart has to execute a data FENCE before requesting that all remote RISC-V harts execute a FENCE.I

Yikes. That sounds cumbersome for multithreaded code patching systems, like modern JIT compilers. (A "hart" here is a hardware thread.) Sounds like all threads must poll periodically to check whether they should run a FENCE.I, and when they do so, they report that they've done it. Doesn't sound like a lot of fun to implement, though maybe better in software than hardware?

No. The point of the article is that it's ok to undo an abstraction that has done more harm than good. Abstraction and DRY is still a good default mode of thinking.

Agreed. To me, the real point is not to be afraid to undo an abstraction that has proven to be more trouble than it's worth. DRY is still a good default mode of thinking.

However, let's not go too far: I think DRY is a good default for new programmers. They can learn to break that rule as they gain experience.

Yep, always talk to the person who made a WTF-inducing change. It's even possible they've thought of something you didn't.

Right. I think this is the promise of Java generics: we promise we'll warn you if you're relying on dynamic type checking because we can't prove all dynamic type checks will pass.

This article gives a series of examples that break that promise.

Ever worked at a startup?

People forget that the proverb says it's easier, not better, to ask forgiveness.