> Immutable data structures are always going to be slower than their mutable cousins.
Not always. It depends on usage. Mutable data structures can actually entail more work if the data needs to be accessed from more than one place. Immutable data structures can be shared and reused much more freely. (For example, adding an item to an array you got from somebody else means either the caller or the callee needs to have copied the whole array, while adding an item to an immutable list you got from somebody else means creating a single cons cell.)
At any rate, even if a destructive solution would be faster, the functional solution will probably still be faster in Clojure than the destructive solution would be in Ruby. And if not, you can still do something destructive — it's just not the default.
> "Clojure code is beautiful" should be changed to "Your OWN Clojure code is beautiful". When I finished writing a compact piece of logic or data transformation, I was often struck with the beauty of it. When I tried to read someone ELSE's Clojure code, however, I couldn't even begin to make sense of it.
I believe this is largely a matter of experience (not completely — some code just is hard to read!). Most people get that feeling when they're working with a relatively unfamiliar language. I find that the more familiar I become with Clojure, the better all other Clojure programmers seem to become.
> I find that the more familiar I become with Clojure, the better all other Clojure programmers seem to become.
That could be. However, I believe it's more to do with the fact that idiomatic Clojure encourages continual definition of nested layers of abstraction. Which makes the code beautiful from a certain viewpoint. However, it's also very similar to essentially writing a new language and adding features to it. If you buy this comparison, then reading your own Clojure code is like reading code written in a language you wrote, which is tailored to your own ideas about aesthetics and interfaces.
Which is great. However, that would then mean that in order to read anyone else's Clojure code, you would have to learn a new programming language every single time. I would buy that this gets easier the more you do it, because my second programming language was definitely easier to learn than my first.
That's true to some degree, but for well-written code, I don't think it's necessarily as severe as that description makes it sound. Any Ruby on Rails codebase is also chock-full of pseudo-DSLs (controllers, scopes, formats, etc.), but you don't hear the same complaints about Rails code being unreadable very often. It's possible to go overboard and turn your codebase into the Clojure equivalent of Negaposi, but from my (somewhat limited) experience, it's not exactly endemic.
> That's true to some degree, but for well-written code...
This is sounding painfully close to No True Scotsman argument. Also, for the number of times I've heard Clojure programmers say this, you'd think I would have at least ONCE been shown some of the programmer's actual code, in an effort to provide a concrete example of how elegant Clojure is.
> This is sounding painfully close to No True Scotsman argument.
Well, excuse me for trying not to make over-broad claims. Would you like me to go find some Negaposi to prove that other people's Ruby code is unreadable? The thing about "No True Scotsman" that makes it bad is that it makes a categorical claim, but it defines the category in an arbitrary way. I'm not really making a categorical claim — I'm just saying that, much like any other language, Clojure authors can write readable or unreadable code. Clojure gives you slightly more powerful tools, but overly "clever" use of the tools available in Ruby can produce unreadable code just as well.
> Also, for the number of times I've heard Clojure programmers say this, you'd think I would have at least ONCE been shown some of the programmer's actual code, in an effort to provide a concrete example of how elegant Clojure is.
Take a look at any of the more popular Clojure projects (https://github.com/languages/clojure is a good place to start). I find that they tend to be fairly readable.
Not always. It depends on usage. Mutable data structures can actually entail more work if the data needs to be accessed from more than one place. Immutable data structures can be shared and reused much more freely. (For example, adding an item to an array you got from somebody else means either the caller or the callee needs to have copied the whole array, while adding an item to an immutable list you got from somebody else means creating a single cons cell.)
At any rate, even if a destructive solution would be faster, the functional solution will probably still be faster in Clojure than the destructive solution would be in Ruby. And if not, you can still do something destructive — it's just not the default.
> "Clojure code is beautiful" should be changed to "Your OWN Clojure code is beautiful". When I finished writing a compact piece of logic or data transformation, I was often struck with the beauty of it. When I tried to read someone ELSE's Clojure code, however, I couldn't even begin to make sense of it.
I believe this is largely a matter of experience (not completely — some code just is hard to read!). Most people get that feeling when they're working with a relatively unfamiliar language. I find that the more familiar I become with Clojure, the better all other Clojure programmers seem to become.