About this book

Clojure is a modern, dynamic language that you can use to develop robust, multithreaded programs. Clojure Polymorphism is a comprehensive guide that shows you how to use Clojure’s features to your advantage.

The book begins by describing examples that show how to define and implement abstractions with plain functions and multimethods. Then you'll analyze these examples and separate the good and bad aspects of their design principles. You'll also learn how to perform data transformation abstraction with a plain function and discover how to write new cross-platform predicates while keeping the core of your abstraction free from reader conditionals. The later chapters explain the considerations to keep in mind when implementing Clojure protocols on the Java Virtual Machine (JVM).

By the end of this book, you’ll know how to use the various polymorphic tools of Clojure to your advantage while designing your applications.

Publication date:
November 2019
Publisher
Packt
Pages
56
ISBN
9781838982362

 

Introduction

When it comes to Clojure (when I say Clojure, I am usually referring to both Clojure and ClojureScript. Sometimes I am referring only to JVM Clojure, but context should make it clear), there are many tutorials, websites, and books about how to get started (giving information on the language syntax, how to set up a project, how to configure your IDE, and so on). There are also many tutorials, websites, and books about how language features work (protocols, transducers, core.async, and more). There are precious few tutorials, websites, and books about when and how to use Clojure's features.

This book is not a getting-started tutorial. Neither is it a deep dive on a particular Clojure feature. It is more like a class in comparative architecture. I assume that you are familiar with Clojure and even a bit proficient at it. I will pick a theme and talk about the tools Clojure provides in that theme. I will use some example problems, solve them with different tools, and then pick them apart for what is good and what is bad. There will not be one right answer. There will be principles that apply in certain contexts.

Who am I? I'm Paul Stadig, and I have been using Clojure since 2008. I took a job writing Clojure full time (actually writing Clojure every day) in 2010. Since then, I have worked at two other companies writing Clojure code full time, and I still do!

I have worked on large, distributed, cloud-based applications that ran Clojure services on hundreds of Amazon Web Services instances, processing jobs from RabbitMQ. I have worked on Clojure services that served front-page ad carousels to 1,000,000 visitors per day. I have worked on distributed Clojure systems that process graph algorithms across billions of observations about network activity.

I have patches that have been applied to Clojure. I have been an administrator for Clojure's Jira ticketing system, and for the Clojure developer Google Group. I have been actively involved in Clojure user groups. I have created and contributed to many Clojure open-source projects. I have spoken at Clojure conferences. I have been a technical reviewer on several Clojure books.

I also have a life outside of Clojure. I live in central Virginia in the foothills of the Blue Ridge Mountains with my wife and four children.

This is not a cookbook. This is me conveying my experience of writing large Clojure systems. If I am successful, then I am not teaching you recipes; instead, I am helping you develop a taste for good Clojure design. Partly, this will be up to you. I will help as much as I can, but you must see through the examples to perceive the design principles underneath, then take the design principles and use them in your own work.

The principles I am sharing are based on my own experience, so they may not be the best advice or the most beautiful design principles. I am writing this in a very personal style, as though we were chatting in a coffee shop. Just like any other advice you may receive, you must judge it for yourself. Do not throw out everything because you found one thing that is wrong or does not make sense. Take the good. Leave the bad. Use discernment.

Finally, I cannot claim to have invented all of these principles, but I will attribute where I can. Many of these principles I learned working with amazing people on amazing teams, and—if I learned my lessons right—you will get to benefit from that experience.

I hope I can help you develop a taste for good Clojure design.

If you have any questions or feedback, send me an email (paul@stadig.name). You can also, find me at Real World Clojure (http://realworldclojure.com/).

About the Author

  • Paul Stadig

    Paul Stadig has been using Clojure since 2008. He took a job writing Clojure full time in 2010. Since then, he has worked at two other companies writing Clojure code full time, and still does! He worked on large, distributed, cloud-based applications that ran Clojure services on hundreds of Amazon Web Services instances, processing jobs from RabbitMQ. He worked on Clojure services that served front-page ad carousels to 1,000,000 visitors per day. He worked on distributed Clojure systems that process graph algorithms across billions of observations about network activity. He has been an administrator for Clojure’s Jira ticketing system and the Clojure developer Google Group. He is actively involved in Clojure user groups and has created and contributed to many Clojure open-source projects. He has spoken at Clojure conferences and is a technical reviewer on several Clojure books. Paul lives in central Virginia in the foothills of the Blue Ridge Mountains with his wife and four children.

    Browse publications by this author
Clojure Polymorphism
Unlock this book and the full library FREE for 7 days
Start now