Don Box charts the course. If they get this particular item right, there's reason for a good long party...
Contain the growth of platform surface area - it's easy to design a complex framework - it's much harder to design a simple one. Now factor in ~30-50% growth in functionality with each release and my ears start to bleed.
To mix metaphors this is a tough row to hoe. Removing production features is almost impossible. Adding new features that don't conflict with or duplicate in some way existing features is hard enough. Merging features to get more expressiveness (increasing the power/effort ratio) is an art form that few people can even comprehend.
Consider arguably the most famous software framework: Smalltalk-80. The team's focus was on simplicity and a high power/effort ratio. They began (rounding off a bit) about 1970. They remained mostly under wraps for about a decade with significant evolutions about every two years.
Smalltalk-80 really hit the mainstream's awareness with the 1981 Byte articles. By 1984 several books were published and vendors from HP to Tektronix had ported the system to their hardware. In 2003 the Smalltalk-80 system is still recognizable, and even operates, within the many commercial and open source Smalltalk implementations.
The Smalltalk platform is still yielding results. Tektronix has had implementations running in oscilloscopes. Object Technology International (now part of IBM) has had real-time implementations (which have led to IBM's real-time Java implementations). And recently a 128kb real-time implementation has become available, including a TCP stack. How does this stack up to the dotnet "compact" framework?
A tough row to hoe indeed.
There are two classic platforms available today: Smalltalk and Unix (let's say BSD and Linux). Legitimate reasons exist for not building on either of them. But every new system should begin with these questions: Should either of these systems be the foundation for this new system? Why or why not?
No comments:
Post a Comment