What is it about Clojure that Rubyists love? I am a Rubyist who is new to Clojure (I love it) and I cant explain it myself. Clojure was suggested to me by several other Rubyists. I find myself suggesting it to other Rubyists as well....
The same applies to Clojure. There's laughably little syntax to learn, and once you've got that under your belt you're just composing functions.
I'm not made to feel I've wasted a lot of memory space on the esoterics unique to some particular language. Clojure works for me rather than the other way around. This no-nonsense obviousness was one of Matz' design goals for Ruby, and clearly ditto for McCarthy and Hickey.
That's homoiconicity, and Clojure strongly resembles an actual implementation of this conceit.
To love clojure you'd have to first become proficient in it and I highly doubt even double digits of HN would claim to be proficient, much less to love the language.
In general, you speak for yourself and yourself alone and my take from your comment is that you love clojure.
I have played around with it but not enough to be able to say that I love it, even though I would like to spend more time with it.
I'm sure that when the honeymoon phase is over clojure will be yet another useful tool in the toolbox. I can't recall a single language that I truly love, they all have their specific warts and I expect clojure to be no different in that respect.
Just a different set of limitations to applicability.
I do not think that the GP was using 'love' in that sense. You can 'geek out' about news and information about something without actually being much involved in that something at all. Witness the popularity of posts about space launches on HN. I doubt that there are very many actual rocket scientists, but we sure do have a lot of people interested in progress made in space.
I'm pretty sure many times more than 99 HN people have used Clojure extensively. Heck, there have been posts here from teams using it in production on their startups.
As for differences I like Clojure because I can compile up an uberjar and hand that uberjar to ops and walk away, so its faster and easier, whole regions of "fun" (In the dwarf fortress sense of "fun") that exist in ruby deployments simply don't exist as a class of problem in clojure deployments.
Ruby appealed to me because of its simplicity and conciseness, but after a couple years it turned out to actually be rather complex.
I found the simplicity and conciseness I was looking for when I was randomly reading some Clojure code a couple years ago in the speclj sample docs (http://speclj.com/tutorial/step7) of all things.
* immutability by default
* decoupling by default
* small libraries rather than mega-frameworks
The comparison is not quite fair; but there's something to be said for appreciating a well-engineered solution versus the usual "SHIP FASTER, PEON!" schtick that Ruby has.
My opinion is that it crosses a syntactic threshold of abstraction, after which a language just loses. s-expressions are extremely powerful, but also the language's Achilles heel.
This resembles how there is a 'happy medium' for writing human languages. We could write all of our text in morse code, but we don't. We know that too many glyphs, like in Chinese, slow down learning too, as the effort to remember them all takes lots of practice.
So just like Scalaz's operators are so arcane that us mere mortals are better served by using words instead of <=o=>, a world of s-expressions makes it harder to find your way precisely because of excessive syntax homogeneity.
Still, I think Lisps are worth learning, it's just that I think the ideal language steals much from Lisp, including most of what s expressions are used for in practice, but it doesn't go all the way.
From Matz (creator of Ruby):
Ruby is a language designed in the following steps:
* take a simple lisp language (like one prior to CL).
* remove macros, s-expression.
* add simple object system (much simpler than CLOS).
* add blocks, inspired by higher order functions.
* add methods found in Smalltalk.
* add functionality found in Perl (in OO way).
So, Ruby was a Lisp originally, in theory.
Let's call it MatzLisp from now on. ;-)Genuinely curious. If I'd had to guess I say just the spirit of the language, the macros being reincarnated as the highly dynamic smalltalk method system. The s-expressions being reincarnated as the blocks.
...otherwise they'll just go "yuuuck!" or "wtf?" or "this is weird" and walk back away to their cubicles. Ruby is great because it changed the culture by letting the kinds of people that wouldn't have dabbled in functional-ish programming or DSLs put their toes in the meta-water ...now hopefully, some of them will start to take swimming lessons :) (and a few will drown themselves and their friends, of course, but there are prices to pay for enlightenment)
java script :)
see also: https://mxr.mozilla.org/mozilla/source/js2/semantics/
* Start with Emacs Lisp [1]: Well, if you like, but in exchange for the perceived simplicity as compared with e.g. ANSI Common Lisp, you're also giving up extremely useful things like lexical scope, and that's going to hurt your users down the road.
* Remove macros and s-exprs: Why? They're a powerful feature, and if you're building a Lisp, then operating on the AST shouldn't be hard. Except that removing s-expressions costs you homoiconicity, which means you need to translate from source to AST, which means the difficulty of writing a macro just jumped by several orders of magnitude, so, fair enough, if you're throwing out s-exprs then macros have to go as well. I can see an argument for this decision, in that it lowers the barrier to entry for non-Lispers who have yet to get over the parentheses allergy.
* Add simple object system: Is it really that much simpler to do single inheritance + mixins (Ruby) than to do multiple inheritance (CLOS)? This is an honest question; I've never implemented an object system, so I don't know which is easier from the developer's perspective. From the perspective of the language user, though, I don't know that I see a lot of difference.
* add blocks: This decision strikes me as totally indefensible.
If you already have lambdas, why do you need this separate abstraction which looks and smells mostly like a lambda, but doesn't act like one except in certain circumstances, and which is also the only place in your entire language with lexical scope rather than dynamic? You've just unforgivably complicated your language's syntax and implementation, and your users' lives; you've made it necessary for people both to write, and to understand, documents like [2]. Why would you ever do that?
And if you don't already have lambdas, in what crazy world of paisley skies and ice-cream seas does it make any kind of sense to put yourself and your users through all these unnecessary mental calisthenics, when you can just add lambdas, and solve all these problems with a single simple abstraction that everyone either already knows or should?
I can't imagine how anyone could possibly defend this reeking farrago, but I'd sure like to see someone try.
* add methods found in Smalltalk: I'll concede this one; it was a good idea, and a lot of Ruby's power comes from being able to hang magic off method_missing. Of course, a lot of Ruby's headaches come from that, too, and it is a persistent source of subtle bugs and unexpected behaviors, especially in frameworks like Rails which make heavy use of such magic hooks. For Smalltalk developers, this isn't so much of a problem, because Smalltalk is so heavily self-documenting; Ruby developers are not so fortunate.
* add Perl functionality: Well, this makes sense, if you're trying to come up with a Perl killer, in the same way that Perl was explicitly intended to be an awk and sed killer. It seems lately to be working, too; there's what looks to be an increasing trend for people to use Ruby for the sort of tooling which, a decade ago, they would've done in Perl. On the other hand, and I say this as someone who grew up with Perl and will always have a soft spot for it, Perl is a giant ball of hair laced with fish hooks, into which only a true expert may plunge his hands and pull them back out without severe lacerations. If you let your Perl emulation anywhere near the conceptual or implementation core of your language, you risk infecting it with the same disease -- indeed, I'm inclined to wonder if that's whence came the brain damage that led to Ruby's mess of mutant lambdas.
Don't mistake me: Ruby is a cute, useful little language, and it has some interesting ideas which I think are worthy of wider consideration, such as the method system. Unfortunately, Ruby also has some grave drawbacks, such as the lack of a self-documenting capability to make the method system sane to use at scale, which in my opinion rather severely reduce its appeal.
[1]: No, I've never seen Matsumoto admit outright that he started with Emacs Lisp, but I think it's a reasonable surmise. Consider: Emacs Lisp descends from MacLisp, which is both simpler and older than Common Lisp; in both Emacs Lisp and Ruby, lexical scope is an afterthought, inflicting at least occasional headaches on users of both languages; prior to inventing Ruby, Matsumoto was an Emacs Lisp developer of considerable Japanese repute.
[2]: http://awaxman11.github.io/blog/2013/08/05/what-is-the-diffe...