Getting Clojure to Functional Programming

We did a Clojure study group, drilling into the langauge features. Want to hear our before/after thoughts? Want to see Jeroen's sketch notes about the book? Read on!

Getting Clojure to Functional Programming

At Infi we're not dogmatic about technology, but we do have our preferences. Some folks already love Clojure, and some still needed to become "Fresh Converts". So we got together and studied Programming Clojure, 3rd ed. by Alex Miller, discussing a chapter each week. Want to read about our expectations, one person's sketch notes, and our conclusions? Then this post is for you!

Here's Jeroen's expectations:

I've done a decent share of functional programming before. Maybe 15 years ago I've worked some with Haskell, and in college I also took some classes around lambda calculas and such. With Clojure I expected a pragmatic, productivity-focused functional language. Something less "math-like" than Haskell, less "academic" than Prolog. A language with the set-powers of SQL but then in an elegant way, useful for building line of business applications that run side by side with other JVM-based applications. And also a new way to write SPA's with ClojureScript.

Here's Wilco's expectations:

There are two things that I really like about programming languages: power and safety. On one hand, I like powerful languages like C++, that allow you to do many things using its powerful but unchecked meta-programming macros. On the other hand, a compiler that warns you of many potential errors, such as those for Haskell or Rust, lets you write safe code that avoids many problems in your code. Because Clojure is a lisp, it allows you to extend the language using macros, which manipulate syntax directly instead of generating code as plain text. Therefore, I'm expecting a very powerful language that still has some safety.

Here's Steven's expectations:

I have worked on a bigger Clojure and ClojureScript project for a few years but I always felt that I missed a complete overview of the language itself. Being not that good at working my way through books on my own I saw this joined book study as a great opportunity. It also helped to understand it better because we discussed each chapter within the group.

Here's Roeland's expectations:

In the past I've done some functional programming in several languages, even a bit of Common Lisp during my studies, so naturally I became a bit curious when colleagues started talking about and even using Clojure. I was curious about the practicality of the language. For example, whether it would be possible to do interop with Java. And what these 'specs' one of my colleagues mentioned regularly are about.

With these expectations we started our study group. Every week we prepared by close-reading a chapter. And every week Jeroen made his first attempt at taking Sketch Notes for things to discuss with the group. So without further ado, here's the outcome: a Kafkaesque stream of consciousness on paper, digitized for your viewing pleasure.

After all that, the question is: what became of people's expectations? First up, Jeroen's thougths:

This book is great. It was clear, to the point, and at a perfect level. The language itself is nice, but not to my taste. There are things I like, most noticeably macros are extremely powerful, and this changes my view and understanding of other programming languages a lot.

But there were more things that were not to my taste. I really prefer to work with a more strongly typed (where type inference is also good) language. In addition, I feel the terseness of both the language and idiomatic (and example) Clojure code comes at too great a cost: too much readability is typically lost for my taste.

Nonetheless, Clojure is a mature language with a proper ecosystem. I dislike the tradeoffs it makes personally, but nonetheless think that it can be a proper choice for a project.

Wilco's thoughts:

I was pleasantly surprised in how well the language works with Java, while still being pleasant to use in a functional style. The book did a good job in explaining each aspect of the language, even though it didn't really show how to use them together.

Macros are pleasant to use, and being able to handle expressions as data is very powerful. However, it is often not clear whether something is a function or a macro. The book doesn't really talk about this, even though it is often quite important for performance or understanding.

Steven's thoughts:

I liked the book a lot. Some books are too much in depth to be readable and some books are really childish or shallow but this was exactly the amount of detail I wanted. This way reading the book and also understanding it was easy to do.

Roeland's thoughts:

Due to time constraints I didn't do a lot of experimenting with Clojure (I have something for that planned though), but I do feel I have a general idea about the language. I especially admire the solutions the language provides around dealing with concurrency, specifically the power software transactional memory can offer. Also the versatility offered by the language embedded macros seems useful (and a bit scary). And the concept of specs was quite new to me, but also interesting. Especially the way it can help generative testing. And as it turns out, interop with Java is a breeze. These subjects, and a few more, were discussed and explained by this book in a pleasant and understandable manner.

Conclusion

Clojure is a great language. It does have tradeoffs that play towards personal taste. What's certain though, is that you can build fine projects with it, and that Infi would be happy to do so. So if you have a project, or if you're interested in working on such projects: let us know!

Wil je iets waarmaken met Infi?

Wil jij een eigen webapplicatie of mobiele app waarmee jij het bij anderen maakt?

Waargemaakt door de nerds van Infi.
Nerds met liefde voor softwareontwikkeling en die kunnen communiceren. En heel belangrijk: wat we doen, doen we met veel lol!

Wij willen het fixen. Laat jij van je horen?

Voor wie heb je een vraag?