This may be a character flaw, but I found this book's style of teaching by mocking random snippets found in the wild really, really entertaining.
Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
51–60 of 93 posts
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#52Really 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…
It's a pretty usefully compact definition.
In my understanding however, it's valuable to note that the chain-ability of the bind operation also sets up a continuously nested set of closures, which is where the real power comes into play to give you a useful approximation to imperative programming. (This can easily be abused, of course, to circumvent thinking and structuring code functionally.)
Related to this, SJP stressed in a talk some years back about how monads conveniently encapsulate the unavoidable messiness of side-effects in the least painful way yet discovered.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#53Earlier quoted context omitted.
Haskell-style types aren't a prerequisite for functional programming. Lisp and Elixir are dynamically-typed, which is why you don't see monads in those. That said, they do occasionally form useful abstractions.
Can you explain why you don't need monads if your language is dynamically typed? That's a new one to me.
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.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#54Since 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?
As long as software is executed in the real world you have side effects, including "side effects" coming in from the outside, like bits flipped in RAM. Yes. So let's just be practical. We can have the equivalent of a middle ages theological discussion or one rooted in this world :-)
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#55Earlier quoted context omitted.
Can you explain why you don't need monads if your language is dynamically typed? That's a new one to me.
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.
I find them to be at least somewhat useful in a language like javascript. I imagine they are more useful in a typed language with proper inference, but I wouldn't say they're entirely useless in a dynamic language.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#56This may be a character flaw, but I found this book's style of teaching by mocking random snippets found in the wild really, really entertaining.
You should see the videos he made for Egghead.io! Stop motion hedgehog! I know some people complained, but Egghead backed his unconventional teaching methods which is pretty cool.
- https://egghead.io/instructors/brian-lonsdorf
- https://www.youtube.com/watch?v=h_tkIpwbsxY
I'm pretty sure he's the only person to make this topic so approachable. I'm glad he's into having fun with it. Quite refreshing!
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#57I spent about 30 minutes reading, but I didnt understand why this has 140 points and is the top thread. Can anyone explain?
Functional programming (FP) is an important paradigm with many practical benefits, such as preventing bugs, improving parallelization, etc. JavaScript is a language in which one can apply the FP paradigm, with some (considerable) effort. This book explains both the underlying FP paradigm and how to apply it in JS. Other languages (e.g. Haskell, Scala, F#) are designed for the FP paradigm and make it much easier to ap…
> with some (considerable) effort
disclaimer: I haven't read the book and am not sure if this is mentioned anywhere.
What helped me when thinking about functional design in javascript was realizing that all js functions actually only have one parameter, an array of arguments used by the caller:
function add(x, y) {
return x + y;
}
function add() {
const x = arguments[0];
const y = arguments[1];
return x + y;
}
add1 :: [Number] -> [Number] -> Number
add2 :: [Number, Number] -> NumberRe: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#58Great 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...
ahahah, this is incredibly entertaining :D
(Skip to 0:30 in the first video, it's full of this kind of "context".)
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#59Since 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?
I'm not really part of the FP crowd, but I'll take a stab at it. Note well, however, that what I say here could well be wrong.
On one level, there is no such thing as FP. All there is, is assembly-language (or binary) instructions being executed in a CPU that has access to some memory. (Almost) every instruction creates some kind of side effect (including changing the flags).
But nobody wants to program at that level, so we build abstractions on top of it. All higher-level languages create an abstraction. Even C creates an abstract machine, even though it's very close to the hardware. If the abstraction doesn't leak, you can just think about the abstraction, and ignore what's going on at the level(s) below it.
FP creates an abstraction that's at a higher level than many other abstractions. Within that abstraction, (almost) all you have are functions and values. Memory and registers are below that level. The changes to the call stack when you call a function are below that level. Those things are therefore not seen as side effects, because they are below the level of abstraction you're working at.
But disk is not. Therefore writing to disk is seen as a side effect, and those other things are not.
Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)
#60Earlier quoted context omitted.
Can you explain why you don't need monads if your language is dynamically typed? That's a new one to me.
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?