Q1 2022Sketching, Modeling and Programming


it's horrific to look at what's happening in Ukraine. It's horrific to imagine what war is like, and we are still in shock that it's happening right next to us, in our neighborhood. I've heard good things about Razom and that's where we've been donating, and I encourage everyone who can, to do the same.

We're incredibly lucky to be able to move over to nerdy computer stuff in the next paragraph.

I don't have that much to share on the side-projects side this time. In January, I built a simple temperature and humidity Wi-Fi sensor for our basement, just to see if the temperatures there don't go too low, and if humidity doesn't ramp up too high. Do I need a better dehumidifier? Doesn't seem like it right now. The project is nothing exciting, just an ESP32, a sensor I had lying around, piped through MQTT to my home-server Raspberry Pi which runs a bunch of automations using Node-RED, including logging the collected data into an sqlite database.

My talk from LIVE2021, about one of our recent Ink&Switch projects, is finally out. You can watch it below, it's only 10 minutes, and then there's a bit of Q&A:

We're still working on the essay — I'll let you all know when it's out for sure! In the meantime, I wanted to mention a couple of interesting learnings from this project.

Sketchiness of tools. Importantly, this is not a matter of leaving hand-drawn marks, though having them helps. This point is more about working with half-formed ideas, and a big part of it is that the Fidelity of The Tool Should be Proportional to The Maturity of The Idea. Basically, computers are great at enforcing rules (Computer Science Positivism), but tools in the earliest stages of thinking, should provide the exact opposite — freedom to poke at the problem from multiple ends, freedom to leave unfinished pieces lying around in your Peripheral Vision, freedom to be messy.

Programming with live, embodied objects. There's a distinctive difference in how it feels to program a system where everything is represented by a visible, embodied, and responsive representations — instead of one where you refer to things by abstract names, and imagine what will happen when the program runs (by playing Simulator in your head). Importantly, this is not what most of "Visual Programming" (that I know of) tries to solve — these projects are usually about visualizing the structure of the program which is not as useful as Visualizing the Domain of the Problem.

Spatial messages as a way to communicate between embodied objects. The way that most programming was done in Inkbase was by sketching out some shapes on the canvas, and making them react to each other, by asking "what's to the right of me?", "is there anything inside that region?", etc. For example, in the demo below, the pink "wires" are not what makes the logic gates talk to each other — they are there just for user feedback. Instead, the logic gates query for what's to the left (inputs), and send the calculated values to everything that's to the right:

Mixing reactive data-flow and imperative mutations in the same environment. Our objects were programmed using ad-hoc lisp implementation, with a small library for push-based reactivity. The basic API was as follows:

  • Reactive chains were set up with ?.
  • Imperatively updating values was done with !.
  • You could also update a value by piping it through a lambda with ..

Here's an example to make it bit more concrete:

(! value 5)
;; ↑ cell named "value" holds `5`

(! double-value (* (? value) 2))
;; ↑ cell "double-value" holds `10`,
;; and will update as "value" updates

(! logger (log (? double-value)))
;; ↑ `10` logged out to console

(! value 7)
;; ↑ `14` logged out to console

(! ticker (interval 1000 #(. value inc)))
;; ↑ `16`, `18`, `20`... logged out every second

The reality was a bit more complicated, but you hopefully get the idea from this short gist. I think this could be a pretty useful part of the project to turn into a clojure library, but I'd be surprised if there wasn't anything that does this already. I haven't dug around yet, so send me a message if you know of any!

Overall, the project taught me a ton, and charted a direction for a next one, that is also finished, and also, as of yet, unpublished. We managed to push the essay out a couple of days ago after all! The project is called Crosscut, and you can read about it here. The essay is much more comprehensive than anything I would write on my own, and I encourage you to check it out — and do so on a desktop browser as we have a bunch of live demos in there.

Crosscut running on a Tablet

Books I enjoyed recently:

  • How Buildings Learn: What Happens After They're Built — I really enjoyed the "low road" / "high road" framing for how buildings are used, and adapted, over time; architecture always seemed to me like something "set in stone", but Brand argues that it is far from that
  • Visual Thinking — felt a bit dated and dense, but makes a great argument on how all thinking is based in perception
  • The Story of Art — great overview of how art evolved from the earliest cave paintings to modernity
  • I went on a little (mostly graphical) design thread:
    • Designing Programmes — a cult classic in some circles, somehow didn't make that much of an impact on me, maybe because of my humble "creative coding" background where making programs to make designs is the bread-and-butter of the field
    • Interaction of Color
    • Thinking With Type — this one was excellent, I loved how it plays with the "form", and reminded me a bit of "Understanding Comics" — using typefaces to talk about type, in a similar way as using comic strips to talk about comics
    • A *New* Program for Graphic Design — didn't go into as many details as I wished it would but still a great overview of the field
    • Speculative Everything

On the web:

That's it for this update, as always feel free to reach out if anything in here is interesting.

See you in a couple of months!

Subscribe to my newsletter to receive quarterly updates.