Imprecise programming: How to stop worrying and love the bug May 3, 2011
Posted by olvidadorio in Programming.3 comments
A bug walks into a program…
…Nay, it rather puts on a suit, and becomes a program!
In this article I suggest a novel approach to programming that’s more like poetry and hopefully a lot less sucky… Caution, it’s a rough draft, but I’m quite keenly interested in making it intelligible, so if it isn’t please hit me. So here goes the story:
This afternoon, I was sitting on the loo, letting the usual trivialities flow through my mind; visual programming and such, the usual. One of my thoughts was: How cool would it be to have a user-interface that returns to the expressiveness of command line interfaces and the days of programming languages as operating system. That once again makes the average user an applied programmer as opposed to a mere button pusher along the lines of “select from this range of three fuckin’ fabrics”, nothing more than a consumer of pre-programmed options.
So while sitting there trying to figure out what that kind of user-interface might look like this idea for a new programming language paradigm (re-)struck. This paradigm kind of goes in the direction of natural language interfaces but might also be combined with some visual approach. But let’s try to put it together:
Poetic programming or the imprecise language
An interpreted programming language that is not precise, where the interpreter doesn’t let you or make you fully control, predict or understand the syntax or actual execution steps of your program. This language gives you the freedom to do “not all things considered” style programming in exchange for giving up control of well-defined execution behavior. Essentially it treats your code not as a drab cookbook but as a deep and mysterious poem, full of unexplored subtleities.
..But you say: This is bullshit. I don’t care if it hurts! I wanna have control. Heaven forbid if things go horribly wrong?!
Well, then we need fault-tolerance built into the language. Because, coming to think of it, we need fault-tolerance anyway. We should constantly be monitoring and testing our applications’ behavior anyway. Because things are going to go wrong anyway, anyhow, anywhere, at any time, and preferably while you’d rather be doing something else…
So a few fault-tolerance characteristics:
- Undo everywhere. All actions are journaled and undoable if ever possible.
- A limited and access-controlled set of non-undoable actions
- Possibly “let-it-crash” supervision and process capsuling mechanisms as known from Erlang, Akka etc.
- Context, context, context. The interpreter basically performs anaphora and general reference resolution on the tokens used in the programmer’s instructions. This may be an unsolved problem – in general and in natural language – but since we are creating an iterable artificial language from scratch, reference resolution might actually be tractable. I imagine a system in which various methods could be plugged in and refined bit by bit. Maybe one could even create a kind of economy/evolution, with selection criteria and feedback. But fundamentally this is a part where the language must be very malleable and customizable.
- Side effects all over the place; While functional programming languages such as Haskell try to get rid of all side effects altogether in order to get safe programs, we take the opposite approach, put side-effects into everything. Let functions’ execution affect each other, this allows for context, more information, less work. And then make sure you can undo it when things go wrong.
- Case-based programming. Have various views in which to do things, these actions are automatically journaled and can then be recalled using incomplete references.
what? 