Elixir for Programmers (PragDave)

Just bought the video course. The “Programming Elixir” course-book convinced me this should be the next stop on my path of Learning Elixir.

1 Like

Why should a non-umbrella architecture be considered better?

2 Likes

There was a discussion about that here.

3 Likes

Less temptation to couple code, and more reuse of independent components.

Dave

5 Likes

I just bought this course. These reviews are awesome. I got half way through the Programming Phoenix and realized 1.4 is coming soon and so is he book, a lot of what I learned is relevant but very much different so I am hoping this will be better.

1 Like

Nice - let us know what you think, I hope you’ll love it as much as I did :003:

Programming Phoenix is out in beta for 1.4 too btw :023:

1 Like

Just bought. Looking forward to it!

2 Likes

I am brand-new to Elixir and Phoenix, and I just bought this. I look forward to diving in shortly!

Edit:

P.S. I have never used Rails, yet most Phoenix tutorials seem to make references / comparisons to it. On a first look, it looks like this one departs from that assumption that everyone has a Rails background - so I am liking it already.

5 Likes

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