I’m a programming language enthusiast. I love studying different language designs, comparing them to one another, and hopefully learning something new in the process. So it’s no surprise that I’m a fan of polyglot environments. In fact, one of the real advantages of microservices is that they encourage multiple languages. Polyglot architectures are extremely healthy for an engineering organization, both in terms of employee satisfaction and from a technical standpoint. Of course, there are some disadvantages as well, but I believe they are easily outweighed by the benefits.
Everyday, programmers use many tools to get their work done: a command line, a text editor, source control, espresso, etc, but far and away the most important tool we use is the language we code in. But calling a programming language a *mere tool* is doing it a huge disservice. Unlike most other tools, which are used by the engineer for some specific purpose, the programming language has as much control over us as we do over it. By this I mean: the language we program in determines our modes of thinking, and, perforce, the solution space to the problems we face. Languages aren’t just abstract syntax for controlling a computer — they are an extension of the engineers mind.
When I program in Haskell, I can envision my problem in terms of composition of pure functions, using monads for representing impure side effects and error cases. When I program in OCaml, I can take advantage of a rich module system that allows me to both encapsulate and expose type information in the right amounts. But when I program in (for example) Python, I feel straight-jacketed, unable to craft the solution I want.
Unfortunately, most programmers have never used sum types; personally, after I first discovered them, I’ve felt like any language that lacks them has a insurmountable fatal flaw. Sum types allows one to express heterogenous structure in their programs. Programming in a language without sums is akin to programming in a language without functions — both are equally absurd.
And hopefully, some ideas learned from using other languages will carry over. I’ve certainly found this to be the case. Every language has new ideas to offer: Go’s CSP-style concurrency, Haskell’s type-classes, Simula’s object-oriented programming, Erlang’s actor model, Lisp’s homoiconicity, etc. Exposing programmers to more languages makes them better all-around problem-solvers. Using a single language keeps us stale: monotony breeds mediocrity.
But what if programmers are unable to learn a new programming language? I’m of the opinion that pretty much any programmer can learn almost any language, with the right amount of encouragement, time, and motivation. It seems hypocritical that we expect our engineers to constantly learn new frameworks, libraries, and tools, but we scoff at the thought of them having to learn an additional language. We expect engineers to suddenly be experts in containerization and “devops” automation, but are completely unwilling to invest the same time in something so much more fundamental to our core job (and from personal experience, I can say that Haskell is much less complex than Docker).
Creative workers thrive when they are respected and empowered, not coddled. Engineers are fully capable of surviving and even excelling in a polyglot environment. We will all reap the benefits.