Advice on introducing a Java dev to Clojure

[Johanna Belanger]

Hi :)

I've recently broached the subject of Clojure with another dev in my organization, and his response was basically "What's Clojure"? and I'm not sure how to answer that in a way that might inspire him. "It's a dynamically-typed functional Lisp with persistent immutable data structures that runs on the JVM" doesn't seem like it will grab his interest. =)

I work primarily in .NET, and he does enterprise Java. I don't know him well enough to know how happy he is with it. He did express interest in learning .Net.

 I came to an appreciation of Clojure through 

-CQRS (the power of decomplection!)

-Sussman and Abelson's SICP class at MIT online (the power of homoiconicity and functions!)

-the death of Silverlight (alternatives to Javascript in the browser?)

By the time I found Rich Hickey's talks (eg Simple Made Easy) I was pretty well primed to love Clojure. I've been using it for little personal projects and prototyping for a couple of years, but I haven't put it in production because no one else here knows it.

Could anyone tell me how they got from enterprise Java to Clojure?

Thanks very much,

Johanna

[Ralf Schmitt]

Johanna Belanger <johanna....@gmail.com> writes:

> Could anyone tell me how they got from enterprise Java to Clojure?

Maybe the following links provide some useful information:

http://blog.juxt.pro/posts/selling-clojure.html
http://www.pitheringabout.com/?p=693
http://www.lispcast.com/convince-your-boss-to-use-clojure

--
Cheers
Ralf

[Johanna Belanger]

Thank you, Ralf!

[Colin Yates]

It's tricky, but I would ask them what pain points they experience with the Java stack and go from there. I find the biggest barrier is the "yeah, what I've got works fine"/complacency attitude. If they are perfectly happy where they are then great, lesve them to it and go be 10 times more productive ;).

I found clojure a breath of fresh air because it addressed pain I was feeling. There was a cost, of course; everything is a compromise, but my point is to truly "get" Clojure it has to offer you something you consider valuable.

I will say for me, coming from a very deep entrenchment in Spring, Hibernate etc that the biggest struggle I had was undoing years of learning Java EE and all the support that brought with it. The idea of having to think first? Shocker :). I often like to say that the design  pattern I use the most now is "Hammock time" :).

There are two bookd you might want to give them, Functional Programing for OO by Brian Marick and another one I can't remember the title of but something like Functional Programming in Clojure and Scala. They might both help provide an on-ramp.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sean Corfield]

On Jul 9, 2015, at 5:22 PM, Colin Yates <colin...@gmail.com> wrote:
> There are two bookd you might want to give them, Functional Programing for OO by Brian Marick and another one I can't remember the title of but something like Functional Programming in Clojure and Scala. They might both help provide an on-ramp.

https://pragprog.com/book/mbfpp/functional-programming-patterns-in-scala-and-clojure — Highly recommended!

Sean

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Johanna Belanger]

Thanks, Colin. That's really helpful. He seems very competent in the Java EE stack, too. In .Net, nothing ever stays the same long enough for me to get that comfortable. =\

One good thing is I don't actually need him to switch to Clojure, just to learn it well enough that he can understand my code in case of emergency. Because I'm feeling pain, and I need to be 10 times more productive. =)

[Johanna Belanger]

Thanks Sean =)

[Raoul Duke]

> and I need to be 10 times more productive. =)

you mean, after your 2 week ramp-up time, right?

[Johanna Belanger]

Lol, that's an interesting reply. I'm suspecting it's a warning. Care to expand?

[Johanna Belanger]

I should say, because I'm worried this came across wrong, that I don't expect him, or anyone, to learn Clojure for my sake, but only if they find value in it. That's why I'm looking for a simple way to showcase the value.

[Sean Corfield]

On Jul 9, 2015, at 7:58 PM, Johanna Belanger <johanna....@gmail.com> wrote:
> I should say, because I'm worried this came across wrong, that I don't expect him, or anyone, to learn Clojure for my sake, but only if they find value in it. That's why I'm looking for a simple way to showcase the value.

One caution I will provide here is that Clojure is a radically different way of programming / thinking for an "Enterprise Java" developer. I touch on that here:

http://seancorfield.github.io/blog/2014/09/23/clojure-in-the-enterprise/

(referenced in the LispCast article that Ralf linked to earlier)

