In my last entry I intimated that software, at the object level, had no real structure, and that this was the root of most of the problem in programming today. I’m sure this is a rather puzzling statement, as other than adding data members to a class, what kind of structure could you have for a class?
Before I go there, I want to detour slightly into some light theory. The most fundamental principle of the science in computer science could probably be stated this way: Don’t repeat yourself.
Its the principle of parsimony and Occam’s razor. Programmers quickly gain the skill of slapping repeated code chunks into one place and making it a subroutine – otherwise you don’t get out of Coding 101. In Computer Softese, this activity is known as factoring, or in the case of data, normalization. It all comes down to the same basic concept.
However, the kinds of stuff that typically gets factored is the behavior code – the code that does stuff – actions, operations etc. So what other kind of code is there? To quote our President, there is the “decider” code.
Strung throughout the “Actions” in the software are the conditional statements that evaluate the state of the nation and choose a codepath for the instruction pointer to travel. This decider code is the true nervous system for software – it continually tests its environment and activates appropriate activity in response to what it discovers. To put it another way, this conditional logic is the “brains” of software – the rest, the activity code – is the “brawn”.
Underlying the actual code is the logical “idea” of what the software should be doing – the experience it is really trying to deliver. This abstract ideal is, in fact, the most critical part because it is the actual point of the whole endeavour. But this fact remains obscure due to its format – a bunch of Boolean tests strung throughout the code each heading up a lot of code branches. So despite its primary importance as the most critical part of our software, it remains the portion that no one actually tries to normalize – that is apply computer science to!
We can describe this logical idea of the software as its set of “modes”. The Boolean conditionals are actually testing the raw data of the system to discover what mode the software is in, and then doing some activity based on that discovery. This is all fine. The problem emerges, the denormalization that is, when these same tests are done over and over again throughout the codebase. How can this happen? By being the typical and simplest (but not best) way to build out an API. And it is almost mandated in a complex, multilevel object-oriented class.
I’ll pick up on that next time.
I like the website – though I can’t find any details of the technology implementation…?
Can you comment on other implementations of HSM, such as the Quantum Frameworks?
In the past I’ve been on development teams where we’ve implemented simple versions of what you show here – state machine visual design tools which spit out XML, which is then translated into . They were very successful for obvious state machine components, but less so in other areas. We started to find that there were new design patterns which needed to be learned to create HSMs to ensure they were understandable and correct.
Anyway, nice to see people thinking about the way we represent design.
Cheers, Coopsnakes.
Hi Coopsnakes,
The website at the moment is just a first stab at getting this information out. Soon I will have another 2 chapters up which will complete the basic instruction on how to build Software Circuits.
I don’t have any language specific examples yet. However, for each piece of visual notation, I’ve provided a “code mechanism” in a generic form of pseudocode that should map to most (all?) OO languages.
So for the moment, it is a by hand affair.
However, we are actively developing a free tool which will be released within a couple of months, I hope, that will provide generated code in as many languages as we can get the XSLts made for.
And yes, the state machine approach only applies to complex, stateful software. A lot of code for the web these days doesn’t need this approach because the web pages themselves already act just like a state. The code on the server is the “Action” code + a little bit of “Transition” decision logic to decide what page to go to next based on the result of the Action.
There are also other “trivial” objects – objects that just act as data repositories and don’t have any real state.
And then there are the objects with two or three states that aren’t that complex, and it is a toss-up, when doing them by hand, if it is worth it to implement all the machinery to do a proper state machine.
With the tool, I hope to change that math to be very favorable to going the state machine route. Please keep checking back.
Mark
Somehow i missed the point. Probably lost in translation
Anyway … nice blog to visit.
cheers, Collectivism!!!