How many control-of-flow paradigms are there? (deleted)

Question

----zvolkov: trying to delete this old question but it won't let me ----

--Note: the question is NOT about programming language paradigms as in OOP vs functional vs. formal logic!--

---

I'm trying to grok different ways a logic can be expressed in a computer language. The thinking goes along the lines of imperative/declarative but at somewhat finer level of details. Or perhaps I'm mixing domains, then please tell me so.

Please help by suggesting new paradigms and/or providing references to programming environments best suited for each paradigm. I'm particularly interested in the "Goal seeking" category and how it can be implemented in modern programming environments.

Examples of the paradigms I have in mind:

• Sequential execution -- program follows the sequence prescribed in the code (whether written in OOP or procedural style). E.g. a C/C++/C# console program.
• Sequential execution imitating event-driven execution with explicit event loop. E.g. an early Windows API program.
• Interactive / Event-driven -- program reacts to external events pushed to it by the framework / system. No explicit event loop present in source code. Each event handler is a mini-sequential program. E.g. a WinForms GUI application or ASP.NET application.
• Goal seeking. Program (at the source code level!) is a set of tasks and dependencies between them. The environment arranges execution of tasks in the best sequence possible. What would be an example of this?

Examples of the paradigms that I believe are invalid for this exercise:

• Formal logic Program is a set of facts / predicates and ways to query them. E.g. SQL, Prolog, etc. At this point I don't think it's a valid example as you can't write a complete independent program in this style, you must mix it with another paradigm to make it work.
• Continuous optimization / independent agent. The program is one or more Goal Function(s) which it strives to keep at maximum possible value, plus an interface to external world. Not sure if this is a valid example as the internal logic of the agent seemingly has to be written in event-driven style...

Mmm... let's see if this makes sense to anybody out there

Answer 1

Sequential execution also includes Xorg event stacks.

An example of Goal-seeking programming would be, for instance, the Prolog language. No, Prolog is not just about a set of facts and predicate. You also can include deterministic, explicit behavior.

Also, I think you forgot a paradigm: purely functional, process-driven languages/VMs like Erlang and Caml.

Answer 2

Quartz composer for mac might be a good example of your goal seeking.

It consists of predefined "patches" that are graphically connected. The patches are only executed if they influence the final rendering at the current frame.

Answer 3

You seem to have missed (functional) reactive programming and array programming in your list of paradigms. As an example of the latter in J:

f=:1!:2&2"0
f*~1+i.10

prints the first 10 squares. It happens to print them out in order, but in more complex situations the runtime is free to run in whatever order it feels is more optimal. It does, of course, still keep the relative order of the elements of the arrays, as well as the relative order of separate statements.

Makefiles, though not well suited for generic use, are the classic example of being purely driven by a goal, a set of targets, and dependencies between them. This seems to fit your "goal seeking" definition perfectly.

Lazy evaluation means "do stuff in whatever order you want, as long as it returns a consistent final result", but in practice is implemented as "do as little as necessary to make progress" (though optimizations meddle with this a bit). For example, sequentially generating numbers of the form 2^i * 3^j * 5^k in Haskell:

(x:xs) @@ (y:ys) =
    case x `compare` y of
      LT -> x : xs @@ (y:ys)
      EQ -> x : xs @@ ys
      GT -> y : (x:xs) @@ ys
hamming = 1 : map (2 *) hamming @@ map (3 *) hamming @@ map (5 *) hamming
main = print $ hamming !! 300

This only evaluates as many elements of hamming as are needed to print the final result of 84375. I'd say this is pretty similar to "goal seeking", but dependencies do not need to be explicitly specified.