This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Back to Basics?
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
The spark behind this growing trend comes down to control - enterprises tout IDEs as the development tool du jour, with supporters arguing that programmers will get more done if they can do all their work inside a single environment. But many programmers (especially experienced ones) prefer a markedly different approach, using code editors and pluggable modules, modes, or other extendibility features to pick and choose just the tools they need. They don't enjoy being shoved into a single development environment, and contend that IDEs are resource-intensive, slow, and have many more features than are really needed to get the job done.
Maybe that's because the IDE's are huge, bloated, and slow? Have a look at the footprint (both on disk and, more importantly, in RAM) of Eclipse, JDeveloper, etc - they are huge. I only have 256 MB of RAM on my two development systems - so that pretty much rules out any of the mainline Java tools. On the other hand, a baseline VW system starts up using 12 MB of RAM, and my standard development system, with all my tools loaded, uses 17. Heck, a dev image with all of BottomFeeder loaded - and a bunch of test artifacts lying around in workspaces - runs 24 MB. There's more:
"The editors in most IDEs don't have nearly enough features and they make manipulating code difficult," says Chris Rathman, a consultant and software developer. "For example, I need to be able to work with several hundred files in a single session and I must have the ability to do global search and replaces. Oh, and it has to be fast."
Hmm - that sort of refactoring in VW using the Refactoring Browser is nearly instantaneous - even on old, slow hardware like my PII 400. Maybe if the tools had a consistent meta environment, and didn't live on huge directtory trees of source code... The other intereresting thing is the need for editing features. Using Smalltalk, I'm simply never editing large bodies of text (other than SSP pages for the web - for which I often use an html editor). If the source for a method is so large that I think I need a power editor, then I made a mistake. Most methods should be short, and do one job - and by short, I mean - in Smalltalk terms - 7 to 10 lines. Consider the productivity loss from a language that, by its nature, pushes you towards long methods.
I also love this oft cited theory:
When it comes to expanding developer skill levels or teaching new programmers, there is some debate about whether code editors or IDEs are the right way to go. An IDE's extra features can act as a set of training wheels for new developers, depending on how much knowledge they bring to the table at the start. However, many of those who adhere to the code editing philosophy believe that junior programmers have an easier time learning the fundamentals of a programming language using a code editor because the new developer is not saddled with learning the bells and whistles of an IDE.
I guess some people just like creating mountains of text so that they can feel powerful about the whole thing. This is all part of the He-Man school of code construction, where the more text you create, and the harder it all is, the better.
Previous Topic