[Michael McLellan]

That brings up an interesting point - what's the ramp-up time usually like for the Java devs that convert to Clojure?

[Johanna Belanger]

That's a good read, Sean. 

I'm a dedicated departmental programmer, and to be effective in my position, I need to be quick and nimble. For some of the problems I'm solving, my tools are causing an unsupportable amount of drag. Clojure would be a brilliant match. But because I'm a one-person team, the truck number makes it so risky to choose an unconventional technology.

Sharing Clojure with other developers is an attempt to balance those forces. I hesitated for a long time, but I finally decided it didn't hurt to try.

At this point, I'm not thinking of using Clojure for all of my coding, but only a few particular cases.

Thoughts?

[Erik Assum]

If you're a one-person team, don't be too worried. Your Clojure code will likely not be too big, so it will be fairly easy to understand and possibly rewrite to Java, if the truck thing was to happen. 

Erik. 

-- 

i farta

[Johanna Belanger]

Interesting opinion, I'll think that over. Thank you! 

[Johanna Belanger]

I ended up giving him a brief description of Clojure, with stress on its ability to do heavy lifting with very little code, and sent him a link to Neal Ford's talk "The Curious Clojurist". We'll see what happens. Thanks everyone for your advice.

[Juvenn Woo]

Hi Johanna,

I don’t know if it'll work for your team, but I find Shaun Le Bron's "Interactive guide to Tetris in ClojureScript” the most succinct and beautiful way of showing power of Clojure and ClojureScript.

https://github.com/shaunlebron/t3tr0s-slides

Have fun!

-- 

Juvenn Woo

Sent with Sparrow

[Juvenn Woo]

Hi Johanna,

I don’t know if it'll work for your team, but I find Shaun Le Bron's "Interactive guide to Tetris in ClojureScript” the most succinct and beautiful way of showing power of Clojure and ClojureScript.

https://github.com/shaunlebron/t3tr0s-slides

Have fun!

-- 

Juvenn Woo

Sent with Sparrow

On Saturday, 11 July, 2015 at 1:24 pm, Johanna Belanger wrote:

[Johanna Belanger]

That's really cool, thanks!

[Matt Bailey]

Johanna,

I noticed you mentioned CQRS. In my work, we use CQRS heavily, specifically the Axon framework for Java (utilizing Spring and Hibernate). I got into Clojure through watching Rich Hickey's talks and figured that any language that he wrote had to be good.

It's remarkable to me how cleanly the concepts applied in CQRS map to concepts in Clojure. The funny thing is that CQRS would never be necessary if it wasn't for languages like C# and Java.

It can be discouraging to see people's eyes glaze over when you talk about code as a series of transformations on the input. Many people limit their understanding of code to a very procedural style with ifs, elses and "helper methods" that have side effects.

Sorry I don't have any words of wisdom on how to evangelize Clojure, but I am glad to see someone else noted the parallels between CQRS and a more functional style of programming.

Cheers!

-Matt

[Colin Yates]

My latest project uses a CQRS and event sourcing design and the power it gives, coupled with Clojure is just fantastic. Hydrating an object becomes (merge {} (event-store/load ar-id)) - just fantastic.

I too find a lot of sympathy between CQRS, event sourcing, FRP and Clojure which I keep meaning to blog about, but my todo list is a mile long. Still, highly recommend that architecture. Lots of downsides; everything is a trade off, but conceptually, yeah, it gets a lot right.

[Colin Yates]

I do of course mean (reduce merge {} (event-store/load ar-id)) or (apply merge (event-store/load ar-id)) :)

[Johanna Belanger]

Matt,

Nice to hear you noticed it too! I saw a presentation once (wish I could remember where) about design patterns that are 100% unnecessary in Clojure. That definitely had an effect on my thinking. So much boilerplate...

Thanks for your thoughts,

Johanna

[Johanna Belanger]

I am always eager to hear anything and everything about your experience with this. Especially downsides. =) 

I haven't done ES yet. My hydration code is definitely not that lovely. What do you think about ES vs Datomic? (Probably not the right thread for that question, huh?)

[Colin Yates]

Hi Johanna, you may intuit some of my experience by my posts on the DDD groups ;-).

