Every time I write another DTO → domain → DB mapping layer in Kotlin/TypeScript, I think about Clojure. I’m pretty grateful I learned it. It really changed how I think about software. Still, it’s a trade: less ceremony, more responsibility.

I was lucky at one point to work professionally with Clojure for several years and it has made a huge impact how I think and write code in other languages as well. Also, those other languages now seem needlessly verbose and annoying compared with Clojure.

Clojure is very enjoyable if you respect the practices encouraged by Rich Hickey.

I've worked with Clojure in a number of companies, it's an elegant language and a thing of real beauty when done well, but it's not so much fun when you're working on a codebase that doesn't respect the philosophy of avoiding breaking changes; especially when these breaking changes are done in library code, and where a more liberal approach has been taken when it comes testing.

"less ceremony, more responsibility" is a good summary, in a larger codebase a bit of ceremony is not always a bad thing though. I'm also glad I learnt Clojure, it made me a far better programmer.

Kudos to Mr Hickey, I'm looking forward to the documentary.

Picking up Clojure was the best learning experience I've had in my professional life. Rich is inspiring; I wish him all the best.

> but it gets in the way when you're rapidly prototyping and exploring.

If you prototype a new features for an existing system, a test let you execute only the code you actually need. This will shorten your feedback loop and allow you to iterate faster. Refactoring a test is fine. Writing a BS test just to explore a solution is fine. In my experience following a test lead practice will help you build a simpler system which will be easier to maintain.

I tend to view TDD as a form of coding using a REPL, like in Lisp, where you can easily test chunks of your code as you go along. The main difference is that you leave behind your tests so they can be used in the future.

There is this book "Drive The Surprising Truth About What Motivates Us" which makes the same point, they also cite some studies about this.

As I understand, implicit joins are another selling point

I'm really greatful for clojure to exist. It exposed me to a lot of concepts and gave me a new perspective to think about problems, which in turn helped me to grow tremendously as a developer.

The emphasis to work directly with the data is quite unique to clojure (as I'm aware of, please proof me wrong on this) which allows me to just dive in and think about the problem I want to solve instead of fighting my language or framework. The interactivity of the environment paired with immutability results in an instant feedback loop which let me get into mental flow really fast, which is a joy.

Could you specify, what you mean by "refactor large codebases"?

> compiler telling you if the pieces still fit together?

You still write tests in scala do you?

Since types give me guarantees that pieces still fit together, I usually only need a handful of unit tests for my non-trivial algorithms, plus some integration tests. Never for functions which hand things around. After fixing all compile errors caused by a massive code change it almost always still just works.

> and because it is statically typed with a decent type system, you can refactor quite safely in general.

I wish that would be true. Would make my current job a lot easier.

Are there any examples for 2 and 3 openly accessible? While I grasped the basic idea I lack the imagination how it would look in a real world system.

If I recall correctly: cisco threat grid is using core.logic