There are many forms of computing hardware systems, ever more so these days with TPU (Tensor Processing Units), GPUs, Multi-Core CPUs, Parallela Epiphany cores, FPGAs, Risc-V ISA, Analog Computing, Quantum Bits, Memristors, AI, ML, Deep Neural Nets, ...

thocp.net/biographies/pa…

The linked paper above is one older perspective. It was written just as the age of networking was beginning and published two years before the advent of Smalltalk-80 that brought in a new paradigm of Object Oriented Programming were objects communicate via passing of messages.

Functional Programming makes rather massive claims that it is somehow fundamentally different than the procedural programming that came before it. Both are based upon functions calling other functions with the passing of arguments as in Lambda Calculus mathematics. 🤔 Not new.

There are differences in procedural programming flow and functional programming language flow, to be certain.

What is lacking from most FP languages though are the higher level abstractions of message passing between objects not to mention taxonomies of objects aka classes.

As modern research has shown classes are not the only way to organize abstract data types with their related data items and related code that works on those data items. As the Self Language demonstrates Protypes are effective. Traits are also an effective enhancement/replacement.

A primary problem with functional programs is their over confidence in their Lambda Calculus Type Systems that force rigid types upon all variables and parameters in their systems.

It is crucial to note that strict types do not mean correct programs contrary to FP mythology.

Smalltalk, a dynamtically typed systems where everything is 1 uniform strong type of "object" and where their behavior or class information carries their "object subtype" around with them means that objects are far more resiliant and free to move uncontrained through a program.

Contrast this with static typed systems where variables and parameters are highly constrained by the type of the data that is permitted to be placed into these variables or parameters and where these variables and parameters carry the type information, not the data object itself.

By using static variables and parameters to store the "type information" of the contents the data values are not first class objects as they are literally divorced from their "type information"; they are highly constrained to only travel along their prior proscribed type paths.

Static types are so constrained that each type is like a city crisscrossed with a different set of rails that only take one width of wheels like different train track rail widths before they were standarized to one track width.

Every type has its own track width. Doh.

In Smalltalk like systems all objects are of one type of data, an object pointer to the record structure of the object that includes a pointer to the object's behavior or class where the object's methods live. In some variants individual objects can have their own unique methods.

Another aspect mentioned in John Backus's paper linked above is that of program reasoning; a field undergoing a lot of research. It turns out that runtime type inference enables the collection of object type information that can agument any reasoning systems for OOP.

One of the crutches of the Functional Programming illusion that breaks down their "pure functional" attempts is that the real world interferes. Programs are just not idealized pedantic mathematical beings. Programs have to deal with the real world. Monads in FP lie to keep pure.

In order to maintain the illusion of "pure functions" that only compute from their inputs and never store or use stored state the FP concept of Monads was introduced to protect the lie that the environment is purely mathematical. Monads are used to hide real world effects.

Monads are used to hide real world effects to keep the lie of mathematical purity alive as long as possible. Why is this a lie? a facade? a deceptive trick?

The notion of pure functions relies upon not storing or accessing state to compupte.

Monads store state, thus the lie.

Let that sink in. Monads store state, the data value and two functions, each time they are created to provide the pure functional illusion that no state is to be stored.

To provide the pure no state claim they have to store state, thus the lie, the deception, the con of FP.

Be that as it may be about the con game that is FP let's be very clear, if it works for you to be so deceived please continue to be so deceived and keep using it.

Oh wait, you can't as you've not been informed. Now you can't claim ignorance of the central pure lie of FP.

Other languages have had Monads long before it became fasionable. For example, Smalltalk has ValueHolders and there are design patterns for various kinds of monads. In addition Smalltalk has proper exception handling so that error monads are not required.

Common monad types.

"monads can be seen as layering "effects" on:
Maybe: partiality (uses: computations that can fail)
Either: short-circuiting errors (uses: error/exception handling)
[] (the list monad): nondeterminism (uses: list generation, filtering, ...)
...

...
State: a single mutable reference (uses: state)
Reader: a shared environment (uses: variable bindings, common information, ...)
Writer: a "side-channel" output or accumulation (uses: logging, maintaining a write-only counter, ..)
Cont: non-local control-flow (uses: numerous)"

"Impure functions can call pure functions, but impure functions can only be called by other impure functions."

So the pretend pure functions are at the bottom of the call stack.

Link for the list of monads above and the quote, stackoverflow.com/a/8777358.

Real pure functions are those that only compute with their input parameters, and that do not store state (including not storing them vicariously via monads), and do not access encapsulated state.

Smalltalk's messages "ifTrue:ifFalse" on the Boolean classes are pure functions.

