This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Bang your head against the wall, repeat
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.
A Smalltalker familiar with dotNET (he's been involved in C# projects for the last 18 months or so) pointed me to this MSDN article - the second of a series on the presumed move from software craftsmanship to software factories. I'm not so sure that we'll get there anytime soon, at least not with Microsoft leading the way. Here's an interesting admission:
The first reason is the current economic model for commercially sustainable reuse. In the previous article, we discussed the Language Framework pattern, which describes the progression toward automation:
After developing a number of systems in a given problem domain, we identify a set of reusable abstractions for that domain, and then we document a set of patterns for using those abstractions.
We then develop a runtime, such as a framework or server, to codify the abstractions and patterns. This lets us build systems in the domain by instantiating, adapting, configuring, and assembling components defined by the runtime.
We then define a language and build tools that support the language, such as editors, compilers and debuggers, to automate the assembly process. This helps us respond faster to changing requirements, since part of the implementation is generated, and can be easily changed.
The first two parts of this pattern are within reach for most organizations, but the third part is not. Developing language-based tools is currently quite expensive, and therefore makes economic sense only in broad horizontal domains, such as user interface construction and data access, where the necessary investments can be amortized over a large customer base. For this reason, commercial implementations of the Language Framework pattern are supplied almost exclusively by platform vendors.
Look at that last paragraph - Developing language-based tools. Here's a tip - these folks might want to talk to Steve Kelly at MetaCase. The tools that MS thinks are too hard for most of us are not, in fact, out of reach - unless you insist on using low productivity development platforms - like, say, the ones Microsoft (and Sun, and IBM) promote. Here:
We are now at a point in the evolution of the software industry where frameworks and tools must become more vertically focused, in order to realize further productivity gains. They must provide more value for smaller classes of problems. This breaks the current economic model because markets for vertically focused frameworks and tools are too small to support platform plays, and because the domain knowledge required to develop them is housed mainly in end user organizations that have not traditionally been software suppliers.
The premise is correct - the expertise does exist only in end user environments, and the generalized frameworks that MS is after are just too hard to build if you work in static environments. There's simply not enough flexibility in the CLR or the JVM to support that kind of work - static typing, the need to cast repeatedly to accomplish anything useful, and the continual larding of new language "features" simply makes those environments more and more complex - makiing it harder and harder to actually get anywhere.
Steve kelly demonstrated the MetaCase tools to me at the Cincom Smalltalk User's Conference last December - it's an amazing little system - it allows you to build domain specific languages (leveraging the expertise of the end organization). The key thing is, it's hard to build tools like the ones MetaCase have - at least, if you use straightjacketed environments. Smalltalk removes the artificial complexity from the tool building exercise, and lets us take that next step - the one MS wants to get to. They have the right ideas - model driven design and domain specific languages - but the wrong tools with which to implement those ideas. If you want to see those ideas in action, visit the guys at MetaCase
Previous Topic
