4 ms·
Blocks, and the way they make it very easy to add new control structures "seamlessly", are indeed cool—but aren't ruby's blocks taken pretty much verbatim from
by snogglethorpe 14y ago
Blocks, and the way they make it very easy to add new control structures "seamlessly", are indeed cool—but aren't ruby's blocks taken pretty much verbatim from smalltalk (which of course is also many decades old, if not quite as old as lisp)?
Indeed, smalltalk seems a better example, as it uses methods and blocks to implement all control structures, even the "built-in" ones.
- masklinn 14y ago> aren't ruby's blocks taken pretty much verbatim from smalltalk Yes, with some crippling to fit them in a different syntax (Ruby's blocks are not first-class, so using more than one of them or methods on the blocks themselves isn't very nice) And amongst the important similarities are return being nonlocal from within blocks.
- pat_shaughnessy 14y agoI admittedly don't know a lot about Smalltalk - I was aware Ruby's (and every other language's) object oriented ideas were invented originally with Smalltalk, but I didn't know it had a block/closure syntax also. In this post I wanted to go back as far in time as I could :)
- vidarh 14y ago> In this post I wanted to go back as far in time as I could :) Then you might want to look at Simula as well. As much as the term "object oriented" was invented in conjunction with Smalltalk, a lot of the basic concepts (classes, objects...) came from Simula (but not closures).
- munificent 14y agoYou should check out Smalltalk blocks. They are much closer to what Ruby has than Lisp-style closures are.
- mseepgood 14y ago> but I didn't know it had a block/closure syntax also Blocks are one of the most important concepts of Smallalk. Every control structure is done via blocks in Smalltalk, even if/else is a method (message) on a boolean object, that takes two blocks as arguments: one for the 'true' case and one for the 'false' case.
- vidarh 14y agoProbably. In terms of features, Ruby is pretty much an unholy mix of Smalltalk, Perl, Awk with a dash of Lisp thrown in and a parser that's a monstrosity of epic proportions put on top (the MRI 1.8.x series had a Bison parser with 6k-7k lines of C to implement context-sensitive tweaks...) to make the whole thing have a syntax palatable for those of us who'd otherwise complain loudly about square brackets or parentheses... And I write this as someone who loves Ruby - there's much to love about Ruby, but a clean design is not it.
- pat_shaughnessy 14y agoLol - very funny. I have to agree you; as a Rubyist studying MRI internals there's a lot of very confusing code in there. And FYI Ruby 1.9/2.0 retains the confusing Bison grammar file. One of my goals with the eBook is to allow readers to get an understanding of how Ruby works without having to struggle through the confusing implementation themselves.
- diminish 14y agoBut do you agree that Ruby is an unholy mix? I would say it is a holy mix, Matz targeting programmer happiness, principle of least surprise etc. Speaking of internals, do you know enough internals of Smalltalk, python, Perl implementations to judge, Ruby is confusing compared to them? How would you compare them to Ruby implementions MRI and 1.9/2?
- pat_shaughnessy 14y agoNo - not the "unholy" part. Like vidarh I'm someone who loves Ruby (why else would I write a book about it!) but I do agree with him about the internal implementation: it's very confusing and hard to understand. At times, this leaks out into the syntax of an otherwise beautiful language. JRuby and especially Rubinius are great alternatives to MRI if you're interested in studying internals - they're much cleaner and easier to understand. Sorry I don't know anything about the internals of Smalltalk, Python or Perl and can't comment on them.