I have come to a realization today. Actually it has been gradually dawning on me but it came clearly into focus today. I consider myself somewhat of a connoisseur of programming languages. It started when I was first learning about computers. I read every issue of Byte magazine. But my favorite issue of Byte was always the August issue.
Every August Byte featured a different computer language. This is how I first learned about Lisp, Smalltalk, APL, Forth, C, and several others. The language issue always featured several articles that illustrated the breadth of each language and described the innovations that it brought to the table. Byte magazine eventually faded into the sunset but my hunger for new languages only grew.
I was on a quest to find the most eloquent computing language so that I could write beautiful programs. On my journey I learned a lot about design, organization, communication, methodologies, and process. I also learned to program. I slowly began to realize that although some languages were more eloquent and expressive than others there were other factors that were more important in choosing a programming language.
First, you want to pick a language that is widely used and has a strong community. This is important so that other people will be able to read your code and maintain it. It also ensures that there are a lot of community developed libraries to leverage when you are coding your application. It also means that there will be people around to help you figure out what you are doing wrong when you are at wits end.
Second, you want to pick a language that has a clear understanding of its philosophy. This usually happens when a language is shepherded by a “benevolent dictator for life” as Guido van Rossum, the creator of Python, calls himself. Another example of this is Ruby’s Yukihiro “Matz” Matsumoto. This kind of strong vision helps keep the language focused on solving problems in a particular fashion. The consistent flavor of a language is often more important than any other measure of technical quality.
Finally, pick a language that you like. If you are going to spend large chunks of time reading and writing code in a language, don’t choose one that frustrates you or causes you to have to struggle with it to solve your problem. There are way too many choices of language out there to spend any time at all being miserable.
When you find a language that is good enough, quit looking, at least for the time being. There will always be a newer, better language. These languages will take years, even decades to develop a community and the resultant libraries and infrastructure that make a language ecosystem great. Revisit your choice periodically. Don’t discount the investment that you make in the language that you have been using.
Of course you will often be told what language you must use, especially if you are working on a large project. In that case, cheer up. There are always ways you can improve the experience of using a language, if no other way than using a disciplined approach that lets you capitalize on your successes and minimize your struggling. And there is always the ultimate consolation of learning features to avoid in choosing future languages.
Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.