By far the hardest thing I found was applying DDD, identifying bounded contexts etc. However, from a technical point of view the thing that most stood out to me was the power of recording the decision, and effect of every single decision as an event. All mutation is captured in the event log. My ‘aggregate roots’ tend to be a namespace with a multi-method of ‘react-to’ which takes in a command and emits a bunch of events. Those events tend to be trivially mapped to state transitions of the aggregate root. Hydrating the aggregate root then becomes (let [events (event-store/load-for aggregate-id) ar (apply merge events)…]). 

The strict separation of domain logic/model from the views (and supporting infrastructure) is a significant win; every screen has a server side view with a server side de-normalised store (yeah, OK, a table ;-)). In our domain there are a bunch of different ‘modules’ (I won’t call them BCs!). However, some of our views map across those modules. Imagine I am looking at my current order, I also want to see when it is dispatched from the warehouse or if there is a cheaper deal etc. I also found that many of our existing applications were making key business decisions at the time of querying; what is the sort order for these things, how many things are out of stock etc. It was shocking how many decisions weren’t explicitly in the code/codified in SQL (as a team we are all culpable, but this was written before I got here - ha!). 

Putting it succinctly, I found there are many-to-many relationships between modules and views. Modelling this in a ‘traditional’ way would have been a great big ball of mud where one piece of code was concerned with far too many things; there is a significant disconnect between the use cases and the views.

From a maintenance point of view - fantastic. ‘How did this get to be this’ is by far the most necessary question our support teams need to answer, now the answer is trivia - all (actually almost all) mutation is done via events - look in the event log. If a view changes then we can simply delete the view and replay all of the events to build the new view. 

The Clojure tooling needed for this is remarkably small and the conceptual fit is fantastic; immutability - check (event log); data everywhere - yep, events flow through the system; decomplecting everywhere and always - yep, aggregate roots are ignorant of everything apart from their splice of business logic, views are ignorant of everything apart from the screen they support; functional concerns - yep, aggregate roots and views are just reductions of the event log

Pain points:

 - it is really tempting to share common views/normalise the DB. Do I really de-duplicate the patient name everywhere or have a t_patient table?

 - having an event store as the SOR changes everything, everywhere, for everyone. Messes with your mind

 - DDD is a discipline, not something you can read a book about and do. It is a specialist non-technical skill - getting it wrong can lead to more mess and heartache than the big balls of mud we are at least familiar with 

 - not much prior art, at least not much published art. Very few general answers; ‘it depends’ is the rote answer

 - DDD and event sourcing and CQRS are very different (complementary but different) beasts - tackling all three caused a lot of pain because there is no familiarity anywhere

 - performance can suffer, it can also be significantly improved, but my intuition was worth nothing due to the change of paradigms

 - making decisions when querying actually provides a lot of grace - fix the bug, deploy and the problem goes away. When you have an event log and every decision is explicitly captured you lose that grace. You can add compensating events or (although frowned upon) go through and mutate your events (yeah, I said it was frowned upon). That event log can become a chain around your feet. 

 - nobody is going to have a clue what you are talking about until you can educate them

Plus points:

 - the words best and most accurate audit log

 - separation and the fine granularity of models makes parallel development and maintenance significantly simpler

 - view models are transient, throw them on different servers to scale - fine

 - exposes many many key business decisions which weren’t handled explicitly

 - concepts are a natural fit for the functional world

 - I am a better developer, engineer and domain expert because of the rigour required

 - very little infrastructure required to achieve this

 - you can view the world as a sequential set of mutations to smaller and more focused state machines

 - a clear separation of read and write means your write can be more expensive to make your reads more efficient (given that most systems read _far_ more than they write)

 - being able to restore your system to any moment in time is just fantastic. Opens the door to simulations, replaying history, diagnostics etc.

 - it tickles your ‘geek’ spot (you know, the one tickled by using Linux instead of Windows, or tiling instead of floating, or being able to use grep, awk and sed together with regular expressions without having to open a book or google)

I haven’t had much experience with Datomic, but I think the event log and Datomic both treat time as an explicit concern and neither are simply plugin replacements for ‘a database’.

