Being a polyglot programmer
coding.kulman.sk
coding.kulman.sk
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)
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:
http://pragprog.com/book/btlang/seven-languages-in-seven-wee...
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.
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.
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.
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.
(http://news.ycombinator.com/user?id=MatthewPhillips)
"My current interests are in Clojure, ClojureScript, and IndexedDB."
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 :)
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.
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.
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.
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.
Why did it not change your OO style to be more functional? Static methods, no mutation, etc etc?
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.
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:
CAN I ADAPT EASILY TO ANY ENVIRONMENT?
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.
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.
The more tools in your belt will definitely allow you to build better things more efficiently
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).