3 ms·
I'm going to have to disagree with almost everything you said, let's have a look: > I always think it's hilarious when Clojure enthusiasts try to address conce
by kolme 6y ago
I'm going to have to disagree with almost everything you said, let's have a look:
> I always think it's hilarious when Clojure enthusiasts try to address concerns about the language by talking about parentheses, as if that was actually the major barrier to entry.
Not that they are a major barrier, but they do scare people away. I know this because I've been tempted to try lisps before and after having a look at some source code, I was "scared" of the parenthesis. They are ugly (at least I thought at first sight) and they seem like very tedious to type. Of course I know better now, but that was _the_ reason I had not to try lispy things, at least on a couple of occasions. So yes, the "the parens are A-OK!" is absolutely warranted when trying to sell Clojure or any lisp for that matter.
> It's slow
So what? If I'm not writing anything CPU bound, I'm not very concerned about that. Clojure is fast enough for most things. The performance penalty is completely justified if it takes me half the time to write an app. This is just a trade off, or do you write all your stuff in ASM?
> Development with the REPL is slow because the startup times are glacial and REPL-oriented development usually requires tons of from-scratch restarts.
This is just very much not true. First of all, nobody is forcing you REPL-oriented programming. Second of all, it doesn't take more than a couple of seconds for most apps to restart. And third, if you use "def" and "defonce" correctly you'll hardly ever have to restart the REPL.
> The tooling sucks.
That's just your opinion, man, and it's also pretty rude. Clojure have awesome IDEs and tooling, and the aforementioned REPL-development allows you to have the same "react-hot-relading" developer experience, anywhere.
> Java interop is a black art.
Java (and Javascript) interop is pretty straight forward. You call functions and instantiate classes and stuff. No naked dancing under the moon involved.
> The ecosystem practically doesn't exist.
It maybe didn't some time ago. The ecosystem right now is thriving with pretty cool projects.
> The lack of static types hurts you in many ways, most of all your ability to refactor with confidence.
That's also pretty subjective, in my opinion the only thing that gives you confidence to refactor is unit testing.
Plus there's other ways to validate parameter and return values in Clojure, and they are not limited to the type.
You'll agree, that a return value is of a given type doesn't guarantee that it's correct.
> Clojurescript is weakly typed, Clojure is strongly typed.
Plain wrong, types are semantically equal in both languages (they are weak). The semantics of the target languages are just implementation details.
You can try this on a REPL of any variant you like:
(def foo 42)
(def foo "Hello, World!")
Sharing code between Clojure and Clojurescript is fine, especially if you stick to the built-in data types and functions. Of course if you have a lot of specific interops interleaved, it's going to be painful.
- darksaints 6y ago> Plain wrong, types are semantically equal in both languages (they are weak). Nope. Try evaluating (+ 1 "1") in Clojure as well as Clojurescript. One is weak...it doesn't throw an error, might throw a warning because the compiler can plainly see that it is wrong, but you'll get no warnings when it is out of scope or evaluated at runtime. The other is strongly typed, because it will actually throw an error, knowing that adding a string and a number is nonsense. While it would be better if this was caught at compile time, catching it at runtime is waaaaay better than not catching it at all. The languages are actually different languages, because their type semantics are different. And you might want to figure such things out, as well as the far reaching implications, before you go around telling people they're wrong on the internet about a language that is laying in the mud like a crocodile, waiting for the perfect time to bite you in the ass.
- kolme 6y ago> And you might want to figure such things out, [...] before you go around telling people they're wrong on the internet Apply it to yourself my friend, you are wrong again. What you are talking about here is implicit type coercion, which doesn't have much to do with strong vs weak types. Also in your example you do get a warning, so it doesn't seem to be a problem?
- darksaints 6y agoImplicit type coercion is exactly the difference between strong and weak types. FFS. https://www.educative.io/edpresso/statically-v-dynamically-v-strongly-v-weakly-typed-languages https://www.educative.io/edpresso/statically-v-dynamically-v... And if you really do not believe that to be a problem because the compiler warned you about it, I bid you the best of luck. You're gonna need it. There are dozens of ways that bug can sneak its way past the compiler where you won't get a warning because the compiler only does local type inference.