Jez Higgins

Freelance software generalist
software created
extended or repaired


Older posts are available in the archive or through tags.

Feed

Follow me on Twitter
My code on GitHub

Contact
About

Sunday 06 January 2019 The Forest Road Reader, No 2.13: Slithering Along

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.


Tagged blockchain

Wednesday 19 December 2018 The Forest Road Reader, No 2.12: Winter/Spring Tour 2019

The JezUK Winter/Spring Tour is Coming!


Tagged accu-conference, blockchain, archangel, and machine-learning

Saturday 01 December 2018 The Forest Road Reader, No 2.11: A Letter To Tharg

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.


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

Got posted with ours in Blenheim Road

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


Tagged 2000ad, and comics

Thursday 22 November 2018 The Forest Road Reader, No 2.10: Recreational Flattening

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.

  • Range.prototype.flat([depth]) flattens any iterables in the sequence, down to the depth given. The depth is optional and if omitted or is less that 1, it defaults to 1.

  • Range.prototype.flatMap(fn) applies fn to each item in the sequence, then flattens the result into a new sequence

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 -

function* flat(iterable, depth) {
  for (const item of iterable)
    if (non_string_iterable(item) && depth > 1)
      yield* flat(item, depth-1);
    else
      yield item;
} // 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.

function flat(depthArg = 1) {
  const O = toObject(this);
  const sourceLen = toLength(O.length);
  const A = arraySpeciesCreate(O, 0);
  A.length = flattenIntoArray(A, O, O, sourceLen, 0, depthArg);
  return A;
}

function flattenIntoArray (target, original, source, sourceLen, start, depth) {
  let targetIndex = start;
  let sourceIndex = 0;

  while (sourceIndex < sourceLen) {
    if (sourceIndex in source) {
      const element = source[sourceIndex];

      if (depth > 0 && isArray(element)) {
        targetIndex = flattenIntoArray(target, original, element, toLength(element.length), targetIndex, depth - 1) - 1;
      } else {
        target[targetIndex] = element;
      }
      targetIndex++;
    }
    sourceIndex++;
  }
  return targetIndex;
}

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 🙂


Tagged javascript, rillet, and code

Tuesday 13 November 2018 The Forest Road Reader, No 2.9 : Snakes Into Snake Oil

The ACCU Conference is one of the key events in my work year. It’s been an important part of my professional life for (counts on fingers, remembers when first child was born) nearly twenty years - for the things I’ve learned there, the conversations I’ve had, and the people I’ve met and who have become friends. I’ve had the privilege of giving sessions at the conference several times too - on countback I was surprised to discover it was eight times - and those occasions have been important for me too.

When this year’s Call for Papers opened, I didn’t know if I had anything to submit. This runs slightly counter to my conviction that everybody has something they can talk about, so I just left the knowledge that the Cfp was running to sit for a bit. One year, I didn’t even have an idea for a proposal until about ten minutes before the cutoff. Last year, something came to me during a Twitter conversation and Chris and I had nearly two hours to thrash out the details.

In truth, I did already have an idea but I was, frankly, extremely wary of having my name associated on the internet with the words blockchain and cryptocurrency. Eventually I resigned myself to it - I’m a big grown up boy, I can handle it - and submitted the following -

Snakes Into Snake Oil - What Blockchains Are And Why They’re Terrible

Since Bitcoin first rose to public awareness in the early 2010s,cryptocurrency enthusiasts have predicted a new world order. Central banks would fall away to be replaced with a consensus currency arising almost magically out of a worldwide network of independent computers, each transaction indelibly carved into the blockchain. The blockchain, immutable and permanent, stretching back in time to the genesis block, and growing, every few minutes, one block at a time, is, they say, the answer to all our economic ills.

And not just our economic ills: blockchains, perhaps running some kind of smart contract have been proposed as solutions for insurance markets, music distribution, land registries, voting, distributed file archiving, provenance of artworks and antiques, domain name resolution, human resources records, cross-border customs clearance, and more.

Snakes

In this session, we’ll have a look at what a blockchain is - how they’re implemented, and why they can indeed claim to be immutable. We’ll examine different consensus mechanisms, and how they allow new blocks to be formed without a central authority. That will lead into an overview of transaction mechanisms, and smart contracts. We might even write and a deploy a little smart contract of our own.

Into Snake Oil

Alongside establishing a baseline understanding of what blockchains are, we’ll also be looking at why they’re terrible.

The distributed nature of public blockchains purports to allow us to trust data produced by unknown and, indeed, unknowable third parties. This may not be the case, and if it isn’t you might never know. Blockchains are permanent and immutable, but is this feature or misfeature? While the ideas behind blockchains are all frightfully clever, is a blockchain basically a database with slow reads, really slow writes, and generally awful data throughput? Are they, in fact, ill-suited for many of the applications they are pitched to solve? And if you thought multi-threaded programming was hard, that’s just peanuts compared to smart contracts. Maybe we’ll also get a bit existential and consider whether a blockchain can die, and what happens if it does.

After all that doom and gloom we’ll try to end on a small positive note, with a brief look at a project which I believe is a good fit for a blockchain solution, and which might even make the world a slightly better place.


If the conference committee smile on me, I’ll be in Bristol in April to present it. If not, I’ll be in Bristol in April anyway.
The conference committee have, indeed, smiled upon me, and I’ll be presenting at the ACCU Conference 2019.


Tagged blockchain, and accu-conference
Older posts are available in the archive or through tags.


Jez Higgins

Freelance software generalist
software created
extended or repaired

Older posts are available in the archive or through tags.

Feed

Follow me on Twitter
My code on GitHub

Contact
About