A very interesting discussion, the only things I’d like to add are that naming is IMHO extremely important and very underrated and great care should be taken with it since it tends to stick around (and the time to change it is now), and that distinguishing between stateful code and stateless/functional/pure code (and having different names for those) is definitely useful
1 Like
Interesting presentation! while I agree with most of his criticism, the “you all are doing it wrong, but don’t worry: I got The Solution right here” format of the talk is not something that I usually enjoy because it often generates cult of personality, and we really don’t need more of that 
One thing I am a bit unsure with is the distinction between library (defined as “components that have no state”) and component (stateful processes?). It would be useful if he could organize all these ideas in some sort of document and include formal definitions for his proposed nomenclature.
3 Likes
In writing OOP software, I have found a very useful “practice pattern” (for lack of a better name). Sometimes I am designing a class, and I know perfectly well that there will be a whole family of similar classes, sharing functionality that should be in a base class, but I’m having trouble figuring out where to make the base/derived cut. In that case I implement it as a single class, then when the need for the second class comes along I copy/paste/modify to create it. Once they’re both working well, then I compare to see what true commonality remains. I’ve found that this is a very effective way (for me at least) to get good hierarchies with less mental effort…
1 Like
I agree with Dave about the direction Elixir should be going in (and it is).
I disagree with his implementation advice because the community can go an increasingly functional direction without changing any of the underlying tools.
Take his criticism of Phoenix. The web interface can be separated from the components within an umbrella structure. This is what Functional Web Development with Elixir walks the reader through.
I strongly disagree with his critique of GenServer. He’s free to share his own library, which people can adopt if they prefer it. But he himself admits that it evaluates to the same underlying code! Why obscure this from developers? The point of the existing syntax is that it is an extension of Elixir’s Behaviour design pattern (which makes implementing a GenServer easier and more predictable).
As for the naming conventions, I may agree with a thing or two but why not bring it up with the Mix and Phoenix teams and either see if they agree or learn their objection(s)? Don’t advocate to replace them all together!
I think he also misses the practical use cases Phoenix addresses. Its being Rails-like makes it friendlier for those coming from Ruby programming and highly productive. I think Mix’s default is a minimalist alternative. Add in the power of the umbrella directory structure and one can implement his functional design ideas without the hassle of assembling the components together.
This is where he should focus his leadership efforts–the component paradigm is only as useful as the assembly’s implementation, which he barely discusses. Spell this out and let the community figure out how to best adapt existing tooling to this architecture (since he hasn’t).
Build upon, don’t renovate.
3 Likes
I’m not sure if this is on topic or not, but I think GenServer is stuck in the uncanny valley of convenience.
It’s supposed to be a convenient interface, but it leaves just enough boilerplate for you to fill out that it feels confusing and unwieldy.
For example, someone new to Elixir would be better served to just skip the abstraction entirely.
This is why some have said that you’re better off learning Erlang before Elixir. Because Erlang does a better job of displaying what’s actually happening.
1 Like
Where’s the documentation for that?
I ask because Elixir allows you to write Erlang code, so if the documentation is sufficiently clear, again, it’s not an either-or issue.
I do agree that I haven’t seen a good explanation of Elixir’s Behaviour design pattern… if you know of any good talks/reads 
UPDATE: Just got to Part III of Functional Web Development with Elixir. This part of the book goes over the same design-level critiques as Dave.
Wow, really? This makes me more interested in that book… What do they say about it?
A post was split to a new topic: PragDave’s new Componant library - his preferred way of building apps
