Thanks for the example dave!
Interesting discussion being generated!
shifters98
sztosz
I really like the library, although I didn’t have chance to use it. I have my doubts that hiding so much implementation and adding layer of abstraction is making it a bit “magical” but the trade-off might be worth it.
And I really enjoy reading discussion about using functions over processes etc. It’s so insightful!
0
jeremyjh
OTP processes are not intended as a mechanism for encapsulation and information hiding, and they are not free. I thought you agreed with this from your response in the related issue I opened. I do think encapsulation is a bit of an issue with structs. If you want to encapsulate data, one possibility is to use private records. Of course people can still fiddle with it, but at least it makes the intent very clear. You can also use @opaque types if you are using dialyzer.
2
OvermindDL1
Proper data hiding in a functional language should be handled by the typing system. Hopefully we get a decent one ‘on top of’ elixir someday (wish I had the time to write it!). 
Otherwise we have as much data hiding as Python has, which is to say not really any. Even Dialyzer is so optional that most people don’t use it. 
2
pragdave
Author of Programming Elixir
Sure, but using those is clearly not sanctioned by the owner of the original server, whereas passing out state is. It’s a question of intent.
Yes, I agree that’s something to think about. And that is one of the reasons I’m exploring this. I’m trying not to be doctrinal when I play with all this stuff: OO vs functional etc are just labels, and often labels divide opinion more that they help.
One thing that motivated all this thinking was Phoenix itself. Think about plug. Is there a less functional piece of code in the Elixir world? Side effects, hidden state, the magic conn variable? And routes, with the side effect of creating an entire module of code.
Initially I really disliked this .It went against everything I thought I knew about functional design. But the more that I thought about it, they more I realized that all that design stuff wasn’t more important than the simple model that plug represented. Would I prefer it to be “pure”. Sure. But what’s probably more important is that it presents a model that people can work with.
So, based on that kind of thinking, I’m exploring different ways of thinking about design in Elixir. It has the advantage of not being a fully functional language, so it allows us some wriggle room in which to experiment. I’m seeing what happens if we relax some of the “rules” that everyone says are necessary.
You say my approach is imperative. It might be, in the small. But my mid-term objective isn probably closer to a continuation-passing style, or Joe’s idea of process pipelines, or event sourcing.
The experiment is to design code as sets of cooperating but relatively independent processes. Each process acts as a kind of reducer, taking an input and the current state and producing and output and an updated state.
When I first tried coding like this, every function was stateless: it received input and state as arguments and returned an output and updated state.
But if you try that for any real world program, you end up with a big ball of mud: the state becomes unwieldy. So instead I’m currently trying the opposite: each function (I guess really, each server) manages its own state, and that state is always private.
Do you lose some of the benefits of other approaches? Sure. You mentioned error reporting, and I agree that’s a major issue. (But that’s as much the fault of the horrible error reporting that the Beam does. I think that some effort spent there would make life easier regardless of where state is held.)
But my approach is not to focus on the stuff that we might lose, but instead to look at what could be gained. I understand all the negatives, all the reasons that “this is how we do things.” Instead, I’m excited by the idea that there might be changes that end up making it easier to write code in this increasingly complex world.
3
OvermindDL1
Isn’t Plug exceedingly functional? It’s a simple pipeline that passes in a Plug.Conn and passes out a new version of it (not editing the original, since it can’t), with no side effects, hidden state, only magic is the macro pipeline builder (plug Blah instead of just doing |> Blah.call(unquote(Macro.escape(Blah.init([]))))), which is quite easy to understand overall. The only impure parts about it is when the socket is communicated with like getting the request body or sending the result, which are done using messages to the socket process, but Plug itself is entirely pure otherwise. o.O
Functional doesn’t mean pure, they usually go hand in hand in most cases because purity makes functions trivial, but it’s not a requirement. The BEAM breaks purity because you can pass messages and set process flags and data. OCaml breaks purity with ref’s (although when the Algebraic Effects get pulled in then that will become pure, but right now it’s not), as well as an escape hatch for doing low level assembly calls. Etc… etc… But they are both very Functional, generally some of the prime examples of Functional Languages.
You can always set process flags/data at each call to make it more obvious where some data came from as well as decorating the state immediately with some ‘recently accessed’ info or so, there are patterns.
1
pragdave
Author of Programming Elixir
You’re making my point for me. Plug.Builder is remarkably not functional, but no one cares because it is easy to understand.
That’s exactly what I said.
0
OvermindDL1
But it is functional though.
Plug.Builder is a set of compile-time macro’s that transform ast to ast. And all calls made within it are also functional.
2
pragdave
Author of Programming Elixir
Sorry, but anything that keeps state in module attributes is not functional. The use of @before_compile is a pretty good hint that we’re storing state somewhere to be used later.
The Plug DSL is decidedly stateful…
0
OvermindDL1
Except it only uses those at compile time, and they are inline then, like here:
https://github.com/elixir-plug/plug/blob/v1.7.1/lib/plug/builder.ex#L105-L145
This is where you use Plug.Builder, it defines a few function, sets a few compile-time variables (behaviour and plug_builder_opts), and at the end it does register an attribute to aggregrate an attribute. However, a module attribute at compile time is the same as just normal bindings in a normal function at runtime (it is runtime at compile-time), they are not accessible before defined and they can be rebound just like function bindings.
Even still, this relates to Purity, not Functionality, it is not entirely ‘pure’ as I think Module.register_attribute/3 sets something in an ETS table, but it is still Functional.
It is stateful in the same vein as bindings in a function are stateful, like this:
def something(a, b) do
c = a + b
blah(c)
end
This function is stateful in that there is intermediary state before the c = a + b expression, a new state where c is bound, you cannot use the c binding before it is bound (state!), and the state is passed into the blah/1 call, but this is still Pure and Functional both.
5