Hacker News Reader

Comment by atonse | Hacker News Reader

The biggest adjustment for me was the fact that everything is immutable. Apart from that, everything has been simpler to reason about in elixir.

Now objects feel very weird.

View on HN

Elixir seems to encourage simple data structures — everything is made up of basic data structures, and since there's no encapsulation, libraries seem to be built with an attitude of "developers are gonna inspect everything so we might as well make things clear and simple". I only noticed this in contrast to libraries in popular OO languages (most recently Python) where everything is done through objects that often have inscrutable instance variables and "missing" methods/methods that library authors simply haven't gotten around to implementing.

Having a small library of functions operating on a small number of data structures makes programming a lot more intuitive than a large number of classes, each with their bespoke set of things you can do to them.

Instead of "lack of encapsulation", it's more "lack of private state". In an object oriented language, you have private instance variables and methods to manipulate them. In a functional language, you have functions which manipulate data structures.

If possible, the data structure would have straightforward fields which are public and documented. If necessary, you might make it opaque, expecting only the library which manages the data structure to manipulate it.

One way to think about this is that in functional programming, the "verbs" (functions and manipulation patterns like map) are more generic and the "nouns" (data structures) are less important than in OO languages. See http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

> straightforward fields which are public and documented

The rational (whether right or wrong) in OO for private fields and public "manipulator" methods is that the field's representation can be wider than the intended public use. For example, you may store the credit-card number as a string of digits, but only allow the correctly CRC'ed number to be set.

Of course, in a more functional paradigm, you would have a credit card number type (which is just a function that strictly enforces the domain and range of the possible valid values), rather than an object which can have independent identity storing the same information.

There is no encapsulation like in OOP (data level), but there is another kind of encapsulation (process level): a process is the only one accessing/modifying its own state. And this is very liberating when you need to think about what is going on, what could go wrong...

You should try Haskell, perhaps. It's very much in the functional programming camp, but has oodles of data structures in rather extensive libraries.

It encourages a functional way of thinking, IMO: since you can't have mutable objects, use immutable data structures and functions which alter them, such that where you may have had:

    x.f(y)

you now have something like:

    x = f(x,y)

I've found that years of functional programming have mangled my brain. Now when I use something like Python, I only use dataclasses and accessor methods on them, or write methods which perform and return the result of some computation based on the values of the object.

Yup I find myself wanting to do the same.

Writing these static methods that pass around data. But it’s not the same.

I also really miss pattern matching when I don’t have it. But more languages have been adding it.

I always joke with my team that the best thing I did for my Python was learn Erlang, and that was when I was stuck with NamedTuples and not DataClasses.

Reply on news.ycombinator.com