Tools, again

Wednesday, May 21st, 2008

Computer Swedens developer columnist Tobias Fjälling the other day answered the question “What should a good development environment include?”. (MÃ¥sten i en bra utvecklingsmiljö - Computer Sweden).

Tobias list:

  1. Auto-complete
  2. Refactoring
  3. Navigationsupport
  4. Extendability
  5. Speed
  6. Debugger
  7. Code templates

I find this to be spot on what Ola wrote about) the other day which I already quoted:

It’s interesting, many Java programmers talk so much about tools, but they never seem to think about their language as a tool.

Tobias seems to be a good guy, I am giving him the benefit of the doubt and assume that he forgot.

The Programming Language Is Your Most Powerful Tool

Thursday, May 15th, 2008

Ola is so spot on with this one:

A New Hope: Polyglotism: “The one thing that I am totally sure if is that we need better tools. And the most important tool in my book is the language. It’s interesting, many Java programmers talk so much about tools, but they never seem to think about their language as a tool. For me, the language is what shapes my thinking, and thus it’s definitely much more important than which editor I’m using.”

I do not know how many discussions I have had with Java developers who questions Ruby et al. because there are no IDE’s with the same feature sets as those found in Java.

(Via Ola Bini on Java, Lisp, Ruby and AI)

Choice Is Good

Thursday, December 13th, 2007

I was happy to note that Dion Almaer commented on my blog post on Merb. Dion is one of my favorite bloggers/podcasters and I value what he writes highly.

But I disagree with him on this one. The problem with using Java for web application development was never one of too much choice. In fact, it was because of that choice that Java became a player in the server side market at all. Sun alone never had the answer to what was needed for server side development, instead the open source world stepped in and made incremental corrections.

The same thing is happening to the Rails world. The core team cannot create a framework that is a one-size-fits-all. The initial Rails proposal is great for a large number of webapps, but it is other things around it like plugins and JRuby that is making Rails a viable choice for all.

My Java tools of choice was usually Tomcat/Jetty, FreeMarker, iBatis, WebWork tied together with Spring or PicoContainer. What I hated was having some frankensteinian-enterprise-architect-design-by-comittee-lets-not-be-different stack forced upon me with a fullblown J2EE server, EJB’s, Struts or the JSF monster, sprinkled with an Eclipse-only development environment. And I hope dearly that Rails development is not going the same way where people question you on your choice of tools and wonder why you are not using MySQL and TextMate like the rest.

There is one choice that I do not miss though - directory layout. I am truly happy every time I do not have to choose it.

Instead of not having to choose, the most important difference I’ve experienced is that Java as a language together with the Servlet/J2EE spec induces a lot of accidental complexity, which is almost non-existent in the Ruby/Rails world. It is that which enables the increased velocity many development teams experience when switching to Ruby.