Concept map: Functional progamming

May 29, 2013 • Neal Davis

TL;DR:  I mapped functional programming at the same time I re-emphasized the basic foundations in my own learning.  I think that knowing one is going to create a concept map distracts from learning, both because the learning becomes ends-oriented rather than for the joy of it, and because it encourages premature formation of categories just so you can start writing things down.

I have mapped out the basic principles of functional programming and their connexions.  While I have a little bit of introductory experience with Haskell, I am not by any stretch of the imagination an FP-style programmer.  I noticed that there was another older concept map outlining the differences between functional and procedural programming styles.  I explicitly avoided referencing that to keep this version “pure”.

Neal Davis - Functional Programming Context Map v. 1

The first draft I made was largely based on the logical structure of the Wikipedia article on functional programming, with connexions drawn based on my own prior knowledge of historical problems with formal computation.  I think it ended up with too many spurious categories, categories of interest to the mathematical study but probably inappropriate for an early-pedagogical presentation.  In addition, the experience of preparing the concept map at the same time as reading was more distracting than traditional note taking for me, and I wasted time trying to match synonyms for “relates to” so I could draw double-headed arrows.

Neal Davis - Functional Programming Context Map v. 2

For the second version, I started from scratch and threw out the initial first-level categorization (for the most part).  I pulled the historical stuff out to a separate level to leave more room for practical insights.  I also wrote down headings only rather than drawing any lines at this point.  Many lines were also simply connexions rather than verbal—more useful for me but not an observer.

I’m more satisfied but still not too keen at the overall prospect.  Functional programming may be too broad for a good concept map—is my scope the idea of FP? the practice of FP? a comparison of FP with OOP or PP?

In looking around, I noticed that others have wildly varying levels of complexity in their concept maps.  I’ve no objection to this—it just seems that some ideas, at about a middling level of complexity, are most suited to concept maps.  Otherwise you end up too simple (Itamar’s variable assignment) or too complex (Yuxi Luo’s git chart) (not to pick on anyone in particular—as I said, FP seems too broad as well).  Julia Evans seems to have hit a nice level of complexity.  I also found that I was largely bugged or pleased at the relative level of complexity based on my acquaintance with the topic at hand.  Which suggests, unsurprisingly, that concept maps are good ways to represent learning but not to convey it.

The more effective concept maps distinguish the “starting point” clearly, else it’s too crazy to jump into.  It’s also apparently not clear where the line should be between needing a word versus a phrase versus an entire sentence to get a concept down.  If you need a sentence, should you really be using a concept map anymore?

And it was probably a mistake to attempt to craft a concept map at the same time I’m learning a new concept, rather than simply outlining something with which I’m already very familiar.  It’s unfair to hang too much of that albatross around the neck of the concept map, I suppose.