/tinyletter

The Programs of the Week of My Birthday

This Week’s Program: Aug 22 - Aug 26

This week, I celebrated my birthday. Another year living under the ongoing threat of chemtrails. jk.

I’m not emailing this from my FreeBSD server. I’ll let you know when that happens.

This week was all about getting familiar with how to do things in Elm. I spent the bulk of my work pouring over documentation and Elm package source code.

93e0da3e2b895d4367352c50e3274e3c0eedd68c

This is the SVG clock example right from the Elm Introduction. Since I first encountered Elm, the language has evolved and the terminology I had originally associated with the language has been refined. As I worked through this example, I couldn’t help but think, “what is happening under the hood?” Particularly as I work to understand Elm’s Effects Managers — the things that are actually driving the Sub and Cmd types down to the host. Elm is a language that is actively being developed, so a lot of these concepts haven’t quite been pinned down, and documentation is catching up.

18bf5bef193c319a9476e528886a85b504f9200f

There is an explosion of tools in the JavaScript build tool space: Grunt, Gulp, Broccoli, Brunch… I just like that old standby Make. You tell a Makefile what you want to make, how to make it, and what you need to make it, in a quirky, terse syntax, and it does that. It’s been doing this reasonably well since the 1970’s. Comfort in working with a Makefile separates the 10x developers from the 10x chumps. It’s one of those tools, like AWK, that you won’t regret having learned. Sure maybe it’s not for every thing, but it’ll do darn well for most things.

Anyway, I start a Makefile for quickly building this project to JS without having to be super specific with elm make every time.

Most Elm projects reach for the really nice elm reactor, but I always feel like it’s much easier to start in rapid loops on the terminal. The elm repl does a decent job, but it seems to be missing a few things that would make it a great experimentation target. I want my Elm program to spit stuff out to the command line…

It turns out that’s not something that Elm really does naturally.

eb46b177580c10b03ec707b37d08d01475c035c6

Elm is less of a general purpose programming language and more of a robust DSL for making web apps. The interop story with JavaScript is prescriptive, and puts its burden on the implementor. You set up your Elm application to expose certain functions with port to act as a “hole in the side of your Elm program where you can plug stuff in.” With either Sub or Cmd you can either subscribe to Elm messages from JavaScript, or send JavaScript messages into Elm. There’s really not much else you can do. If you want tighter integration with the host environment that’s just not very well documented, and is kind of actively discouraged by Elm’s community. The idea is that you don’t want to so readily escape Elm’s purity, but there’s still a lot of missing functionality in Elm’s packages. All Elm main functions must have a type of Program, but so far that type can only be constructed through Elm’s Html.App.

For my Elm app to interact with a command line process is going to be tricky. Luckily, I know how to rock a rhyme that’s right on time.

8f8e20bd9b970c75e626ae953cf3b230d724cc6c

Here’s a little node app that pulls in the compiled Elm project. It sets up the Elm application as a worker, which is a way of initializing the Elm Program without a DOM tree. It subscribes to the tick function from Elm and outputs a clock, centered in the terminal window. The clock is driven by Elm.

Next week I hope to write some Necromunda-specific types and models for the game, as I read through a big selection of texts:

Until then,
🎂 Mark