|
James Robertson, in his Cincom Smalltalk blog, writes...
[Even] though most of the learning is at the library level - the language and runtime still matter. In Smalltalk, one can extend or change any class or method you need to change. That's highly useful - because the library designers don't always make it easy to replace a given class via subclassing. Sometimes, you just have to go in and modify the base system (or build scads of wrapper classes). In BottomFeeder, I have had to both subclass and modify the base XML parser - in order to handle errors in ways that the original developer simply did not foresee.
It's a nice theory to say that the library can be fixed, or that an unchangable library is a boon - but that sound you hear is the sound of lost productivity.
Smalltalk systems typically have good version control, comparison tools, packaging tools, and browsers. An application in Smalltalk very often will add a instance methods in the Object class, and other so classes that come with the core system. These are only included in that application.
This is very hard to duplicate in languages like Java and C#, where you pretty much have to take what you can get from the vendor. Maybe "aspects" or some other mechanism can get around these core limitations to developer productivity. Doubtless not with the same ease and manageability.
Posted to critiques by Patrick Logan on 12/16/03; 5:47:45 PM
|
The Sound of Lost Productivity
