This post originated from an RSS feed registered with Agile Buzz by Keith Ray. Original Post: Agile Languages Feed Title: MemoRanda Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics. Latest Agile Buzz Posts Latest Agile Buzz Posts by Keith Ray Latest Posts From MemoRanda

Christopher Diggins asks "What would a developer expect from a more agile C++"? My answer: the first steps towards agility from C++ would be to move away from the source-file-based compiler/linker setup. Consider that Extreme Programming, the first Refactoring browser, and many of the people involved in the Design Patterns movement all started with Smalltalk programmers. In Smalltalk, the compiler, byte-code-interpreter, the debugger, class browser and editors, and all classes and methods, are all objects that can be manipulated like any other by writing code or using tools provided in the GUI environment.

While Java code starts as source files, a Java source file has to parsed only once to create a .class file: after that, when compiling other source files, any references to that class can work with the .class file instead of re-parsing the source. Contrast that to C++ compilers that have to reparse the header files for every source file that #includes them. Sure, there are some optimizations supported by various compilers and IDE. I use #pragma once and precompiled headers when my development system supports them, but the text-file based system, the preprocessor, and the syntax of C++ combine to make it very difficult for anyone to create refactoring tools for C++. Without refactoring tools, C++ will never be as agile as Java or Smalltalk.

Consider using Objective-C as a dynamic C-based language instead of C++. It has some reflection capabilities, and its classes are represented as objects at run-time. Objective-C's objects are "completely" polymorphic (unlike non-virtual methods in C++) and the "optional-typing" features of the language allow header files to be almost entirely empty -- speeding compilation.

Objective-C is still being enhanced by Apple... try/catch/finally has been added not too long ago. Key-Value Coding/Key-Value Observing are another useful feature in Objective-C/Cocoa.

Two big things missing from Objective-C/Cocoa are refactoring tools and garbage-collection. In theory, a conservative garbage collector could be built into the Objective-C run-time, but in practice there's a lot of legacy code inside and outside of Cocoa that probably would need revision to properly work with GC. While Objective-C still has the problem that C++ has with the preprocessor and including header files, the syntax of the language is simple enough that refactoring tools could be implemented, if the people with the right skills are motivated to work on the problem.