Forem: Michael Taggart

Programming and Bloom's Taxonomy

Michael Taggart — Thu, 07 Dec 2017 18:00:26 +0000

Originally appeared on my blog

You can't get near education theory in the 21st century without Benjamin Bloom's categorization of cognitive activities. Yes, there are accompanying taxonomies for affective and psychomotor activities, but for now, I'm focusing on the cognitive set. Let's all recite them together:

Remembering
Comprehending
Applying
Analyzing
Synthesizing
Evaluating

Amen. These are ordered by cognitive complexity, and as it so happens, map extremely well onto the process of learning the skills of computer programming. Perhaps that's obvious: a framework for describing learning describes how you learn something. Still, I'd argue that the congruence is remarkable. Some subjects engage with many of these levels at once, asking students to analyze, synthesize, and evaluate all at once. In programming, it is difficult to approach a higher echelon before mastering the ones beneath.

Let me explain with my own experience learning these skills.

Remembering

There are ways in which learning to program is like learning a language—the symbols and syntax of each programming language is unique, and it takes time to memorize these sufficiently to produce code that is not riddled with errors.

Here's a bit of code in Python—my first language—that checks whether a number is even or odd:

def is_even(n):
    if n % 2 == 0:
        return True
    elif n % 2 != 0:
        return False

I am willing to bet that even if you've never read a line of Python before, you can make some sense of that. The modulus (%) returns the remainder of integer division, so essentially I'm saying:

If, when dividing n by 2, I get zero, n really is even.

Otherwise, if I get anything that isn't zero, n is a phony, a fake. A flim-flammer.

This bit of Python is syntactically perfect. Of course, it took me days to be able to rattle off something like this without constantly checking the reference documentation. But the syntax, the symbols, were the first thing I had to learn. I had to remember what Python was even supposed to look like.

But you know what? This code is partially nonsense. It's a little like a Chomsky sentence: structurally sound, but functionally useless. To fix it, I had to comprehend something more about the task. In this case, something about the nature of functions, and the nature of if/else statements.

Comprehending

"If it's sunny, then I'll go to the beach. Otherwise, I'll go to the movies."

if sunny == True:
    go_to_beach()
else:
    go_to_movies()

A contrived example perhaps, but that's how conditionals work. We perform tests on our information, and then we execute different commands accordingly. You can see how the same structure exists in English, and maps well onto Python's syntax. But you'll also notice that the second part of the code is an else, not an elif like above. Conditionals, if they have more than one option, must end with else; it's the default behavior. And I didn't comprehend why when I wrote the syntactically-correct version above, it was yelling at me.

Once I comprehended the rule that conditionals must end in else, I rewrote it as:

def is_even(n):
    if n % 2 == 0:
        return True
    else:
        return False

But I still had more to comprehend. This time, about functions.

That def is_even(n): line above is the start of a function. Like in math, functions take information in and spit something back out. That's what the return symbol is all about: spitting back either True or False based on whether the number is even. Functions can only return one thing—after they do a return, they stop until they're "called again." So if I have 4 to my is_even function, it would test to see if 4 is evenly divided by 2, and if so, return True. The elif ("else if") part of the code isn't even touched in that case.

Turns out, I don't even need the else! Just a single if will do, because if that test passes, return ensures the rest of the function isn't run. So my final form looks like:

def is_even(n):
    if n % 2 == 0:
        return True
    return False

A tad more elegant, no? Concision isn't necessarily a goal for programmers (readability is), but it tends to result from a deep understanding of the tools at one's disposal.

UPDATE: Bob accurately points out that the following:

def is_even(n):
    return n % 2 == 0

...is even more elegant. I often, when writing teaching code, leave the last step of elegance to preserve clarity. Still, the above is worth understanding as an improvement.

Applying

Certainly writing a function to tell even numbers from odd is a bit contrived. Nevertheless, the patterns I learned in this exercise would become invaluable in the countless functions I went on to write.

If we zoom out from the specifics of evenness/oddness, what is this function doing? It's determining the nature of an object, sorting it into one of two categories. Of course in human life, binary states are rare; life is shades of gray. But in pure reason, it is often the case that we must determine whether something is or is not. Every time we do, this pattern emerges. With a firm comprehension of the form of this reasoning, of its pattern, I was able to apply it to other problems.

Analyzing

As a writer and English teacher, I took pride in my proofreading abilities. I'd find that missing Oxford comma, that malapropistic "its." Reflecting on this ability, I'm certain it derives from sufficient practice, yes, but also sufficient reading such that my comprehension of the "rules" of language made violations of the rules readily apparent.

