When you look up the word “Language” in the dictionary, you’ll find a few variations of similar definitions. My trusty Google Dictionary extension in Chrome, offers up a first definition that is rather obvious, but nevertheless:
The method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way.
The second definition is more interesting because it allows me to make a point about programming languages. It goes like this:
The system of communication used by a particular community or country.
Look at that. Isn’t that beautiful? Let’s cut the country stuff, and shorten it to, “The system of communication used by a particular community”. Tell me that it’s not a spectacular definition of programming languages as well.
We can look at programming languages in two possible ways. They can be a means for us to instruct the computer, and incidentally communicate with fellow programmers, or they can allow us to communicate with other programmers in specific terms that are ultimately executable.
The first interpretation is technically more accurate. Or, more specifically, the worst kind of accurate.
I like to think of programming languages as languages because, outside of trivial programs, above all else they enable programmers to communicate with one another when it comes to resolving a problem or completing a particular task, while incidentally producing code that is also understood by computers via “translators” (e.g., compilers and interpreters).
There are plenty of benefits that can be derived from thinking about programming in terms of the second interpretation.
When you view programming in this light, you start considering the value of comments expressing the “why” and code expressing the “how”. Tests become a way to communicate to a fellow programmer  that a change to the codebase has violated a given requirement. Above all, writing idiomatic code becomes important.
Remember the Google Dictionary definition. “The system of communication of a particular community”. It is in fact the community, for better or for worse, that sets the guidelines and de facto style of a particular programming language.
Since we are operating in a system of communication, programming is a bit like driving: predictability is important. That’s why in the Ruby community we have the principle of least surprise  and in the Python community one finds the “There should be one – and preferably only one – obvious way to do it” mantra. 
When you think of programming languages as a series of conventions adopted by a community, and incidentally understood by the computer, you avoid recklessly monkey patching classes just because you can. You know that doing so leads to unexpected results and miscommunications with other programmers.
You also avoid features which are technically legal in the language, but rare and confusing to fellow experienced developers in that particular language. For an example of this, take a look a the Flip-Flop operator in Ruby (a reminiscence of its Perl heritage). Technically legal Ruby, even useful at times, however you shouldn’t use it because only a handful of fellow Rubyists will understand what you’re doing.  Worse yet, it will be hard to Google for an answer unless you are familiar with its name already.
When you’re first picking up a human language, you learn the meaning of common words. Then you use simple sentences that you memorize from books, people around you, songs, movies, and TV shows. Then you try to mimic the idioms you see used by mother tongue speakers. Often you won’t get them right at first, resulting in comical variations that are close, but not quite right, to those of native speakers.
When it comes to programming languages things really aren’t all that different. That’s why it’s critically important to read other people’s code, write code and receive feedback in code reviews, do peer programming, take part in open source contribution, and engage in other forms of social interaction pertaining to code. Doing so is immensely important when it comes to truly mastering a programming language.
Another consequence of this emphasis on communication among programmers through a common, precise, language whose style, conventions, and idioms are defined by the community is that you should choose your communities carefully. What are the community’s priorities? If there is no love for beautiful, clear, elegant, easy to understand code, tread very carefully. 
As someone who had to learn English as an adult, pretty much from scratch, I can tell you that I find many parallels between the experience of learning a new language and that of a new programming language.
Even if the two are not a perfect match – and seeing a programming language as a human language is an imperfect metaphor – I feel that thinking of it in these terms has allowed me to quickly acquire key skills in the programming languages that I needed or wanted to learn.
- At times, that other programmer is just your future self. ↑
- Well, at least that doesn’t surprise Ruby’s creator, Matz. ↑
import thisin your iPython shell. What, you’re not using iPython? Stop reading. Go install it. ↑
- Idiomatic code can be hard to understand by inexperienced programmers. And that’s fine, as long as reasonably experienced developers can parse its meaning. If nine out of ten programmers in your own community are unable to understand what you are doing, you are equivalent to someone who intentionally uses archaic words in conversation. You end up sounding grandiloquent for no good reason. ↑
Get more stuff like this
Subscribe to my mailing list to receive similar updates about programming.
Thank you for subscribing. Please check your email to confirm your subscription.
Something went wrong.