Slashdot Mirror
6 Languages You Wish the Boss Let You Use
Esther Schindler writes "Several weeks ago, Lynn Greiner's article on the state of the scripting universe was slashdotted. Several people raised their eyebrows at the (to them) obvious omissions, since the article only covered PHP, Perl, Python, Ruby, Tcl and JavaScript. As I wrote at the time, Lynn chose those languages because hers was a follow-up to an article from three years back. However, it was a fair point. While CIO has covered several in depth, those five dynamic languages are not the only ones developers use. In 6 Scripting Languages Your Developers Wish You'd Let Them Use, CIO looks at several (including Groovy, Scala, Lua, F#, Clojure and Boo) which deserve more attention for business software development, even if your shop is dedicated to Java or .NET. Each language gets a formal definition and then a quote or two from a developer who explains why it inspires passion."
However, if I wrote any sort of interactive application, a scripting language would not be my first choice. To me, it basically boils down to this: a "job" that cranks off, does it's own thing, and then ends, is a very good candidate for a scripted language. For an "application", I'm probably going to crack out C or C++ to tackle that one.
And I completely disagree about GUIs. The only requirement on language choice for an application is that user interaction happen in ~0.1 seconds or less, and on today's computers scripting languages can do this easily. So with that out of the way the choice is on how easy it is to write, how nice it looks, how reliable it is, etc. And in these categories scripting owns C, C++.
A lot of great programs are being written in JavaScript or Python these days. For instance, MusicBrainz' Picard is written in python, but you would never know it from using it. Even ones that are supposed to be 'fast'... users don't notice a performance difference between mercurial (python) and svn (c), but mercurial is already light-years better because people can understand the code (svn sourcecode is an absolute disaster re: readability).
I would go so far as to say that the primary reason to write most GUIs nowadays in C or C++ is just so they can't be reverse engineered.
I'd consider the minimum for a really good programmer to include at least a project or two's worth of exposure to:
At least one assembly language or pseudo-asm.
At least one mid-level pointer-driven language (C/C++/etc)
At least one statically typed functional language (ML/Haskell/etc)
At least one dynamically typed functional language (Lisp/Scheme/etc)
At least one dynamically typed OO language (Smalltalk/Python/ruby/etc)
At least one higher-level statically typed OO language (Java/Ada/C#/etc)
That still leaves some holes that could be tricky to pick up, and ideally you'd know:
At least one stack-based language (Forth/Postscript/etc)
At least one imperative programming language (Prolog/etc)
At least one DBC-centered language (Eiffel/Sather/etc)
At least one concurrency-oriented language (erlang, etc)
But you can have a long and successful career as a top-shelf programmer without really needing that latter group.
And yes, those monikers are a bit arbitrary; you can do full OO in Lisp, functional programming in Python, etc. So you can get away with a lot fewer languages than there are on the list, as long as you learn the different programming models. It tends to be a little easier to learn a model with a language that's been used that way traditionally.
I'm sure I'm missing some areas, too.
rage, rage against the dying of the light
I wasn't sure what I was getting into when I had asked a programmer to replace our crummy Jython interface with Groovy. Ten minutes after I had asked him to do it he says he's done. He shows me a clean interface complete with the functionality for saving files, copying and pasting, search and replace, and a handy output section. I had even asked him to integrate it with the rest of our program, but a simple 'import com.ourcompany.ourproduct.package' in the groovy console already had that solved. Now development has sped up slightly as we even do some development in the groovy console so that small tweaks and changes don't mean we have to wait for a re-compile.
I am one boss who welcomes groovy.
Learning a new language involves lost productivity, and if you choose a language that isn't in mainstream use it will involve lost productivity for everyone you hire to use it.
Generally speaking new languages don't offer enough benefit over the old languages to justify that expenditure.
It's the thing everyone always forgets, even if learning something new is easy, the new thing has to be sufficiently better than the old thing to justify the learning.
Boutique languages are almost never a good investment because even if you hire a programmer who loves to learn the liklihood that they've learned any particular language is fairly low. Languages become popular not because they are superior in any technical sense, but because they provide a benefit for a project which outweighs the investment cost.
Just because a programmer can learn a language doesn't mean it makes financial sense for them to do so on company time.