Stone Soup Programming

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:

  1. The components must be additively commutative.
  2. The components should be idempotent, e.g. redundancy as choice or fallback.
  3. The components must provide integration hooks.
  4. The components do not directly identify one another.
  5. robust and stable; nothing volatile, toxic, explosive
  6. 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:

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.

Like Loading...

7 Responses to Stone Soup Programming

  2. Carl Gundel says:

    You need more than one pot, don’t you? Won’t you need a graph of pots? I don’t see how this idea is going to free anyone from dependency hell unless it is acceptable to produce very simple applications.

    • dmbarbour says:

      Yes. I imagine this would be performed in a fractal manner. The Internet might qualify as “one pot” on a grand scale, with software components like Google Search and Wolfram Alpha. But so could, on a smaller scale, each of the applications and services that contribute to its behavior. And so could each of the modules or agents that contribute to a particular application or service.

      Developers will develop applications at the scale they need, and will have sufficient control over selection of sensitive dependencies.

  3. John Carlson says:

    Umm. At one point, I considered compiling/translation as a pot. Throw in a program and get out machine code. Good Luck

  4. Andrew F says:

    How granular are the “ingredients”? Are we talking “Ajax request module” or something more specific? It seems like the application logic either has to go in the inter-module glue or in new modules/”ingredients”. As an application developer, what have I gained?

    This reminds me of component oriented game programming, which in your list is most similar to traits AFAICT. To make a new type of game object, just throw some existing components in a bag and let it run. It seemed to suffer from the granularity issue, as well as communication between pieces of code that are ignorant of each other’s existence. I never got a good answer as to how this worked in real life, but apparently it does.

    • dmbarbour says:

      I think pots and ingredients could coexist at many levels of granularity. At a high level, it may be modules or services. At a lower level, traits, constraints or typeful dependencies.

      As an application developer, such mechanisms can reduce efforts to compose and configure apps or subprograms. I.e. you only need to reason about or adjust combinations of elements, not permutations. Further, even if you write some aspects of the logic to hint and direct how elements come together, leveraging search may greatly reduce total glue code.

  5. Pingback: Pipes that Flow in both Directions | Awelon Blue

Leave a comment Cancel reply