We are reviewing our plans for extensibility. Our initial thinking was that we had built a system that was too extensible, because it intimidated the storybuilder and required the presence of a programmer on team to get anything to work. Now, however, I see arguements pointing in both directions.
For Narrow Extensibility
By defining a given set of S-codes, we protect the storybuilder from S-code inflation. Who's gonna keep track of hundreds and hundreds of S-codes? What if the exuberant storybuilder cooks up so many functions and data structures that he runs out of screen space for the menus? What if his menu structures are garbage? How do we know he won't screw it up? Aren't we creating a support nightmare with broad extensibility?
We'll need to augment the narrow extensibility with some extra features. First, we'll need some blank slots in the personality model and the classifier. Second, we'll need a looping construct. What about deals? What about higher levels of mathematical abstraction in the Erasmo-language?
For Broad Extensibility
This is the initial concept, what we have already implemented.
First, we must consider our market. Anybody who can pay us lots of money for a license will have no problem keeping a programmer on staff to handle the needs of the storybuilder. So why do we need to make the storybuilder independent of the programmer? It seems like an unnecessary feature.
Then there's the matter of unancipated changes. How can we be so certain that our design will address all the needs of our storybuilders? Broad extensibility is the only way to cover all needs. The Erasmo-language is just too narrow.