So, knowing that creating stable software is a hard endeavor, it is one of our responsibilities to build the means and concepts to make this possible without growing paranoia. And this is when formalisms come into play.
A formalism can be formulated as a concept and a concept can be implemented as a piece of software. Concepts are the most basic building blocks of software, and so they can be applied universally. Most of them even exceed their intended scopes and cross boundaries leading to unexpected applications.
Concepts are like lego bricks, they can be combined to create new ones with new capabilities that were never intended or predictable. Concepts are software patterns that can be formalized.
Having a versatile framework where we can move away from all these daily annoying development problems and do not need to wait for the compiler until the coffee gets cold, we may now be able to create a concept platform to prototype formalized ideas instead of creating code that sooner or later suffers from intransparency.
.NET is one step in this direction, moving away from programming languages to the patterns and concepts that actually make them running, and so providing a platform to create new languages at instant.
Though they are restricted to the basic facilities of the runtime, Microsoft does a very good job in extending it to support even the most unusual language features like closures or lambda expressions.
But one must accept that seamless creativity does not result when writing software programs.
Perhaps this is because writing code is not interactive. A high degree of interactivity is the key to feel like a kid when playing with toys, so it must be a goal to avoid the compiler altogether.
We need to create objects as soon as possible and visualize them at instant. Thousands of software products are offering these possibilities in their respective domain, but only a handful are trying to generalize graphical editing and none of them is able to make it affordable for a developer to create a set of formalized widgets for simple “playing around” or prototyping a formalism.
Parameterization requirements make it even worse, and editing a parameterized graphical model that changes in many aspects when you modify one parameter, makes me think that graphical editing may not actually the answer to what we want.
Visualization required, of course.
Then, what’s left is the most effective input device, the keyboard. But taking a look at all these scripting languages leaves me with the feeling that we are missing some interactivity again.
The conclusion is that we need a textual editor that is capable to create objects, visualize them at instant and support a rapid prototyping of ideas.
Probably this editor will be based on the .NET framework, and the “object creation” scripting language is itsself based on .NET reflection and attributes. Additionally, the objects and associations offered to be used may also be .NET classes.
The language may enforce you to write down code which can be executed line by line in the order defined by their computed dependencies. And so the runtime is capable to create these objects right after you typed in a few lines.
Then imagine an inference engine which is always aware of the interdependency of the created objects. It may support partial views of the graph and incremental rebuilds of the model in case of parameterization changes.
Finally, imagine a second view or screen where the current dependency graph is shown and custom visualizers are able to render the scene in a domain specific representation.
Wouldn’t that be a seamless, universal creativity platform?
Start playing, again!