This book is very good. If you like Javascript and want to further your understanding of functional programming, then I would highly recommend it.
Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
61–70 of 93 posts
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#62The Fantasy Land spec and related libraries like Sanctuary and Fluture deserve a mention here, even if only as a next step after reading this guide.
It helps bridge the gap between looking at all of this from the more math/Haskell perspective and how it's implemented in javascript, without sacrificing definitions (as much as possible).
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#63Earlier quoted context omitted.
I don't agree with that "not needed" explanation. But they are quite useless if the compiler can not deduce that both the values returned from the functions you are calling are monads, and what kind of binding should apply to them.
OK, for the slow of understanding: What I think you said is that, in an untyped language, a function will just return "something" (as far as the compiler is concerned). But in a typed language, the compiler knows that a monad was returned. So the point of the monad is to make the compiler do magic, not to make the runtime do magic. Is that accurate?
Well.. It's like 25% accurate, and you hit the part you were most worried about. But you have been seriously misled about monads in the past.
There is no magic in monads. At the level of runtime operations, they're just a couple of functions.
The magic taking place in the compiler is type inference guiding the selection of the right pair of functions during compilation. Without that, you have to explicitly use the correct functions. It's much easier to offload that bookkeeping to a computer than it is to do it yourself.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#64Since the FP crowd is here, why is loading a program into memory, writing a register, or calling a function not seen as a side effect, but writing to disk is seen as a side effect? Or have I got it wrong?
Loading a program into memory is part of runtime(it happens before your program starts executing; so how is that useful to model that?); Why would calling a function be a side-effect?
Not sure what exactly you mean by writing a register; if you directly mutate a location, it is considered side-effect. Otherwise any register rewrites that happen are just implementation details and if you have a different architecture than von-neumann than it could also be implemented without writing to a register.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#65Since the FP crowd is here, why is loading a program into memory, writing a register, or calling a function not seen as a side effect, but writing to disk is seen as a side effect? Or have I got it wrong?
Because it's outside the scope of how you interface with the language.
Calling these side affects is like calling Python a low level language because programs you write still use registers and raw memory access.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#66Really enjoyed this book. Once you get currying, and using curried functions to pipe/compose, everything clicks into place. I found the examples of using Nothing/Maybe monads for error handling pretty neat as well - is that a common pattern, because I don't remember native support for those types when I briefly dabbled in elixir. Also is his explanation of monads as 'functors that can flatten' a simplification for th…
There's really multiple definitions of "functional" right now, and the type of "functional" being discussed here, Erlang isn't, and I don't think Elixir particularly is either. This is not a criticism of any kind; this is a point about definitions . There are definitions of functional where Erlang is functional, and IIRC Elixir can be said to support it. (And there are definitions of "functional" where almost every l…
> There's really multiple definitions of "functional" right now
It would be very helpful to see an explanation of this spectrum you describe for someone who is not really familiar with the definitions. I would love to read an explanation of the various “functional” paradigms as they diverge from “conventional” (ie. C) programming languages.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#67This is excellent. But man, I don't think I can ever go back to not feeling like there's a huge pedagogical gap between the local maxima the functional programming explanations engineers are typically exposed to, and the much higher (though probably still not a global maxima) point that pure mathematicians have been adapted into. I just wish we'd embrace the geometric (topological, differential geometrical) threads t…
What's an example of a coding problem which would benefit from all that abstraction?
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#68Great book. I'd also recommend his free video course on Egghead. It's rather quirky, which is something that I very much enjoyed: https://egghead.io/courses/professor-frisby-introduces-compo...
He should make a Professor Frisby plush toy with a voice system which provides a functional API.
How do you transform someone's voice like that?
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#69This is excellent. But man, I don't think I can ever go back to not feeling like there's a huge pedagogical gap between the local maxima the functional programming explanations engineers are typically exposed to, and the much higher (though probably still not a global maxima) point that pure mathematicians have been adapted into. I just wish we'd embrace the geometric (topological, differential geometrical) threads t…
What's an example of a coding problem which would benefit from all that abstraction?
While I sympathize with your sentiment – and share the mindset during my day job – I believe that this type of "what practical applications does this have"-thinking is making us short-sighted and preventing us from being able to move past our current local maxima, to cross the adaptive valley[1].
I'm not expecting the whole engineering field to start exploring the question of what pure mathematics (and not some watered down for-engineers version) can do to fundamentally transform the the way programmers think and talk about what it is they do. But the fact that there are almost zero people from the geometric side of pure mathematics (though again, there are plenty of logicians) working together with everyday programmers, that's what I wish I saw more of every time I see one of these explanations of functional programming that seem almost always to be pedagogically colored by logicians hands.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#70This is excellent. But man, I don't think I can ever go back to not feeling like there's a huge pedagogical gap between the local maxima the functional programming explanations engineers are typically exposed to, and the much higher (though probably still not a global maxima) point that pure mathematicians have been adapted into. I just wish we'd embrace the geometric (topological, differential geometrical) threads t…
What's an example of a coding problem which would benefit from all that abstraction?
Games