Although the blogging bug has not hit me lately, I have been thinking about bloggable topics. One interesting topic that I’m mulling around in my mind at the moment is the idea of emergence in programming language design. The catalyst for this focus was my recent research into the processes that board game designers use to create games.
Emergent strategies and idioms
First, one of my favorite designers Kory Heath, has extensive design notes for two of my favorite games Zendo 1 and Uptown. 2 In both design histories you’ll see themes that are very reminiscent of the same themes that pop up when talking to language designers about their creations.3 It’s eerie the parallels between the two worlds. I suppose this parallel explains my recent interest in the process of board/card/dice game design.4
A point that I particularly like espoused by Mr. Heath is that idea of emergent strategies. The idea of emergent strategy reminds me of programming language idioms. Idioms in languages come about for various reasons, but the best idioms emerge from the language itself. That is, the strongest idioms emerge during the use of the language and play on and highlight the language’s strengths5. It’s almost as if the language itself begs for a given idiom to arise. It’s a topic I want to ponder much more — in both game design6 and language design.
The second topic that I’ve been thinking about concerns quality. There is a very interesting discussion by Daniel Solis and (again) Kory Heath about differing approaches to achieving quality in their designs. There are many nuances in play during the discussion, but I hope that a representational summary is as follows:
- Heath: Hold back a design until it feels perfect
- Solis: Quality will emerge (there’s that word again) from quantity
You can watch the video below to regain some of the nuance, but I believe that summarizes the discussion fairly well.
This dichotomy really hits home for me, especially in the way that I view, and have viewed, open source software. That is, until about 13-months ago I believed that more was better in open-source and by releasing package after package I could contribute a body of work that was not only useful in isolation, but could point to an underlying philosophy of design. However, after spending nearly a year on a single system my viewpoint on the matter has changed completely. That is, my view now is that I want to hold off on code and designs until I feel like they tell a story by themselves.7 Practically speaking this means that I’ll be releasing far less software than I have in the past. I still want to contribute to open source of course, and am still active in Clojure, Datomic, and _.contrib; however for my own designs I want to strive for something more.
My son calls Zendo, the ultimate brain-game. ↩
The ultimate “Chillaxing” game. ↩
Another thing that I’m sure drives my along this trajectory is that I struggle tremendously on game design, so it’s really started firing neurons that I didn’t know that I had. ↩
Rather than patch a language flaw. ↩
As it turns out, I have decided not to release Zeder as open source. After spending a year working on it and its encompassing system, I’ve come to the realization that I can do better. That’s not to say that I’m disappointed in its design, indeed it could be useful to many people. Instead, to release Zeder would put me in a position where I would feel compelled to maintain it for the next X number of years, and that is something that I cannot bring myself to do with a system that I do not believe is perfect. ↩