You cannot view this unit as you're not logged in yet. Go to Account to login.
24 Comments
sammygaddon November 8, 2020 at 2:03 am
The first example looks really confusing to me as an Elixir noob. I think it would be a bit easier to understand if the params variables had different names. Overloading them makes things even more confusing. (Or do I completely misunderstand how this works??)
I’d love to answer your question but I’m not sure I understand it. Are you referring to the example at the “In Pieces and Whole”? Or are you referring to Exercise #1? Which params would you change to improve the clarity?
I’m referring to the example in “In Pieces and Whole”. The first line declares a params variable. Then the function binds the arguments to another variable also named params.
At least this is how I understand it. Or are those two variables actually the same?? If not then, to me it would be easier to understand if they had different names to signify that they are different. (A guess simply moving the first line below the function would also help)
Ah! I see. Thank you for explaining that. The idea with the outer params variable is that it’s like the params you get from Phoenix in a controller from a user POST. They come in with string keys.
Within the scope of the function do_work, the params argument to the function is different. In this particular case, they would have the same values, but they are different. So yes, I can see that this is confusing. Would it make more sense if the outer params were named phoenix_params or web_params?
Yes, for me that makes total sense. I think `web_params` would makes this more clear for noobs like me 🙂
Thanks!
Mark Ericksenon November 10, 2020 at 1:02 pm
Awesome! Thanks for the feedback! I’ve updated the lesson.
Francisco Quinteroon November 25, 2020 at 8:30 am
Awesome exercises. The last one took me a bit because I wasn’t pattern matching in the function definition but when I realized that, it all went downhill to have passing tests.
I loved the explanation and again I was having doubts and needed to understand better was this large of pattern matching and your explanation was very helpful for me.
Just the second exercise I made a mistake on pattern matching and after review the sample of the NestedBinding.award_bonuses function I realized the test with success and the rest was builded more quickly.
And it wasn’t needed to put the ‘ = _response’ for match the map.
And your notes are amazing thank you!
I love the format. I notice that I instinctively went to a case statement instead of defining the function multiple times. Are there pros/cons to that approach that I should take into consideration? Specifically, here I am referring to the classify_response(...) function. I did the following
def classify_response(response) do
case response do
%{.... relevant pattern ...} ->
{ok:, token}
%{.... another pattern ...} ->
{error:, invalid:}
end
end
That’s a good question. In a simple example like this, where the code being performed on a match is a simple mapping to a tuple, there isn’t much difference between a case and using separate function bodies.
In general, I encourage you to reach more often for separate function bodies. Consider what the case statement would look like when more involved logic is performed on each match. It could easily become many lines possibly including nested case statements. A wonderful side-effect of having multiple function bodies is that the logic for what to do in that case is fully contained. This makes the code easier to understand. The functions become very straight forward and single purposed.
Upon further reflection, the suggestion for multiple function bodies seems to be the most “pure” of the functional approach. Each function “does one thing” and your job as a developer is to make it “do that one thing well”. I think you could argue that having multiple pattern matches in one function via a case statement could violate that principle. Especially when you aren’t limiting your pattern matching to only a single “domain” (e.g. customer, order, etc..).
Well said! I agree that the pattern matches in the function declaration helps keep individual function bodies focused on a single purpose. Functions that are focused on a single thing are much easier to understand, test, and maintain. However, it is also common to use case statements inside functions for simple things like this…
def place_order(%Customer{} = customer, order_params) do
case Orders.create(customer, order_params) do
{:ok, new_order} ->
# notify customer that order was placed
{:error, reason} ->
# notify customer of order problem
end
end
In this example we need to execute the function Orders.create/2 before we can have data to pattern match on. Also, the code we perform in the case matches will likely be simple. So there are plenty of times we want to use a case too. It becomes a question of complexity and when is the right time to refactor it out into functions.
You are correct. They are functionally equivalent. It is really a personal preference. I think the Credo library even accepts both versions but all of the code must do it consistently the same way.
The community convention is to define the pattern first and then name it (if desired). The critical part is the pattern, so that’s why I like it first.
But you are right, they both give the same results. 🙂
Learning to program and I am loving your courses Mark!! Thank you for providing them and please make more! Maybe a short one on either using Exercism.io’s problems and/or common problems/challenges concerning app construction and build out? As if you are not doing a lot already. I love what you are doing at Fly.io!!
Question:
From my beginner perspective I am confused why there is such a debate about dynamic versus static typing when types appear to be taken care of with patterns like the one you used above for Billing. I have to be missing something, could you explain this to me or provide a link possibly?
defmodule Billing do
def apply_charge(%{id: customer_id} = customer, charge) do
record_charge(customer_id, charge)
notify_customer(customer, charge)
end
end
Static types are checked at compile time. The code won’t compile if the compiler isn’t satisfied that all the types, variables of those types and the operations on those types are all valid. This gives some greater compile-time guarantees and even enables more powerful refactoring IDE tools.
Dynamic types are checked at runtime. Like in the pattern matches, the pattern is checked against the data at runtime… during program execution. So it becomes possible to write the following.
def do_work(customer) do
IO.puts customer.invalid_field
end
This will compile… because there is no check or type declaring what customer is here. But it will fail during executing because the field is invalid for the actual data passed in.
A con for static types is that you spend a lot of time doing work just to satisfy the compiler. A lot of language features (like interfaces) get created just to help provide types while trying to separate them from the data. You end up doing things like “dependency injection” just to work around the constraints of the types. I find it adds a lot of complexity that gets in the way of the expression and intent of the code.
There are pros and cons to each approach (static vs dynamic). Having worked in both, as you can guess, I prefer dynamic. However, others will prefer static. I hope that at least helps a little in understanding the difference.
I hope you have fun as you continue on your programming journey!
That was more than I hoped for, thanks!
Oh, this weeks Thinking Elixir talk with Dave Lucia was super interesting for me since I imagine making an app that this stack and architecture might well serve. Thanks, again!
The first example looks really confusing to me as an Elixir noob. I think it would be a bit easier to understand if the params variables had different names. Overloading them makes things even more confusing. (Or do I completely misunderstand how this works??)
I’d love to answer your question but I’m not sure I understand it. Are you referring to the example at the “In Pieces and Whole”? Or are you referring to Exercise #1? Which params would you change to improve the clarity?
I’m referring to the example in “In Pieces and Whole”. The first line declares a params variable. Then the function binds the arguments to another variable also named params.
At least this is how I understand it. Or are those two variables actually the same?? If not then, to me it would be easier to understand if they had different names to signify that they are different. (A guess simply moving the first line below the function would also help)
Ah! I see. Thank you for explaining that. The idea with the outer
paramsvariable is that it’s like the params you get from Phoenix in a controller from a user POST. They come in with string keys.Within the scope of the function
do_work, the params argument to the function is different. In this particular case, they would have the same values, but they are different. So yes, I can see that this is confusing. Would it make more sense if the outerparamswere namedphoenix_paramsorweb_params?Yes, for me that makes total sense. I think `web_params` would makes this more clear for noobs like me 🙂
Thanks!
Awesome! Thanks for the feedback! I’ve updated the lesson.
Awesome exercises. The last one took me a bit because I wasn’t pattern matching in the function definition but when I realized that, it all went downhill to have passing tests.
I loved the explanation and again I was having doubts and needed to understand better was this large of pattern matching and your explanation was very helpful for me.
Just the second exercise I made a mistake on pattern matching and after review the sample of the NestedBinding.award_bonuses function I realized the test with success and the rest was builded more quickly.
And it wasn’t needed to put the ‘ = _response’ for match the map.
And your notes are amazing thank you!
Awesome lesson!
I’m glad you liked it!
I love the format. I notice that I instinctively went to a
casestatement instead of defining the function multiple times. Are there pros/cons to that approach that I should take into consideration? Specifically, here I am referring to theclassify_response(...)function. I did the followingdef classify_response(response) do case response do %{.... relevant pattern ...} -> {ok:, token} %{.... another pattern ...} -> {error:, invalid:} end endThat’s a good question. In a simple example like this, where the code being performed on a match is a simple mapping to a tuple, there isn’t much difference between a case and using separate function bodies.
In general, I encourage you to reach more often for separate function bodies. Consider what the case statement would look like when more involved logic is performed on each match. It could easily become many lines possibly including nested case statements. A wonderful side-effect of having multiple function bodies is that the logic for what to do in that case is fully contained. This makes the code easier to understand. The functions become very straight forward and single purposed.
Upon further reflection, the suggestion for multiple function bodies seems to be the most “pure” of the functional approach. Each function “does one thing” and your job as a developer is to make it “do that one thing well”. I think you could argue that having multiple pattern matches in one function via a case statement could violate that principle. Especially when you aren’t limiting your pattern matching to only a single “domain” (e.g. customer, order, etc..).
Well said! I agree that the pattern matches in the function declaration helps keep individual function bodies focused on a single purpose. Functions that are focused on a single thing are much easier to understand, test, and maintain. However, it is also common to use case statements inside functions for simple things like this…
def place_order(%Customer{} = customer, order_params) do case Orders.create(customer, order_params) do {:ok, new_order} -> # notify customer that order was placed {:error, reason} -> # notify customer of order problem end endIn this example we need to execute the function
Orders.create/2before we can have data to pattern match on. Also, the code we perform in the case matches will likely be simple. So there are plenty of times we want to use acasetoo. It becomes a question of complexity and when is the right time to refactor it out into functions.Given that:
response = %{payload: 123}Please, what’s the implied difference between:
def fun( resp = %{payload: data} ), do: {data, resp} and: def fun( %{payload: data } = resp ), do: {data, resp}When fun(response) is called they, I get the same result.
You are correct. They are functionally equivalent. It is really a personal preference. I think the Credo library even accepts both versions but all of the code must do it consistently the same way.
The community convention is to define the pattern first and then name it (if desired). The critical part is the pattern, so that’s why I like it first.
But you are right, they both give the same results. 🙂
Thank you for such a great response. I’ll stick with the community convention.
Wow!!! This lesson made me thinking ‘pattern matching’. 💯
Awesome! It’ll become your new super power!
Learning to program and I am loving your courses Mark!! Thank you for providing them and please make more! Maybe a short one on either using Exercism.io’s problems and/or common problems/challenges concerning app construction and build out? As if you are not doing a lot already. I love what you are doing at Fly.io!!
Question:
From my beginner perspective I am confused why there is such a debate about dynamic versus static typing when types appear to be taken care of with patterns like the one you used above for Billing. I have to be missing something, could you explain this to me or provide a link possibly?
defmodule Billing do def apply_charge(%{id: customer_id} = customer, charge) do record_charge(customer_id, charge) notify_customer(customer, charge) end endHi Bill! Thanks for the kind words!
As for static vs dynamic types, it’s a good question and I’m not sure I can do it justice here. I’ll give it a try. You may have already seen this, but in case you haven’t: https://thinkingelixir.com/elixir-in-the-type-system-quadrant/
Static types are checked at compile time. The code won’t compile if the compiler isn’t satisfied that all the types, variables of those types and the operations on those types are all valid. This gives some greater compile-time guarantees and even enables more powerful refactoring IDE tools.
Dynamic types are checked at runtime. Like in the pattern matches, the pattern is checked against the data at runtime… during program execution. So it becomes possible to write the following.
This will compile… because there is no check or type declaring what
customeris here. But it will fail during executing because the field is invalid for the actual data passed in.A con for static types is that you spend a lot of time doing work just to satisfy the compiler. A lot of language features (like interfaces) get created just to help provide types while trying to separate them from the data. You end up doing things like “dependency injection” just to work around the constraints of the types. I find it adds a lot of complexity that gets in the way of the expression and intent of the code.
There are pros and cons to each approach (static vs dynamic). Having worked in both, as you can guess, I prefer dynamic. However, others will prefer static. I hope that at least helps a little in understanding the difference.
I hope you have fun as you continue on your programming journey!
That was more than I hoped for, thanks!
Oh, this weeks Thinking Elixir talk with Dave Lucia was super interesting for me since I imagine making an app that this stack and architecture might well serve. Thanks, again!
Awesome! Glad it was helpful!
I’ve got to say, this chapter really excited me. I’ve done a lot of fetching/parsing JSON, and it’s a pain, even with nice libraries or tools like jq.
The example you gave is a killer. I love it.