2 ms·
This is exactly where typical pure lambda-calculus based programming falls short. Lambda calculus afaik doesn't have the concept of IO, so it has to be bolted o
by snidane 8y ago
This is exactly where typical pure lambda-calculus based programming falls short. Lambda calculus afaik doesn't have the concept of IO, so it has to be bolted on in the programming languages as an afterthought.
I believe more powerful formalism has to be used. For example pi calculus or petri nets. In both you can represent the 'global variable database' as a process sitting somewhere and you communicate with it using channels or as a message passing in general. Lambda calculus is too constraining, because everything is a deterministic function and it can't model exactly this scenario. Another use case hard to model in lambda calculus is time. Eg. run some function after N seconds. Or plain 'sleep' function.
When you now look at programming languages in terms of, let's say, Petri nets, you see clearly how OOP (Alan Kay's message passing) is the part where you send messages between processes and FP is contents of a particular process.
Other than that, there are two types of OOP I noticed.
1. Alan Kay message passing. Originated from people trying to implement simulations
2. OOP as modules (Java, C++), aka 'Dog implements Animal' OOP. In this paradigm people try to come up with ontologies, ie. hierarchical models of data dependencies. Instead of using actual modules, people use classes for some reason. Then you can see module-like features implemented on classes, eg. private and public modifiers of methods.
'Dog implements Animal' should be modeled as 'Module Dog depends on module Animal'