PurelyFunctional.tv Newsletter 230: Brutalism, Delays, Characters

Written by Eric Normand. Published: June 19, 2017. Updated: July 2, 2017.

Eric Normand's Newsletter

Software design, functional programming, and software engineering practices

Over 5,000 subscribers

Issue 230 - June 19, 2017

Hi Clojurists,

Please enjoy the issue.

Rock on!

PS Want to get this in your email? Subscribe!

The New LISP

I love these think-pieces with new perspectives on Clojure. I'm a collector of perspectives and I always cherish finding ones that are new to me. This one compares Clojure to Brutalism, the architectural movement.

Dan McKinley on the Cognicast

Dan McKinley talks about his experiences at Etsy and Skyliner. Dan McKinley is famous for saying "use boring technology" and for clearly explaining what it takes to make data-driven product decisions.

I happen to agree with the "boring tech" idea, but I disagree that PHP is such boring tech. White Screens of Death are always very exciting to me.

Clojure/conj Opportunity Grants

The Clojure conferences always do a great job helping people from underrepresented groups get to the conference, even if they can't afford it. Please apply because the Conj is a great experience and a welcoming group.

Username and Password components (refactoring)

Last week I recorded another lesson in the Building Re-frame Components course. This lesson marks the beginning of the end. I'll be wrapping the course up soon with a full-blown user signup form.

Delay: Clojure's forgotten concurrency primitive

Dan Lebrero has been killing it with tons of great articles recently. This one is no exception. It's about the importance of Delays as concurrency primitives. I think he's right and I'll be adding it to my Ultimate Guide to Clojure Concurrency.

REPL Debugging: No Stacktrace Required

Stuart Halloway makes a good point about stacktraces in this article. It's no excuse for hard-to-read stacktraces. However, I really do sympathize with the technique he demonstrates in this article. The technique truly makes stacktraces less important. He shows that by doing REPL-driven development, you can quickly debug a function and figure out which expression has the problem. The instinct to dive into the REPL to solve your own problems is one everyone should develop as soon as possible. Use of the REPL is a sure sign of experience. The REPL contains the answers to any question you might have because it is the live, running system. That said, something must be done about error messages, and I have an idea.