3 ms·

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 buil

by feifan 6y ago

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.

jake_morrison 6y ago
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-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- chii 6y ago
  > 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.
- leghifla 6y ago
  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...
eru 6y ago
You should try Haskell, perhaps. It's very much in the functional programming camp, but has oodles of data structures in rather extensive libraries.

by feifan 6y ago

jake_morrison 6y ago

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-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

chii 6y ago
> 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.
leghifla 6y ago
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...

eru 6y ago

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