Elixir for Programmers (PragDave)

Hi,

I have some questions:

  • This course receive updates? I see comments above about this course use Elixir 1.5 and Phoenix 1.3.
  • This course is one time payment or monthly?

Thanks!

I don’t think the course has received many updates, but I don’t think any are needed either - any changes or differences will be minimal.

It is a one time payment - get it you won’t regret it :003:

3 Likes

Thanks for your response.

I just bought xD

2 Likes

Nice - let us know what you think :023:

1 Like

Know exactly what you mean. This is a valid selling point in my view.

With Dave’s new component library just released - I am intrigued - i have his book (and many others :slight_smile: ) - this has lead me here as i want to learn his approach to elixir coding in particular the component and decoupling. Thanks all for the drawing my attention here.

1 Like

The main reason I am quite reluctant into buying his course is because none of his ideas gained traction. I am talking about his opinions about components, libraries and even Noddy.

All seemed good ideas overall, but after spending hours reading community feedback they just don’t hold. And this is what scares me.

Can anyone give me feedback on my fears? Are they valid, or does he present something else, something new?

I haven’t taken the course, so I can’t give any useful feedback. Can you show me some specific examples where his ideas have failed to gain traction in the community?

A small set of opinions regarding his component library (there is a huge one with over 100 posts but I forgot its name):

His Noddy library that didn’t really took off:

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

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

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 :smiley:

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.

https://pragdave.me/blog/2019/01/10/where-does-state-live.html

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.

3 Likes

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

2 Likes

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.

2 Likes

Hello,

is this course still up to date ?

thanks !

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!

2 Likes

Hello @AstonJ

Would you recommend the course nowadays? The “:thinking:” 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 :thinking:

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

1 Like

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

1 Like