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.
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").
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.
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.
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.
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)
Agreed, working with APL has been an extremely valuable exercise.
Another experience I found enlightening was working through the Pragmatic Programmers book Seven Languages in Seven Weeks which points out the more interesting and distinguishing features of Ruby, Io, Prolog, Scala, Erlang, Clojure and Haskell:
I just finished a class in my CS graduate program where we used this book for part of the class. It was very interesting and has widened my perspective on languages quite a bit (including giving me a bit of a functional language interest). I've only done C/C++/Perl in the past so working with some of the languages in the book was a bit of a mind bending experience, but very rewarding. I may have to check out APL as well.
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 can learn whatever it is that they use. In your spare time, do what you enjoy, if ColdFusion is that, use ColdFusion.
I used to eagerly spend time learning every new language I came across - but that was 1988 or so, and the languages were actually different: Lisp, Prolog, Basic, Pascal, C (not that different from Pascal), various assembly languages, SNOBOL, Perl, APL, C++, Python, TCL ; each had different strengths as a language, and "knowing XXX" meant knowing the syntax and some idioms, but mostly grokking the philosophy. I used to write a Tetris game in each language to make sure I actually understand it.
But now? most languages are basically the same Java/C# with minor variations in semantics and syntax - but you don't "know" C#/Java or even Ruby or Python these days unless you also know the library/framework ecosystem. And knowing the ecosystem is not about understanding the philosophy - it's about rote memorization. And that takes time and memory, rather than insight and understanding.
I'm sticking to C for speed, Python for elegance, and K/J/APL for fun. I really like erlang although I haven't had a chance to work with it. While I occasionally still have to write code in other languages (100 lines in random language every month), looking up the syntax/semantic differences and library documentation feels like a Sisyphean chore rather than acquisition of knowledge.
I agree that you only really need to know several types of languages to (a) prove you can learn what you need and (b) get exposed to different philosophies of problem solving. An OO language, a dynamic scripting language, a functional language, and a procedural language are likely enough.
I think it's also very important to have some exposure to the full stack. I interview too many programmers who don't understand what is really happening inside the computer when programs are running or who don't have enough knowledge about networking, security, or operating systems to tune and troubleshoot issues.
Being well-rounded is important and learning various programming paradigms is only a part of that.
There are lots of other shiny new things that he could have learned. Clojure happens to be a rather practical new language to learn if you already know Java, and ClojureScript has a pretty small hump if you already know Clojure and JavaScript (which, lest anyone forget, is about 15 years old now).
Yeah, I never said I don't want to learn new things. I still have a desire to be employable, and if something new seems novel I'll look into it. But I have, for example, no desire to learn any new OOP languages (aside from a quick look) until the ones I already know become irrelevant.
That's funny, I actually am more drawn to being a polyglot as I get older. Part of this is to keep my mind nimble and myself excited, as I was when I first started learning things as a young adult.
Also, I think as I get wiser (I hope), I'm realizing more and more the precept of "when all you have is a hammer." It also helps that I'm decent enough in the things I've specialized in that I can learn new things with the purpose of supplementing the deficiencies in my specialties...which makes learning those new things both easier and more profitable.
I'm on the same boat. After dabbling in many programming languages, databases, various Linux and BSD distros, I made up my mind to be productive (solve problems) instead of to keep on learning and use my brain less.
These days I tend to be pragmatic and keep a set of tools: Java, JavaScript, and Python (may change to Ruby...), PostgreSQL, Linux (ubuntu, may switch to RH if I decided to pursue RH certification) and try to become extremely proficient in each of them.
I'd prefer to be full-stack as opposed to polyglot.
Interesting that nobody puts forth "Because I enjoy learning" as a motivation for learning. It's not a dichotomy: You can enjoy learning and benefit from learning idioms that cross over between languages, or enjoy learning and insure yourself against obsolescence, &c.
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.
So true! There is a APL and its descendants mentioned, so array-based languages are covered, but what with concatenative ones, like Forth, Factor or Joy?
I found learning (the very basics of) Forth illuminating almost to the same extent as learning Scheme if not more. `swap`ing the order of argument with higher order function is never going to be the same again :)
The article doesn't actually provide any significant reasons as to why you need to be a polyglot programmer. If anybody is reading this I would love if somebody can provide reasons besides being able to think differently. I'd like to encourage programmers, at a ruby user group, to learn other programming languages. But besides the think differently 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?
i think you can make the case that for many (largely self-educated) programmers, learning new languages is a good way to understand programming at a more abstract level. and that, in turn, means that you can write better code.
for example, if you understand an object-oriented and a functional language then you understand two quite different ways of encapsulating state - as objects and as closures. that leads you to thinking about state as something more general than either, which gives you a higher level view of the problems you are tackling.
so learning multiple languages illustrates different aspects of "deeper" issues in programming and motivates the discovery of those abstract concepts, which then provide a stronger "mental toolbox" to do your work.
from my own work, for example, i feel that google's guava library has improved my java code considerably. using that library well requires (i believe) an understanding of the advantages and disadvantages of both oo and fp programming.
> if you understand an object-oriented and a functional language then you understand two quite different ways of encapsulating state - as objects and as closures. that leads you to thinking about state as something more general than either, which gives you a higher level view of the problems you are tackling.
Yet, it may not be general enough. With one data point, one doesn't generalize. With two, one tends to think of a spectrum. With three… Now it gets interesting.
For instance, encapsulating state: you had objects and closures. They look pretty different, until you learn of Functional Reactive Programming, where state is handled in a much more timeless fashion.
Thinking differently is the big one, but not the only one. There are places where one language has tangible advantages over another. Knowing more languages helps with the "When all you have is a hammer" problem.
I will never use C++ to parse text files when I have Perl available. On the other hand, I shudder to think what most C++ software I've seen would look like in Perl.
Sometimes learning another language helps with understanding constructs in the languages you already know. I started seriously programming, after a 7 year break, with C#. I am self taught and it was going well. Then I got to lambdas and I got stuck. Later I started picking up F# and got more into functional programming. From using F# I became familiar with lambdas and anonymous functions and they started clicking with me in C#. That allowed me to expand my C# skills indirectly.
The next phase of being polyglot programmer is actually using multiple languages in the same project. This can result is astounding examples of using the right tool for the right job. ROS.org is an excellent framework for message passing between C++, Python, Java and lisp (and in my current project we also have custom bindings to a Prolog interpreter).
In our project we use Prolog for classical reasoning, C++ for signal processing, and Python for a dynamic architecture. With an applied polygot programming style you get the execution speed of C++, the agility of python and domain specific features WHEN YOU NEED THEM
Learning other languages and thinking differently gives you entirely new ways to solve problems, and can't really be encouraged enough. Beyond that, there's the analogy of the carpenter. If someone working at a carpenter only has one tool (a hammer) how effective can they really be? They might be able to do beautiful work, but just think how much more they could do if they only had a saw.
For me, learning a new programming language is an opportunity to see how different languages implement different features. For instance, JavaScript, lua and C# all have different ways of implementing inheritance. Understanding the pros/cons of prototypal inheritance vs. classical inheritance makes me a better developer.
> 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.
Why did it not change your OO style to be more functional? Static methods, no mutation, etc etc?
Why would it? OO languages aren't functional. Trying to misuse a tool seems like a great way to resent it. After learning to use a saw, trying to cut boards with a hammer would be a nightmare.
It depends on your OO language. If you have garbage collection, you can at the very least refrain yourself to use mutable state all over the place, especially at interface boundaries. It's not hard: http://loup-vaillant.fr/tutorials/avoid-assignment
I learned java in school and used C# professional for year. Almost every useful refactoring I perform in C# is based on functional concepts. You can slap patterns on a mess to provide order or you can introduce functional concepts to remove it, almost entirely.
I am not trying to dismiss patterns, but when you have lambda's you have a free way to add a visitor, command or specification to your code. It is one line instead of three interfaces and a bunch of shared understanding.
Consider,
var even = (new [1,2,3,4]).Select(x => x % 2 == 0);
The select statement gives you a way to interrogate individual objects, in the same way you could if you built up all the plumbing for a visitor pattern. What did I have to add to do this? Nothing. C# is awesome.
For me, being a polyglot programmer is about being able to sit down and get comfortable usage from any language or framework.
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.
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:
All of these languages are mostly imperative. The author recommended, and I concur, getting some hands-on with other paradigms (Functional, Logic, etc).
I agree with you, I'd love to find the time to learn Clojure. Hopefully things slow down a bit for me this end of the year I'll find some quality time to sit down and learn.
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.
For me, having learnt to program in multiple different languages means I've learnt that being a programmer is more than syntax and given I've programmed from C++ to Ruby to Node.js that I've usually got (some) insight into the best language to tackle a particular problem.
Whether or not I'm correctly attributing this to having programmed in multiple languages I'm not sure, but it's certainly nice to be able to jump between things with a slightly smaller learning curve.
Learning different programming paradigms is of course a great practice however I'm not sure we can attribute that to learning different languages. I think for a good programmer choice of a programming language does not matter.
> I think for a good programmer choice of a programming language does not matter.
I disagree. I think an important part of being a programming is choosing the right tool for the job.
You might be able to build what you need using a hatchet to cut your lumber, but you will almost certainly end up with something much cruder than if you had chosen to use a saw.
So a good programmer should be able to get by with the tools he has, but should pick the best tool for the job when he has the option.
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.
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.
If I had to guess, I would say that many programmers first learn one language at the university. It's hard, because it's their first one. Then they learn C++. It's hard because it's C++. From that, they infer that languages are complex, difficult to learn, and maybe impossible to implement.
This is true of languages that desperately try to be the proverbial hammer. That's why we call them "general purpose". On the other hand, more specialized languages are often much easier to handle: Of the top of my head, I can think of Make, Lua, and OMeta.
I learned the basics of make in a few days. I'm currently using Lua for the first time, to re-implement OMeta, which I learned in a couple days. It looks like basic Lua proficiency will take about a week of practice (during my spare time).
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").
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.
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.
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.
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)