I write about learning Haskell on https://dooygoy.github.io/funcstream/observations/ and now I feel inspired to challenge myself further and join the #100daysofcode adventure. The linked github page consists or documented mental exporations I usually go through while trying to understand the whole funcional programming vibe, a place where I try to animate what I learn and go through together with my writing self. I feel writing about learning helps me learn better, and also documenting everything brings a current of clarity and expands the horizons of what I have learned. I find myself using the Hemingway method, I read what I have written the previous day and then begin from that.
But I also feel like reaching out here on dev too, writing kindles my fire of inspiration, because Haskell is beautiful, but also because Haskell seems so hard. Actually Haskell is easy, it is just that it makes you really understand how to model a problem domain without actually beginning any work defined by simple operational semantics or even a premature optimization.
We have learned that it is through types that we can reason about our programs, so we want to put as much knowledge as possible about our problem there, in the types.
I am learning to model the problem domain, to organize what I know and not know into categories and then mix and match closest relations and the first types we learn are the sum types. What are sum types? Can we go back in time and see an earlier form of sum types? How about case analysis? A case analysis is like writing out different cases that may or may not happen. What do I mean by cases? Cases could be events, or we can simply call them patterns. But how do we write out all the patterns, there must be an infinite amount of patterns? So we first need to think about our problem domain and write out possible patterns that may happen in our domain. Our domain may be a simple pizza baking enterprise and possible pattern could be a Margherita, Bianca, Frutti di Mare etc.. someone might come and enter out program and ask for this and that pizza, but what if we get an unknown, unfamiliar request, like a Burger with french fries? Our program would crash in error, because our pizza place does not make burgers. In real life we would send someone and explain to the customer that we do not make pizzas, or we could print out a menu with all possible pizzas. Should we explicitly define what to do in the case if someone still asks for a burger? Could that happen? What if the person asks something else, like a Miles Davis recording of So What?
Of course we want our program to be able to deal with all reasonable inputs... In fact, formally, this process of enumerating all the possible ways to construct a datatype for the purpose of scrutinizing it through a case expression is called pattern matching.
Stay tuned, would you like to know more? Quotes are from A Type Of Programming, an amazng book about thinking functionally, about learning to program in Haskell. For more info see https://atypeofprogramming.com/
Top comments (0)