Abstraction, intuition,…

Tuesday, August 26th, 2014

Abstraction, intuition, and the “monad tutorial fallacy” by Brent Yorgey.

From the post:

While working on an article for the Monad.Reader, I’ve had the opportunity to think about how people learn and gain intuition for abstraction, and the implications for pedagogy. The heart of the matter is that people begin with the concrete, and move to the abstract. Humans are very good at pattern recognition, so this is a natural progression. By examining concrete objects in detail, one begins to notice similarities and patterns, until one comes to understand on a more abstract, intuitive level. This is why it’s such good pedagogical practice to demonstrate examples of concepts you are trying to teach. It’s particularly important to note that this process doesn’t change even when one is presented with the abstraction up front! For example, when presented with a mathematical definition for the first time, most people (me included) don’t “get it” immediately: it is only after examining some specific instances of the definition, and working through the implications of the definition in detail, that one begins to appreciate the definition and gain an understanding of what it “really says.”

Unfortunately, there is a whole cottage industry of monad tutorials that get this wrong….

It isn’t often that you see a blog post from 2009 that is getting comments in 2014!

I take the post to be more about pedagogy than monads but there are plenty of pointers to monad tutorials in the comments.

Another post mentioned in the comments that you may find useful: Developing Your Intuition For Math by Kalid Azad.

What if you ran a presentation from back to front? Started with concrete examples of your solution in action in multiple cases. Explain the cases. Extract the common paths or patterns. Then run out of time before you can repeat what everyone already knows about the area? Would that work?

Morph

Saturday, May 24th, 2014

Morph – A Library of Morphisms: Monoids, Functors, and Monads by Armando Blancas.

From the webpage:

Morph

Morph is a library of Haskell-style morphisms: monoids, functors, and monads. These constructs are helpful for designing programs that are purely functional and that encapsulate the boilerplate employed by many programming techniques.

Features

• Implementation based on protocols and data types.
• Predefined monoids and functors; with support for Clojure collections.
• Support for curried functions.
• Library of generic functions for the above constructs.
• Sample code in src/main/resources.

These constructs have a reputation of being hard to explain and even harder to understand and to apply in everyday programming. I’ve made every effort to present them as regular techniques and idioms with practical benefits. Behind their strange or fancy names, these are just functions that work on data types.

An intuition of their behavior is all that’s needed to take advantage of these functions; you may never need or want to write your own. I’m pleased with the power and simplicity these techniques have to offer and I hope you may find them useful as well.

Lowering the learning curve for using functional programming languages? Is that a bit like being able to use a compiler but not write one? Whatever drives adoption is a good thing.