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.
* 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...