Live data from Hacker News

Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

mostly-adequate.gitbooks.io

41–50 of 93 posts

Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

#41
post #29

> We have all the features we need to mimic a language like Scala or Haskell with the help of a tiny library or two. Seems misleading at best, as you mimic only some parts of functional programming. For example, for-loops are not used but neither are recursion and tail calls mentioned. > [T]yped functional languages will, without a doubt, be the best place to code in the style presented by this book. JavaScript will…

It seems like a good book, but I think this is fair criticism. It skips some of the basic FP concepts that you mentioned, and is surprisingly heavy on more advanced topics (e.g. category theory, which I personally enjoy).

Most of the book isn't really a beginner's guide. A more accurate title might be "JavaScript for Haskell Programmers".

Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

#42

Really 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…

The Option/Maybe monad is very common in FP languages. I don't know if it's native in Elixir, but apparently it's pretty easy to implement: http://www.zohaib.me/monads-in-elixir-2/#maybe

There are lots of ways to conceptualize monads. I think "functors that flatten" is accurate, but is just one way.

Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

#43
Good read. He annotates his function with Hindley-Milner type signatures (specified in comments). I really prefer this to, say, jsdoc. Anyone know if there's a jsdoc-like tool that understands these comments? That'd be pretty swank.

Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

#44

Actually the course on Egghead is terrible. The voice that is used to comment on the video is very badly recorded and I have no idea why they chose that voice for a serious video for adults. Edit: Also fine to not have my opinion on this, but a lot of people shared my opinion, check the Egghead comment section. I would've loved to watch that video, with a more professional voice and walkthrough.

We detached this subthread from https://news.ycombinator.com/item?id=17072865 and marked it off-topic.

Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

#45

Really 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…

Functors have fmap. Pointeds have pure. Monads have fmap, pure and join/flatten. So what's missing from "functors that can flatten" is pure, and monads are more precisely "pointed functors that can flatten".

This is the canonical source: https://wiki.haskell.org/Typeclassopedia

Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

#46

Really 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 language in current use is "functional". There's even some so weak that C is "functional" because it has "function pointers", though this one is now out-of-date and not currently being used by anyone. But, yes, there was once a time in which C would have been considered "unusually strong" in its "functional programming" support, because other contemporary languages didn't even have function pointers.)

"Also is his explanation of monads as 'functors that can flatten' a simplification for the purposes of teaching, or is that more or less what they are?"

A little of both. Technically it is correct, but the "flattening" in question applies to many things that most programmers wouldn't consider "flattening". For instance, consider monadic IO as Haskell uses. There is a way in which you can consider the execution of an IO value as "flattening" it, and it corresponds to the mathematical term, but it's not what most people have in mind. There's more to "flattening" than "simplifying data structures in some manner"; it doesn't even always involve what we'd traditionally think of as data structures at all, such as, again, IO.

Personally I think it is an actively unhelpful metaphor for these reasons, as it is very prone to leading to false understanding, but YMMV.

Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

#47

Good read. He annotates his function with Hindley-Milner type signatures (specified in comments). I really prefer this to, say, jsdoc. Anyone know if there's a jsdoc-like tool that understands these comments? That'd be pretty swank.

I'm not sure what "Hindley-Milner type signatures" means. Obviously it is intended to refer to Haskell-style type signatures. Hindley-Milner, though, usually refers to a system of type inference which is independent of syntax.

As I understand it, the author is using Hindley-Milner as if was the name of a syntax, like Backus-Naur form. But this is something I've never heard, and I wonder if the credit for the Haskell type signature style belongs just as much to Rod Burstall or David Turner, in other words I'm inclined to believe that it is something conventional that evolved over years.

Re: Professor Frisby's Mostly Adequate Guide to Functional Programming (2015)

#48
post #32

Really 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…

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.
Post reply on HN