kdmb@localhost:~> ssh kdmb@kdmb.ca
kdmb@kdmb.ca:~> ls thoughts/
kdmb@kdmb.ca:~> cat thoughts/languages.txt

---
title: languages.txt
createdAt: 2022-03-11
---

# I'm glad we call programming languages ... languages.

I'm glad because it's such an appropriate name for what we write every day as developers. Though, it's sometimes hard to remember the purposes languages are intended to serve. Why do we write software using programming languages all day long?

Language is the medium we use to communicate our intentions to one another while also outlining instructions for circuits and computers to run. Programming languages, that is. Interestingly, I think there's a lot to learn by expanding our understanding of programming languages by viewing them through the lens of "general" language.

So what can we learn about programming by using general language as a reference?

I think we can grow and improve as coders similarly to how we all improved at other language.

English was my first, and effectively only, language, but I've always been fascinated in how other languages communicate things humans have always shared - namely emotions.

As an example, my family got deeply invested in a japanese animated show about an old card game requiring quickly recognizing poetry. The game, aptly named 100 Poems by 100 Poets, requires the memorization of said hundred poems, 31 syllables each. I find a special beauty in this game because these poems written thousands of years ago by "ancient" humans attempt to communicate emotions so real and relatable even to this day.

In many ways, languages have always developed so humans could share these emotions that we all share, and coincidentally, we got better at communicating intention in general along the way. These are a few ways that we can improve as developers with this perspective in mind.

# Read code that other people have written

I remember my childhood babysitter gifting me the first two installments of the Harry Potter novels, but I didn't have a whole lot of exposure to British culture in my small farming/mining village, so when I first read of Ron's youngest sister Ginny, I didn't know how it was supposed to be pronounced. I then proceeded to talk to all of my classmates about Ginny (pronounced gift + mini), and was very quickly corrected.

Let's avoid the .gif debate, for now...

At this young age, I learned that the world was much, much bigger than my small farming/mining village. The novels' author assumed her audience would recognize this name and would pronounce it correctly, but I never had that context.

This is precisely the reason why I think we can grow as developers by reading others' code. Reading code written by others gives insights into what problems the authors tried to solve and how. More often than not, there's lessons to learn from the way other people solve logic problems, and those solutions may be something never conceived. Or pronounced.

# Learn multiple programming languages

You know how there's always a really complicated, long german word to express oddly specific feelings and circumstances? Naively, this makes me think that german has some really cool composing capabilities if a single word can be created for such specific circumstances. I think there's even more strength to be found in wielding multiple languages - evidenced by the many multilingual families around the world who can't last a single sentence without switching tongues. These families have more than one set of tools to precisely communicate their thoughts, and can use whichever tool is most effective for the task.

In learning multiple programming languages, there's more to respect in software development by understanding that each language has its strengths and weaknesses. Through these strengths and weaknesses, we can discover new ways to communicate and new strategies to solve problems. And maybe, we may pick up a favorite phrase or two.

# Include as much language as necessary to communicate

At the end of the day, computers are pretty stupid. they will do exactly, and I mean exactly, what they're instructed to do, so it's our responsibility as developers to get those instructions right. Inevitably, they'll never be 100% error-free.

If debugging is the process of removing bugs, programming must be the processing of adding bugs.

So what do we do when a regular language is incomplete in its communication of intent? We use more. As much as necessary to communicate what's necessary.

Our stupid computers don't need to understand intention, but it's critical that we accomplish this communication in the programs that we write. We should use whatever tools at our disposal (code comments, docblocks, READMEs, etc) to communicate our intention so the next person who reads the code - another person - can update the instructions if the computer changes how it receives them.

# So little time

So many languages to learn, so little time. But the more languages we learn, the better we'll be - programming or otherwise. Right now, elixir and lua have me kinda hooked, and I know there's even more exciting things for me to discover.

kdmb@kdmb.ca:~> _