Being a polyglot programmer

If you are planning to be a polyglot, I highly recommend learning a language of the APL family (APL, K, J, Kona) and writing a few nontrivial programs.<p>The benefits of being a polyglot is that it lets you more easily think "outside the box" in any language you are using (especially when you can't use "the right tool for the job").<p>The facilities in most languages are designed to let you build larger and larger abstractions based on previous abstractions. That's true for C++, Java, C#, Scala, Perl, Ocaml, Ruby, Python, and almost every other language out there.<p>APL (and to a smaller extent, Erlang) tick differently; on one hand, they do not provide abstraction facilities to build your own "classes" and other "abstract data types" or new kinds of "flow control". On the other hand, they provide simple tools that let you get buy without those.<p>Only after really grokking K, I realized how much language and library infrastructure do not actually help you achieve your goals of "getting things done". The usual reply to that is "well, but it makes things more readable/maintainable" - which might be true in most cases for e.g. C++ or Java, but that's mostly because they don't provide the right tools for the job.<p>Take some time to grok APL. The learning curve is not easy, but the payoff in insight and productivity is immense. (And also in pay: K programs command significantly higher salaries than e.g. Java or Scala programmers)

The older I get the less I want to be a polyglot. Or at least the meaning of polyglot changes. I used to love learning every new language that I came across, but now I find less value in doing that. I find it too time consuming to learn new languages and I'd rather be creating things. It's difficult enough to create things in your spare time with the languages you already know. It's enough for me to know one language of each of these types: one statically typed OOP, one dynamic OOP, one functional. Being strong in 3 of those and employers will see that you <i>can learn</i> whatever it is that they use. In your spare time, do what you enjoy, if ColdFusion is that, use ColdFusion.

Interesting that nobody puts forth "Because I enjoy learning" as a motivation for learning. It's not a dichotomy: You can enjoy learning <i>and</i> benefit from learning idioms that cross over between languages, or enjoy learning <i>and</i> insure yourself against obsolescence, &#38;c.<p>But for some people, it's a personal thing, they simply enjoy learning, much as an Architect who designs tract houses might still enjoy reading about new, avant garde office buildings.

The article doesn't actually provide any significant reasons as to <i>why</i> you need to be a polyglot programmer. If anybody is reading this I would love if somebody can provide reasons besides <i>being able to think differently</i>. I'd like to encourage programmers, at a ruby user group, to learn other programming languages. But besides the <i>think differently</i> I can't come up with any compelling reasons. Am I being silly? Is being able to think differently about problems the only reason to learn different programming languages?

&#62; When I finished the course I really liked Haskell and functional programming because of its clarity, readability and the fact that I could write a very compact code. But I had no practical use for it. It did not change my Programming style but made me look for a more pure and “nicer” language to learn.<p>Why did it not change your OO style to be more functional? Static methods, no mutation, etc etc?

For me, being a polyglot programmer is about being able to sit down and get comfortable usage from any language or framework.<p>I started out with VB.Net in University, during my second year started using C# on my own. Next came Ruby with it's elegance. Followed by PHP for it's commercial potential (lots of people pay for this), followed by Ruby on Rails, followed by CakePHP, followed by ASP.Net, followed by ASP.Net MVC.<p>I have about 2 months of CakePHP experience - and I have a full time job using it at a Senior Position. It's about being able to somewhat "bs" your way into a job but NOT suck at it, because you are used to change. You can adapt and roll with the punches. Paradigms, toolchains, dev ops, are secondary - your real concern should be:<p>CAN I ADAPT EASILY TO ANY ENVIRONMENT?

I think that being a programmer is not about coding in a particular language. It's all about thinking differently thus his point about being a polyglot programmer does not seem to hold. For me programming is how would I solve a particular problem with the tools I have. Maybe an easier solution exists if I do a certain thing a certain way but it would be more satisfying for me if I come up with a solution my way.

In my opinion, it all goes back to your tool belt. If you only have a hammer, you can only hammer nails. You can use a hammer to cut wood if you beat the wood with the claw long and hard enough, but you would be much better off if you had a saw.<p>The more tools in your belt will definitely allow you to build better things more efficiently

I would tentatively agree but would say the pace is important. Otherwise you end up a jack of all trades and master of none. My goal is to learn one new language every year as well as to deepen my knowledge of the languages that I use regularly.

Dont be a polyglot, it is read to hell! Learn only two languages which are stable, use similar stack and complement each other (C and Lua; C++ and Python; Java and Clojure). And become _best_ at those two.