Are you tired of all of that modules, processes and functions nonsense? Do you want to just use classes, objects and methods? If so, use OOP [1] library in Elixir [2]!
[1] Actually, according to Alan Key, the inventor of OOP, “objects” is the lesser idea; the big idea is “messaging”. In that sense, I can’t agree more with Joe Armstrong’s quote that Erlang is “possibly the only object-oriented language”.
[2] Please don’t. You’ve been warned.
import OOP
class Person do
var :name
def say_hello_to(who) do
what = "Hello #{who.name}"
IO.puts("#{this.name}: #{what}")
end
end
joe = Person.new(name: "Joe")
mike = Person.new(name: "Mike")
robert = Person.new(name: "Robert")
joe.say_hello_to(mike) # Joe: Hello Mike
mike.say_hello_to(joe) # Mike: Hello Joe
mike.say_hello_to(robert) # Mike: Hello Robert
robert.say_hello_to(mike) # Robert: Hello Mike
joe.set_name("Hipster Joe")
joe.name # => Hipster Joe
Or @wojtekmach you could bite the bullet and actually learn FP on its own terms. To abuse an analogy, stop trying to ride two horses at once. Eventually you’ll fall off and they’ll trample you.
Jokes aside , Combining OOP and Functional programming has advantages in a select few cases.
I had a lot of fun with swift in that regard. (you could possibly do it in JS as well , but no … just no )
@bsmr you have quite successful OO with classes or prototypes implementations in languages that do not support it out there. This is simply a matter of syntatic sugar and mechanisms built into the language, that make it easier.
GObject in C is good example, it is heavily used in Linux world.
Open question remains if binding data with functions together is such a great idea. Personally I think it impedes ability to use functional programming style. It also encourages you to create functions that have side-effects, rather than transforming the data in visible, clear manner. Not to mention that majority of OO implementations are also promoting mutable data structures.
I’ve been thinking about this a lot lately. I had a discussion about this (e.g. the never-dying OOP vs FP – which is better argument.) yesterday with a colleague. My current state of mind:
OOP and (Actor-Model-based) Functional Programming allow for a similar amount of abstraction and conciseness in programs.
The features in (Actor-Model-based) Functional Programming (immutability, pattern-matching, real concurrency without deadlock-dangers) allow you to write programs that are much faster than the alternative in OOP-programs.
There are a lot less ways in (AM-based) FP to shoot yourself in the foot than in OOP, because patterns like Demeters Law or tell, don’t ask resolve themselves naturally when working with processes/immutability.
I don’t remember who, but someone showed me this image a while back:
Basically, there are less patterns to learn, because most problems we face in Object-Oriented design resolve themselves in the functional world.
The hardest thing is to change your mindset from a I have this data and I want to put them in a hierarchy of objects to I have this data and I want to write functions/processes that consume it.
Of course there are nice features like Polymorphism, that some claim only exist in OOP-land, but I’d argue that that isn’t true; In Elixir we have Behaviours and Protocols to fill this gap, and they work great at allowing code-re-usage and ‘swapping out components’.
I really wonder if Ruby could be rewritten in Elixir. You could argue that Ruby’s biggest problem is lack of concurrency. Would this solve the problem?
Ruby has many features that make it flexible to use (and easy to shoot yourself in the foot with in the long term), but which mean that there is a lot of metadata to keep track of, which makes the language quite a bit slower. Also, these features go against the concurrency-principles in Elixir. What would happen, for instance, if you would load monkeypatched code in one ruby thread?
So while it is doubtlessly possible to build a Ruby intserpreter on top of Elixir, a lot of Elixirs nice features are lost because it will have to support Ruby’s design choices that go against it.
I learned from José’s keynote at the first ElixirConf that Elixir was originally a prototypal OO language on the BEAM – closer to Ruby and Javascript. But, yes, it performed poorly and he went a new direction, bringing us the Elixir we know and love today.
I love it.
To abuse an analogy, stop trying to ride two horses at once. Eventually you’ll fall off and they’ll trample you.
