4 ms·
Inheritance from java.lang.Object does not make Clojure data mutable. Blocking for IO does not make Clojure imperative, it not a purely functional language, bu
by synthc 5y ago
Inheritance from java.lang.Object does not make Clojure data mutable.
Blocking for IO does not make Clojure imperative, it not a purely functional language, but its still a functional, not imperative, language.
It's possible to build a service in a purely functional language using non blocking IO that also takes minutes to render.
No language will save you from a bad design.
I do agree that Clojure is not the most suitable language for large projects with lots of contributers because of it's dynamic nature.
- blacktriangle 5y agoThe problem is not the built-in Clojure data structures. The problem is that a huge part of Clojure's heavily marketed value proposition is seamless-ish Java interop, which means working with Java objects and all their associated mutability. So while pure Clojure has very controlled mutability, pragmatic Clojure inherits all of Java's problems. And since they hype interop so much, nobody wants to rewrite functionality in Clojure when they could just leverage Java.
- yogthos 5y agoIn practice all the interop lives at the edges of the application. As a concrete example, Pedestal HTTP server has around 18,000 lines of code, and 96% of it is pure functions. All the IO and side effects are encapsulated in the remaining 4% of the code. This has been a common scenario for the vast majority of Clojure programs I've worked on in the past decade. https://www.youtube.com/watch?v=0if71HOyVjY https://www.youtube.com/watch?v=0if71HOyVjY Core of the application does data transformations using native Clojure data structures. This is where all your interesting business logic lives. The interop lives at the edges and typically used for stuff like database drivers, HTTP servers, file access, and so on.