🌱 Seedling noteworthy

A great blog post on the art of programming languages and the culture of programming

posted on in: Coding and Software Development and tech.
~620 words, about a 4 min read.

I really enjoy how this author conceptualizes programming language, as a creative tool. This is very similar to how I think about it, with the idea that while there are specific things we want to do, the decisions about how to accomplish them are fundamentally creative ones and they alter the final outcome in ways that may or may not be perceptible to the end user.

I see a great deal of work on programming languages as a struggle—often in vain—by those of us who love programming so much that we wish to free it of its unfortunate imperfections. We strive to remove the impediments and obstacles we face when translating the beautiful, platonic programs we hold in our heads into the comparatively cold, alien language of silicon calculating machines. There is a widespread mythology that programming languages are primarily abstractions over machine code, but this perspective has been misguided for almost as long as programming languages have existed. Programming languages are instruments of thought, frameworks for precisely specifying an executable idea, and they are designed almost entirely for humans, with computers often providing little more than a loose set of inconvenient restrictions.

I think that the author is perhaps a little too gentle to this inherent conservatism in the programming and software engineering fields. This trend presents many problems, the ones that emerge inside the software engineering realm is the least of them though. The confusion between risk mitigation and rational decision-making is one that really popped out at me.

It should come as no surprise that programming language design is largely a social problem. Choice of programming language tends to be driven by strong network effects, and programmers tend to prefer languages that resemble what they already know. Programmers’ general lack of curiosity and outright hostility to learning new things has always been a personal frustration of mine, but I ultimately do understand much of where it comes from: as engineers, an overwhelming part of our job description is managing risk. Exotic technology choices are risky, and it is a responsible impulse to be wary of them.

Because yeah, though I don't think the author connects the two tendencies I think that the specific approach of programmers in the above leads to the note he makes below:

I also think it would be enormously refreshing if programmers did not nearly universally speak with an expert’s confidence on subjects they have only passingly encountered.

I do really see how this framework and the analysis within this post definitely come from what he notes as a sometimes unique frame:

I like writing software. It is strange how radical a statement that sometimes feels. So many programmers seem to practically despise what they do for a living, at least as you’d hear them describe it. I have never really been able to empathize with that mindset. I find programming fun, and I derive a unique joy from writing code that decisively solves the problem at hand. It doesn’t have to be a particularly interesting problem, and the solution doesn’t even have to require much more than snapping blocks together, but as long as I can take some pride and satisfaction in the craftsmanship and end result, I am usually pretty happy.

I too like writing software, I enjoy it! I wish more people saw where the joy in the software building process comes from and approach it as a creative practice that brings joy more.

I do believe very earnestly that the functional programming and programming languages communities would benefit enormously from more demographic diversity. Even compared to software engineering as a whole, the gender ratio is, frankly, almost unbelievably grim.



— Via Alexis King, A break from programming languages
Page History

This page was first added to the repository on May 30, 2025 in commit bafa160b. View the source on GitHub.