We define the State datatype and take a peek into its inner working. By manually constructing an instance, we’ll start to get a feel on how the type separates state management from our stateful computations. As State depends on a Pair type, we get to know how each portion can be extracted through the fst
and snd
Pair instance methods.
Would be nice to turn off the keyboard noise. :)
Hi Ian, great course! This stuff is blowing my mind! One thing though about the setup, for those running the code locally in just a terminal with node index.js
, at least for me, I get a window is not defined
error, of course since there is no browser.
For anyone else who might be getting the same error, I just removed the const log = require('./logger')
and changed the log()
function to console.log()
, and you can follow the lesson through!
@Chris
Great point, I do have a github repo
that has each lesson in a branch that will run on node w/o any modification. If that helps!!
@David
Would be nice to turn off the keyboard noise. :)
Noted. Will take care to bring that down in future casts. Sorry about that!!
Yeah, the clicking from the keyboard is way to loud and very annyoing.
Andy please try to talk like in real life next time. You are not selling us something ;)
Thanks Chris. I ran into the same issue. Your answer helped. - E
A little bit of background and context at the beginning would have been nice. For a whole series on State and monads, an overview of what state and (especially) monads are in this context is pretty crucial IMO. 10 seconds in and we're already learning some specific library.
At 7 seconds in you're using (IMO) unclear notation for something we don't even know what it is yet. At 28 seconds in, that notation with :: is also very confusing, and seems to be inconsistent with that you wrote previously. It feels like you're using notation from another language or paradigm, because I failed to recognize it as a JavaScript user.
TL;DR - I'm still sitting here wondering what a Monad is.
@Matmo10 There are a lot of resources out there surrounding Monads and the Type Notation. With this lesson I am trying to focus on how to use a State Monad to abstract away state management and unload it on the type itself. Instead or reiterating subjects that have been thoroughly covered. I really have nothing new to add to that space (Monads in JS, Hindley–Milner type signatures, etc).
For the theory portion I HIGHLY recommend @drboolean's course:
Also he has a wonderful book which you can find here:
One thing regarding those types, is I attempt to put in english what the siggy represents as I type, hoping that the learner may pick up syntax.
As far as proprietary, those types used in crocks
use a common "open" standard for creating algebraic datatypes in javascript. So even though we are learning with crocks
, a vast majority of the State
datatypes in the wild will behave in the same manner (with a few exceptions of course).
I do hope you push through though, it is my hope that as the course progresses, an intuition on the purpose of this datatype starts to form.
Thanks for the resources Ian, I will definitely take a look!
Ohh, keyboard is sooo noisy! Don't use a gaming keyboard for video tuts.
Sounds kinda robotic. Also, it would be helpful to explain some basic things that might take a bit to click like 'fst' is for 'first' and 'snd' is for second!
Sounds kinda robotic. Also, it would be helpful to explain some basic things that might take a bit to click like 'fst' is for 'first' and 'snd' is for second!
Thanks for the feedback.
Sorry about the fst
and snd
I (wrongly) assumed that saying the values at 1:43 with their respective names first
and second
would have made the connection enough for it to be put into context at 1:52 to what they would be for the portion of the State (Resultant/State).
As very soon in the course we drop directly working with the Pair
in favor of execWith
and evalWith
, I thought it may obfuscate and take away from the structure of the State ADT. Will definitely reevaluate how much I should just breeze over in the future!
Thanks again for taking the time to provide feedback. Always appreciated.
I have to agree with Ruby Team and Adesso. Both the voicing and the clicking keep me from listening beyond a few minutes.
I think the voicing is engaging and much better than the usual monotone. Good job on the course.