Language Mavens, Tool Mavens


Recently, a fellow coworker referred me to an article by Oliver Steele about Language Mavens and Tool Mavens. The synopsis is that there are two types of deveopers:

  • Language Mavens are those that leverage a features of the best language to complete the task at hand; the IDEs/tools used do not matter so much.
  • And conversely, Tool Mavens leverage the power of mature, full featured development tools to complete their tasks: an integrated editor, debugger, code refactoring, etc. The language itself does not matter because, it is just the same old set of classes and methods with slightly different names.

Naturally, this led to a bit of introspection, which resulted in the diagram that you can see above: I think I am somewhat between both camps, in that I choose and tend to use a variety of languages on a frequent basis to get my work done. But I find myself more so gravitating towards the languages with the richer tools, because they make suit my programming habits better.


The tool I require a language to have before I even consider touching it is an integrated debugger. Well, to qualify that statement, I require that for applications with complex execution paths and sustained runtimes. That means for bash, Ruby, Perl, and JavaScript, it doesn’t matter, because printf debugging will suffice. [1] However, if you follow this blog, you may have read about my work on porting Mono to Android. Although Mono has a great integrated x86_64 debugger, none exists for the ARM platform. Doing development using Mono on Android is not really a viable option to me until the debugger exists (or I get around to implementing it myself).

The other tool I prefer a language have is auto complete (aka content assist). It’s purpose is two-fold:

  1. When learning a new language/API/platform, content assist severely lowers the learning curve. Instead of hunting down method signatures, class names, and descriptions on Google, it is built into my editor. This ultimately saves me a significant amount of time.
  2. Eventually, when I master the language, auto complete serves a different purpose: it reduces the amount I need to type by a little under 50%. [0] This is interesting, because a language without code completion would need to be able to complete a task in half the lines over a language that does support it before it actually becomes a more efficient use of my time.


As Steele’s article states, C# and Visual Studio, as with everything with Microsoft, is an exception to the rule. The new languages (and features) are released at the same time as the tools. And generally, I find myself getting more excited about the languages aspects, than the tools. For example, with VS 2010 (which should be in beta very shortly I hear), we will get: F#, Dynamic Language Runtime (Iron*!), and full expression tree support in C# (to support the DLR and the new dynamic keyword). [2]

Lately, in various projects, I find myself wanting to do more in the way of code generation. Be it code being generated from a model or modifying/creating new code at run time. So that is what spurred my desire to learn Ruby and Python (of which I currently favor Ruby). Though I don’t think this is something I can not live without.

As for language features that are to-die-for, I find it hard to cope without closures and generics, of which Java has neither. [3] The lack of generics is why I also did not really adopt C# over C++ (templates) until version 2.


Where do you fall as a language/tool maven, and why?





[0] I did this by recording my keystroke count using a free Windows application, and disregarded keystrokes for any navigation or correction keys: backspace, delete, and arrows. Then I compared the results versus the character count of the code written.

[1] Incidentally, I realized I have learned around 5 new languages in the past year. Though I can only claim proficiency in one, the language with the best tools: Java.

[2] Using expression trees in C# to Frankenstein together some new code at runtime seems like there could be infinite Lisp-ish possibilities. Though you can dynamically create new code at runtime using Ruby/JavaScript, you can’t modify or access the expression trees themselves like Lisp. C# doesn’t allow you to look at any expression tree at runtime either, but it does provide language integrated support for building expression trees (and has in a primitive form since C# 3), which can have a similar effect.

[3] Type erasure is not what I would call a real implementation of generics. Anonymous inner classes are not closures.


Matt Brubeck said...

Thinking about this more, I realized that one of the tools I have a hard time living without is a full-featured REPL. Ironically, this is one of the few tools that's impossible to do well in C++/Java/C#. (It's not hard to create a REPL for these languages, but it's super-annoying to use in practice because of all the required structure and boilerplate. Even Scala, which is much more concise than Java, is kind of clumsy in the REPL.)

A good REPL serves a similar purpose to a line-level debugger, and is also one way to get perfect auto-completion in very dynamic languages.

You mention that auto-completion saves you about 50% on keystrokes. Well, looking at the Project Euler solutions, languages like Lisp and Haskell typically require about one half to one third the code of languages like Java and C#. And they have auto-completion too!

Koush said...

Of course, what you say about Lisp/Haskell having autocomplete is true. Incidentally, I recently discovered that Ruby under Eclipse/Aptana supports halfway decent autocomplete (had been using TextMate prior to that).

But how efficiently one can write code using a given language/tool isn't the only thing that determines what language/tool should be chosen. You need to factor in what is available on the platform, the skillset of the other developers on your team, performance implications of that language/tool, etc.

And given our area, mobile phones, I wouldn't say Lisp or Haskell is a viable, or even a possible option. :)