Oliver Mooney

Array programming languages are so strange if you’re used to more traditional programming schools (procedural, object-oriented, or functional). Aaron Hsu is both a well-known professional APL programmer and a researcher into programming language education, and he helps cross the barrier with this great talk he co-presented with Dhaval Dalal and Morten Kromberg at 2018’s FnConf. It’s a long watch, almost 90 minutes, but the key bridging of concepts is presented in the first few minutes. I’ll try to reproduce it in text below, mainly for my own benefit.

Functional programming languages use abstract data types, first-class functions, and abstractions built on the composition of those parts, whereas array programming types use the array data type, a rich set of language primitives, and directness rather than abstraction (so you’ll resist abstraction in favour of direct composition of arrays and the rich set of array manipulation tools given to you).

It’s hard to over-emphasise what “rich” above means. Long-standing programmers might argue that Ruby has a rich standard library, for example, and it does compared to something like C. But APL and it’s ilk give you primitives as powerful as those what Numpy or Pandas give Python programmers for data manipulation, but as built-in primitives rather than the parallel world you often have to use Numpy/Pandas code in (i.e. you’ve to use the data types Numpy gives you, not Python’s native data structures).

The talk goes over it so much better than I’m trying to express here 😅. You can compare implementations between programming schools (using javascript, haskell, and scala on the one hand, and APL on the other) in the repo that accompanies the talk.

There are two main schools of javascript drawing APIs: those that let you paint shapes onto a canvas that are merged into a single image (normally targeting a web canvas or similar surface), and those that remember the individual shapes and let you interact with them after they’re drawn (normally targeting surfaces like SVG, or perhaps WebGL). Generally speaking they follow what the drawing surface they target supports, though in some cases you will find libraries that try to extend one target with the capabilities of the other.

The library I’ve probably used most extensively is Mike Bostock’s D3.js, the data visualisation lib that targets SVG, though it has support for canvas as well. It was a key component of the GetBulb startup I worked on for a few years. It’s a great library: mature, full-featured, and easily composable with other libraries (like React). It was developed while Mike worked as part of the NYTimes’s data visualisation team, so you’ve probably seen it in action on some of their excellent data visualisation reports.

Recently some users have complained that it’s been too oriented towards Observable, Mike Bostock’s live visualisation editor/platform hybrid. But the previous versions are still available, and the latter complaints smack of overly self-interested users with their own expectations but no desire to pitch in on a fork that scratches their particular itch.

I’ve also used Processing, mainly via its Clojure wrapper, Quil. It’s also very full-featured and mature. It has an online analogue, p5.js, that you can use instead of the original java-hosted version, that seems to largely have parity with the original. I wrapped some processing examples from the Generative Design book using Quil a few years ago. There’s a newer version of the Generative Design book for p5.js which I’ve still to dig into but looks every bit as good as the first. The companion machine learning library, ml5, is also worth checking out.

Other libraries that I’ve used, though not as extensively as Processing or D3 include:

• thi.ng is extraordinary. Karsten Schmidt is a phenomenally productive coder and visualisation artist. He’s written far more lines of Clojure & Clojurescript than I could ever hope too as part of his data visualisation libraries - and then for good measure ported them all to Typescript while still expanding their functionality. They’re a bit harder to get into due to their breadth and the docs assuming a higher level of competence than a typical introductory guide. But the scope and quality of these libraries is breath-taking. A magnum opus. I attended one of his workshops in London about 5 years ago and I recommend them whole-heartedly to anyone.
• Pts, which I really like, largely because of its rational attempt to organise its API around “abstractions of Space, Form, and Point”. Space is equivalent to a drawing surface, Form to a pen or other means of making marks, and Point to the data representation of your visual idea. The documentation is excellent too. William Ngan, it’s author, has a good Medium blog as well.
• Two, a “two-dimensional drawing api geared towards modern web browsers”. It can target any of SVG, Canvas or WebGL, and comes with a scenegraph and animation loop. I need to trial it properly. The name is either a reference to three.js or a nice case of simultaneous invention by two separate authors.
• Three, a low-complexity, lightweight 3D engine. It usually targets WebGL but it can also work with Canvas or SVG. It’s another large piece of code to navigate but their fundamentals series gets you up and running quickly. Courtesy of Mr Doob - check out his homepage, currently it’s a fun multi-user sketch pad.
• Skija which I’ve mentioned in passing before - looks like a great target for lower-level drawing access than what Processing offers. Also focused on the JVM, built on the Skia, the cross-platform 2D drawing library. Unlike most of the others this one can’t target web-hosted drawing surfaces, though maybe you could get part of the way there with Emscripten, Skia & the Canvas API?

That’s not even a complete list 😅 but this is turning into quite the library zoo. There’s some tantalising examples of generative design using J, the array programming language, which I’ve not had time to dig into too closely, and I’ve not even mentioned where I first started getting into this kind of stuff - back when I was a teenager and one half of the demoscene Mesmery team on the 8 bit Commodore 64. Hilariously that might’ve been when I got the most stuff done - there wasn’t quite the paralysis of choice the above list hints at…

I’ve been fascinated by languages like APL, J and BQN, and the succint expression of dense computation they allow.

Sure, I’ve always been fascinated by programming languages. But one constant bugbear has been just how much code it takes to express any significant computation. Array languages offer a set of primitives that operate and compose on much richer data sets (n-dimensional arrays) than the default in other languages, at the cost of looking quite… dissimilar to what programmers normally expect to see, code-wise.

I genuinely love that APL stands for “A Programming Language”. Iverson’s Notation as a Tool of Thought is eye-opening in its promise, no less so today then when it was written. BQN seems to be the best-available modern open-source implementation, but its documentation is still lacking, especially for programmers new to APL-derived languages. So I thought I’d start with J, especially as it doesn’t need the symbol set APL requires, and it has some interesting means of combining operators (hooks and forks) that looked fun to play with too. There’s also ngn/k, an open-source implementation of K that has an online playground if you just want to jump in and be bewildered.

