I’ve started doing some proper background reading and research for my upcoming talk at the ACCU Conference 2019. This is something of novelty. All my previous talks have been on a subject I’m comfortably familiar with, either because it’s quite a tightly defined topic or because I was speaking from my own experience. Consequently, I just needed a bit of firming up around the edges to fill things out.

This time though, my topic is rather broader and my knowledge rather more incomplete. Given the title I chose, Snakes Into Snake Oil - What Blockchains Are And Why They’re Terrible, (described by a friend as a bit clickbait-y) I’m clearly flagging my opinion. Disappointingly, nothing, absolutely nothing, I’ve read so far has given me any reason to reassess that opinion.

In the abstract for my presentation on the ARCHANGEL project, I wrote it’s about the only blockchain application you’ll hear of that doesn’t immediately make you feel dirty. I meant it as a joke but it’s increasingly turning out to be true.

As a single small example, browse around State of the ÐApps, a website that lets you discover the possibilities of the Ethereum, EOS, POA, and Steem blockchains with the definitive registry of ÐApp projects. It groups the various apps it lists into various categories. The three largest categories are games, gambling, and "high risk". The bulk of the games are variants on collectable card games. The majority of the gambling apps look to be some form of lottery. Finally, "high risk" appears to be a euphemism for "scam". Absolutely world changing stuff.

In the categories the blockchain tubthumpers have told are ripe for disruption, insurance say or energy markets, there are some apps listed. They all, however, seem to be entirely notional. They don’t exist - either they have no code, or in the unlikely event they have code then they have no users.

From top to bottom, it’s a catalogue of utter crap.

Right now, I feel like ninety slides all saying Blockchains are a pile of shit (each slide containing the SHA-256 hash of the previous slide, obviously) would be as informative and useful as whatever it is I do end up writing.

The JezUK Winter/Spring Tour is Coming!

A couple of weeks ago, I wrote a letter to Tharg. Sadly, The Mighty One has not deemed it worthy to print in his illustrious organ so I humbly present it here. The Mighty One smiled upon me, and it was Letter of the Week in Prog 2114, cover dated 16 January 2019.

Dear Mighty One,

As I stooped to gather Prog 2109 from my doormat last Saturday morning, I noticed it wasn’t contained in its usual Thrill-restraining plastic wrap. It was accompanied by its address label though, upon which I saw the handwritten note

I can only assume that two copies had, perhaps due to the high level of thrills therein, adhered to each other so strongly that the best efforts of the Post Office could not prise them apart, leading to my copy being inadvertently delivered to the wrong address.

I would beg Tharg give me the opportunity to publicly salute and thank my unknown fellow Squaxx who, on discovering this error, immediately hot-footed it to my house - not a huge distance, but not exactly next door - to deliver the misplaced prog before I had even noticed its absence. I would ask any graphic novel I might receive for printing this letter to instead be forwarded to them, my mysterious ally on Blenheim Road in Moseley, Birmingham.

Florix Grabundae,
Jez Higgins

Spent a few minutes an evening or so back adding another couple of methods to Rillet, my JavaScript streams library. Sometimes it’s nice just to nurk around with code for no particular purpose.

The two new methods are flat and flatMap, and they have the same behaviour as the flatMap and flat Array methods currently going through the JavaScript standardisation process. The proposal’s currently at stage 3, which means they’re almost certain to go into the ES2019 standard.

Rillet already had flatten() which is, essentially, flat(∞), which is good because that’s not a method call you can actually make. flatMap(fn) is equivalent to map(fn).flat(1), but in this modern age clearer and, not uncoincidentally, a little more efficient in both time and space too.

One of the pleasing aspects of working on this code is that the implementations of these two methods are really straightforward. Here’s flat -

Because we’re dealing with iterables, and so are lazily evaluating and only have to deal with the particular item at hand, we can lean on the magic of generators and yield and yield* to handle the book keeping. All we need to worry about is answering the does this one thing need flattening question.

Compare this with implementation for the proposed Array.prototype.flat. It has to exhaustively work through the array, examining every element within it, possibly flattening each one, examining elements within those, and so on and so on, until we’ve hit the desired depth limit. Here’s an (incomplete) example, lightly adapted from the core.js polyfill package.

This isn’t in anyway to suggest that the core.js code is at all bad. It isn’t. It’s simply the case that flat for Arrays is going to be wordier that for streams. The heart of our two implementations is essentially the same - if this thing needs flattening then recurse, otherwise use it - which we can express as a single if/else. All the rest of the Array version, ie about 75% of it, is managing state that yield manages for us in the Rillet generator. Sequences are great, I’ve been saying so for years 🙂