Stone soup programming is meant to evoke an image of throwing software components into a pot – in no particular order, and paying little attention to the ingredients – and the result being a nice application. The glue code between components is computed, statically or dynamically. In the static case, this becomes a simple form of staged metaprogramming (with a lot of dead code elimination). Stone soup programming is a very promising approach to more robust, extensible, composable software, and to free developers from dependency hell.
There are a few important features for stone soup programming to work:
- The components must be additively commutative.
- The components should be idempotent, e.g. redundancy as choice or fallback.
- The components must provide integration hooks.
- The components do not directly identify one another.
- robust and stable; nothing volatile, toxic, explosive
- Some notion of `seed` components (will be part of final product).
Ingredients can generally include weak suggestions, defaults, fallbacks, configurations, general knowledge, specific knowledge (e.g. about the host environment), application extensions, and so on.
There are many programming designs suitable for stone soup programming:
- blackboard metaphors or tuple spaces
- publish/subscribe systems, especially if data centric
- ambient oriented programming
- object traits
- concurrent constraint programming
- reactive demand programming
- constructive logics (ingredients are proofs, strategies)
- potentially paraconsistent logics (ingredients are knowledge)
Similar techniques can also be used in a module system, i.e. supporting a type-matching constraint-based linker. I have designed such a system for Haskell, and implemented a simplistic variation for sirea-core. The more feature-complete variation will be associated with a sirea-plugins package (which also supports live coding). This is achieved using `Data.Typeable` to describe dependencies, exports, and flexible constraints in a make-inspired applicative. By having some plugins export `Agent` kinded values to serve as toplevel behaviors, I can turn Haskell into a blank slate app that gains all its behavior from a stone soup of plugins.
Dependency management and setup code should be ever so much easier than it is today. Just toss it in one pot.