This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Still More on Subsystems
Feed Title: Richard Demers Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rademers-rss.xml
Feed Description: Richard Demers on Smalltalk
I received the following e-mail from Runar Jordahl in response to this earlier posting on The Code Grouping Mess:
You write that "...we need to step back and ask what is needed to properly support subsystems, and what tools are needed to do that job." Yes, yes, yes! (I agree) You should, for example, be able to load/unload subsystems in your program easily. Not for the fun of it, but simply managing to do this indicates that code is well-structured.
In my opinion we have come a long way in Smalltalk. Even in VisualAge,
without namespace support, overrides of code and instance variables in
extensions, subsystems can be handled fairly well using ENVY. I do not see big obstacles in archiving this, given the current tools (Store and ENVY). Since you write that you "(...) have applied these concepts to major software projects", I guess you agree that the tools are in place? Only the practice needs to change, right?
I'm afraid I've been somewhat misunderstood. Runar and others seem to associate the concept of subsystems with lumps of code that can be easily loaded or unloaded from a running system. That is certainly one type of subsystem, but I mean something more than this. To me a subsystem is an entity at a level of an emergence hierarchy. Just as there is an emergence hierarchy of physical entities (atoms, molecules, organelles, cells, organs, etc.), so too is there an emergence hierarchy of software entities.
In Smalltalk terms, objects are entities at only one level of the hierarchy. There are other entities, at both lower levels and higher levels of the software hierarchy. In this, I take a purely reductionist point of view (though it may be better to call it "constructionist" for software). You may want to argue with me about the levels, but I see two lower levels:
Bit strings, whose form, semantics and operations are defined by whatever processes create and use them.
Fields, such as strings, numbers, pointers and images, whose basic forms, semantics and operations are defined by specific programs, such as the compilers of procedural languages. I will argue that such fields "emerge" from the lower level of bit strings, though emergence here (and in all software) is by human design.
Then there is the emergence level we call "objects" where each kind of object "knows" its own state and implements its own semantics. Objects, of course, consist of fields mapped onto memory, their methods are actually procedures, and there has to be a virtual machine implementing all of the basic OO concepts (identity, message-sending, inheritance, etc). But given all that, they are clearly something more than just fields mapped into memory waiting to be manipulated.
We have now had roughly 30 years to explore the concepts of object-orientation, and we have seen the evolutionary advantages provided by this emergence level. But we are also seeing that objects are not enough by themselves. There are a lot of badly written OO programs, and OO programs that have grown in size and complexity beyond human abilities to understand and maintain them. Missing are the structures and behaviors of higher-level entities that would enable us to easily handle additional complexity. I believe it is past time to begin exploring those higher levels of software emergence.
By "subsystem" I mean entities at (at least) the next higher level of software emergence. I am not talking about just code packaging. I am talking about entities that are instances of their own classes, and that interact with each other in powerful new ways.
I believe the best example of what that next level should look like can be seen in the System Objects of IBM's OS/400 operating system. But even without that level of system support, we can do a lot in Smalltalk to go to the next level.
Previous Topic
