Re:Advantages of Functional Programming in Java 8
by pmontra on Tuesday September 06, 2016 @09:33AM
(#12435854)
I'm the OP of this thread.
I add the example of Ruby's modules, that can be included in other modules and eventually classes. Combined with dynamic typing they provide a way to import very generic functions, even if they end up being methods (everything is an object in Ruby.)
Erlang and Elixir are a kind of trade off between functional and OO languages. Formally they are fully functional but their processes (a first class construct) are objects by all means. Processes receive messages (equivalent to method calls) and respond by sending other messages (the caller must pass its process id inside the original message.) We could say that OOP objects are castrated processes because they don't multitask.
What I noticed is that an Erlang/Elixir application has many function calls but far fewer processes/objects than objects in OOP programs. Processes usually encapsulate the main data structures. The equivalent of a Java ArrayList would be a process but its elements don't necessarily need to be processes. Pattern matching and some syntactical sugar help (example: http://culttt.com/2016/04/11/working-keyword-lists-maps-elix...).
Maybe those languages are a more equilibrate middle ground between the extremes of pure OO and pure functional, with the advantages of concurrency and all the external but mandatory infrastructure inside the language (deployment, supervisor trees, etc. - a part of devops.)
I add the example of Ruby's modules, that can be included in other modules and eventually classes. Combined with dynamic typing they provide a way to import very generic functions, even if they end up being methods (everything is an object in Ruby.)
Erlang and Elixir are a kind of trade off between functional and OO languages. Formally they are fully functional but their processes (a first class construct) are objects by all means. Processes receive messages (equivalent to method calls) and respond by sending other messages (the caller must pass its process id inside the original message.) We could say that OOP objects are castrated processes because they don't multitask.
What I noticed is that an Erlang/Elixir application has many function calls but far fewer processes/objects than objects in OOP programs. Processes usually encapsulate the main data structures. The equivalent of a Java ArrayList would be a process but its elements don't necessarily need to be processes. Pattern matching and some syntactical sugar help (example: http://culttt.com/2016/04/11/working-keyword-lists-maps-elix...).
Maybe those languages are a more equilibrate middle ground between the extremes of pure OO and pure functional, with the advantages of concurrency and all the external but mandatory infrastructure inside the language (deployment, supervisor trees, etc. - a part of devops.)