Original URL: https://www.theregister.com/2010/02/28/ides_versus_the_people/
MS and Oracle's big dev tools - who needs 'em?
Viva Emacs and Vim
Posted in OSes, 28th February 2010 07:02 GMT
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.
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#.
Fight the power
So, in a way, the command line helps as a check against too much corporate or political control over our computing infrastructure. You can keep up on the latest tools to maximize your efficiency or the maintainability of your code after you've left the project.
But given the fact that today's IDEs pack a fair amount of power, the right question becomes not one of asking whether to use an IDE but how to one most efficiently.
You have to pick and choose when to bring out the big hammer. Here are some tips. Make sure your build processes use command line tools so the IDE is an optional part of your software process. Avoid IDE wizards that generate lots of boilerplate code you or your customers will later have to maintain by hand. Focus on the processes and tools that minimize the time between a code change and test results. Make sure the commands to checkout a project, make a simple change, rebuild and redeploy are accessible without an IDE.
If you're not under corporate orders and can choose your IDE, the question then becomes should it be Visual Studio, Eclipse, NetBeans or IntelliJ?
Visual Studio may struggle to keep up with the fastest-growing platforms supported by competitors Apple and Google, but if you are writing Windows C++ code I can't imagine choosing anything else. For the rest, Eclipse seems like the front-runner - open, free and supported by lots of big companies, making it the safe choice.
Separate but equal?
Oracle vociferously maintains it will support the former Sun Microsystems NetBeans as a viable option going forward, but there's a ton of overlap with JDeveloper that will be difficult for a top-down company like Oracle to manage gracefully. For Java, I use IntelliJ primarily because it has the best Vim plug-in and for what I use is still better than Eclipse by most measures.
Eventually, the best features in modern IDEs will be available in ever more modular, standards-based, decoupled environments, ensuring we as individuals can continue working with the tools we like and keep from being shoehorned into a single suite.
It's just that big software has never been enthusiastic about making its products lightweight, more decoupled and simpler, so this innovation is unlikely to come from one of them. ®
Former Adobe Systems' principal scientist and lead architect Jeff Vroom has designed three declarative software platforms during his 20-plus years in the industry: Adobe's LiveCycle Data Services, ATG/Dynamo, and AVS. He now spends his time coding, consulting and blogging.