Sunday, September 24, 2006

Tool or language

One of the interesting fallouts from the recent discussions about Nuxeo moving CPS over to Java in the future, is whether relying on tools like IDEs is legitimate, and indeed whether this is just excuse-making for the deficiencies of a language.

I'd argue that it doesn't matter. Whether you call it a language or a tool is largely moot. We don't edit Python in ed, we use vim or Emacs or TextMate (sensible people use the latter). Some languages are complemented well by tools, others have less need for them, and some just don't have very good tools available. The important metric is how efficient you are within your working environment, taken as a whole to include your language, your framework and your full toolchain.

Therefore, the learning curve = the language + the tool. If getting the tools set up is going to take you a long time, you lose productivity. Eclipse is fairly easy going. Some of the plug-ins are a pain to get and install, others are a breeze. But move down one level, and it can become a pain to manage builds with Maven (which is very powerful but can also be very complex when you step outside the box a little) or Ant (which is not that complicated, but requires a fair bit of manual work). I know companies that invest two weeks of a team's time just to get the build environment set up and configured right, which surely is wrong.

And secondly - when the tool does the wrong thing, you probably still need to understand what's going on. That complexity that the tool was hiding is rarely hidden completely, forever, because at some point your tool doesn't yet support the thing you need to do. And in many cases, the tool then expects to manage your source code in its own way and either stomps on your changes or breaks utterly.

Good tool design, it seems, is not much easier than good language design. There are still some things I miss in my current, very minimal Python set-up (consisting of Python, Terminal.app, TextMate, Firefox, FireBug), such as code-completion and support for refactoring by finding and modifying code that needs changing because I renamed a function or moved it up or down the inheritance hierachy. But in most cases, Python is high-level enough that the tools I need are in the language itself, saving me from having to learn a whole new tool.

And in the meantime, I just love doing this:
$ cd Products
$ mate CMFPlone CMFCore CMFDefault ATContentTypes
This opens TextMate with all those directories in a project, and I can grep (Cmd+Shift+F), edit, read, svn (Ctrl+Shift+A), add and remove files and do everything else I need. The alternative is to start Eclipse, find the right workspace, and add the particular folder to a project (or open an existing one). Thanks, but by the time Eclipse has loaded, I'm already onto my next task. :)

5 comments:

Andreas Reuleaux said...

As I already posted as a comment
to Martins blog:

You might want to try pydev, an
eclipse plugin for Python:
http://pydev.sourceforge.net/

For a shell with autocompletion
try pycrust & pyshell (now part of
wxpython, http://www.wxpython.org)

__gotcha said...

non-sensible coders use Vim 7.0 where they get code completion ;-)

Martin Aspeli said...

I just find that starting up Eclipse puts me off doing anything. Maybe when I get my new MacBook :)

But also, the window is so heavy (big, lots of toolbars, lots of panels). On my 12" at work it's almost impossible to use without a second monitor.

The TextMate + Terminal combination is so light and I can open context-specific "projects" (really just file sets) and close them again instantly. I guess it just fits my brain. If TextMate had code-completion and could introspect Python, I don't think I'd even think about it. ;)

zXc said...
This comment has been removed by the author.
zXc said...

myanmar friends network