What’s so old-school about text based programming?

Computerworld posted this piece that Microsoft developers are using text editors for development. What’s so old-school about that? What I mean really? Coding in text editors is not a trend among the grey-hairds like Lewis suggested on an internal thread. Text based tools are all the rave with the next generation of developers. I mean people that look like the Mac guy in the Apple commercials.

Lots of today’s developers are all fired up about Ruby, RoR, PHP and even javascript – they’re all about text programming.  Those are going to be the thought-leaders for the next generation of developers and they are programming with very similar tools and dev models that many of us started with. You may say that those developer icons at Microsoft are downright on the cutting edge.

Aside from that … are the development tools really the right thing to look at to judge state of development at Microsoft (or any other shop)? What about code quality? Innovation? Shouldn’t Microsoft developers be judged by that?

Some of my personal conclusions are that the developer(!) community doesn’t crave graphical tools – maybe it’s because they favor power and flexibility over dealing with level of complexity because that’s a higher priority for the job they are doing. Architects likely that deal with multiple more dimensions, i.e. cross-system dependencies, deployment, etc. and thus like other levels of abstractions that lend themselves better to a visual representation.

Furthermore, frameworks like RoR following the trends started with Java and .NET. They are raising the level of abstraction for developers – without going to graphical development models. I just spent time experimenting with some COM work. The productivity problem isn’t working with text-based languages like C++.  The much bigger productivity problem is that COM interfaces were designed for late bound environments and are extremely low level. That problem was solved either with graphical environments or text based environments like VB.

Again, use the right tool for the job. Libraries that raise the level of abstraction have been very successful to boost productivity for developers. Enhancements to text editors to speed up development have been around since way longer than Visual Studio. Pretty much everybody had their Emacs or VI rigged with all sorts of fancy macros to keep code clean. Graphicals tools, at least today are much more helpful for visualizing architecture and the high-level flow of a program. Those are different from executable code and are intended for a different audience.

What am I missing?