Learning Clojure is like going from driving a car on the right side of the road, to driving a car on the left side of the road.
If you can't figure it out in under a month, you're either a hopeless driver, or just didn't really care to try to adapt to the slightly unfamiliar.
I've evangelized Clojure at my work. I've seen many people having to learn and try it given different context.
There's people who end up loving it just as much as me, and people who end up hating it. In all cases, the lovers were willing to break their habits and figure out how to adapt to Clojure's syntax and paradigms. They were eager and happy to learn something different. The haters were not, they felt compelled and forced to drive on a side of the road they weren't comfortable with, it scared them, caused them additional stress, and clearly they didn't care to be here, like they were dragged along a vacation to a place they had no interest for, and would have really just wanted to stay home instead, where things are easy and familiar.
The interesting part though, neither groups were slowed down, or failed to deliver their tasks and stories, because of Clojure. The overhead of having to learn Clojure is minimal. Its just that it's not painless, it's uncomfortable, and you need to think harder then you're used too, that's all.
So even though both groups end up successfully using Clojure professionally to deliver on tasks and stories. The ones who just never wanted to be there in the first place don't want to keep at it, they associated stress and difficulty with it. While the ones who enjoyed learning and being challenged want to use it everywhere and can't go back to Java.
I've learned that, if you give a lot of initial support to the people who aren't open to being put out of their comfort zone, especially help them setup a friendly IDE, show them how to use the REPL first and foremost, make sure they do use it, if they don't, remind them to use it, show them again how, address why they aren't, and help guide them a little through their first month, then you can push them over to the group that loves Clojure, or at least a neutral place.
I say neutral, because generally the latter group tends to have less passion about programming in general. This is a career for them, not a hobby. They may never fall in love with any language, there's just the one they're familiar and comfortable with, and the ones they're not.
Now, some positives to adopting Clojure is that if you are in a medium to large org, the passionate, curious to learn new things, programmers on other teams will be easy target to recruit to yours.
Initially, our manager was worried it would hurt our ability to find talent, but it has actually become our biggest selling point, allowing us to attract really motivated, passionate, curious and knowledgeable devs from other teams to move to ours, because they wanted the opportunity to learn and use Clojure.
Now, I've seen people in the latter group adopt Scala or Kotlin afterwards, this is because while Europe might be too far out your comfort zone, a trip down to Disneyland or Las Vegas where things are mostly the same, and you still feel safe and at home, while only being a little out left might still be enjoyable to them.
Also, languages like Scala and Kotlin can be treated like new versions of Java to some extent. It does make some of the more annoying parts of Java easier. So they're more like having bought a brand new car in a different category, like going to an SUV after a Sedan.
My observation on that is that for a very long time they do not learn about and use the more different parts of Kotlin and Scala, but because of how linear and smooth that curve can be, eventually they end up learning. So again, the learning was made easier and safer by just being amortized over a really long period of time, 6 months to 2 years.
So I've observed that people who go through 1 month of Clojure learn as much new paradigms as 6 months of Scala and Kotlin.
Not everyone is willing to push themselves hard from the start. Those that are, will pick up Clojure in no time and love it. Those that aren't will hate it, even though they managed to use it without issue. For those, you need to offer them really good coaching and support, to ease their pain. Or, you're better off with a FP language that has a more gradual curve like Kotlin or Scala or even Java 8 FP features.
Thanks for sharing these thoughts — would you mind sharing some details about the IDE/REPL setup you set folks up with? My hesitancy to evangelizing clojure at work as always been around a fear of also needing to get folks up and running with emacs, or something of the sort. I've found that a lot of folks are excited to give clojure a try, but hesitant to move away form more..."robust?," "user friendly?" IDEs, like VS Code, Sublime, and Eclipse.
ReplyDeleteWhen I arrived to the company things were quite chaotic, out of a team of 9 developers we used atom, vscode, intellij, and emacs, I tried all of them.
Delete1. Emacs was nice but requires endless configuration, and the learning curve really hinders productivity.
2. Atom and VScode repl support is limited, and the language plugins usually miss proper "IDE" features like "find definition" and the likes.
3. Intellij/Cursive is the one I currently use but it's extremely heavy, and working with more than 1 intellij open simultaneously really staggers the system.
So I'm currently choosing the less of 4 evils. I will give Atom the credit of having a really good parinfer implementation.
This is another thing, to use clojure you need to really be into messing around with things that are not "in the language" like learning paredit shortcuts, or the difference between paredit and parinfer, repl loading, and repl paradigms, etc.
I assume that if you could "simply" open atom/vscode/sublime/etc. install the first plugin and write code like you would with python/javascript/ruby/java there would be less push-back.
If they're already a VIM or Emacs user, I show them Fireplace VIM, CIDER and sometimes I'll show SpaceMacs with CIDER to a VIM user.
DeleteOtherwise, I go with Eclipse CounterClockWise. Though I'm going to need to find something else now, since its no longer maintained, and it seems it'll never be getting Java 9 support. Since it does not work with anything newer than Eclipse Mars. That will probably be Cursive, though that's paid, so it requires company approval for every license.
It's kind of unfortunate that half the community is just comfortable with Emacs, since that's another non familiar editor, and Clojure is already unfamiliar as it is.
I don't really understand why you act as if doing the hard choice is the right one.
ReplyDeleteThere are many disadvantages to Clojure even in comparison to Java.
Clojure's tooling system is in quite a horrible state compared to other languages which means many tasks that might be simple in full blown Visual-Studio / IntelliJ, are excessively hard in Clojure.
Disliking Clojure is not a bad programming feat, like you make it sound.
Hey, thanks for the perspective.
DeleteI obviously love Clojure, but I also am not a hater of Java, Kotlin, Scala, et all. There are aspects to all three that I like as well.
Many people didn't like Clojure after trying it at work, and I only reflect on why that was, and what was common in their personality. What I've found was generally that they were simply less willing to spend the effort becoming familiar with new paradigms and yet another language. Not because they're bad programmers, but simply because it's not something they are passionate about, that is, learning about new and different programming languages, syntax and paradigms.
What I also observed is that the people who did not like it, found it hard, or felt less productive, were not actually less productive, and their Clojure code was not of lower quality. Thus it means that learning Clojure did not add overhead, even when it was felt as hard. Imagine lifting weights, you do 3 reps of 10. If you take a light weight, it will be easy, and if you pick a heavier weight, it will be harder, but both will take you the same amount of time to complete. Now when I started, I didn't know that Clojure would fit this model, it could be that it is more like learning to drive manual when only ever having drove automatic. In which case, there's an amount of time where you can't get anything done until you reach a certain level of proficiency. Fortunately, this was not the case in my observations.
Could tooling for Clojure improve? Absolutely! The compiler could be smarter, the errors could be clearer, the IDEs could be friendlier, more diverse, they could support more refactoring, better completion, etc. But in my experience, at my work, that would only help make Clojure easier, not more productive. And that is hugely important, because if you're going to move a team from Java to Clojure, you don't want it to affect the business deliveries. It shouldn't slow down the team, otherwise it would be a deal breaker.