Many years ago, I used the Enlightenment window manager on my Linux desktop. I was not a programmer then1, but I thought Enlightenment was really cool, and I spent hours reading through its documentation and wishing I knew how to contribute to its codebase. One piece of code was responsible for dealing with X11’s various quirks to create an empty window, and its introductory description was:
Just give me a window, dammit!
I can’t find any reference to this phrase on the web today, so there’s a good chance I’m misremembering. Still, various permutations of the phrase stick in my head today. For instance, I often find myself thinking:
Just let me write code, dammit!
There has been a push towards declarative domain-specific languages away from Turing-complete programs, but whenever I spend serious time with those declarative DSLs I find myself wishing for more expressiveness. Just let me write code, dammit! Three examples:
-
Ansible comes to mind first. I got so frustrated with the rigidity (and verbosity!) of Ansible’s YAML documents that I wrote progfiguration, which eschews DSLs for regular programs.
-
Terraform suffers from DSL rigidity much more than Ansible does. It has no escape hatches like Ansible’s plugins or command actions; if the limited
for_eachconstruct doesn’t meet your needs, you have to generate your Terraform from a more expressive language. The Cloud Development Kit which exists to allow writing Terraform in Turing-complete languages makes me question the entire project. Terraform wraps the cloud platform REST APIs in its own DSL, but then we wrap the Terraform DSL in a more expressive SDK – why do we need Terraform in there? -
Finally, I often hit this with Hugo when working on this site. Hugo has no construct for real programmability; I abuse partial templates when I need something like a classical function that takes arguments and returns values. I just read Alex Kladov’s Data Oriented Blogging, where he says “I am somewhat skeptical of static site generators implemented in languages without eval”. It’s tempting to try to roll my own JavaScript SSG, as he did.
I suppose Alex’s version is more professional. Here is a bit more context:
If you pick an SSG, pay close attention to its extensibility mechanism, you want to avoid situations where you know how to do something “by hand”, but the SSG is not flexible enough to express that. Flexible SSG typically have some way to inject user code in their processing, for free-form customization. For this reason, I am somewhat skeptical of static site generators implemented in languages without eval, such as Go and Rust. They might be excellent as long as they fulfill your needs exactly. However, should you need something more custom than what’s available out of the box, you might find yourself unable to implement that. This creates discontinuity in complexity.
Alex Kladov, Data Oriented Blogging
But my version is punchier. Just let me write code, dammit!
-
That old version of me would be very proud of the 2023 version, who has become a competent and prolific programmer, though I think somewhat disappointed that I still haven’t contributed to any desktop Linux software projects. ↩︎