This article is more than 1 year old

MS and Oracle's big dev tools - who needs 'em?

Viva Emacs and Vim

A chunky Visual Studio 2010 releases soon, packing more features and representing perhaps more hours of development than any other single vendor's development tool.

How could you resist?

And yet many do resist such highly automated and powerful productivity tools and continue to favor Emacs or other text editors and command lines for their development.

Ruby, the fastest growing language ecosystem, has evolved primarily without IDE tool support. What explains this love/hate relationship with the IDE among developers and the companies that make them?

Will we ever all get on the same page?

There's general agreement on the productivity benefits of the modern IDE: more structured code editing and navigation, import and dependency management, and real time syntax checking. Code quality improves with semantic analysis, which can detect uninitialized and unused variable errors. Code readability improves with richer syntax highlighting that helps differentiate between static, instance, and local variables.

Larry Ellison

Big software wants your inputs

But lighter-weight tools offer a more rapid edit/test cycle with less waiting time. The command line remains one of the most powerful and fastest ways to interact with your system.

Emacs, Vim, and other editors have basic syntax highlighting and code navigation for an even broader set of formats despite the fact that they lag behind IDEs in features. Though IDEs offer impressive plug-in capabilities, traditional script and config files seem easier to learn and use and ultimately more flexible.

Command line workflows offer a more flexible, less integrated and less guided approach to development. You learn how to use them one tool at a time. Development and adoption of new tools is usually easier as you are not tightly coupling tools into one complex user interface. Admins, analysts, and designers use command line tools, making it easier for them to work with developers when the IDE is not front and center.

The IDEs themselves have warts. Writing an IDE plug-in is a rather involved process specific to each IDE. Configuration is stored in opaque proprietary formats managed by labyrinthine UIs. IDEs also fail as crossover tools for administrators, analysts and designers.

It's no surprise that Microsoft, IBM, Oracle and other members of "big software" promote IDEs strongly. If you write code in their midst, more than likely you've been using one as your primary tool for a long time. You might even be required to use a particular tool on a particular project. From a marketing perspective, the IDE helps with lock-in, product bundling, and perception that each vendor is a one-stop shop for development productivity.

But developers tend to resist lock-in, are wary of bundling, and shun brittle or overly-complex corporate standards. Just look at the Ruby ecosystem as an example of the backlash against all things Java or C#.

Next page: Fight the power

More about

TIP US OFF

Send us news


Other stories you might like