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.

Pre-emptive runtimes are hard. Inserting yield points judiciously in loops isn't that incredibly difficult, and neither is reducing the cost of a yield point. It's far harder to make sure every machine instruction in every part of the runtime is prepared to be interrupted and have all it assumptions violated by the time it resumes.

Ah, mutable data. Is there any abstraction it can't ruin?

I'll just leave this here:

https://xkcd.com/927/

Yep. In fact, this is how it formed in the first place.

You're mis-reading it. The blue line is subsequent 10-year performance, so it's already shifted back (left) several years from its natural alignment on the chart.

Wow, really interesting read. Thanks for the link.

Only trouble is that once people find patterns like this, they have a habit of disappearing. Hopefully this one is based on solid enough fundamental market forces that it persists after its publication. It was published in 2013 so we won't know for sure until after 2023.

--minor spoilers--

But John Wick Chapter 2 is not a period piece. The VIC-20 is not meant to be a modern computer there. As I recall, they have women dressed as 1940s switchboard operators with prominent tattoos using VIC-20 keyboards connected to modern monitors to take orders for assassination of assassins -- tell me again which part of this seems out of place?

Cool, thanks for the link.

My mistake--I thought "regions" meant some sort of interprocedural "code regions".

I suspect the state of the art in GC has moved in the last 15 years since this paper was written, and they might have trouble beating modern techniques, but that's speculation.

Ok, so you analyze "regions". Then what? Modify the data structures to use some kind of efficient headerless representation? Then stop the world and rewrite the whole heap if a new class gets loaded that violates an assumption? Or if existing code tries to use reflection to look at these things?

Nothing's impossible I guess, but this kind of global datastructure reshaping is definitely far beyond the state of the art in Java JIT compilers.

Ah, got it. Yes, I think that claim about EA would be considered naive in retrospect.

IBM's Java jit compiler already has this "partial escape analysis". EA basically still never made much difference in real apps. It also fundamentally can't solve the problem you want it to solve, because what happens if your value objects do escape? I really think the compiler is the wrong tool for the job here.

Java has two fundamentally different kinds of types: objects and primitives. Value types are user-defined primitives. Seems pretty straightforward, from a language design perspective. I'm not sure why we're trying so hard to avoid this.

I'm not sure what benefit you're picturing from escape analysis, but EA is largely pointless because GCs have gotten so good that stack allocation of objects is really no better than heap allocation plus collection of short-lived objects.

I worked for years on escape analysis in IBM's Java JIT compiler. We struggled to find any actual programs that showed any benefit at all. The real benefits of escape analysis were second-order effects like eliminating monitor operations on non-escaping objects, or breaking apart objects and putting their fields into registers (especially autoboxed primitives). The actual stack allocation wasn't really any faster than heap allocation, and a GC operation in the nursery doesn't even look at dead objects.

EA is basically a microbenchmark-killer. For real software, it's not often worth the trouble.

These aren't breaking changes. This isn't even the first time they've added bytecodes. (Java 7 added invokedynamic.)

> - Purely functional programming - Impure function calls in pure functions are detected and raise errors at runtime.

Bzzz, wrong answer. This is too naive to be workable. It implies you need to drop out of your language in order to _build_ those functional components.

Google can:

https://www.google.ca/search?q=why%20is%20electricity%20call...