PurelyFunctional.tv Newsletter 366: Is the Clojure philosophy bad for beginners?

Written by Eric Normand. Published: February 24, 2020.

Issue 366 - February 24, 2020 · Archives · Subscribe

Clojure Tip 💡

Is the Clojure philosophy bad for beginners?

People often ask if Clojure's philosophy is bad for beginners, so I'd like to address it in the context that I set up in the last issue. In short, if it's true that Clojure libraries shouldn't anticipate all of the needs of the user, doesn't it make it hard for beginners to use the library? My short answer is I don't know.

Here's the code from last week that the CSV library expects the users to write themselves:

(defn rows->maps [csv]
  (let [headers (map keyword (first csv))
        rows (rest csv)]
    (map #(zipmap headers %) rows)))

Any experienced Clojure programmer could write something like this with no sweat. But could a beginner? I doubt they could do it without some help. Some of the concepts are at least intermediate level, like combining map with zipmap.

It reminds me a lot of the troubles the Smalltalk group had teaching beginners that I talk about in my recent podcast episode. Here's a quote from The Early History of Smalltalk.

It started to hit home in the Spring of '74 after I taught Smalltalk to 20 PARC nonprogrammer adults. They were able to get through the initial material faster than the children, but just as it looked like an overwhelming success was at hand, they started to crash on problems that didn't look to me to be much harder than the ones they had just been doing well on. One of them was a project thought up by one of the adults, which was to make a little database system that could act like a card file or rolodex. They couldn't even come close to programming it. I was very surprised because I "knew" that such a project was well below the mythical "two pages" for end-users we were working within. That night I wrote it out, and the next day I showed all of them how to do it. Still, none of them were able to do it by themselves. Later, I sat in the room pondering the board from my talk. Finally, I counted the number of nonobvious ideas in this little program. They came to 17. And some of them were like the concept of the arch in building design: very hard to discover, if you don't already know them.

Seventeen nonobvious ideas in two pages of code. And this is a language designed for children! What hope does Clojure have of being beginner-friendly?

Alan Kay's conclusion was that programming is hard. It has to be taught like we teach reading---over many years with many examples and lots of guidance. There are a lot of ideas that aren't hard when they are taught, but they are hard to discover on your own. We need to learn them and pass them on to the next generation. Programming is culture.

So when people say it's unfriendly to ask beginners to write the code above, I agree, but I think the solution is not to wrap it up in a function and give it to them. I think the solution is to teach them to do it themselves. That's passing on culture, and in fact that's what the clojure.data.csv Readme does. Beginners solve their problem and learn a bit of Clojure at the same time.

The extra advantage is they are learning something that is useful elsewhere. They're not learning the ins and outs of the options of that particular library. They're learning to use the core library and transform data in a Clojury way. We need to teach the next generation.

I don't think we can blame a language for programming being hard. Clojure is hard, JavaScript is hard, Smalltalk is hard. Each language might make some things easy, but there will always be hard things. We need to pass down the culture that we have built up for a few generations now. It's more work for us experienced folks, and, yes, more work for the beginner. But the beginner will be better off! Honestly, would you rather know how to write your own parser or know the specific combination of options you need for one particular parsing library? I just think it's a matter of education, not coding.

Book update 📖

Chapter 6 is out! Buy it now: Grokking Simplicity.

Also, the liveBook is ready for prime time! This means you can preview the content of the book before buying and you can read it online after you buy. Amazing!

You can buy the book and use the coupon code TSSIMPLICITY for 50% off.

Podcast episode🎙

In my most recent episode, we are reading from The Early History of Smalltalk by Alan Kay. Listen/watch/read here. Be sure to subscribe and tell your friends.

A new episode is coming soon. In it, I read Lambda: the Ultimate GOTO by Guy Steele, Jr.

Clojure Challenge 🤔

Last week's challenge

The challenge in Issue 365 was to model a Starbucks coffee. There were no submissions :( I guess modeling problems aren't that fun? Let's try something different.

This week's challenge

Number of hands of poker

Poker users a 52-card deck, where each card is unique. After shuffling, a player gets five random cards. How many different hands are there? Remember, in poker, the order of the cards in your hand does not matter.

Write a function that takes the number of cards in a hand h and the number of cards in the deck d and calculates how many possible hands there are.

(defn combinations [d h]
  .....
)

Hint: there is a mathematical formula for combinations already!

As usual, please reply to this email and let me know what you tried. I'll collect them up and share them in the next issue. If you don't want me to share your submission, let me know.

Rock on!
Eric Normand