PurelyFunctional.tv Newsletter 462: PurelyFunctional.tv Migration

Written by Eric Normand. Published: February 21, 2022.

Issue 462 - February 21, 2022 · Archives · Subscribe

Housekeeping 🧹

PurelyFunctional.tv Migration

A little housekeeping this week.

I'm migrating all of my video courses from PurelyFunctional.tv to a new platform called Podia. In fact, that has been the only way to get access to them for about a year. As I've said before (but maybe not enough times?), I'm going to totally remove access to the videos on PurelyFunctional.tv on March 7. Current members' subscriptions have already been canceled, so no one will be charged. Even after you've been canceled, you still have access until your expiration date.

On Podia, you can buy the courses with either a one-time purchase or a 12-month purchase plan. That purchase plan, along with the purchasing power discounts for other countries, should make them affordable.

As always, most of my output (guides on my site, newsletter, podcast, etc.) is free. If you need well-planned courses, like video, or just want to support me, please buy a course on ericnormand.podia.com

I haven't mentioned this before, but at the same time as I power down the videos on PurelyFunctional.tv, I'm going to retire the PurelyFunctional.tv brand. Instead, I'm just going to use my name, Eric Normand. When I chose PurelyFunctional.tv as a name, I had hopes that I could bring other FP languages and teachers into the fold, but that has not gone well. It was never a great name, anyway. Now it will just be a personal brand.

The new website will be ericnormand.me (the .com was taken). My podcast will be The Eric Normand Podcast. My newsletter will be The Eric Normand Newsletter. No clever naming. Simple and clear win!

My next book will be The Eric Normand Book (just kidding!!!).

So, no other essay this week. I'm going on a needed break.

Awesome book 📖

The Essence of Software by Daniel Jackson is a book about designing software's mental models. In it, Jackson describes many cases in commonly used software where user error was exacerbated by poorly chosen mental models.

The book is good, though it left me wanting more. The first few chapters have a very analytical feel, which I liked. He presented a framework for concisely and completely describing "concepts" (his name for the parts of a mental model). It seemed really useful, and I was saddened that he didn't continue using it throughout the rest of the book. Instead, problems with concept design were described narratively. I wonder why he didn't use it. Perhaps it's not as useful as it appeared. A good notation should clarify the idea and reveal problems---as well as being more concise than narrative form.

That said, there is some analysis of why poorly designed concepts don't compose well and often lead to errors. One is left feeling like it is still a dark art, full of esoteric rules of thumb. Yet the book brings hope that one can at least identify and describe why a concept might be confusing before you build the software.

Does the world need this book? Yes. We need to understand why some software is frustrating. But the book needs a good follow-up with more case studies of applying it to a new project.

Book update 📘

More Twitter messages like this one in my feed. I love it:

And did you know there's now an audiobook version available? What? I haven't listened to it (I actually had nothing to do with it). You can hear the first chapter on the Manning site.

You can order the book on Amazon. Please leave a rating and/or review. Reviews are a primary signal that Amazon uses to promote the book. And they help others learn whether the book is for them.

You can order the print and/or eBook versions on Manning.com (use TSSIMPLICITY for 50% off).

Clojure Challenge 🤔

Last issue's challenge

Issue 461 -- Primes in a number -- Submissions

This week's challenge

Odd One Out

Write a function that takes a list of words (Strings). The function should return true if exactly 1 word differs in length from the others. It should return false in all other cases.

Examples

(odd-one? ["a" "b" "c"]) ;=> false
(odd-one? ["a" "b" "cc"]) ;=> true
(odd-one? ["abc" "aa" "xyz" "jj"]) ;=> false

Thanks to this site for the problem idea, where it is rated Very Hard in Java. The problem has been modified.

Please submit your solutions as comments on this gist.

Rock on!
Eric Normand