lukashrb

I thought the same for a long time and it really discouraged me. My natural pitch recognition is pretty bad. What helped was starting with very simple melodies and songs, so I could get familiar with the most common movements. That made it easier to figure out progressions, because I learned how to narrow down the options. I’m still not great at it, but I keep improving. That’s why I think it’s trainable.

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.

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.

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?

> 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

> I get paid to deal with requirements that change every bloody week because we have quick customer feedback

In my experience this is something where clojure is exceptionally good at.

Thank you.

If I understand you correctly, this i a general problem of functional data structures?

> Clojure will always be slow, because it's not cache friendly.

You always have the option to use the java data structures, for the cases this kind of optimization is needed.

> Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode.[0]

[0] https://news.ycombinator.com/item?id=1803815

The link is broken. Nevertheless I don't now much about the benchmarks but SBCL seems impressively fast.

You're absolutely right. I guess I mentioned pattern matching in particular because of the cited sentence from OP "I'm still waiting for pattern matching + algebraic data types".

> The same is true for the rest of the things you've mentioned: none are specific to static typing!

Sure, I could be wrong here. I frequently am. But could you point out why do you think that?

Your are right! Thank you for correcting me.

For what its worth: People don't use dynamic language because they don't know better or never used a static language. To better understand what dynamic languages bring to the table, here are some disadvantages of static types to consider:

Static types are awesome for local reasoning, but they are not that helpful in the context of the larger system (this already starts at the database, see idempotency mismatch).

Code with static types is sometimes larger and more complex than the problem its trying to solve

They tightly couple data to a type system, which (can) introduce incidental complexity >(I'm still waiting for pattern matching + algebraic data types) This is a good example, if you pattern match to a specific structure (e.g. position of fields in your algebraic data type), you tightly coupled your program to this particular structure. If the structure change, you may have to change all the code which pattern matches this structure.

I would really appreciate if someone takes the time to enlighten me how monads solve the problem.

Interesting take since Clojure and Java are two very different languages. And unlike for example Kotlin, Clojure does not try to be a better Java than Java. But true though Clojure leverages the power of the jvm.

Thank you and all contributern for your amazing work on clojurescript.

Nice article.

Sadly a lot of people won't even try clojure since it is dynamic typed. I see their point but nevertheless clojure does something really well here. As the author obserserves designing around some core data structures results in high code reuse. A library like spec is also way better in encoding business requirements than all the mainstream language typesystems e.g. a number in business context has mostly constraints like a particular range etc. I really looking forward to see someone come up with a static type system inspired by clojure's approach.

The first time I encountered "interactive development" was when I had to use python with jupiter notebook. I really liked this style of development. The tdd approach I practiced before was somewhat similar but by far not as visual.

Clojure was an eye opener for me and I think it offers a great developer experience (e.g. I'm addicted to C-c C-p)

It seems my journey hasn't ended and I definitely have to check out CL!

But atm it's hard for me to give up the things clojure offers to me: persistent datastructures, access to a great ecosystem and a very good designed standard library.

Just delete their cookies to work around this. But I agree I don't like medium either the site is very slow and the extra steps necessary to access the content are very annoying.

The author is aware of the fact that mutability makes this kind of problem easier [0]

[0] https://twitter.com/josevalim/status/1379771275627921409?s=1...

Reading this and other replies I wonder why no one mentions core.async?

Could you give us more details about the problems you running in?

> Clojure is also ideal for a startup, where a couple of competent Clojure programmers can write a complex application that would took a huge team of developers in other languages years of work.

There is a saying "if something sounds too good to be true, it probably is".

I wonder how many other languages did the author try to know that clojure is the reason for his success?

That being said, I really enjoy writing clojure and I absolutely love the interactive style of development. I hope more devs would try it so that it would get more traction in mainstream development.

I really enjoyed the read and think this is a really good, fair and down to earth perspective. Also reminds me how much there is to explore for me :)