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.
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
NullPointerExceptions are a
time suck for programmers. The same language without them would be
But this analysis ignores an important point. Clojure was designed to
integrate well with the JVM and all of the existing JVM libraries. The
NullPointerExceptions. So this flaw was inherited, due to an
explicit design decision. The best Clojure could do is make it better to
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.
PS Please check out the sponsor. The Arachne
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 ?
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.