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:
- Browsing https://github.com/isRuslan/awesome-elm
- Elm Tutorial
- Pestering the Elm Slack
- Elm Effect Managers
- Robert Nystrom’s Game Programming Patterns
- And a whole lot of videos to watch
Until then,
🎂 Mark