PurelyFunctional.tv Newsletter 331: Tool: shadow-cljs

Sign up for weekly Clojure tips, software design, and a Clojure coding challenge.

Issue 331 - June 17, 2019 · Archives · Subscribe

Clojure Tool 🔨


I've never used shadow-cljs on a production project, so this week I rolled up my sleeves and used it for a new thing I'm working on. I was quite impressed.

shadow-cljs is a complete project tool, like Leiningen. It does all the hard work you need to do to get a ClojureScript project started, developed, and built. I was very impressed and I daresay it will be my main way to develop ClojureScript projects in the future.

It really lowers the barriers to entry---so much, in fact, that I think I will use ClojureScript more. I will occasionally use plain JavaScript for little scripts that I don't think merit the overhead of setting up a ClojureScript project. shadow-cljs reduces that overhead so I'll probably use it a bit more.

Clojure Media 🍿

I have really been enjoying the ClojureScript Podcast by Jacek Schæ. Just check out the lineup: David Nolen, Russ Olsen, Mike Fikes, and Bradford Smith (who works on Google Closure). Jacek is doing a great job spreading the word about ClojureScript.

Brain skill 😎

Make it concrete.

Programmers have a tendency toward abstraction. It's a good skill, but sometimes we over-apply it. Next time you're stuck on a problem, get down and dirty and make it concrete.

Sure, in the moment, it may seem like you need to write a job scheduling system. But step back and get concrete. What you really need is for one thing to run on Friday at midnight. When you put it that way, a cron job is the obvious answer.

Clojure Challenge 🤔

Last week's challenge

The puzzle in Issue 330 was to list some properties of the sort function. They didn't need to be in code. Even English sentences were accepted. The idea was to start thinking about them.

I got some great submissions. You can check them out here.

Some notable ones:

  1. sort should be idempotent
  2. sort should return a collection with the same elements as the argument
  3. sort should return a collection where each element is less than the next element

All of the submissions were great and rather complete tests for sort. Mark Champine came up with a bunch of interesting ones that test the function from different angles.

There were two techniques that were not used that I thought I should mention.

  1. Generate a sorted list, then shuffle it. Sorting the shuffled list should result in the sorted version.
    Sometimes it's easier to generate the desired output than to check the output given random input.

  2. Use another implementation of sort as a model. Compare your version of sort to the model.
    In this case, it's probably cheating, but it's the most straightforward way to test it if you can do it. As an example, you could test that a key-value database acts like a hashmap. A hashmap would be your model.

Sometimes, these two techniques can work through difficult situations to test.

This week's challenge

generating sorted lists

In the technique #2 above, we generate a sorted list. But how do we do that?

This week's challenge is to come up with ideas how we might do that. Don't worry if your idea is crazy. The intent is to engage your brain and get thinking about how to generate values.

Here are two I'll just throw out there to plant a seed:

  1. Generate random lists and throw out unsorted ones. (Clearly, this won't work, but that's okay! I'll throw it out there anyway.)
  2. Generate random lists and sort them. (Is this cheating? It doesn't matter. I'm putting it out there.)

Now it's your turn. Get creative! Let's see how many wacky ways we can think of.

As usual, please send me your answers. 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