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.
