@U7ANZ2MTK If I had a team of 60 devs, I'd find a small group of them (5 to 9 devs) that were enthusiastic to learn something new and leave the rest to keep on churning out Java. Then I'd spend a bit of time getting the enthusiastic group productive with Clojure and agreeing as a group as to the tools they wanted to use. Then I'd give them some really interesting projects that was very data centric and help them build something really impressive. If there were more people interested after the first group started delivering, then I'd form another small group. I really dont think you can change the minds of 60+ developers as a single group, at least not all at once anyway.

TBH my answer to that would be "why switch?". I guess maybe Eclipse doesn't have the flexibility that other IDEs/editors do? I mean, before we did Clojure we had half the team on IntelliJ IDEA, 2 vim users, and a few Sublime or VSCode users. All of those found Clojure plugins allowing them to still use the IDE/editor they were used to. The only slight awkwardness is that I liked Clojure (and Cursive) enough to shell out for a Cursive license, whereas the other IntelliJ users are using a few free/older plugins that are much less powerful/configurable that Cursive, but are 'good enough'

The curly braces I don't have an answer for, but we were doing various scripting in Python alongside our other stuff anyway, so we were used to lacking those 😉

introducing anything new under those conditions is pointless, unless you get a mandate from management. If you dont have the backing of the developers and the managers dont want to fix the management problems, then very little will improve and certainly not in a significant way.

thanks a lot John

I think the power of macros and reader-macros in particular had a part to play historically in the curse of lisp. However I’m not sure this is really true of clojure; macro’s aren’t commonly encountered; and when they are they tend to be relatively tasteful. In my experience teaching clojure over the last 10 years, the main issues people have struggled with are: 1. Getting used to a REPL based workflow. Most people are used to a hack/compile/start app/stop app, or a similar flow but with a test harness. Clojure works best with a REPL work flow, and as a continual dialogue with the system you’re building. I genuinely think this experience can be superior to what is provided in most other language workflows/environments; but it does require adopting relatively unfamiliar tools. “Lightweight” (less tooling) classic approaches are hobbled by slow startup times. I’ve seen good developers refuse to adopt REPL workflows, and get stuck in stop/start misery. 2. The language isn’t as small as it was when I learned it in 2008; so there are more gotchas now; and syntax variations that confuse beginners, e.g. namespaced keywords; destructuring forms like :keys [::foo/baz] #:foo.bar{:baz :blah} map syntax etc. 3. Almost everyone I’ve ever taught clojure too even after grokking the benefits of immutability, purity, lack of mutable state etc; get frustrated and waste lots of time and brain cycles debugging things by unconsciously attempting fixes that might be reasonable in languages which are mutable by default etc. i.e. I think they fallback on their experience (where it counts for less) and find it hard to internalise the fact that immutability/purity etc mean you shouldn’t look for problems where they usually don’t exist. 3. Error messages. TBH I think most of clojure’s error messages make perfect sense; but people just see a huge error trace, and don’t take the time to pick it apart. The messages are usually accurate and point to the problem; but require understanding some things like what “Can’t convert ISeq to Integer” mean. 4. Related to 3, I think most people learn clojure on the job; and assume a lot of things like: “it has if and for, apart from the (’s it’s basically like the languages I know!“. Not taking time to learn the fundamentals of evaluation; lazy sequences, or FP and just skim over them, causes people lots of grief. TBF I feel for people having to learn on the job like this, especially as there’s a difference between the theory and the practice; i.e. use of clojure.tools.namespace/refresh, or component/mount/integrant, it’s not something that is really taught in books. 5. Having to join lots of small libraries together to make a whole; rather than having a framework, can make building something like a modern webapp harder than it should be. Lack of good universal build tooling here also makes things hard. Boot is powerful but for me feels very unclojure-like, and is quite a lot to learn, lein is good for simple/small single-dep/app stuff but can be awkward to extend; when you need to compile assets etc etc… You can use something like luminus, duct or yada; but the community is split between them. I think the above lead to the steep learning curve, much more than macros; and I can’t think of many clojure libraries that I’ve found that are hard to learn; though I’m sure I could list a few; they’re not things you tend to stumble across very often. In my experience most clojure libraries are a joy to learn/use and read.

Mmn. Certainly as far as we are concerned we may use macros a fair bit (thread first and last, most commonly), but we've only actually got one macro we've written in our codebase, and it is quite mind-bending. You can go a long way without having to write macros, and I've never found them any harder to understand when using than regular functions. In fact I'm willing to bet there's a load more than I'm using and I simply haven't realised they're macros instead of functions

Don't languages like Python have a REPL based workflow these days?

I must admit I do still tend to fall into the pattern of boot run and just testing small chunks of code in the REPL rather than true REPL driven development

I've never had an issue with the error messages either, but some people seem to as @U06HHF230 said. And I actually found the Lisp syntax really helpful to get my "FP head" on. Clojure/Lisp looks so different from 'normal' languages that I naturally feel i drop into a functional/immutable/etc way of thinking when I sit down and look at some Clojure code. Whereas with something like Scala I find myself falling back to OO ways and trying to solve problems with an OO mindset because it looks like so many OO languages I've worked in

I do think I benefitted from my boss being very FP oriented though, so he kept directing us to the correct mindset etc. If I'd been trying to self-teach, or learning with a team of equally inexperienced (in FP/Clojure) devs as I was when I started, it would have been a much rockier journey

> Lack of good universal build tooling here also makes things hard. 100% esp when I’ve tried to teach new folk

> Don’t languages like Python have a REPL based workflow these days? Kinda, but not the same sadly

Where you really see the difference with Clojure's REPL is when you have a running application -- either one you started in the REPL or one that starts a REPL you connect to -- and you have the full power of the language available within the running application so you can run any code in the application in context and you can redefine functions on-the-fly, whether it's to add debugging or to fix bugs. While the app is running.

I find it interesting to hear Boot described as "unclojure-like" given that it's about functions and composition -- whereas Leiningen feels so declarative (which is very "unclojure-like" to me)

well unclojure-like is perhaps the wrong word — but I think it’s fair to say boot programs don’t look like regular clojure programs. I appreciate this is perhaps a weak cosmetic argument, rather than one based on semantics, but the ergonomics of boot appear to be things like lots of side-effecting calls at the top level, use of zero-arg functions, with implicit I understand builds are perhaps sufficiently different to warrant this. Regarding leiningen and being declarative, I’m equally not sure why that’s unclojure-like 🙂; is deps.edn un-clojure like? It’s arguably more declarative than leiningen. Leiningen on the whole is just a project map expressed as clojure data (though yes it is evalled in a syntax quote), but internally it’s still really just a map. It does suffer from extensibility etc and is far from perfect. Anyway my intention is not to criticise boot or defend leiningen, my intention was simply to say that I don’t think clojure build tooling is done yet. I think tools.deps is an important evolution here, and I hope to see other more focused tools pop up around it take on the challenges of building projects.