philosophy

Philosophy

The intent is to have a tool that allows the easy composition of highly configurable applications with builtin error handling and logging. Failures are expected.

The origins of this logiciel is the desire to create a step by process, which is repeatable, and which reports all that happens, expecting some failures to occur. It needed to have user interaction dialogs, and to run once, or interactively in a loop until someone decides they've done it enough.

Particle.io boards communicating through the particle-cli come and go and are finicky when automating a process that works fine at human-terminal interaction speeds.

Thus, the original pain points of needing composeable parts which are consistent and reliable in their behavior along with an interactive way to play with those parts and construct bigger parts.
From, that, the list of things to prioritize follows. I doubt that I have cited all of their origins. Some are personal, and others are were driven by the original project. Still others came about as it became apparent this was more like a programming language than a framework. Although its restrictions and abilities give a definite shape to how things are done. Not doing things until they are truly necessary has helped prioritize the evolutionary steps that have happened. Having variables was only important for a minute, it seems completely unimportant now. If/Else seems like a good idea, No? Haven't needed it yet. But what if it was there ? How would that change anything? I'm going to wait until I need it. On verra.

Desirable things, idea's and concepts:

• What is executed is configurable along with everything about how it is executed.
• composeable parts
• consistent, reliable, repeatable.
• A REPL, read eval print loop, so it's easy to reason about and play with.
• Simple non-existant syntax
• Configuration file inheritance in an easy to read format.
• Easy and automatic generation of help.
• Easy to extend
• Transparent integration with python
• Transparent data store with easy access and manipulation for all uses; configuration data, command line data, internal data, and application data.
• Code is data, A configuration file might be all that is needed to code an application.
• Easy to read and reason about
• As stupid as possible, so that it's evolution is defined by pain points.
• Features should frequently be almost magical when implemented because the parts are all there. - sometimes they already work. - see eval
• Try not to make it just another lisp.
• Do we really need if? it'd be easy to make. How would it be used? would it introduce unessary complexities in the coding patterns ?
• Do we really need a stack or real variable de-referencing or scope at all ?
• Does this behavior or feature make things easier or harder to reason about?