PurelyFunctional.tv Newsletter 323: Tip: Keep your workflow simple

Issue 323 - April 22, 2019 · Archives · Subscribe

Clojure Tip 💡

keep your workflow simple

In my Repl-Driven Development in Clojure course, I recommend learning three commands for executing code: one to evaluate the whole file, one for a top-level form, and one for a single expression. With those three, you've got all you need for selectively evaluating code. There are more options available, but are they worth learning? It's doubtful.

It's always tempting to solve workflow problems with another tool. Is reloading namespaces hard to get right? Add another tool. Do you forget what keys belong in a certain map? Add another tool.

These tools could fix your problems. And they might bring their own new problems. In my opinion, it's much better to aim for elegance and solve the problems by removal, not addition.

I've done a tiny bit of modern JavaScripting, and there were two problems with the tooling. The first one everyone talks about: the churn of tools. New tools replacing old tools. And new versions of existing tools. Very rapid change.

But there was a second problem that people talk about much more rarely: the sheer quantity of tools. Transpilers. Linters. Minifiers. Tree shakers. Dependency tools. Whatever Browserify is. Each one solves real problems. But there is a high cost associated with each.

We don't have the same problem to the same scale, but the problem is there. We will always be tempted to reach for a new, shiny tool to make our problems disappear. Very often, the problem is still there, and we also have a new problem---the care and management of the tool.

My recommendation is to avoid taking on new tools. Sure, give them a shot, but with a skeptical eye. That won't completely eliminate new tools since they will tend to slip in, just due to entropy. So you must actively look for tools and dependencies you can eliminate.

Do you have a tip you'd like to share? Let me know. Just hit reply.

Functional Programming Media 🍿

As you may know, I have a podcast. It comes out twice per week. A kind listener recently pointed out that my RSS feed only had ten items in it. That means only 5 weeks were included. I've extended it to all items now, so you can find all the episodes back to day one.

Check out my podcast. It's called Thoughts on Functional Programming.

Brain skill 😎

Take notes by hand. There's something about holding a pen and moving your hands across an empty page. Paper is two-dimensional, so your notes don't have to be linear. Your mind slows down since you hand write slower than typing. Does it make you learn better? That's unclear. But using a different part of your brain might help make more connections.

Clojure Puzzle 🤔

Last week's puzzle

The puzzle in Issue 322 was to count the number of ways to add coins up to 200£.

You can see the submissions here.

One thing I like about Project Euler problems (and this was one) is that they seem pretty simple. The difficulty comes in their scale. They often don't fit in memory, or the naive solution is exponential, or some other scaling issue. The simple, straightforward solution doesn't work. So you have to start using your brain again, even when you're in a powerful language.

This puzzle was no exception. My naive implementation never returned. You can see mine here. I did manage a recursive, lazy approach which does much better. It was inspired by Duminda Rathnayaka's submission.

This puzzle was perhaps a little harder than usual. I only got two submissions. This gives me the idea to teach a little bit about recursion. I do have a podcast episode about it , but it's very high-level.

This week's puzzle

range consolidation (from Rosetta Code)

We can represent a range of numbers as a tuple, like this [1 4]. That means all real numbers between 1 and 4, including 1 and 4. The task is to write a function that takes a collection of ranges and consolidates them so that there are no overlapping ranges.

For example, [1 4] and [3 5] overlap, so they would be consolidated to [1 5]. [10.2 15] does not overlap, so it doesn't change.

(consolidate [[1 4] [3 5] [10.2 15]]) ;=> [[1 5] [10.2 15]]

There can be any number of ranges in that collection, and they could be in any order.

As usual, please send me your implementations. I'll share them all in next week's issue. If you send me one, but you don't want me to share it publicly, please let me know.

Rock on!
Eric Normand