That means that my total experience writing APL-style code to date amounts to some tentative J written while following their tutorial. I’ll publish some notes on the experience when I’ve completed it. It’s been fun so far, but not without its own warts & cruft. Host OS interactions look, well, absurd. But I’m still the neophyte here, so it’s their party.

I’m simultaneously trying to get my fingers used to two keyboards: the Keyboardio Model 01, and the OLKB Preonic.

There are probably cheaper ways of introducing hordes of errant keypresses into your daily work.

They’re interesting keyboards. Perhaps the most striking thing they both have in common is how they reduce the space bar to a normal sized key, allowing your thumb access to a lot more keys.

So, on the current preonic keymap, my thumbs are responsible for the space, delete, enter, shift, command and mode-shift keys. It makes for a compact keyboard, but… it’s probably too much. I thought it’d be a good idea to combine my shift and enter keys, for example (hold down the key and press another key for shift behaviour; just tap the key for enter). I also have that key right beside my space key. Now what happens is that I press enter all the time instead of space. In apps like Slack, where enter starts a new message, that leads to very disjointed and confusing conversations. With your boss. Who might be wondering if you’re drunk.

However, the neat thing about both keyboards is how you can re-program them to behave almost however you’d like. I think I’m going to break the shift/enter key combo, instead taking a leaf from the default Model 01 layout and combing the enter and space keys instead (tap for space, mode + tap for enter). I’ll post back here after some experience with that.

Other notes:

• the ortholinear layout (unlike the staggered keys layout on traditional keyboards) took me no time at all to adjust to. I touch type and don’t even notice the difference.
• I’ve yet to find a good use for the latching key-switches I added (tap ‘em once to lock them down, tap again to unlock) but I’m still thinking about that
• typing on heavy clicky mechanical switches (Kailh Box Navy type) is very pleasant but definitely more tiring, and possibly slower too, compared to shallow travel keyboards that bottom out near immediately
• My keycap set hasn’t enough accent keys, and using words for keys like “alt” means you can’t turn them 180º for easier typing by thumb. It’s the MDA-profile Big Bang 2.0 set - gorgeous otherwise. Despite the mis-sized “8” keycap legend.
• The current QMK instructions for updating your keyboard layout are right, but not the easiest way to do it - instead, just use the online configuration tool; it’ll compile your firmware for you too!

I found this book so difficult to read. I literally squirm at the slightest hint of anybody doing something socially embarrassing or something self-interested to the point of harming other people, and this book is FULL of that, full of otherwise excellent people doing appalling things, the narrator more than anyone - but the book is excellent. I recommend it unreservedly. The writing is excellent, both in how it grips you through the most difficult scenes and how it describes the variety of the sea in all weathers, something that resonated as I grew up and live by the coast.

This must seem so vague so far but I don’t want to spoil anything. It is a very plot-heavy book, though the story is lightly told, entirely from the perspective of the narrator, a retired theatre director in his sixties who is a walking definition of an unreliable narrator. He’s cruel, obtuse and wrong but remains endearing in his own peculiar way.

It’s a love story too, or a story about a concept of love vs the perception of another couple’s practice of love, and how that can twist your perspective and permit you to think whatever you most need to think…

It’s so sad in parts, but also so oddly content at the end, post-action, when Murdoch blessedly continues the story so you don’t have to say goodbye to the characters sooner than you’d like.

It’s a very well-regarded book: it won the Booker in 1978, when it was first published, and has been adapted into radio plays twice by the BBC. The 2019 re-issue comes with an introduction, though it’s one of those introductions far better read after finishing the main book than before. I far prefer the 2019 edition to the 1978 one, which featured a portion of Hokusai’s The Great Wave off Kanagawa. That’s a great piece of art but comes with a lot of associations that don’t quite fit the book (presumably it wasn’t quite as widely known in 1978).

I might update this when I’ve not had three glasses of wine. But I had to pen it down - please, give The Sea, The Sea a try.

The Pimoroni Keybow is a great little 12-key macro-pad kit. I got mine with Kailh Gold clicky keys too, as I wanted to see what those were like - they’re nice, light to press but with a definite click. They come with a DSA keycap profile too. I’m currently fascinated by keycap profiles and I really want to build a keyboard with high-quality SA keycaps and heavy clicky keys to emulate the look and feel (if not noise!) of the beam-spring behemoths of yore - but that’s a topic for another day.

Back to the Keybow kit. You can make it without any tools and it gives you a RaspberryPi-powered macropad - a small but fully-fledged computer that you can configure to your heart’s content, if you’re comfortable digging into configuration files and maybe some light programming.

Even if you’re not, you can still do some fun things! Each key has an RGB LED under it, and Pimoroni have set it up so that you can animate the LEDs just using an image file in PNG format. Any popular image-editing tool can create these. The image file should be 12 pixels wide, one for each LED, and you can animate it by having additional rows. One row is a single step in the animation (so just have a single row for a static set of lights permanently on).

It’s not clear from the Keybow’s documentation which column in the image corresponds to which key. It doesn’t match how the keys are numbered in the programming sections. After some experimentation, if you orient the keybow so that the USB cable is coming out of the top, column one of the image is on the bottom left, the bottom right is column four in the image, the top left is column nine, and the top right is column twelve. The two keys in the middle row are columns five and six of the image, and so on.

With that worked out, I wanted to make a snow animation, matching the orientation of the keys (i.e. with the narrow side facing up). The image file I made is here. It’s not quite as random/unpredictable as I’d like, but a few more animation cycles would help - pull requests welcome :)