Secrets of a polygot programmer

I often read opinions about using the best tool for the job in reference to choosing programming languages, frameworks, and libraries.

I am a polygot programmer but I am one mostly because I use languages and other software tools that my customers request. Seriously as a consultant I serve my customers' best interests and that process usually does not include trying to get their teams to pivot to use my favorite tools.

For my own side projects I am for the most part happy enough to use any of the languages that I feel most comfortable with, my favorites being Ruby and Clojure, but I also really like to use Java and Common Lisp. I usually choose languages for my own projects based on available frameworks and libraires that I can build my code on, and more rarely because of specific language features. Yes, I feel a little heretical saying that!

My secret for being comfortable with several languages is that I try to make the development experience similar across programming languages. For example, from the mid 1980s to several years ago I mostly lived inside Emacs. Certainly some language like Smalltalk carry their own IDEs around with them, but for the most part I used Emacs. Things are different now, I use various JetBrains IDEs because the editors, settings, etc. are all mostly similar:

  • Clojure - I use IntelliJ with the La Clojure and Leiningen plugins
  • Java - IntelliJ all the way
  • Ruby - I use RubyMine most of the time with some quick work done in GEdit or TextMate
  • Python - this is a tough language for me because I don't much use Python unless a customer is a Python shop. I find that PyCharm with code completion and instant syntax error hiliting really helps me a lot.
  • Common Lisp - yes, I still use Emacs
Other things that help are common tools like git, svn, crontab, PostgreSQL, MongoDB, and bash (like) shells that are fairly much constants in my work.


  1. hi mark,

    thanks for sharing your thoughts on the subject.



  2. Hi, Mark. You, Sir, have a new reader. I feel so less crazy now about my "heretical" way of thinking about being a developer/consultant...

    Thanks for sharing!

  3. Hi Mark,

    I just wanted to know why don't you use Emacs for Clojure? And why not for Ruby/Python?


  4. I used Emacs for my first year of Clojure development (and I still have Emacs setup for Clojure dev) but I found that the experience using IntelliJ was a little better.

    I do use Emacs for Common Lisp and Gambit-C Scheme development. Not very standard but I really like Marc Feeley's custom Emacs support just for Gambit-C.

  5. Hi Mark

    Very good post. I think there's a lot of merit in pointing out cases where technology choices are largely governed by clients. I've found that this can be different in organisations that build their own products and/or tools, although that's definitely not always the case.

    I've found that the best "tool" isn't necessarily an implement so much as a thought process or mindset - and this is where being a polyglot can prove to be quite useful. I've found that our approach to problem solving is largely driven by our familiarity with our tools - if you've only worked with one language, your solutions might tend towards those that neatly fit the language you know. But if you know multiple languages, you gain an awareness of other techniques that you can leverage (poly-paradigm would probably be more useful than polyglot).

    So we may often find we use the the same language tool, but our conceptual tools are shaped by what we've been exposed to.

    To put more concretely - it's quite likely that you can tell a monoglot's programs apart from a polyglot's purely because of the approach taken.

    I think you've hit the nail on the head regarding the development experience. That can make a world of difference when it comes to productivity.


Post a Comment

Popular posts from this blog

Ruby Sinatra web apps with background work threads

My Dad's work with Robert Oppenheimer and Edward Teller

Time and Attention Fragmentation in Our Digital Lives