Language Tower

Published:

Over time, I’m evolving this idea of a Language Tower. I think the name came to me from Scheme’s numeric tower—not that there’s any real correlation between the two. It’s just a name—maybe not a very good one, but it’s working for me. More importantly, the idea is an opinionated, hierarchical categorization (maybe sieve?) of programming languages that helps me choose the appropriate tool for a task. I make no claim that the categorization is exhaustive or fairly representative of the landscape of programming languages—it’s a reflection of the kind of tasks that I use programming languages for right now. Without further ado…

  1. Domain Specific Languages (e.g., HTML, CSS, SQL)
  2. Systems Programming Language (C, Assembly)
  3. Shell Language (YSH)
  4. General Purpose Language (Go)

The specific languages listed are the “opinionated” part. The tower is like a questionnaire, and these are my answers. It helps me focus on the problem and avoid analysis paralysis around choosing a tool. I know these tools—they work for these jobs. The corresponding questions are something like:

  1. Does an obvious, de facto DSL exist for this problem? Use it.
  2. Is manual memory management required? Is efficiency paramount? Use a systems language.
  3. Can the problem be solved by gluing together existing tools? Use a shell language.
  4. None of those? Use a general purpose language.

It’s an intentionally spartan list. I think of it as a gigging musician’s philosophy of programming languages.

In years long fallen into shadow, I was a professional guitarist, and was forced to come to grips with the reality of traveling light. For that reason, I’m not a gear head. Every instrument I own had to earn its place—they’re workhorses. I have:

*This is the one minor exception. It’s sentimental—my first decent guitar. While not strictly necessary, I found a use for it! I had the tailpiece set flush (for multi-string bends—think pedal steel) and used it for country gigs.

For the non-guitarist, the idea is that each instrument serves a very specific purpose with little to no duplication or overlap. My guitars were selected (let’s be real… retained) to cover the largest set of uses with the smallest set of instruments.

As I’ve gained experience, I’ve adopted a similar disposition towards languages. Time has taught me the limits of my working memory; I want to make the most of what I have. Despite a vigorous enthusiam for learning languages in earlier years, it’s turned out to be more valuable for me to be a domain generalist and language specialist.

On My Language Choices

I don’t think my particular languages of choice are the salient characteristic of this idea, but it does help me to record and think about the reasons for their inclusion over time.

  1. No comment on DSLs. For me, they’re least interesting of the bunch. You need them when you need them, and you don’t have much choice.

  2. C. Among the languages on my list, C has historically had the most precarious tenure. I’m always tepidly searching for something to unseat it (e.g., Rust, Zig, Odin, etc.), but I think it’s C for me. It’s ubiquitous. On the whole, it’s relatively slim and simple. I (mostly) understand why the complex parts are there and why they’re murky (it’s about flexibility and portability). I know it’s kind of rough and dangerous, but it’s also an old friend.

  3. YSH. I should confess upfront that I love shell languages. I think they’re absolutely a super power, and I suspect that I reach for a shell language far more often than most developers. YSH is the most unconventional pick on the list, but also one of my most enthusiastic. Andy Chu’s Oils project is a valiant effort to upset the status quo in shell programming, and he’s been a tremendous shepherd of the project and community. Of the recent crop of alternative shells, I think Oils is best positioned to succeed long-term—it’s also the most “shell-like”. I’m biased here. I’ve been an occasional contributor and fairly active member of the Zulip forum.

    I’m primarily interested in the YSH language. It’s still maturing, but is already miles ahead of Bourne shell in usability, readability, and language design. I’ve found and reported a few bugs (usually with quick turnaround), but over the past year, YSH has been remarkably stable for me, and I’ve used it a lot. Killer features: proper hash maps and fixes shell’s error handling.

  4. Go. This should be an unsurprising, boring pick. Though lately I seem to hear increasingly violent grumbling about how grug-brained Go is. It works for me, and that has surpised me at times. I came to Go after having been steeped in OCaml for several years, and Go eschews a lot of wisdom from that stream of language design that has lately become much-loved (maybe from folks encountering those ideas in Rust). At first, the lack of generics seemed like a non-starter, but even since they landed, I can only think of one(?) case where I’ve needed them. Maybe Go has warped my mind, and I like it?

    Practically and philosophically, Go has grown to be a perfect fit for me (or I’ve grown toward it?). I think it’s worth reading about the design and creation of the language—that’s where it began to click in my mind. Rob Pike, in particular, has risen considerably in my esteem for his taste, restraint, and vision. Killer features: it’s usually fast enough, it compiles quickly, the tooling is excellent, the standard libary is excellent, CSP is the way, and it’s minimal and opinionated.