Professor Frisby's mostly adequate guide to functional programming (2018)

I’d just recommend skimming over something like Haskell book to gain some vague familiarity with what concepts exist, then just write code and learn applicative/monad/monoid etc as you run into walls.

Generalizations are notoriously hard to describe as they become more general. Better to understand where and when to use those patterns over being able to write a blog post about what a monad is.

I highly, highly recommend skipping Haskell for now and learning statically-typed FP using this excellent free online course: https://www.coursera.org/learn/programming-languages

The lecture videos are short, about 10mins each, and Professor Grossman explains the concepts carefully and succinctly, within a fixed teaching framework so you have a predictable learning experience with each concept. It's by far the best way to get into the mindset of typed FP.

If you're serious about picking up the language, I urge you to simply start building something. Build something you can relate with, something similar that you've already built with a different toolset. Like a web server.

A lot of the fancy abstractions don't make sense until you have a problem where you'll actually need them. Artificial problems, like some algorithmic assignments in books just don't click nearly as well to many of us.

Monads are very simple. If you know how futures / promises work (the chain of .then), you already have enough intuition about them.

Also, (Glasgow) Haskell has ghci, a rather nice REPL. You only need to learn to use :{ ... :} for multiline stuff. It's very good for quick experimentation with zero build time.

I worked as a Haskell developer for a year and a half. The best productivity boost I had was switching to compiling on an EC2 instance. I saved battery, sped up compiles with greater parallelism than my XPS had cores for, and didn’t have to worry about cleaning up ~/.stack

A bunch of languages have some special syntax to solve hairy problems. Async await, yield for generators, ? for dealing with errors in rust, etc.

If those deal with composition and variable scoping in an intuitive way it's a monad. This "intuitive way" is equivalent to changing block scoping in imperative languages.

    {
        let x = foo()
        let y = bar(x)
        let z = baz(x,y)
        ...
    }

should stay equivalent to

    {
        let x = foo()
        let z
        {
            let y = bar(x)
            z = baz(x,y)
        }
        ...
    }

and you should be able to add empty scopes without changing anything so

    {
        foo()
    }

should still equal

    {
         {}
         foo()
         {}
    }

And that's the entire definition of monads. The abstract monad interface is useful to let users define new interpretations for the syntax sugar but not necessary when getting started with haskell - you will pick up intuitions while using it.

Have you seen What I wish I knew when learning Haskell?

[0] http://dev.stephendiehl.com/hask/

And some more little videos on Brian's YT channel https://www.youtube.com/channel/UCKjVLbSDoM-8-eEM7A30igA/vid...

I hope he makes some more programming stuff at some point as he has a super creative and interesting way of teaching.

I think it's fair to say it was pioneered by why's (poignant) Guide to Ruby [0].

Spolsky is a fan of the style. He's made the case for deliberately writing documentation that's fun to read, rather than using a dry style. As he puts it, nobody read the spec, because it was so dang mind-numbing. [1]

[0] https://en.wikipedia.org/wiki/Why%27s_(poignant)_Guide_to_Ru...

[1] https://www.joelonsoftware.com/2000/10/15/painless-functiona...

Depending on the circumstances, I often do. For a big topic like this, part of the reason I like it is that the pacing is better. It tends to be less densely packed, and lets me read through something carefully but not feel too strained. It also has a story, if you will, that helps me get back on track later on if I'm sticking with it. It's not to say a more formal style of writing couldn't achieve similar goals, but I just find they don't tend to.

There are plenty of scenarios where it wouldn't fit (references, specifications, etc) of course. So I don't think it's great everywhere. But yeah, overall I find it easier to read when starting out on a big topic.

we did this book for our work book club a year or so ago. most people in the club enjoyed reading it. there were issues getting the some of the examples to work at the time but that's another matter.

Personally I found that style funny for a while but now I feel it's becoming tedious and won't age well. In the long run I prefer a style like Kernighan & Ritchie which is concise, easy to read and timeless.

> perhaps to seem friendly and more approachable.

nothing makes me press ctrl-w faster that a web page that tries to be "friendly" (in an american pop-culture way) with me.

It's dynamic scoping, as appose to lexical scoping. With the dynamic scoping, the environment of invocation becomes the caller's environment, while with the lexical scoping the environment was tied to the scope or original definition.

JavaScript is kinda weird because it uses lexical scoping for most of the part, but uses dynamic scoping for 'this'.

Lexical scoping looks sane, and it's adopted by most programming languages nowadays. Because it's much easier to reason about - it just worked as how the code was written, in the same file. While dynamic scoping would leak variables everywhere - when you need it it's not there, when you don't want it, it just sneakily replace many variables that you expect to be other things.

But there are still quite some mostly dynamically scoped languages in use like Emacs Lisp, or shell languages like Bash and Powershell. Other than dynamically is debatable faster and easier to implement, it's also handy when you override the environment variables for short shell scripts. But for large codebases it's a nightmare, so traditionally Emacs Lisp scripts have super-long-variable-names-in-order-to-avoid-collisions just like writing CSS, and people had enough now so in newest version people can have a syntax that can enable lexical scoping.