That’s probably enough; I would love to do this properly in a blog post/github demo project but I just don’t have the time :(, but I’m happy to respond to questions/upgrades/advice etc.

Thanks,

Colin

[Colin Yates]

One other point I should have expanded more. Viewing your domain model as a state machine responding to a sequential list of commands allows you to easily isolate time as just another property. I have a [:set-time {:now ….}] which emits a [:time-set {:now …}] which opens the door to so many things. Of course, you can’t ever to a (Date.) anywhere instead you need to check the denormalised time store, but ok. A lot of our domain is about reacting to things over time so now I can start the domain without time changing then issue a [:set-time…] and then inspect the domain and so on. Very very powerful.

On 15 Jul 2015, at 22:14, Johanna Belanger <johanna....@gmail.com> wrote:

[Johanna Belanger]

Thanks so much for this really nice rundown. A few responses inline...

On Thursday, July 16, 2015 at 3:23:17 AM UTC-7, Colin Yates wrote:

Hi Johanna, you may intuit some of my experience by my posts on the DDD groups ;-).

 

 I've read them all. =)

By far the hardest thing I found was applying DDD, identifying bounded contexts etc. However, from a technical point of view the thing that most stood out to me was the power of recording the decision, and effect of every single decision as an event. All mutation is captured in the event log. My ‘aggregate roots’ tend to be a namespace with a multi-method of ‘react-to’ which takes in a command and emits a bunch of events. Those events tend to be trivially mapped to state transitions of the aggregate root. Hydrating the aggregate root then becomes (let [events (event-store/load-for aggregate-id) ar (apply merge events)…]). 

The strict separation of domain logic/model from the views (and supporting infrastructure) is a significant win; every screen has a server side view with a server side de-normalised store (yeah, OK, a table ;-)). In our domain there are a bunch of different ‘modules’ (I won’t call them BCs!). However, some of our views map across those modules. Imagine I am looking at my current order, I also want to see when it is dispatched from the warehouse or if there is a cheaper deal etc. I also found that many of our existing applications were making key business decisions at the time of querying; what is the sort order for these things, how many things are out of stock etc. It was shocking how many decisions weren’t explicitly in the code/codified in SQL (as a team we are all culpable, but this was written before I got here - ha!). 

 

Right. I've gotten a huge amount of value out of this. In my domain, only a small amount of the write side complexity is modeled in the software. The rest is in the users' heads and they don't want that automated at this time, lol. Everything after that point is called "reporting", but actually contains a ton of business logic around constructing, disseminating and acting on those "reports" and correlating the timing of those things. Making all that logic explicit has been a huge win.

Putting it succinctly, I found there are many-to-many relationships between modules and views. Modelling this in a ‘traditional’ way would have been a great big ball of mud where one piece of code was concerned with far too many things; there is a significant disconnect between the use cases and the views.

From a maintenance point of view - fantastic. ‘How did this get to be this’ is by far the most necessary question our support teams need to answer, now the answer is trivia - all (actually almost all) mutation is done via events - look in the event log. If a view changes then we can simply delete the view and replay all of the events to build the new view. 

The Clojure tooling needed for this is remarkably small and the conceptual fit is fantastic; immutability - check (event log); data everywhere - yep, events flow through the system; decomplecting everywhere and always - yep, aggregate roots are ignorant of everything apart from their splice of business logic, views are ignorant of everything apart from the screen they support; functional concerns - yep, aggregate roots and views are just reductions of the event log

  

This is great to hear, and when you get time to do your blog post it will be a nice thing to share with the CQRS community. Build a little love for Clojure. =) 

Pain points:

 - it is really tempting to share common views/normalise the DB. Do I really de-duplicate the patient name everywhere or have a t_patient table?

 - having an event store as the SOR changes everything, everywhere, for everyone. Messes with your mind

=)

 

 - DDD is a discipline, not something you can read a book about and do. It is a specialist non-technical skill - getting it wrong can lead to more mess and heartache than the big balls of mud we are at least familiar with

 

Would love someday to hear any stories you can share. 

 

 - not much prior art, at least not much published art. Very few general answers; ‘it depends’ is the rote answer

 

Yep 

 - DDD and event sourcing and CQRS are very different (complementary but different) beasts - tackling all three caused a lot of pain because there is no familiarity anywhere

 

