The circularity of IDEs and code proliferation
Use of text code* (eg. Java, C++) IDEs encourage non-dynamic code. Steve Yegge puts it perfectly:
The second difficulty with the IDE perspective is that Java-style IDEs intrinsically create a circular problem. The circularity stems from the nature of programming languages: the "game piece" shapes are determined by the language's static type system. Java's game pieces don't permit code elimination because Java's static type system doesn't have any compression facilities - no macros, no lambdas, no declarative data structures, no templates, nothing that would permit the removal of the copy-and-paste duplication patterns that Java programmers think of as "inevitable boilerplate", but which are in fact easily factored out in dynamic languages.* I say text code IDEs specifically to exclude the Smalltalk environment where perfect automated refactoring is entirely possible with very dynamic code.Completing the circle, dynamic features make it more difficult for IDEs to work their static code-base-management magic. IDEs don't work as well with dynamic code features, so IDEs are responsible for encouraging the use of languages that require... IDEs. Ouch.
11:46 PM, 02 Jan 2008 by Mark Aufflick Permalink | Short Link







