Recently, I sat down and compiled a list of programming features that really make a positive impact on my day-to-day work:
- Functional programming- First-class immutability- First-class REPL- Data-oriented programming- Static typing
That’s it. The end.
You can get all of those bullet points in TypeScript or JavaScript + Flow. But I lied about it being the end. There’s one more bullet point:
- Simplicity
Rich Hickey, the author of Clojure expressed it best in his talk “Simple Made Easy”. The talk is mostly about architectural simplicity, but the language itself is also fundamentally syntactically simple.
There are only a handful of special symbols. Everything else is just combinations of data + functions. There is no special syntax for async/await. There is no special syntax for comparisons or conditionals. It’s all just function (or macro) composition.
Thanks to Clojure, every time I dabble in a different language — even objectively nice ones — it just feels dirty by comparison.
I have roughly 15 years of C# experience under my belt. My day-job is currently a Rails stack. One thing that Rails (and C# and most OOP stacks) encourages is data-hiding. What do you get back from “insert fanci API call here”? Some object. What is its shape? Who knows? What data is accessible to you? Have fun wading through layers of inheritance, public, private, protected methods and accessors, etc. Why is that bit of data you want hidden behind a private method? ARGH!
Clojure on the other hand is an exhibitionist. It lays everything out for the world to see. And this is a good thing. What do you get back from “insert fanci API call here”? A map, list, set, or vector. Almost guaranteed. What’s the shape of the data look like? It’s simple combination of basic primitives, prints nicely to the REPL, and can be accessed and manipulated using a clean, small set of common, well-understood functions.
Data-oriented programming is probably the thing I like best about ClojureScript. It may not sound like a game-changer, but it is.
Incidentally, I think that the data-oriented design is somewhat incompatible with static typing. It’s hard to statically analyze the shape of a list of maps. I suppose it could be done, but I suspect it would negate some (or most) of the compositional strengths that are gained by Clojure’s dynamic system. If I have to choose between data-oriented programming and static typing, I’ll choose data-oriented.
This pairs really well with the previous point and maybe vies for the “thing I like most” category. In Clojure, you almost never mutate data. You just transform it. This makes Clojure code much more predictable than typical mutate-all-the-things Ruby/JavaScript code.
Here’s an illustrative anecdote. I recently found a bug in our payment processing logic at work. It was caused by the fact that the Stripe JavaScript library mutates the objects you pass to it. Stripe was literally deleting properties from my object and adding new ones. Thanks a lot, Stripe!*
*For the record, I love Stripe. Moving on.
In Clojure, mutation of state is well controlled and well understood. Again, this is a game-changer.
Lots has been written about functional programming, so I won’t gush on about it here. It’s not the end-all-be-all, but in general, I find that codebases composed of small, simple functions are easier to read, maintain, and reason about than codebases composed of class hierarchies, inheritance chains, etc.
A good REPL is also hard to beat, and Clojure’s got em.
ClojureScript’s dynamic nature makes JavaScript interop a good deal easier than statically typed alternatives.
ClojureScript seems to have the most battle-tested front-end libraries of any of the alternative functional JavaScript stacks.
Clojure’s community is vibrant, helpful, and welcoming (check them out on Slack and Reddit).
Want more reasons to check ClojureScript out? I’ll pass you along to Derek Slager:
Still skeptical? Take a look…
It should be obvious that I like Clojure and ClojureScript. But I’d be lying if I said everything was rosy. Here are some drawbacks and mitigations I’ve found.
And it requires the JVM (which is arguably worse than the slow boot, in my book). Self-hosted ClojureScript, eliminates both of these issues, but it’s still a little ways away from maturity.
Check out planck or lumo for fast-booting ClojureScript REPLs.
If you’re not a Java guy (I’m not), then you’ll probably poop yourself a little the first time you see a Java stack trace. Here are some handy tips to get to the bottom of things when that inevitably crops up:
- http://eli.thegreenplace.net/2017/notes-on-debugging-clojure-code/- https://aphyr.com/posts/319-clojure-from-the-ground-up-debugging
Well, it’s built on JavaScript and/or the JVM, so nulls are a part of life, but it would be nice if they weren’t.
Do you like documentation? Yeah. Me, too. Clojure’s got some great docs. But it’s also got a lot of poor or non-existant docs. (Can you have a lot of non-existant docs? Dunno. English is my first language, but I no can speek good…)
That said, I haven’t generally found this to be too big of a problem. I can generally find my way through whatever is blocking me. Code is generally fairly easy to look at and reason about. And if I really need a hand, the folks on Reddit and Slack are superfly.
Static typing. I don’t really miss it. I wish Clojure could sprinkle it in, but it’s not really as big a deal as I expected. I suspect Clojure.spec will help here as my apps get more complex.
There’s no great debugger, but I have (thus far) found functional programming + a good REPL is better than mutable imperative/OO programming + debugger.
Parenthesis. Yeah. Everyone whines about em. You know what? With a good editor, you don’t really think about or notice them. And the regularity of the syntax is more than worth it.
If you’re interested (and you should be), head over here to get your feet wet:
- https://learnxinyminutes.com/docs/clojure/- http://www.braveclojure.com/
If nothing else, Clojure/ClojureScript is worth a look, simply for the experience of it. If you haven’t already, I encourage you to check it out. Work through the initial pain points. It’ll pay off.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!