A typo or grammatical error can be irritating. A program that doesn't run because of a logical flaw or a typo (it can be difficult to tell one from the other) is infuriating.

Here's a line I feed to all my students: programming is a uniquely frustrating discipline, because most of the time you spend working on a problem, it feels like you're failing. Once it works, you stop and move on to the next. And when you get it wrong, you know right away. No craft so ruthlessly exposes your own logical flaws.

Enticed yet?

Okay so to properly analyze one's own code or someone else's, the first two tiers of the Taxonomy must be well in-hand.

Ah, but analysis in the realm of programming also refers to the problem domain. A programmer has to understand the operating parameters and solve within them. To build a bridge, one must first read the terrain, measure the gorge, and plan carefully. It is in analysis where programming begins to resemble engineering in its thought processes.

Synthesizing

The examples so far have been rather simplistic, in part because they can afford to be. And even in most programming curricula, the tasks set students will be one- or two-dimensional up to the level of synthesis: write a function that takes X and returns Y; implement function A to integrate with output from function B. You'll find significant amounts of scaffolding in the early chapters of a programming curriculum. In order to give beginners anything like an authentic experience, the tasks set to them have to be contextualized in ways that resemble what they'll encounter later in their journey. Real software applications have a lot of moving parts. It's a Rube Goldberg machine up in there.

So by the time students reach the synthesis phase, they can code a multidimensional project. A real application.

Or, y'know, direct an OK Go video.

Evaluating

Up here in the thin air of Bloom's, we have evaluation. In programming—and perhaps in writing—this is where style emerges. The programmer has a strong enough foundation in their craft to begin making choices about how to approach a given problem. Shall we use object-oriented or functional patterns? Would a stack or queue data structure make more sense? Should I attempt a recursive algorithm?

Choice may even extend into the programming language for a given problem domain. With broad experience comes a broad array of options, and programming languages are just tools.

But how could a programmer make such choices without experiencing extending to fully completed projects. Put another way, programmers must have completed a synthesis before ascending to evaluation.

Beyond Bloom

Bloom's Taxonomy fits the programmer's journey well enough, as far as it goes. However, one criticism of the Taxonomy is its hyper-individualism. It's a curious model, given the social nature of, well, humanity in general, but certainly of learning. Any Harkness teacher will tell you that deep learning is a social enterprise, yet Bloom functionally elides discourse and dialectic in the Taxonomy. One might argue that the emotive component of the Taxonomy speaks to it, but emotional activities are specifically distinct from the cognitive, yet intellectual discussions are definitionally cognitive.

So I have beef with Bloom here, especially when it comes to programming, since programmers no longer work in solitude. To fully master the craft, a programmer must join a community of others, sharing experiences and code in an open marketplace of ideas.

Sharing

It takes courage to publish one's code to the internet, open to the scrutiny of others. Yet millions do this every day. We'll talk more about open source tomorrow, but joining the community of programmers is an integral part of mastery. Learning how to discuss issues, contribute helpfully on projects, and hold oneself accountable for assigned work as part of a team transforms programming from craft to profession.

Community-Building

Lastly, the young programmer will hopefully start their own open source project that develops a community of contributors around it. Here, the programmer is now also a connector of people, responsible for the communal bonds that develop around the common goal of the project. Success here is no longer situated in the craft of programmer, but the more holistic human skills we hope to impart to all students.

In short, the full path of the programmer is not so different from other skills or disciplines: mastery makes one, through the hard work along the way, a good person.

Things I learned writing my first Elm app

Michael Taggart — Sun, 26 Nov 2017 15:40:24 +0000

Some disclaimers up front. I am not a professional developer; I'm a self-taught programmer who's found himself in the unlikely position to be the Director of Technology for a school. Possessed of these skills, it's often the case that I see value in building a solution to our problems rather than purchasing one. To do this means successfully passing a rigorous cost-benefit analysis in which "build" beats "buy." It also means I have to build in such a way that I am not the only person who can maintain applications that become mission-critical.

I'd like to tell you that I therefore follow every best practice: thorough documentation, writing tests for everything. I'm not there yet. I'm still learning.

About a year ago I learned about Elm. Having dabbled in Haskell and written a React Redux app, I was completely enamored with functional programming and The Elm Architecture, in particular. So when the opportunity to rewrite an in-house scheduling app came about, I knew I wanted to use Elm. It wasn't a particularly complex application, just a way to create recurring events on a six-day rotation rather than daily, weekly, or monthly. The perfect size for a foray into a new language.

But hang on, what about that maintainability thing? Wouldn't introducing a completely alien language be a nightmare for anyone besides me who had to look at the code?

