Story Based Development

People think about the world, in terms of stories.

But actually even software developers think about code, in terms of stories.

That's because its just the right way, of thinking. It's not a limitation.

Even something as simple as "display this file on screen as a picture". That's a story. There's no code here, so it's a story.

In other languages, we are told that documenting your intentions is good developer practice. But, with speedie, you will actually code your intentions. Your intentions will be the code.

This doesn't just allow the "true meaning" of the code to be "machine processable"... This also makes the code easier to understand by people! After all, a story about code, is generally much shorter than the code itself.



The technical "trick" behind it... is to write code to solve problems, in the same language that the problems are expressed in.



Story based development, is where you write your program down as you would normally think of it, as a human, and it gets turned into code. This is kind of magical. After all, normal people don't understand code, but they do understand stories. If people could use stories to create programs, then what couldn't they create? Even software developers think about code in terms of stories. But here your stories will be the code.


Story-pieces



Obviously, its never as easy as that. How do stories get turned into code? Well the compiler will need a databank of "story to code" translations.

The whole thing will revolve around reusable "story-pieces". These will be a small piece of code, and some meaningful description of that code.

Much like how real stories (like a good fantasy novel) are made out of smaller events, the compiler will take "story-pieces" and assemble them, to make a bigger story. Except it's also piecing together the code, to make your program for you.

What happens if the compiler is 'missing a piece' of the story? Someone has to write that piece. I think it will feel rewarding, because you only have to write the story once, it will increase re-use greatly.

In this case, if the missing piece was "parse some XML", you would import an existing XML library, and just meaningfully describe it in Jeebox language. Like taking a strawberry pie, putting it in a box, and writing "Strawberry pie" on the box. So it could fun and easy.

In this way, the first people working on these "story-pieces", would do the hard work. But after that, it would be easy for everyone to write programs in terms of stories.

It is definitely something that requires a community to build, simply because of the number of "story-pieces" needed, will be large. So it's a very "parallel" task, something that requires many people. Much like a "user created dictionary" (wikipedia) is a very parallel task, but can also be built up in a short amount of time with enough people.


Stories help to hide information



Another thing that interests me, is hiding of information. For example... people may want to write story-pieces, but stop people stealing what they made.

Let's say you invented a concept of how to do something. If you can describe the original concept... that's really the true invention, not the implementation, because many implementations are possible.

For example, the concept of “an 8x8 grid to describe a chess board”. Two implementations might be:

• An array, of an array, of "ChessPiece" objects.
• A 64 byte string, where each byte represents a chess piece.

During the translation of story-pieces into actual code... the compiler can obfuscate the implementation. Basically, create some code that's really awkward.

You only give the compiled code to the end-user. He'll never have the original concept.

What happens when someone steals the compiled code? Well... if the implementation changes in horribly incompatible ways, each version... then anyone who has invested time writing a program around one of your stolen implementations... is now stuck with that old version.

Meanwhile, the obfuscation causes you no issues.

Each "Decision point" in your code, multiplies with other decision points. With 10 decision points of 3 approaches each, you'll have 3^10 (59049) possible incompatible versions of your program.

The compiler can purposefully write... code, that is "only as good as it needs to be".

If in the future, you need a faster version... you'll suddenly be able to do things faster than they thought was possible... after all... they are using an inefficient version of the code they stole.

Meanwhile they are limited... Good surprise for the theives...