Yes yes yes. I tried that on a personal project with a deadline. It failed. =/ I was already practiced with DDD, too, but the other 2 were new.

 - performance can suffer, it can also be significantly improved, but my intuition was worth nothing due to the change of paradigms

 - making decisions when querying actually provides a lot of grace - fix the bug, deploy and the problem goes away. When you have an event log and every decision is explicitly captured you lose that grace. You can add compensating events or (although frowned upon) go through and mutate your events (yeah, I said it was frowned upon). That event log can become a chain around your feet. 

 

But on the flip side of that, all consequences of bugs are explicitly recorded. 

 - nobody is going to have a clue what you are talking about until you can educate them

Plus points:

 - the words best and most accurate audit log

 - separation and the fine granularity of models makes parallel development and maintenance significantly simpler

 

And really reduces the amount of complexity to deal with at any one time 

 - view models are transient, throw them on different servers to scale - fine

 - exposes many many key business decisions which weren’t handled explicitly

 - concepts are a natural fit for the functional world

 - I am a better developer, engineer and domain expert because of the rigour required  

 - very little infrastructure required to achieve this

 - you can view the world as a sequential set of mutations to smaller and more focused state machines

 - a clear separation of read and write means your write can be more expensive to make your reads more efficient (given that most systems read _far_ more than they write)

 - being able to restore your system to any moment in time is just fantastic. Opens the door to simulations, replaying history, diagnostics etc.

 - it tickles your ‘geek’ spot (you know, the one tickled by using Linux instead of Windows, or tiling instead of floating, or being able to use grep, awk and sed together with regular expressions without having to open a book or google)

The power! 

I haven’t had much experience with Datomic, but I think the event log and Datomic both treat time as an explicit concern and neither are simply plugin replacements for ‘a database’.

Me neither. My one thought on this is that with Datomic the event schema could be more flexible. The event name is just a tag on the transaction.

[Leon Grapenthin]

I have tried various different approaches from convincing of Clojure advantages in the Java devs concrete domain, showing off incredibly awesome toy projects, larger projects, not tryng to sell, trying to sell, sending ClojureTV videos and what not approach you can think of. I have not managed to introduce one Java dev to Clojure in a way that he picked it up and had no interest before. I have spent many hours thinking about how I could improve my "evangelizing" skills. And today I believe that what you can do is very little and your approach does not affect the outcome a lot. There is enough motivating and introductional content about Clojure on the web. If someone isn't motivated by all this and your initial impulse, he is simply not able to upgrade. It might be a lack of time, a lack of interest in programming altogether aka silent burnout, the fear of having to learn new things, the fear of forgetting old things, the fear of not wanting to leave a comfort zone, the fear of not being able to autocompleteprogram or the fact that someone is simply happy with clicking classes together and writing a new group by implementation every few days and being paid for it very well and many other reasons. 

In many cases an existing comfort zone is an obstacle that you can't change. Almost nobody leaves his comfort zone only because you told him about something else outside of it, even if its gold and he believes you. OTOH people who leave their comfort zone on purpose every now and then do it because they are intrinsically motivated to do so. If they are out of ideas where to go, they will ask you for one and then "selling" Clojure is about as easy as mentioning between one and three interesting facts about it. They will be watching Rich Hickey talks in a minute.

Unless a programmer is adventureous and likes to try out new languages or has decided that he "wants to learn something new", there is little you can do. In the other case there is little that you have to do.

Personally I have simply decided not to waste time on trying to convince programmers to learn Clojure, instead I try to help those who are. 

OTOH spending time on improving evangelizing and elevator pitching is still well spent if you want to convince managers. I find Rich Hickeys rationale on the Clojure page is a great starting point and there is also a great talk by Paul deGrandis (Clojure minimizes risk).

[Leon Grapenthin]

[Johanna Belanger]

Leon,

That sounds like hard-won experience, thank you for sharing it. I couldn't find a Paul DeGrandis talk with that name, would you happen to have a link? Is it "Clojure-Powered Startups" perhaps?

Thanks,

Johanna

[Jorge Branco]

I did read some of the answers on this topic but not all of them. From those I read, I feel they may not really be answering to the crux of the question: do the people you want to convince to use clojure actually care?

Most software developers do software development for a living, and they couldn't care less about what other technologies are there. They want to work from 9 to 5 and get paid, and for all that matters that's it. They probably learned all they know because there was some kind of internal mentoring or training course at work, otherwise they'd just know what was taught to them in university.

