No!

Ruby 2.0 won’t have continuations?! Say it ain’t so!  I feel like the guy who’s kinky punked-out girlfriend just converted Baptist and took out all her piercings.

View All

3 Comments

  1. As a diehard Schemer, I would be the first to demand continuations; however, implementing them does have a computational cost. Do most Ruby programmers even contemplate using continuations? or even closures? Some have called Ruby an acceptable lisp. I confess that attempts to embody lispy concepts while shying away from the use of s-expressions/prefix notation have always rubbed me wrong. I often think about how one could retain the magic of the language without the awkward syntax, but such thoughts always come with the nagging feeling that I’m trying to violate some sort of conservation law. Anyway I’ll stop here before I start subconsciously repeating Paul Graham.

    1. No, most ruby coders don’t use continuations, but on the rare occasion that they are useful they are usually the only way to achieve the desired affect. Typically that means you’re implementing some new flow of control construct. Although it’s worth noting that the Smalltalk Seaside web framework, which uses continuations to make stateless web programming act like straightforward procedural coding, got it’s start in Ruby.

      I’m not sure that I buy the “acceptable lisp” story. Perhaps for most things that most people care about. But it’s hard for me to see any language in which a) the code isn’t data, and b) there are no macros as on parity with Lisp. It’s true that you can fake most of the stuff you’d use macros for using metaprogramming tricks, but there are limits.

      I understand that there was an attempt at least once to make a true Lisp with non-sexp syntax. It was called Dylan. Unfortunately it never took off; Apple was interested in it at one time, but that was before Steve Jobs came back. I believe there is an open-source implementation available.

      1. The mention of Dylan reminds me of Paul Graham’s (actually quoting Steel and Gabriel) take on the non-sexp Lisp question.

        Graham suggested elsewhere (in one of his Arc-related writings) that such syntax should be a well-defined (and user-redefinable) “skin” on top of sexps. Possibly promising.

Comments are closed.