Fridge-Oriented Programming - [Are We There Yet?]

Sometimes I like to cook.
There are at least two modes of cooking: dish (aka intent, goal, design) mode and fridge (aka tools, economy, implementation) mode.
Dish - you define what you want and allocate required resources.
Fridge - you start with controlled resources and look for a wish that fit the most.

We (humans) switch between this modes all the time, usually too fast to recognise.

I sense we are too focused on “how to” (fridge) part, and don’t pay enough attention to “what is it for” (dish) part in our current state [of software development].
If implementation name is REPL, then design name is PERL.

Thread macro “->” is a good example.
Thread of what? My intents or CPU cycles?
Easier (to read) is a tricky argument.
Easier to confirm a happy path? Maybe.
But what about other options?
We have to untwist a thread into a DAG.

Yeah, I know, sometimes “just do it/any option” is not a bad option. Sometimes.
If you forget about other options. Like, don’t do it now (at all).

Take a look at any workflow/dataflow/visual-programming-tool.
It always “implementational”, time-forward, left-to-right.

Even the best example I’ve found so far ( goes halfway in example.
Intent (aka result) for each edge goes first, but still “finish” is the last line.

(def job-graph
  {:start []
   :result1 [:start]
   :result2 [:start]
   :finish [:result1 :result2]})

Do you need your “finish” or you just like to “start”?

I like the fridge metaphor, but I’m not sure about your example!

That have been tried many times. See Prolog. Doesn’t work well for most problems, but sometimes it does.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.