Lambda the Ultimate

(This first sentence would have been a rhetorical question, because those are short and clear, but usually someone thinks I want a question answered, like I'm asking a homework question. So the next paragraph begins with the question. But it's rhetorical. It's only meant to frame a topic clearly as the top point of a reverse pyramid. Questions are good for that. It might have something to do with stupid headline style that inspires Betteridge's law of headlines.)

Do you have alternate ways of framing descriptions of program behavior with better results (clarity, concision, directness, etc.) in some domain, or class of application, which simplifies or untangles the pattern of desired activity? I ask for a couple reasons. First, there's not much traffic and I hope to spur a small amount of discussion. Second, I'm cooking up a fairly inchoate idea I might try to describe under this general heading. Rather than devote a topic to just my crazy idea, the general idea seems more interesting: how you describe a problem affects how easy it is to solve.

It's sort of an invitation to compare and contrast how you model what happens in code, including cliché paradigms like object-oriented or functional. But marketing prose for old stuff isn't what I hope to hear. (And I may write a dialog mocking a market pitch if really blatant. :-) Instead I hope to hear about less conventional ideas, whose explanation have an odd or surprising quality (even if it means half-baked and not obviously useful). This implies a weird ontology, if a programming language revolves around an unorthodox idea, because a programmer must think in terms of that model to write code. I anticipate no responses, though, except for "everyone must start using actors now", but a happy surprise would be nice.

I'll take a shot at describing my half-formed idea in a post later. But it hasn't gelled at all, and I'm even having trouble finding words that tend to imply the right thing. It involves viewing code as usually waiting for something to happen. For example, in a UI, menu items wait for you to select them, and a command line waits for you to enter another command. Installed programs wait for you to use them, and functions in a library wait for you to call them. Servers wait for requests, and network cards wait for packets. Writing code generally involves editing what is ready to react to stimulus in some form of input, usually with an aim to generate output or cause effects. But the word wait is a bad fit because it implies active waiting, with a purposive (almost teleological) framing that doesn't include the necessary aspect of passive option. Starting from option seems equally valid, and other words too perhaps. There's more, but just as unclear so far.

Edit: An idea which doesn't gel can sound tautological, making you ask: What is the point? Exploring a thread can cause every loose end to dry up so you only know what you knew before, that you merely tried an awkward angle.