That brings me to the first thing I learned.

Elm makes some clean code

I am in love with the way Elm code reads. The update function takes a set of messages sent by the view and updates the model (state of the app/module). It looks like this:

update : Action -> Model -> (Model, Cmd Action)
update action model =
    case action of
        NoOp ->
            model ! []

        RequestCalendars ->
            model ! [ getCalendarList clientId ]

        ReceiveCalendars calendars ->
            { model | calendars = calendars } ! [ getLetterDays letterDayCalendar ] 

        RequestLetterDayEvents ->
            model ! [ getLetterDays letterDayCalendar ]

If you've never read a functional language, that might look completely bananas. The first thing to know is that the top line is the function definition. It tells us what types come in to the function, and what type comes out. Then we name the arguments in the second line, which is equivalent to function update(action, model){.

The action argument is of a special type that I've described myself. It describes the kinds of messages the view (what users see/interact with) can send to update. Beneath that, you see a case/of statement, which is similar to a switch statement in JS. Each line after an -> indicates what update should return in the case of that given action.

Action, in fact, is part of the second thing I learned.

I love strict typing

My programming journey began in Python, then moved to PHP, then JavaScript. So for a long time I had a bit of apprehension about static typing, to say nothing of strict typing. Then I learned Haskell, and discovered a new way to think about programming. Procedural languages treat programs as sets of instructions to execute in order—the classic "recipe" example. And that's all fine, and is often the absolutely correct way to conceive of a problem space. By contrast, functional languages like Haskell and Elm ask the programmer to consider the "shape" of information coming into a function and the shape that should emerge from a function. Applying the right operations to the information between input and output produces the desired result. Rather than thinking of steps in order, you begin thinking of enclosed transformations. In doing so, you must be completely clear on your data types between input and output. That's where strict typing comes in. By defining functions first in terms of what comes in and goes out, there's never any ambiguity about what's happening or what's being passed around your code.

Consider the following mega-contrived example:

Suppose I wanted to write a function that takes in an array of numbers and returns them squared. Easy enough, right? Here is such a function in JS:

function squareEach(nums) {
    let res = [];
    for (const n of nums) {
        res.push(n * n);
    }
    return res;
}

Okay, I know there's a cleaner way. Here you go:

function squareEach(nums) {
    return nums.map( n => {
        return n * n;
    });
}

Problem is, I could only know nums's type through comments. And while comments are good, nothing in comments will stop me from writing a really bad bit of code that ends up sending undefined or something worse to squareEach().

Now, here's the same function in Elm:

squareEach : List Int -> List Int
squareEach nums =
    List.map (\n -> n * n) nums

First I define squareEach, telling Elm (and anyone reading my code) that it will take a list of integers and return the same kind of thing. Then I implement it, using a lambda (anonymous function) and List.map to emulate the same behavior as Array.map() in the second JavaScript example.

Now suppose I write some function elsewhere that tries to pass, say, a String to squareEach. The Elm compiler will catch it and provide an error for me. I can't even compile stupid type mistakes.

And that's thing #3 I learned.

Love recompiling

I fought with the Elm compiler a lot. Some mornings, I just had to stand up and walk away from the computer, since I could not get the compiler to agree to build my code. Invariably, my thinking was in error and taking the time to correct my mistakes the proper way resulted in cleaner, more elegant code. Spending copious amounts of time reading documentation helped. It isn't a great feeling, constant screens of red text in my terminal as Elm code fails. But you know what's an incredible feeling?

No runtime errors.

That's the tradeoff: rather than finding a ton of errors in production because an unexpected value slipped passed me, even with tests, hammering away against compiler errors results in a fairly stable application. No surprise undefineds to wreck your runtime. This isn't to say that Elm makes failproof apps—any language is only as good as its user. However, the number of issues caught by the compiler vastly reduces live debugging. Adding good tests to this mix is an even greater guarantee of stability.

Well, I say "stable," but...

Elm ain't done yet

There's no question this language is going places, and I've never had more fun putting together a frontend. Nevertheless, there are a few pieces still missing from the core library, like reasonable Date/Time tools. I used Justin Mimb's excellent date-extra package to handle date/time parsing. But I shouldn't have to install a third-party dependency for ISO Strings, or to compare (<, >) Dates.

On the flip-side, the community packages are of a high quality. Just know that if you're making a non-trivial app with Elm, you'll end up installing a couple of third-party dependencies, or writing a bunch of your own helper code.

So if you want to change the way you think about programming, I highly recommend checking out a functional language. And if you want to fall in love with frontend again, I highly recommend Elm.