Last Thursday night we took the HuffPost Tech Team out for an exciting night of ping-pong. We're passionate about Table Tennis. If you come to visit the Huffington Post you'll often find our engineers facing off around the wiff-waff table after a hard day of coding and debugging. In the last six months the Huffington Post engineers have delivered hundreds of new features from new editions for Japan and Maghreb to new iOS and Android apps. It was time to reward the team with a night of beer, bar food and lobbing bright orange plastic balls around green tables with rubberized paddles.
I was watching the action with HuffPost Labs' Director Brandon Diamond and Intern Ilana Sufrin, cheering on the team from the sidelines, when the "everyone on the planet needs to learn to code" meme came up. I am a big fan of this idea. I've written about it a couple of times and I'll talk your ears off if you ask me why it's such a good idea. Perhaps it's because as a literally "starving art student" in the 1980s "learning to code" paid my bills, enabled me to provide for my family, and sent me around the world. With all the problems we have today, more people coding means more people happy and more problems solved.
There are hundreds of avenues for the aspiring student to learn to code from the traditional university degree route (Stanford), to non-accredited schools (The Starter League), to free online resources (edX.org). My worry about some of these programs, even the academic ones, is that students learn to cut and paste code, not write code. To be a writer of any language, English or Python, you have to not only memorize the grammar or syntax, but deeply understand the core concepts.
Shakespeare did not cut and paste paragraphs, he invented new ones. Shakespeare didn't learn to write at a prestigious university, he learned in grammar school, which he attended from the age of 6 or 7 until the age of 12 or 14. There he learned the core concepts of English, Latin, and Greek -- especially Latin. And he learned these human languages at a tender age when it was easy to deeply assimilate new concepts.
By the time I started learning to code, as a hobby, I was well into my twenties. I believe my computer science education started much earlier. My father, a mathematician, used to give my brother an I unsolvable math problems as puzzles and entertainment (the iPad having not been invented yet). I remember Dad writing down these problems, like the Hadwiger-Nelson problem, on the back of menus and napkins while we waited for our pancakes to arrive at a diner. I was in elementary school, I had no idea who Hadwiger-Nelson were, but I was fascinated by the idea that it was impossible to color a map of the US using only three crayons such that no two states of the same were touching. Dad had made mind numbing geometric graph theory enjoyable to the 6-year-old. Reddit would have loved him.
You might be thinking: What has coloring maps (or nodes on a graph) efficiently have to do with learning to code? Everything. When I did eventually discover BASIC, Pascal, and C the core ideas of imperative programming, data structures, and algorithms, seemed intuitive to me. As if I was remembering something I had forgotten, not learning something new.
Let's go back to the ping-pong. Learning to code is important, as important in the 21st century as learning English was in the 17th century, if not more. Mostly we teach the coding and computer science to young adults. If we want to make a dent in the software crisis we have to teach it to grammar school aged kids. There are some noble efforts out there, such as Squeak, created by seminal thinkers Dan Ingalls, Alan Kay, Ted Kaehler, and Scott Wallace. Squeak is great if you want to teach youngsters about object-oriented programming and messaging in a Smalltalk environment.
With the advent of the Internet and the mountains of data that is collected every minute online, object-oriented Programming isn't enough. We need to teach ourselves, and our kids, functional programming. Google, Facebook, Twitter and even the Huffington Post has a problem with data -- a big data problem. We're using functional programming techniques with programming languages like Scala and Erlang to write distributed systems that can process petabytes of data quickly to discover the grains of gold in an endless river of Internet traffic that passes through our collective servers. (Just like the NSA!)
Functional programming isn't new, it's just been ignored. Mostly this have been for performance reasons. Imperative style programming, executing one instruction after another while changing the shared contents of a computer's memory, was just faster on the computer hardware of the 20th century. Now that we do our computing on clusters of computers in the cloud, functional programming is faster than imperative because it's possible to break a computing problem down into parts and send it off to different computers at the same time.
Object-oriented programming is younger than imperative or functional -- it's the new kid on the block. OOP grew up with the graphical user interface (GUI) and is very helpful in figuring out which button was clicked and what to do about it. It's natural to think of computer users interacting with objects and breaking down areas in a window or on a web page into buttons, menus, text, images and movies.
Functional style programming seems new, almost like a fad, but functions are a key part of (almost) every computer language. It's just in functional programming the functions are the stars, not the supporting players. What does it mean for a function to be a first class part of a language? It means functions do one thing, and one thing only; work done outside a function doesn't change anything inside the function (and vice versa); functions are data and data is functions so functions can pass other functions around like a soccer ball inside the computer.
A big problem for coders who come from an object-oriented or imperative programming background is wrapping their heads around Functional Programming core concepts. You have to think different, really different, to do functional well. Kelsey Innis does an excellent job of explaining it in her video Learn Functional Programming Without Growing A Neckbeard. Unfortunately that's a video lesson aimed at adults who, like me, who grew up with Java and want to get up to speed on Scala. Good for me, not so good for 6-year-olds.
During the ping-pong games Brandon, Ilana, and I tried to come up with a metaphor that would explain the core concepts of Functional Programming to non-programmers: 6-year-olds and Art majors. Ilana is an editorial intern with an arts background and an interest in coding and thus a great partner in our quest to explain Functional Programming without jargon. We wanted to find a metaphor that captured the essence of deterministic, encapsulated, commutative, and first class functions without explaining what any of that gobbledygook means.
Below is a sneak peek at our metaphor...