I don't see a big point in trying to sell clojure (or any other functional language for that matter) to the typical "enterprise" software developer. If it doesn't have beans and doesn't run on some sort of a container it will just be outside of his comfort zone. Most people wouldn't see an advantage in knowing design patterns or to attempting to improve their code-base with ioc. They don't recognize there is a problem. And you can be sure that if it's 2015 and they know about it, it's either because they had to memorize some stuff about it in some oracle course or because they know someone will ask about those topics down the road -- in an interview, for instance.

Bottom line: if it's 2015 and they "don't know" or "never heard" about clojure you can be damn sure they don't want to know about clojure. They don't know clojure because they just don't read blogs, don't read magazines and generally don't take any attention to what's out there -- they are uninterested.

[Paul deGrandis]

I have had success here with a few approaches.

For every company I work with that is new to Clojure, I provide them with a "Quick Learn" document.  The document is split into 5-7 days, and every day they skim/read an article, poke around a resource (like ClojureDocs), and watch a talk.  Sometimes that "resource" item is an exercise or something interactive.

Your goal should never be to convince someone of Clojure - Clojure itself is convincing enough.  Instead motivate someone to want to learn more - get them curious and self-driven to dive in wherever their interests lay.  Get them well adapted to the Clojure culture and the radical approach to simplicity.  Get them questioning their own practices and technologies.  Entice them with the functional approach to system creation.

Leon mentioned my talk, which claims, "Clojure manages risk better than any other technology" - http://www.infoq.com/presentations/Clojure-powered-Startups
For well-established enterprise shops, I think my most recent Conj talk is more convincing - https://www.youtube.com/watch?v=BNkYYYyfF48

Consider the following talks by Rich:
 * Clojure, Made Simple - https://www.youtube.com/watch?v=VSdnJDO-xdg
 * Are we there yet? - http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
 * Simple Made Easy - http://www.infoq.com/presentations/Simple-Made-Easy

Nothing is more convincing than a working system.  If it's possible, illustrate the virtues of Clojure and its approach to problem solving by "walking the walk" on a small scale, where the stakes and risks are low.  Build a tool, prototype an idea in half the time it would normally take, show the power of Protocols within your own existing system, etc.

Regards,
Paul

[Lawrence Krubner]

I wrote this for a blog post, but I think it is relevant here. After a long comparison of a bit of code, first in Javascript and then in Clojure, I wrote: 

At this point, a Javascript developer might say, “You've shown that the Functional style has some advantage, but why should I care? I can write in the Functional style using Javascript. I don't need Clojure.” That is absolutely true, and we all know that developers tend to be fiercely loyal to their languages, up 'til the moment they are not. I myself was fiercely loyal to Ruby, up 'til the moment when I wasn't. True moments of conversion are rare and always depend on a person reaching some point of pain with their current path. I myself suddenly realized that I was working with languages that would not carry me into a future full of multi-CPU computers and massive concurrency ... at which point I began to explore what the future might hold ... at which point I discovered Clojure.

I would, however, counter the Javascript developer with my own set of questions. If you have realized that the Functional style is best, do you want to work in a language that undercuts that style, or supports it? Do you want to burden yourself with the extra discipline needed to pull off the Functional style in a highly mutable language, or do you want to work with a language that was designed from conception to make your life easier ? Do you want to “navigate disappointment” or travel directly in the direction of success? 

In his talk, “Why Clojure is my favorite Ruby,” Steven Deobald refers to dealing with pain points in a language as “Navigating disappointment.”

[Johanna Belanger]

Thank you for these suggestions, Paul. Especially the last bit about a working system. I'll look for an opportunity to do that.

I loved your conj talk. Incredible!

[Johanna Belanger]

I think it depends also on the role a developer is in. If success on the job means plugging together what you are asked to plug together, then the risk/benefit analysis favors sticking with what you know. If success requires innovation, then you've got to look for new ideas that can give you leverage.

[Derek Troy-West]

Hi Johanna,

 You could try the angle that a Clojure REPL is a practical adjunct to standard Java tooling, particularly if the developer is using IntelliJ since Cursive is extremely accessible.

 

 I wrote something along these lines: http://derek.troywest.com/articles/proximity-and-brevity.

 

 This thread is a little old, so I have to ask - have you had any luck?

Derek