No Silver Bullets?

One of the most persistent questions I see on Programmers.SE is “What language should I learn?” and its endless legion of variations. These questions seem innocuous enough; beginners looking for insight into the hideously complex and bewilderingly partisan world of software development. It’s more than just languages too. Languages all have attached cultures and ecosystems. Not to mention an endless parade of varying implementations and the other attendant issues like third party libraries and the melting, gibbering insanity that is the world of software licensing.

The problem isn’t that the question is invalid per se. It’s more that the motivations for asking it are typically suspect. People typically ask the question for one three reasons: They want to be magically employable by learning language X, they want to solve a problem automatically via language Y, or they want to expand their programming horizons but don’t have the research skills to do a proper job on Google. I’ll address these and several edge cases.

Speaking to Power – Languages that Employ:

The problem with “What language should I learn to get a job” is the nature of the market for languages. Companies are typically invested in a technology stack such as .Net on Windows or Ruby on Rails on Linux or something like that. You have the language, the development environment, the operating ecosystem, the deployment environment which may not be the same at all and numerous other considerations. Changing a development stack is non-trivial. It involves more than just installations. There’s training your team to deal with the code and/or the new elements of the refactored stack. There are business and legal considerations too like the cost of licensing. Individual use of a technology stack is often free. Company use tends to be much less so. Thus, companies tend to be more wary of the “new hotness” if they have a process and stack that generates money.

So you come to another case here, which is “I don’t like the stack I’m using and I want to change it without changing companies”. This is related to the second category I mentioned above about magic solving of problems, except that it is trying to magically solve your dislike of the tools you are given. Sometimes, this problem can be solved by using a cross-platform language like IronPython for .Net but often the support simply isn’t there for Language Z trying to make it into your company’s stack. Smashing the Stack is very real business concern if you’ve got a working process. Any disruption even if it’s just the injection of one new programming language can mean the difference between a profit and a loss. It’s natural to want the best tools but sometime the best tool is to adapt to the existing stack rather than wish for something “better”.

The root of this matter is the idea of the “silver bullet”. The problem is that programmers and engineers are trained to find optimal solutions. We naturally seek the best solution possible within constraints. The issue is what to do when those constraints are our own prejudices/desires? At that point it’s time to try and take a step back and see if what we are proposing is a realistic solution. The question to ask is:

“Are we fighting Werewolves?”

If you are fighting Werewolves, then using silver bullets makes total sense. Sometimes though you don’t have any silver. So the question is how to silver bullet without silver (or sometimes even bullets). The answer to be good enough at the fundamentals to hack together a solution. I know that aesthetics are important, technical debt is important but when it comes down to shipping a working product in an ugly language or 6 months late and beautiful; beautiful will leave you broke.

Putting Holes in Wizards – Magic Bullets for Personal Projects:

The same goes for people trying to get a language to silver bullets for a personal project. There is no one right answer. Everything is good for something. It depends more on a solid understanding of the problem domain of your project than a magic code from the beyond that swoops in save you the trouble of actually thinking. Sometimes languages make a world of difference but these tend to be domain specific like R for Statistics or a general language that has a particularly good setup for something like Perl’s Regex functions or Fortran’s numerical capabilities. Fundamentals are again key. Know what algorithms you need and how they fit into your problem. Solve the problem then figure out what language features you need to solve it most effectively. Then pick a language that does that optimally. Tada! “Magic” Bullet!

GoogleFu Programmer Style – How to Do Research in 2012:

If you plan on spending any amount of time doing any kind of research on the internet. Learn How to  Google. I’m dead serious about this but it particularly applies to programming where the situations are often very time sensitive. Language learning for personal growth is a great thing and usually not as time sensitive but it is no less imperative to learn to research effectively before asking around on the Stack Exchange, or anywhere else, but particularly on the Stack Exchange. Doing research often requires dialogs and discussions and that’s not something SE is particularly kind toward. Fundamental knowledge again helps here; it allows you to ask the right questions using the right words. Most languages now have websites and user groups. Once you get a targeted question, rather than a nebulous notion, it’s time to go ask it on the Stack Exchange. Examine the FAQs for your particular question category. If you are unsure ask on the site’s Meta. That’s what it’s there for.

Closing Arguments – Think before Asking and Never Panic

Language questions tend to Gorilla vs Shark more than most and I hope that this examination will help avoid that. Most of the time the answer is “whatever your boss/teacher told you to learn or why aren’t asking them this question?”. We are programmers and software engineers; Logicians, not Magicians.

The last piece of advice I’d give is to rubber duck your question: Read your question out loud at least twice to a nearby inanimate object. If you can’t explain what you’re trying to ask to the “rubber duck” you need to more carefully consider exactly what you are asking. Tight deadlines can be panic inducing but don’t fret. Take a deep breath and focus. Laziness is a virtue in programming in the sense that it makes you want to be efficient. Learn to efficiently research and communicate effectively with people and you will have a much easier time asking questions on the Stack Exchange, programming language learning related or not.