5 ms·

Persistent data structures: Useful but you can get that in JS too, and if you can get your whole team to agree on it, you can avoid mutable data structures. I'v

Persistent data structures: Useful but you can get that in JS too, and if you can get your whole team to agree on it, you can avoid mutable data structures. I've been able to do that 100% for years now. Multi arity functions: That's actually a minus, not a plus. The vast majority of the usages of this are solved with options params with default values in a much clearer way. Multi methods: In 5 years of using Clojure professionally, I think I've never seen these used once. Transducers: This is just an optimization, and I'm pretty sure it's possible in JS too since it's an API design. Data oriented design: This is a design practice, it can be done in JS too, and it's a questionable one too. Spec: When Spec came out is around the time I realized the period of true Clojure innovation is over, which peaked from around 1.3 to 1.5 or so. TypeScript is by far a better version of adding type innovations to a dynamic language. REPL driven: You can do this in any language with a REPL, even JS. Better live reloading: This is just as good in JS. There's no language feature of ClojureScript that makes this better than in plain JS. Meta data: The only times I've ever seen this feature used was in storing internal representations of things in DSLs, which can be done in JS by using plain objects for their representations which store an inner object. Protocols: JS only doesn't have this because it's duck-typed and they are implicit. An explicit counterpart exists in TypeScript's interfaces for those who want it to be explicit. Core async, Go channels: These have to do with threading, but JS mostly exists in single-threaded runtimes, so it's non-applicable. Atoms, Datoms: These are library-level concerns which are doable in JS.

dreamcompiler 7y ago
You're rehashing a couple of the most tired arguments Lispers always hear: 1. Parentheses are inconvenient. 2. Everything you can do in Lisp you can do in $other_turing_complete_language. What you're missing in (1) is that as much as you wish you were stating an objective truth of the universe, you're really just stating your own subjective impression. If parentheses were objectively, universally inconvenient, nobody would ever program in Lisp. And yet many do. So what's the explanation for that? What you're missing in (2) is that although (2) is certainly true, it's irrelevant. If (2) were relevant, nobody would ever prefer any Turing-equivalent language over another. And yet objectively, people certainly do. So what's the explanation for that? The other thing you're missing in (2) is Greenspun's tenth rule, but I'll let you look that up.
- sdegutis 7y ago
  Novelty. That’s the explanation. People love novelty. Especially programmers who tend to get bored easily at their jobs.
- kazinator 7y ago
  > So what's the explanation for that? Why, they are impractical buffoons who lack the benefit of my own vast personal experience, which trumps everything. Or else blind zealots.
dimovich 7y ago
Yes, you can do all that in JavaScript using libraries. But in how many of your projects ARE you using all this? That's the question. And what are the steps you have to take and the cognitive load to make sure all the libraries you're using adhere to these conventions, and all the people that contribute code to your project also use the right paradigms? When all these things are baked into your language, you're free from all the worries and cognitive load to make sure everything works as you expect it to work.

dreamcompiler 7y ago

You're rehashing a couple of the most tired arguments Lispers always hear: 1. Parentheses are inconvenient. 2. Everything you can do in Lisp you can do in $other_turing_complete_language. What you're missing in (1) is that as much as you wish you were stating an objective truth of the universe, you're really just stating your own subjective impression. If parentheses were objectively, universally inconvenient, nobody would ever program in Lisp. And yet many do. So what's the explanation for that? What you're missing in (2) is that although (2) is certainly true, it's irrelevant. If (2) were relevant, nobody would ever prefer any Turing-equivalent language over another. And yet objectively, people certainly do. So what's the explanation for that? The other thing you're missing in (2) is Greenspun's tenth rule, but I'll let you look that up.

sdegutis 7y ago
Novelty. That’s the explanation. People love novelty. Especially programmers who tend to get bored easily at their jobs.
kazinator 7y ago
> So what's the explanation for that? Why, they are impractical buffoons who lack the benefit of my own vast personal experience, which trumps everything. Or else blind zealots.

dimovich 7y ago

Yes, you can do all that in JavaScript using libraries. But in how many of your projects ARE you using all this? That's the question. And what are the steps you have to take and the cognitive load to make sure all the libraries you're using adhere to these conventions, and all the people that contribute code to your project also use the right paradigms? When all these things are baked into your language, you're free from all the worries and cognitive load to make sure everything works as you expect it to work.