This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: The Learning Curve
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.
Brad Abrams writes about the learning curve for languages and libraries:
One of the pearls of wisdom I took away from yesterday's class was Anders' assertion that when the C language was developed the learning curve for most developers was 90% in learning the language and 10% in learning some libraries.� But today with C#, VB.NET, MC++, etc the learning curve is more like 10% for the language and 90% for the library.� (Well, OK, maybe it is 20% for the language in the case of C++ ;-)).� The relevant point for my class was that if most of the learning curve is in the library then to make the system easier to learn we have to focus on the library. �It is also worthwhile to think about what the implications of this assertion is on the great language debates (C# vs. VB vs C++ vs Eiffel vs Cobol vs Ruby vs Perl vs�.)
This is true, as far it goes. The problem with libraries in the Java and .NET worlds is that they are assumed to be complete by the original developers - many of the classes are defined as final, so that you can't even subclass them, much less extend them. There's a flaw in this reasoning though - the flaw is the assumption that the library developers know all the possible use cases for their code, and have considered and allowed for all of them. That's simply not the case - just go look at all the bits that have been spilled in Java due to the various final classes, for instance. This is why - 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
Previous Topic
