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....
I'm not exactly a Rubyist, but I really like Ruby. One of the things I like about it is its orthogonality: the concepts you learn work identically or similarly in different places, for different object types (where possible) so a relatively small handful of syntax + ideas + the library docs give you a running start at any program.
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.
The concept of homoiconicity has yet to really sink in for me. Conceptually, I understand what it means and I can explain it to others but I have yet to really understand it in a practical sense.
Imagine if, instead of Javascript, you had a language based on JSON, with a few additional types, notably a 'symbol' type and a 'list' type. A few of the symbols are primitives that determine the semantics of the list type, allowing other symbols to be defined as functions.
That's homoiconicity, and Clojure strongly resembles an actual implementation of this conceit.
I'll go out on a limb and say that everyone on HN loves Clojure! It seems to be the least cribbed language here. Its features are hard to beat - that and Rich Hickey's wonderful talks[0] make you all the more confident in Clojure as a language!
In a community of several 10's of thousands of people saying 'everyone' is always wrong.
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.
To love clojure you'd have to first become proficient in it...
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.
Love for space travel and love for a programming language are two different things entirely, the one is an adventure on an almost trans human scale the other is a way to tell a computer what to do.
>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.
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.
Speaking as someone who has lately been studying Common Lisp, I'm not quite sure how I feel about Clojure; I like that it's hosted on the JVM, but I don't like the apparent lack of a debugger, which to my mind is a sine qua non of Lisp development. I haven't seen much in the way of progress on that front, either, but it's been a few months since I last looked into it; is there any sign that that handicap is likely to be repaired?
I'm the author of Cursive, a Clojure IDE based on IntelliJ. Cursive currently has a fairly minimal and occasionally frustrating debugger that I'm planning to improve soon. That said, I use it all the time and it works pretty well. It's really nice to be able to debug a REPL session. Currently breakpoints and stepping work well, and expression evaluation somewhat works but is pretty quirky. Types and names are all currently displayed as Java, unfortunately. I'm planning to have a debug REPL per stack frame when I get around to upgrading this part. I'm hoping to get to this sometime within the next month.
Well, I'm glad to see that you at least appear to be headed in more or less the right direction. I'm not about to invest $100 in Clojure at this early stage of the language's development, but I'll be interested to see how the tooling continues to progress.
They have a similar taste, one of many examples is both are dynamic typed. There's at least some LISP ancestry for both (more for Clojure obviously).
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.
I'm learning Clojure, and my favorite thing so far is that the Clojure community's idea of engineering is substantially better than Ruby's. For example:
* 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.
I think the SHIP FASTER PEON! thing has less to do with Ruby and more to do with the perception that Ruby is some magical tool with which you can rapidly build anything. I learned Ruby 100% on my own and never worked with anyone else who used it and I've found my approach to writing Ruby very similar to my approach to writing Clojure: decoupling by default, immutability by default (where possible), single use design for methods. It wasn't until recently that I learned that what I do naturally in programming has an entire school of thought behind it called SOLID design. I definitely agree that Clojure lends itself more to following SOLID design principles but I think that Ruby can as well.
I love learning, especially how to write succinct clean code. Clojure, like ruby, scratches that itch and is fun to work in. It feels written with the intent of making programmers lives easier through mastery.
I remember reading one of PG's essays about Lisp being the most powerful language, and he made a list of characteristics defending his position. He implied that the new languages that are becoming popular simply move closer to being a Lisp. My guess is that Clojure is the Lisp that emerges most directly from someone who learned about languages from Ruby. I've only ever hacked with Ruby, if I can find a good intro series for non-coders to Clojure, I'm going to dive into it.
Lisp has a lot of strengths, don't get me wrong. But it is an ancient language, and despite its age, it never managed to catch on in a big way. It is true that many more popular languages keep stealing Lisp concepts, but that doesn't tell me that Lisp is amazing, but that despite all of its strengths, it must have some terrible weakness that makes it relatively uncompetitive in the general programming population.
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.
At a fairly superficial level, the :keyword syntax seems reminiscent of Ruby. But I'm neither an expert Rubyist nor Clojurist (Clojurian?) so I would defer to those more familiar.
They both have same roots, the :keyword syntax comes from Common Lisp and others:
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. ;-)
If you remove macros and s-expressions from a simple lisp.. what remains?
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.
It remains something that people living on a strict OOP+procedural+Algol-like-syntax only are willing to swallow.
...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)
Put another way, Ruby is a Lisp implemented by someone who doesn't understand what makes a Lisp worthwhile.
* 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.
There are quite a few things in Clojure that are similar to Ruby. nil? empty? and count all do in Clojure what you'd expect from Ruby. take-while, drop-while are a couple other examples.
