Matz: Ruby's Lisp features (2006)

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/179642

by juliangamble • 13 years ago

62 29 13 years ago

blade.nagaokaut.ac.jp

kbd• 13 years ago

(2006)

jrochkind1• 13 years ago

Take lisp, remove s-expressions.... what are the remaining lisp-like parts?

Ruby's smalltalk influence is pretty clear, and I guess smalltalk says it's lisp-influenced... I dunno. I am dubious that Matz started with lisp rather than smalltalk.

regularfry• 13 years ago

How would you propose resolving this doubt of yours?

chimeracoder3• 13 years ago

Well, Ruby isn't really homoiconic. I can't speak for OP, but to me, if a language isn't homoiconic, it can't be a Lisp.

Lisps don't have to have parenthesis-based syntax, but the grammars should be close to context-free (like Lisp's is - most of the language can be defined by two production rules). Ruby's grammar is nowhere near as simple.

Compare:

Lisp: http://cui.unige.ch/isi/bnf/LISP/

Ruby: http://stackoverflow.com/questions/663027/ruby-grammar

davexunit• 13 years ago

I guess higher order functions and symbols are the remaining Lispy bits.

cgag2• 13 years ago

Being properly OO kind of messes up the way alot of the HoF stuff works as well, since you don't have a bunch of functions that operate on strings, you have methods on string. You have to have some strange thing like mystrings.map(&:to_upper), rather than just passing map the actual function.

6cxs2hd62• 13 years ago

Although removing s-expressions isn't necessarily critical -- see Dylan, Honu, sweet expressions, etc. -- I think removing macros means you no longer have a lisp.

sjtgraham• 13 years ago

Removing homoiconicity means you no longer have a lisp.

aidenn0• 13 years ago

C++ is arguably a lisp then

tomphoolery• 13 years ago

IIRC, Ruby builds an s-expression tree under the hood (disclaimer: this is going by what I've read and I can't find the article right now, please take with several grains of salt). I do know this, however: In Ruby, everything is an expression. So that's why code like..

    foo = if bar?
      :bar
    else
      foo_proxy || :foo
    end

..can be expected to work. One thing I love about Ruby is that I feel as though it works "like a Lisp" under the hood, but doesn't look like one at all. The one thing I could never get over with Lisp-like languages was how difficult the syntax was for me to read. Ruby, OTOH, is a very familiar syntax and includes familiar concepts like various OOP encapsulation features, but it's all built around this expression-driven language that's both syntactically powerful and very easy to read.

edit: I still wouldn't consider it part of the Lisp family, only heavily influenced by that kind of programming...

johnbender• 13 years ago

"Everything as an expression" is concept that exists entirely separate from LISP as a programming language. Eg, in the untyped lambda calculus everything is indeed an expression and it obviously predates LISP.

The thing that makes LISPs interesting is that both data and code have the same representation. Manipulating code and data looks the same and that leads to all sorts of interesting meta-programming constructs

Also I'm not sure what you mean by "under the hood", but Ruby's internal representation is an abstract syntax tree (as with most languages). That AST bears a resemblance to LISP because LISP is both the language and AST rolled into one, but I would never confuse Ruby for LISP because it has an AST representation.

twelvechairs• 13 years ago

My take is that it is essentially that ruby's methods (the basis of OO) are basically based on a simple system of (what ruby refers to as) procs and lambdas (ok, the way they are implemented is not quite the same as the 'proc'/'lambda' objects but you can easily convert between them). These are quite functional and lisp-like. Not that it is done, but you can reduce all of your complex methods to classless functions if you want.

Not sure if this was new in Ruby or came from Smalltalk or somewhere else though.

btilly• 13 years ago

I am dubious that Matz started with lisp rather than smalltalk.

I'm not dubious. Before writing Ruby, Matz had been a Lisp programmer. But he wasn't a Smalltalk programmer.

Conceptually, it makes sense that he would have started with something conceptually like Scheme, then layered things on top.

austintaylor• 13 years ago

I think the answer is the dynamic environment. In terms of syntax and semantic constructs Ruby is not very much like Lisp at all. But the dynamic runtime is very lisp-like. You can modify any part of the environment at runtime—in fact there is really no distinction between run-time and compile-time.

IMO the biggest flaw in Ruby is that it doesn't really take advantage of this design choice. Of course there is a performance cost to this kind of dynamism, and all it really buys you in Ruby is the ability to monkey-patch other people's code (the advisability of which is debated). In the Lisp world you have tools like SLIME which provide a much shorter feedback loop to the developer by connecting the dynamic runtime to the editing environment.

Tools like pry move Ruby forward in this area but it is still nothing like SLIME. My impression is that the weakness of Ruby's module system, along with heavy use of OO classes, make it unlikely for Ruby to ever support that kind of development process.

(There are other examples of Ruby's Lisp heritage, such as everything-is-an-expression and implicit return values, but I think those are relatively small design choices compared to the runtime thing.)

pjmlp• 13 years ago

Ruby's smalltalk influence is pretty clear, and I guess smalltalk says it's lisp-influenced.

Smalltalk was surely influenced by Lisp.

You can read about Smalltalk's history as described by Alan Kay here

http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

informatimago• 13 years ago

Matzacred Lisp. :-(

lispm• 13 years ago

My slightly different take:

  * take Emacs Lisp language (one after CL) and byte code compiler
  * take Emacs Lisp implementation with simple GC and byte code virtual machine
  * 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).

Yukihiro Matsumoto mentioned in some talk that the most Lisp he understood was some Emacs Lisp and that he studied the Emacs Lisp implementation.

Matz: Ruby's Lisp features (2006)

Related Stories