Elixir for Programmers (PragDave)

This course has been re-recorded and released as a new edition, please see the thread here:

The only drawbacks from this course, is that, it teaches GenServer in a very unconventional fashion. Albeit that, it’s a very good course!

Hello @AstonJ

Would you recommend the course nowadays? The “” about Elixir presented in the course is still relevant today? I guess most of it should be still valid, but as I am starting now I do not know how things have changed in four years

I can personally attest to Dave’s talent as a teacher - he has a really unique perspective and problem solving approach. I’d highly recommend the course!

I was lucky enough to take his university course and have been active in the elixir community since!

Hello,

is this course still up to date ?

thanks !

I recently bought the course and love it: opinionated, and filled with wisdom and design notes. Going through it, there are just a few things that I’m a little unsure of. Caveat, I’m only 38% of the way through it:

• He makes changes to code first, and gets the tests passing again afterwards. I believe, though, that this takes away some of the tests’ strength, as opposed to first changing the tests, and then the code.
• I think that an implicit state machine is created, and to understand it, one must read the whole code. A small improvement would be to create “constants” for the various state symbols, to allow the compiler to catch misspellings.
• The function naming confuses me every time I come back to the code. E.g., tally/1. Maybe I’m used to Ruby, where we try to signal whether it’s a function or procedure, and what the return value is. I’d expect (depending on what it actually does) something like compute_tally, tally_for(game:), etc. Likewise, score_guess().
• So far, there are no “keyword parameters” (not sure what these are called in Elixir. This also makes it harder for me to understand function inputs. And then, I find that I often have to read through a function or two to determine one’s output. It’s very possible I’m not approaching Elixir the right way.
• He doesn’t use the { :ok, ... } & { :error, ... } convention and so more functions are impure than I would personally make.

Overall, though, a very valuable course.

Oh that’s a good surprise ! Directly bought it !

The more recent idea that failed to gain traction so far is encapsulating state inside of processes much in the same way that OO objects encapsulate/hide state.

He critizes the following state access and manipulation pattern:

# game is a struct
game = %Hangman.State{} |> Hangman.choose_word_to_guess
game.word_so_far
game.letters_guessed
game = Hangman.score_guess(game, guess)

In particular game.word_so_far and game.letters_guessed expose implementation details of the state which leads to inappropriate coupling. So he prefers

# game is a pid
game = Hangman.create()
Hangman.word_so_far(game)
Hangman.letters_guessed(game)
result = Hangman.score_guess(game, guess)

i.e. the implementation details of the state are hidden inside the process. However this is seen by some as an abuse of processes, pushing towards the “a process is an object instance” model.

As it is, this is possible today without processes with a “hands off my state” coding discipline:

# game is a struct
game = Hangman.create()
Hangman.word_so_far(game)
Hangman.letters_guessed(game)
{result, game} = Hangman.score_guess(game, guess)

And dialyzer even supports an opaque type:

Types declared as opaque represent sets of terms whose structure is not supposed to be visible from outside of their defining module. That is, only the module defining them is allowed to depend on their term structure.

The problem is that doesn’t stop anybody from depending on or messing with the state’s internal structure.

What would be needed is a capability to mark structs as opaque and have the compiler enforce it.

The idea is actually in place. game.ex manipulates the game’s data structure while server.ex encapsulates that state. All of that is wrapped inside the Hangman OTP application and each game instance is identified by a pid. Phoenix stores that pid in the session.

But given the application level decoupling that pid could be replaced by some other form of game_id to be managed in another way.

Ha ! A critical piece of information. I will put this on radar for sure now that I know he doesn’t push component in the course

That topic is about the ideas as proposed in the Empex 2018 Keynote.

The course predates that particular “component” development. It is my sense that the idea in the course is much simpler - favour decoupling. To that end “components” and OTP applications are synonymous for the purpose of the course - the Empex 2018 keynote added tooling/infrastructure for a particular implementation flavour of the component idea to move away from the Erlang/Elixir centric configuration practices (and templates on top of GenServer).

The course takes a much simpler approach - ignore Phoenix contexts and mix umbrella projects and use parallel application (Poncho projects) dependencies instead. It’s a valid approach but a lot of people are loath to give up the convenience that Phoenix contexts and umbrella projects afford them.

The resulting structure can be seen here
https://github.com/pragdave/e4p-code

• Hangman is the game (business) “component”.
• TextClient the command line client
• Gallows the Phoenix web frontend that uses the game “component”.