Clojure Gazette 172: Comparing designs from different contexts

Comparing designs from different contexts

Issue 172 - May 09, 2016

Read more about this week's sponsor, Arachne , at the end of this letter.

Hi Clojurnators,

Design is not in my job title. I've never formally studied it. But I think I'm a designer as much as everyone is in the modern world. It's a natural human tendency to modify our environment. We are all designers, whether we're rearranging furniture or configuring our cell phones. We design all the time.

Because design is so important in our lives, I have read several books on it. And what I've learned is that design is about solving problems. The quality of a design can only be judged within the context the medium is meant to be used in. Can you really compare the design of two programming languages? What seem like flaws in one language might be strengths in a different context.

This relativity of flaws is why it is hard to respond to design criticisms of a language. For instance, it's true that Clojure as a language is diminished because of nil. NullPointerExceptions are a time suck for programmers. The same language without them would be undoubtedly better.

But this analysis ignores an important point. Clojure was designed to integrate well with the JVM and all of the existing JVM libraries. The JVM has NullPointerExceptions. So this flaw was inherited, due to an explicit design decision. The best Clojure could do is make it better to deal with nulls. And I think it has succeeded at that very well. There are different ways to deal with it, but Clojure's choice makes it very comfortable. The two are connected: Clojure's nil and its abundance of good, industry-tested libraries. We need to analyze the tradeoffs of every language for our particular needs.

Do we need to insult the design of the lawn chair to praise the elegance of the dentist's chair? Both of them sit one person and both recline. But they obviously solve different problems. By all means explore the design space of languages. Please, do, in fact. But you don't need to lose respect for the design of a language to learn about other languages.

Why do we feel the need to declare allegiance to one set of design decisions? We soon lose faith in it and publicly voice all of the problems that design leads to. Then we choose another set of decisions that solve those problems and pledge our allegiance to it. Meanwhile, we are ignoring the reasons we are building a solution in the first place: to solve real problems for people.

Rock on!

PS Please check out the sponsor. The Arachne Kickstarter is doing well and can use your support.
PPS Want to get this in your email? Subscribe !
PPPS Want to advertise to smart and talented Clojure devs ?

Sponsor: Arachne

For a hobby project for learning Clojure, piecing together a web app from libraries works fine. But important concerns like security, logging, and authorization often get left behind because who has time for the boilerplate? Luke VanderHart has a new Kickstarter to build a modular app framework for Clojure. With it we will still piece together our app from parts but the boilerplate will be taken care of by the modules. It's the best attempt at a framework I've seen that leverages Clojure's unique strengths. Please back the project if you'd like to build production apps in minutes, not months.