4 ms·
Warning possible flamebait: could Clojure be the solution?
by barking 6y ago
Warning possible flamebait: could Clojure be the solution?
- ssijak 6y agoSolution to what exactly? Clojure is Lisp like jvm language with different characteristics.
- The_rationalist 6y agoScala
- m12k 6y agoA solution to which of the listed pain points?
- dkersten 6y agoI’m a huge Clojure fan, but I don’t think so. They are very different languages with fundamentally opposed opinions on the use of static vs dynamic types, for example.
- johnday 6y agoI've tried to get into Clojure multiple times and it feels quite unergonomic to program. I think my brain is not correctly shaped for its constructs, whereas Haskell fits my mental models perfectly.
- Random_ernest 6y agoVery interesting. I feel like I have written this exact sentence somewhere online only with the languages reversed. Tried to get into FP multiple times with Haskell, never clicked, then tried Clojure and felt productive after 2 days.
- dgb23 6y agoWould you say you are a top-down thinker/programmer?
- johnday 6y agoI think so, yes. I think Haskell helps with this. You can write the top level code first, and be fairly confident that, if the types are sensible, there will be a sensible implementation by the time you reach the bottom. It also helps that there's so much code reuse that the "depth" reached is quite shallow compared to what you might see in other languages.
- danielscrubs 6y agoCorrect me if I'm wrong but Clojure nudges avoiding mutable state while Haskell uses type theory to enforce it at your leisure at compilation time. Clojure seems like a great language, but it has a completely different focus. I'd say Idris is a contender instead, which is not lazy and has theory proving. Will it become popular in the wild? Of course not, Python & JavaScript or something even easier is going to eat the world.
- nimih 6y agoI think Clojure puts a similar amount of effort to Haskell in order to discourage mutable state: the core library makes the easy solutions the ones that use immutable data structures and pure functions, and you have relatively ergonomic escape hatches (State/ST monad, atoms/volatiles/transients) available if you need them. Haskell's compile-time checking of purity and explicit effects is obviously absent from Clojure, but at a high level I think the two languages are mostly aligned in how easy they think it should be to use mutable state[0]. That being said, this is just picking nits and I agree with your larger point that Clojure and Haskell provide very different sets of trade-offs, so one really isn't a good substitute for the other[1]. [0] edit: Clojure just uses the more Clojure-y approach of eschewing compile-time checks in favor of assuming the user is able to responsibly use mutable state and indicate via some side-channel the contract a given function adheres to. Rich Hickey--if he cared about type systems in the first place--would likely argue that there's nothing inherent in Haskell which prevents programmers from writing truly labyrinthine stateful code by performing their computation within the appropriate monad; I have certainly done so myself, on occasion. [1] Unless your only metric is "ability to get functional programming weenies to argue/chatter in HN comments," in which case they pretty interchangeable IME.
- danielscrubs 6y agoI have nothing against Clojure. I like dynamic typing when doing data science, and I like heavily enforced types when someone else dumps code in my lap.
- tome 6y agoI would think that the solution to Haskell having pain points would be fixing the Haskell pain points.