Various Programming Paradigms

2025-09-10

FB (function based)

• the basis of most popular programming languages (like "imperative" ones such as C, C++, JS, Python, and FP ones such as Haskell, and OO ones like Smalltalk, etc.)

• operations are "functions" chosen from an infinite canvas or in clumsy workarounds like namespaces or OO objects

• a function inhales ("binds") input data and exhales output data

• FB is constructed on an FB engine i.e. parameterized, value-returning subroutine scaffolding and stacks built out of much simpler primitives provided by early CPUs

• control flow: hard-wired by the paradigm (left-to-right, top-to-bottom, CALL/RETURN, GOTO), programmers get to express restricted control flow within the boundaries set by the paradigm

• time and ordering are eschewed

• synchronous, sequential

• impure data flow - tangles control flow into the action of passing data

Relational / logic programming

• operations are "relations" chosen from an infinite canvas or namespace-y things

• Prolog is based on a small Prolog engine. The engine determines control flow, programmers create "declarative" code and do not control control flow (modulo out-of-paradigm, clumsy baubles like "!", etc.)

• in/out parameters look like FB function parameters on the surface but are two-way instead of one-way

• time and ordering are eschewed

• synchronous

PBP - Parts Based Programming

• operations are completely isolated from Part to Part, operations do not leak out across Part boundaries, an operation inside one Part cannot invoke an operation inside another Part directly. A Part can send a mevent (essentially a message) asking to invoke an operation, but cannot demand nor expect that this will happen

• Ports only carry data

• Ports are one-way (a Part is like a transformer ; on the surface, it looks like a function except that functions, also, cause ad-hoc blocking (caller pauses until callee returns a value))

• PBP Parts are asynchronous

• ordering can be expressed flexibly, ordering matters and can be explicitly expressed by Software Architects and Software Engineers

• pure data-flow

Each of the above has its place (FB for computation, relational for exhaustive search, PBP for async). All applicable paradigms should be used to solve any given problem. Today, only one paradigm seems to be used - the FB one - all other paradigms are built "on top" of the FB paradigm which I claim stunts thought.

I argue that we need to have program development environments that allow us to use many programming languages at once and many paradigms at once. The idea that we can write programs using only one language (“one language to rule them all”) is out-dated, based on the limitations of hardware in the 1960s.

See Also

Email: ptcomputingsimplicity@gmail.com

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/65YZUh6Jpq

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html