How to introduce Coworkers to Functional (and Clojure) way of thinking?

[tiku]

Hello,
I am working in a small developer team with 6 members, who have more of a OO background. Since I started my clojure journey I adopted some of those “clojure” ideas as well as functional ideas:

• Thinking in terms of data and data transformations
• Passing around functions
• Dislike of mutable datastructures
• Preference of maps over classes
• and other things which I have now in my subconscious from reading a lot about clojures ideas

Since then, my thinking clashes with the way my coworkers think. I was wondering if you have comparable experiences and how you have dealt with them.

I have ideas about maybe giving a workshop for my team, but I am a bit worried, that challanging the way they are thinking may lead to defensive behavior. Your views and experiences on this issue are much appreciated

(I am currently working with Java and Javascript and I am searching for ways to use clojure profesionally)

[slifin]

This is a hard problem, when I started functional programming a lot of co-workers couldn’t wrap their head around higher-order functions and the indirection they were causing, recently I’ve figured out most cases of higher-order functions can be achieved by writing functions that just call out to the other functions, or if your data has the characteristics of a semigroup you can use variadic functions

I suspect most programmers OO or not dislike mutation but not so much so that they’re willing to give up classes, in which case you can use classes but use static methods for nearly everything since this is in their “framework” they likely won’t see this as a transgression

I think the mindset from your point of view should be, now I know what’s bad about OO, continue doing OO but actively avoid areas you know will cause issues, inheritance, state, weak encapsulation etc, data and types are probably going to be the hardest things to cloak, in PHP, for example, it’s easy to continue using arrays for data instead of a type for everything because of its legacy, not sure if you can get away with that in Java, obviously, you want the type as wide as possible i.e. object or array instead of MyPersonClass, language constructs as types like int, string etc tend not to be so bad

Aim to be the best OO programmer on that team, since good OO is essentially FP anyway

The other thing to keep in mind is that this won’t change their mind, in fact, the harder you push for FP the more it won’t change their mind, a workshop is nice but it shouldn’t be an arena for you to prove your point, it should be, here’s a cool thing in a different language, it should encourage them to go on their own journey for different reasons

For your own benefit, Uncle Bob does a good talk on what OO does and doesn’t do

"Uncle" Bob Martin

Ultimately it would be better to move out of the team into a team that is already in your headspace, but in my experience, Clojure employers are extremely picky & onboarding likely harder than in most languages

[jdhollis]

One thing I’ve found helpful is comparing and contrasting something the developers are already doing in their language of choice versus how it would be done in Clojure. It can be helpful to actually illustrate it step-wise: original solution, original solution translated to Clojure (non-idiomatically, so it looks closer to the original solution), and then idiomatic Clojure. Then you can use that illustration to discuss the higher level concepts.

You have to show the value. The compression and power are compelling once a developer sees it, but you have to meet them where they are. How will Clojure make their jobs better, faster, easier?

I’ve had an easier time converting backend developers, though it’s harder with people that love static typing—be prepared to take those developers through spec early on.

Introduce potential Clojure developers to REPL-driven development as soon as possible—a lot of the value in Clojure (and Lisp, generally) is interactive development. If possible, stick to the editor they already know, and pair up.

Starting with one-to-ones can be more successful early on than a workshop. Ideally, you want your initial converts leading a workshop instead of you—it provides more social proof.

I’ve also had great success in getting front-end developers to try ClojureScript by showing them the original Figwheel demo. React developers in particular naturally get the functional aspects of Clojure since most of them are already doing functional programming without really thinking about it. And when you show them how little code it takes to do the same things they’re already doing (say, with a framework like re-frame), they’ll be sold. For bonus points, show them devcards—they solve a lot of QA problems, particularly for agency developers. But be prepared with project boilerplate to get them up and running in ClojureScript as quickly as possible—the tooling has improved a lot over the years, but it’s still non-trivial to set up for a new developer.

[maxweber]

This is how I solved it:

I started my own company

We are using Clojure(Script) and Datomic to build Software-as-a-Service offerings.

In my experience it is very difficult to convince coworkers in the setting you have described. Even if you manage to convince a few, they have to be willing to invest a significant amount of their free time to learn all the Clojure stuff.

If you do not want to go all in with an own company, an alternative would be to became a freelancer or at least a remote worker. Since a few years there are many great remote jobs, where you can use Clojure.

[Richard_Heller]

@maxweber

I started my own company

That’s really your best option. If that’s not going to happen, the best advice I’d give is to not hold your breath waiting for people to get on board with Clojure.

People don’t like to hear it, but there’s nothing inherently superior about Clojure. The preferences are personal preferences that you’ll find aren’t shared by the majority of developers. There’s a lot I like about Clojure and Clojurescript, but just the fact that they’re Lisps is enough to get a hard “no” from people.

The easiest transfer would be from Javascript. All the ideas you listed also exist in JS. The feel of programming in JS and Clojure, to me, is about the same. The difference being that Clojure is more verbose, at least with the real work part of the code. The parenthesis won’t be as big of an issue coming from JS because it’ll just look like a bunch of IIFEs.

So, I think the advice others have given is sound. Try to show people what you like about the language, walk them through why you like it. If any non-critical projects come up, some internal automation stuff or whatnot, write it in Clojure to show people what the language can do. Just be prepared for very few of them to get excited about it.

As far as my comparable experience, I also drank the FP kool-aid and went anti-OOP for about 5 years. In that time, I hit all the same problems I had with OOP when doing FP. That’s when I realized they’re really two views of the same thing and I started using whichever one better fit the problem I was trying to solve. In other words, my thinking also clashed with my coworkers until I realized it didn’t clash as much as I thought and I got over it.

[jgomo3]

A coworker did 2 things to convince me:

1. He recommended me to read “Out of the tar pit”.
2. He used Clojure in a small prototype.

[didibus]

You could try first starting to talk about it as something that has interesting ideas. Just to plant the idea in people’s head. And then don’t wait for anyone to be convinced fully. Just start using it yourself on some new task that isn’t too critical. Since you have some Java, it’s easy enough to mix in some Clojure with it.

[simongray]

While still in uni, I was the headstrong OOP-fan in my first programming job in a startup. Some of the others - who were much better developers than me - had started making stuff in Erlang. While working there, I tried some of the new functional stuff in (then brand new) Java 8 and also used some of the functional parts of Python, but I really didn’t get the appeal of functional programming. Not that I actively tried to educate myself about it.

At the same time I was also convinced that OOP design patterns were mostly bullshit. I even took a class in design patterns and object-oriented design at university, got top marks, and all that did was convince me that design patterns were a ruse. So you could say I was conflicted.

I eventually ended up learning Clojure, but I would probably have sought it out sooner if someone had shown me Mishadoff’s Clojure Design Patterns.

[bsless]

You can start a book club and go over SICP with your colleagues. It’s fun.