we write about the things we build and the things we consume
the euroclojure experience
You know that kind of conferences, not very big ones, but packed with passionate people whose only interest is having fun, sharing and learning cool things, and then having chats all (and I mean ALL) together in front of some drinks? That kind of conference where it’s all about the experience?
Well, EuroClojure 2012 was such a conference.
And I was there, so here is a brief list of take-away points I would like to share: hopefully you’ll enjoy them and in the spirit of the conference be inspired in sharing yours.
Let the fun begin.
because fun is what you have with clojure
And I don’t mean the language itself, which IS fun, by the way.
EuroClojure showed us that Clojure can be used for music and digital visualizations, providing so a great environment for creating domain specific languages that generate art and let users have fun with it: this is a testament to the great flexibility of Clojure as a language and how it can be used to model problem domains far away from our everyday enterprise-ish stuff, yet without sacrificing simplicity.
and it makes hard things nicer, and simpler
The former, even if practically away from our industrial world, is deeply linked with query languages such as SQL and Datalog, while the latter is vitally important to make sense of the big data volume we have today.
Scaling isn’t just a property of systems, but programming languages too: is a programming language easy to develop with for both smaller and larger problems? Does it make simple things simple and hard things simpler?
Well, Clojure really is such a language.
without losing simplicity
Simplicity should be what every programming language and every system strive for, but unfortunately modern imperative/OOP programming is far away from that.
This is not a fault of OOP per se; quoting Alan Key, as refreshed by Sam Newman during an after-conference chat: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP".
- Stop abusing abstractions
- Prefer simple data structures
- Build functions on top of data structures
- Use/Compose functions as your main building blocks
with events as the central theme
Whether we’re talking about infrastructure monitoring, users monitoring, or real-time user interactions, events are going to play a central role in our systems.
Also, honourable mention to Paul Ingles presentation about treating users interactions as actual data to build on: as your users aren’t really a sterile entry in your database, but really an ever changing sum of their interactions.
so should we all use clojure and forget about everything else?
It’s not that easy.
We have existent applications, existent businesses, existent knowledge: migrating everything toward something new is not an easy task.
And Clojure is not the only great language out there.
But Clojure surely IS an excellent choice in case you wanted to start your new business, or just migrate your existent one if possible for you. And by the way, it is an excellent language, ecosystem and community to learn from even if you will not end up using it for your everyday work.
what about clojure @metabroadcast?
We’re starting evaluating Clojure and using it for some infrastructure pieces: in particular, we use the Nimrod Metrics Server, which got a mention at EuroClojure too form Bruce Durling and so you may already know about it, and plan to start using Storm very soon for our real-time needs.
So, exciting times ahead, and if you wanna be part of the team, do not hesitate to get in touch: we’re hiring!