On the beauty of programming languages

Lately I’ve been slowly reading “Graffiti Kings: New York Transit Art of the 1970s” by Jack Stewart. I’m reading it because I’ve always been a fan of pop art, and as I’ve started to understand more about its context during its period, I also want to understand graffiti and street art better.

For me this is personally linked to the demo- and introscene, which, as far as I’m concerned is art, and I think its context links pretty well into current digital art and scarcity which is now possible with blockchains, explored by, among others, async art and SuperRare.

As I’ve dived into and built a better understanding of this type of art, you begin noticing the details that make it unique. You begin developing a vocabulary for describing it, and you begin to understanding what makes it good or bad, what distinguishes it and its style.

It is like this with programming languages as well. Having been a developer for more or less 20 years, you begin noticing these details. What, to the untrained eye, is just some complex text in “notepad,” becomes beautiful patterns.

Programming is often described as both an art form and a science.

There’s certainly a science to the best practice usage of patterns, which help developers become more efficient and less error prone, by reconciling what they should be doing, under certain conditions.

But this is not the patterns I mention. Instead it is the beauty of a structure more generic and succinct. For me, a few years back, after getting a bit lost in the industrial complex of your usual language selection, I was revitalized by Clojure. As a lisp, it was different, something new, and something which allowed me to rediscover why I originally fell in love with programming. It made me a better developer, because it moved me away from the mass produced “art” of your standard ALGOL, and towards a deeper understanding.

Having spend some time with Clojure, I feel I can now look back and fundamentally appreciate its beauty. I can see the art in its patterns, I can feel the quality of its meaning. I’ve been enlightened. It doesn’t mean I’m capable of creating a perfectly minimal and generalized lisp structure, but maybe I’m able to spot one when I see it.

With this chance to appreciate this level of beauty within a few lines of text, maybe it also makes me an overall better critic in the more mainstream domain of programming languages.

For example, I’ve fairly recently become a big fan of Kotlin, simply because it allows me to often describe with similar levels of succinctness, what I want to code, while it at the same time is an extremely practical and forgiving language. It’s a good approximation for both worlds. It’s moving us forward, giving us better tools.

That is a form of beauty which is slightly different than the lisp, but still high quality programming language art as far as I’m concerned. It gives me the same fundamental good feeling about what we’re trying to accomplish.

Sure, it doesn’t have the homoiconicity or the immutable persistent data structures by default. But how could it have those things while being practical?

If we want to bring the general understanding of programming languages, from the point of view of it as an art form, forward, we need to make it immediately practical. It can’t be just another hack hobby project, but something with underlying knowledge guiding its design and intent.

It needs to bring this beauty while at the same time solve those everyday mundane programming tasks served up by the industrial complex of generic software development. Only then can the general understanding of programming as an art form gain a broader platform.