I am glad I am somehow contributing to the great work you guys have been doing. Even though my approach may not be the best sometimes, that is always my end goal ! 
That is correct. PragDave introduced a concept in one of his courses called a Tally. A tally is a special representation of the state we give to the user. In this case, the state would be the quizzes map, and a tally could be a part of the map plus some extra information the user needs. This is a pattern used in FP I was not aware of before trying his courses, but I have had difficulty applying it in other places.
- Have you ever heard of giving tally’s to the client?
- If so, what are your thoughts on this pattern? How would it (hypothetically) fit the mastery example (if at all)?
On page 111 you present the user with this code snippet:
def quiz_fields(), do:
%{ mastery: 2, title: :simple_addition}
Here you create this function that helps us create a quiz by setting some fields. As you can see in this map, the title field is an atom, yet on page 49 you specify the quiz.title is of type String.t. In a discussion we had previously, you mentioned using Strings for scenarios where the input comes from users is better because we don’t fill up the atom’s table (and avoid a crash).
Am I missing something here? Could you please elaborate on your decision to use an atom for the title instead of a String ?
On page 118 you append errors to the list of errors instead of prepending. In the first chapters you specifically recommend prepending to lists rather than appending to them. Could you help me understand the benefits of taking a different approach here?