Smalltalk's messages "ifNil:ifNotNil:" on Object and UndefinedObject classes are pure functions.

Smalltalk systems have many pure functions written as methods on classes all over the system class library.

In OOP we're just not pedantic about it as we deal with the real world.

Are their some benefits to the pure illusion con game? Sure you get to have your bliss in a fantasy of pure mathematics of the massively typed straight jacket of Typed Lambda Calculus.

Untyped Lambda Calculus allows more freedom to move and is part of the ancestry of Smalltalk.

Type Systems do not make correct real world programs. 🤔

Another primary limitation of many Functional Languages including Clojure is that they focus on Pure Functional Datastructures that limit pointers to one direction only by using highly restrictive Directed Acyclic Graphs (DAG) only.

No cycles are allowed, no object A <-> B.

Pure Functional Datastructures (PFD) constrain the data pointers to one direction only. Imagine a a tree structure, balanced or not. That's it. No networks in the data as cycles are not permitted.

Many real world data structures require network graph connected objects.

Apparently two objects are not permitted to link to each other in PFDs. How restrictive.

An Invoice object is allowed to point at its invoice items via a collection but heaven help the PFD programmer, that invoice item isn't allowed a back pointer. Nope as it is evil in PFD/FP.

Apparently some Functional Programming advocates admire the Relational Database Model and it can be seen why both systems disconnect programs from the data they are operating on.

Why is meant by "disconnected"?

Data is defined, often in different systems, from Code.

In a RDBMS system the database defines the relational tables of data where row instances are stored. Rows from the same table or different tables are accessed by fields that have identifiers common between these rows. They are used as search queries via SQL for instance.

The programs that operate upon a RDBMS are not stored in the RDBMS, sure some of the SQL queries might be stored in a system such as IBM's DB2, but the bulk of code is in programs written in other computer languages, such as Cobol, Java; therefore code and data are disconnected.

The powerful idea of Objects is that they:

1) communicate via messages,
2) define #related data items into an abstract type,
3) bring together the related #code & #data in one unit,
4) the combined data and the code live together,
5) encapsulate data/code,
...
N) plus more.

The notion of Objects, a type that combines related data items with the code that operates upon them is highly antithetical to some functional programming adherents and languages because Objects methods store state and that violates the central "purity" lie of FP, store no state.

It is no wonder that some adherents of functional programming do not like state storing objects. The irony is that the Abstract Data Types that FP uses are objects without the code so in fact objects are a more abstract type than their types!

In the #ZokuTalk system #CodeIsDataIsObjects, code is data is objects is data is code. Data, Objects and Code are #Homoiconic & interchangable.

The capability of code to be data enables code to be reasoned about.

Dynamic type inferencing enables FP style reasoning.

#ZokuTalk makes use of some Pure Functional Datastructures internally, however ZokuTalk enables safe use of Cyclic links between objects so network graph connections between objects are permitted in a safe atomic environment.

No need for unnecessarily constrainted data.

In other words #ZokuTalk permits all forms of data object structures without limitations that overly contrained PFDs impose to force their "pure" vision upon the application.

Real work oriented systems need to deal appropriately with the real world requirements pragmatically.

In researching languages to choose the design of #ZokuTalk it became apparent early on that certain core design principles where far more important than others.

The #Homoiconicity principle enables code to be data, data to be code, and objects to be code (and data).

#Messages between #Objects are the big idea from Alan Kay's Smalltalk, as are full #Block lambda closures. In addition #Encapsulation of data behind methods that respond to received messages provide appropriate data hiding so that internal representations can change easier.

All Objects are of a single type so that objects can flow via message sends as desired at runtime throughout the programs method and variable pathways. All objects are #FirstClass Objects providing uniform #MetaProgramming capabilities in #ZokuTalk.

As part of the meta programming capabilities in #ZokuTalk everywhere a #LittleLanguage is needed the full #Message, #Object and data, #Block closure #Syntax (#MOBS syntax) is used so that all programming has the full power a the full general purpose programming language.

Objects collecting related data items as instance variables to store that "state" in an Abstract Data/Object Type (ADT) plus binding related methods/functions that work on said grouped data items is a central core organizing principle that is incredibly useful.

Design principles can conflict with each other. Objects store state from their working methods.

In Functional Programming storing state is considered bad and evil as it violates the "pure math functional programming" model.

To live together these principles need a resolution.

It is interesting that some Functional Programming languages such as Scala have integrated Objects yet others such as Haskell apparently strongly reject the notion of Objects to the point of blind religious ferver by their adherents.

That is fine as it is always their choice.