After having spent much time with Groovy/Java, and a bit with Ruby and a bit with C#, I have a newer perspective on learning new programming languages.  Much of my thoughts are summed up by this post from Gustavo Duartes.  I liked his choice of words at the top – “language dabbling” – which largely describes my C# and Ruby experience.  I’ve done a little bit in them – some paid in C#, some not – but the bulk of my work is in PHP, with a small but growing bit in Grails.

It’s interesting to note his acceptance of “more than one”, but focusing on the “minimal required set”.  We tend to think of languages as Java,C#, Python, etc., but competent web developers need to have a handle on SQL and JavaScript as well.  Many also get into Flash/Flex/Silverlight too, and while CSS isn’t a *language* specifically, it’s something most web developers should be acquainted with.  So, regardless of your serverside language of choice, there’s going to be 2-4 other technologies you need to be at least competent, if not proficient, with.  This may be more the realm of small shop and independent developers – people working on larger teams or in companies with divided responsibilities may be able to get away without knowing any SQL or JavaScript, for example.

One of Gustavo’s points was that you lose momentum on your main language when you start dabbling with others.  There may be a point there, but I suspect some people end up looking at other languages when they reach a plateau in one.  That was certainly my point I reached with PHP.  Having used it since early 1996, there’s only so much more I feel I can do with it.  Yes, the language is evolving slowly, and I’m not keeping up with the ‘best practices’ of namespacing and such in 5.3, and I could probably architect my apps somewhat more strictly using some of the bigger frameworks out there.  However, one of the things you end up learning when you look at other languages is where some of the defects are in your primary language.  You may start to see the new ‘best practices’ as work-arounds in language deficiencies.

It’s easy to point at PHP and talk about how “it sucks” and all that, but I’ve had experiences with some friends who’ve moved from Java over to PHP.  While this was a somewhat unwelcome move at first, given PHP’s reputation amongst the ‘enterprise crowd’, at least one of my friends is really enjoying being able to be much more productive – more functionality in fewer lines of code – and rethinking some of his approaches to web development.  Moving from any statically typed language to a dynamic one is certainly a shift for people to make (and the reverse movement is true as well!), and rethinking those problems we’ve taken for granted can be a real eye-opener.

In the short term, yes, it’s a productivity loss, as Gustavo points out.  In the longer term, it can really provide you with many more tools in your toolkit for attacking new problems.

One caveat I’ve noticed to this is the old saying “choose the right tool for the job.”.  Great in spirit, but my experiences have borne out that rarely is the definition of “right” able to be agreed on.  ”Right” for who?  The DBA?  The sysadmin?  The developers?  I had a project I’d recently prototyped in Grails (after an initial first pass prototype in PHP 6 months earlier).  The Grails environment allowed for much more rapid prototyping and modeling of data, relationships, screens, and so forth.  However, when it came time to accept it, I was told we could *only* build the app on a traditional LAMP stack (I was looking forward to using PostgreSQL on this project as well).  Why?  Because the limited system administration staff didn’t have the time to learn new skills to manage the new technology choices.

While initially I was bummed out, I can understand the decision making process.  I was able to take the db tables from Grails and wrap another PHP ORM layer around them so I didn’t lose all my work, but it certainly put to rest the maxim “right tool for the job.”  Who gets to decide?

So, even if you learn new languages and technology, you might not always be able to use the most appropriate tool from a pure technology/productivity standpoint.  And sometimes knowing that there are better options out there that you *can’t* use for various reasons adds a level of frustration to the mix that you wouldn’t have.  Perhaps we should all stick to just knowing one language and one language only, right?  :)