I recently learned that the big-name mattress companies in the US will give different product names to identical mattress models on a store-by-store basis. It’s all designed to deceive you, the unwitting consumer, by frustrating your attempt to compare prices and features.
Choosing a programming language for your project is a bit like mattress shopping. While there isn’t the same outright deception in the programming world, the decision can be similarly fraught. You’re going to be wed to it for a long time, and you may not know right away whether you’ll be sleeping well through the night or suffering from acute, chronic lower back pain.
Today I’m going to help you find the best language for your project, or mattress for your home.
Why you should trust me
I’ve been writing software for 20 years and sleeping even longer. I spent at least 15 minutes looking at mattress websites while researching this article.
“Language is the source of misunderstandings.”
― Antoine de Saint-Exupéry
One reason it’s so difficult to compare languages and paradigms in the broadest sense is because they occupy such different worlds, each with its own philosophies, principles, practices, and cultures. And because programming language designers are such language lovers, they leave a trail of new vocabulary everywhere they go. (I’m not sure what mattress designers leave a trail of.)
Different constructs sometimes share the same name, too. A Go map is not at all the same as a Clojure map in terms of how, when, or why you’d want to use it, because these languages have such different roots.
It’s an exhausting amount of complexity to consider, and you should probably sleep on it.
Your project’s purpose is the first way to narrow the scope of the decision. While some languages are general-purpose and others serve a niche, each language is best suited to a particular set of needs. This goes all the way down to the syntax, the execution model, the runtime environment and constraints, the higher-level frameworks and open source tools available, and the community.
The real question you’re asking here is, how hard will it be to get a good night’s sleep? To deliver good working software for the project? Will the language make you feel faster and smarter, or will you be fighting it? What’s the toolchain going to look like? How well do the language features and testing environment support the project?
This is a great example of how, even if you are an Agile shop, you will still want to do some initial planning around what your system needs to be capable of so you can make a wise choice here.
Ideally you want the language to suit the working style of your team and the way you communicate. The explicit nature of statically typed languages may be a boon in some contexts (big, distributed teams writing higher-risk code), and a burden in others (small, local teams writing lower-risk code). The choice of type system is never simple, though, because it plays so heavily into the risk profile of the project.
Lurk around a while within the communities that build the languages you’re considering. Programming is like traveling the world, and each language develops its own subculture. So when you adopt a language, you adopt a community too, and that may be the most important consideration. You’ll potentially be hiring from that community. You and your team will be interacting with people in that community a lot and depending on it for support. And you’ll be giving back to it.
How do the leaders of the community set the tone for communication? How are newcomers treated? What’s the general makeup of the culture? (Some languages, like R and MATLAB, are mostly used by researchers, for example…) Are projects of your anticipated size pretty common within this community? Follow some hashtags for the community. See if you can go to a local event or conference centered around the language. Catch up on some of the latest gossip.
The real problem with mattress and programming language shopping is that you do it rarely, yet you need to be really good at it. You have to make a choice quickly, with limited information. You have some pretty strong criteria, but you’re not sure if you can get everything you want. You have to gather a lot of contextual information, but once you make the decision you can let most of it go. And of course, intuition plays a big role.
Some mattresses are poorly designed yet wildly popular. They have too many features: compressors, air hoses, and knobs and switches that nobody should have to deal with after 6pm. And don’t even get me started on waterbeds. Other mattresses have such wonderfully thoughtful, simple, elegant designs that it’s surprising they are not more widely adopted.
It would be easy to assume that choosing the right language for a project is like any other technology decision. When choosing a payments platform, for example, you might look at costs, ease of integration, support, scalability, speed and quality of service, and so on, and you’d get a good sense of how well a given payments platform fits your specific needs. And if it doesn’t work out down the line, your level of lock-in would be pretty low and you could switch to another provider.
But the choice of programming language differs in some crucial ways: the language you choose will tie into your recruiting strategy, your developer community, the collaborative environment of your team, and the toolchain you use (and its UX design, or lack thereof). It may take months to really feel the gravity of the decision.
Matters of the heart
This is where things get a little messy and political. You and your teammates or bed buddies may have differing opinions about OO vs. FP vs. FRP, sateen vs. flannel, Swift vs. React Native, and so on. Given the complexity of the decision, people around you may start tossing out blanket generalizations. One might say, “Decorative shams are a scam,” for example, or “Python is for n00bs.” Ignore these vague and unconstructive criticisms.
The important thing is that you, sober leader, will take the initiative to bring your teammates or sleeping partners into alignment. Everyone should feel their input has been heard and that the priorities are clear. It may help to put together a spreadsheet mapping out the features that really matter: materials, breathability, hypoallergenic properties, costs, considerations around health and human factors, expected lifespan, return policies, and so forth.
Finally, if you’re going to be recruiting developers or slumber companions in the coming years, you also have to understand how your choice will impact your pipeline. The top developers in the world tend to want to work in the most exciting languages and paradigms, and it’s imperative that you hire the best. Especially if you’re a startup, this could mean adopting a hot new language or framework that is immature but on the upswing. It’s risky: you may need to lay more foundational code than you’d have to if you used a more mature language. And newer languages may have inadequate documentation, which will make the learning curve harder for everyone. But it could pay off well down the line.
As long as you don’t let fashion trends eclipse the practical requirements of your bedroom situation, you should be okay. Yes honey, the organic Belgian stone-washed linen is amazingly soft and is totally on-trend, and I agree that it has a beautiful drape, but listen, you can probably find something functional and somewhat fashionable at Target for a lot less.