6 ms·

An Interview with the Creator of Ruby (2001)

57 points by jpelecanos 9y ago

deleted 9y ago
[deleted]
norswap 9y ago
16 years ago, but just 6 years after the language was released, and 4 years before Rails came on the scene. In retrospect, I'm not sure how successful Matz has been in upholding the principle of least surprise. In many ways, Ruby is one of the worst offenders.
- flavio81 9y ago
  >In many ways, Ruby is one of the worst offenders. Can you explain why? I'm curious.
  - weaksauce 9y ago
    The powerful metaprogramming features get used to make dsls and also make it harder to know what methods are available or built in or what gem added them in. I love the language and it's a joy to program in but it's not without fault. Also, there are many ways to do something so you need to know multiple ways. I don't find it particularly hard to program in once you get used to a few paradigms though.
  - norswap 9y ago
    I actually have a whole series of posts up: http://norswap.com/ruby-dark-corners/ http://norswap.com/ruby-dark-corners/ The three topics (module linearization, scope lookups and method parameters) are constant source of wtfs as soon as you go beyond something basic.
- jhbadger 9y ago
  Compared to what, though? I really like how everything is a method in Ruby as compared to, say, Python where it seems completely random if something is or isn't -- for example, I have to constantly remember that to get a length of an array in Python I have to do len(x) rather than x.len(). Although I like what Rust and Nim are doing with making the method/function distinction irrelevant -- there, x.f() is just syntactic sugar for f(x) -- so you can use whichever you prefer.
  - flavio81 9y ago
    >I have to constantly remember that to get a length of an array in Python I have to do len(x) rather than x.len() On the other hand, in Python lists, tuples and arrays are fundamental data types and thus len() is defined as a fundamental built-in function. I think it makes sense. What i didn't like was when map() and reduce() were moved away from the basic functions.
    - bhaak 9y ago
      > On the other hand, in Python lists, tuples and arrays are fundamental data types and thus len() is defined as a fundamental built-in function. I think it makes sense. But len() is only a fundamental built-in function for fundamental data types and you can implement it on any class by implementing the method __len__(self). For those it doesn't make sense any longer to be able to do len(x).
      - flavio81 9y ago
        I'm afraid you're right...
  - steveklabnik 9y ago
    Small note about Rust; you're not 100% right. For example, method syntax will do auto ref/deref on the reciever, for most methods, it'd be f(&x), not f(x), though if f took self by value, it would be! It is true that you can invoke it either way if it's a method, but you cannot if it's a function, as well.
  - norswap 9y ago
    Compared to most everything (PHP is probably worse, and there might some that I don't know). I'm not saying it's surprising because it's different, rather it's surprising because it doesn't seem to be very internally consistent. Lots of complicated rules instead of a few simple ones. As I pointed out in another comment, the way lookup is handled for instance is really a clusterfuck (http://norswap.com/ruby-lookups-scopes/ http://norswap.com/ruby-lookups-scopes/) Other OO languages like Java or Smalltalk (the more direct Ruby inspiration) do much better in this regard of having simple rules for lookup (and other things).
- steveklabnik 9y ago
  Matz has also maintained that it's the principle of his least surprise. You can't be not-surprising to every single possible person.
  - ksec 9y ago
    Matz also mentioned Ruby is no longer his project.
- griffinmb 9y ago
  In general, I think Ruby does a good job of being unsurprising. I like that most things work as I'd expect, with the syntax I'd expect. But then you've got weird things like `File.read("|ls")` that are entirely surprising.
- goatlover 9y ago
  I don't see why it's one of the worst offenders. I always found that it made more sense that PHP and Javascript, and was a bit more consistent than Python and Java. What is your standard for non-offender? Certainly not C++ or Common Lisp. Scheme, Smalltalk, Go?
  - norswap 9y ago
    PHP worse from what I've seen. JS I would say better. Most of what people complain about are wonky implicit conversions -- easily avoided. The retro-fitting of classes onto the prototype is not super elegant (the "Javascript: The Good Parts" approach is better), but can be readily understand with a good explanation and a schematic (1). C++ is probably an offender but for other reasons. My experience is limited, but from I've seen it's mostly vast But when you look at each feature they're not incredibly unintuitive. A huge problem in C++ is that there many ways to do everything (the old way and the new way and the new better way, all which have slightly different semantics). Common Lisp is also vast but seems really solid on its foundations. Scheme, Smalltalk and Go, definitely better. Lua. Java as well excepted maybe the really fine points of generics (captures) -- but in practice understanding that is almost never needed. C, unless you count undefined behavior as against least surprise, then it fails. Python I'm really not practiced enough to tell. All in all, we're probably not using the same criteria for least surprise. I'm not even considering libraries, just baked in language features, and being able to predict what they do. In that sense, Ruby is really much worse than Java. It's really bizarre (see my blog posts in the other comments). And the problem is made worse by the fact that all that weird behavior is not documented anywhere. (1) e.g. https://drive.google.com/file/d/0B0O9lcl5dMLQbDFkYk1kX28xM1U/view?usp=sharing https://drive.google.com/file/d/0B0O9lcl5dMLQbDFkYk1kX28xM1U...
sunseb 9y ago
Is there still some new features coming to Ruby? It seems the language is not this cutting edge technology it was once. I mean we see more changes in Java and PHP than Ruby these days.
- rurounijones 9y ago
  It is largely a mature language and the inherent flexibility of the language means that a lot of things that require new language level constructs in other languages like Java aren't needed here. The interesting stuff is happening in the runtimes (See TruffleRuby https://github.com/graalvm/truffleruby https://github.com/graalvm/truffleruby )
- tcopeland 9y ago
  Yes, although many changes are performance optimizations and other under-the-covers sorts of things. Here are the changes for 2.5 which if tradition holds will be out on Christmas: https://www.ruby-lang.org/en/news/2017/10/10/ruby-2-5-0-preview1-released/ https://www.ruby-lang.org/en/news/2017/10/10/ruby-2-5-0-prev...
- abstruse 9y ago
  What new features does Ruby need? Why does a language need to be "cutting edge technology"? What are the issues with Ruby that need changing? These aren't rhetorical questions, I don't know much about Ruby and am genuinely curious.
  - pmontra 9y ago
    They're adding a kind of pipeline operator (actually a method) http://mlomnicki.com/yield-self-in-ruby-25/ http://mlomnicki.com/yield-self-in-ruby-25/
- bridge_ro 9y ago
  Along with what other people already responded, I think they're also pretty focused on the Ruby 3x3 project (making Ruby version 3 be three times faster), which may be slowing down the general heap of new features Rubyists were used to.
tcopeland 9y ago
> I'm planning a full rewrite of the interpreter for Ruby 2.0 [...] It will use a bytecode engine. And so it did! https://en.wikipedia.org/wiki/YARV https://en.wikipedia.org/wiki/YARV
flavio81 9y ago
I always get tempted to switch to Ruby * whenever i remember that Matz intended to make programmers happy. However, I don't think i'd feel comfortable with a language that only allows object-oriented programming, and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) Additionally, the MRI is perhaps the slowest implementation of a dynamic language out there (besides "R"). I know there are alternative implementations; is there any implementation that is significantly faster (at least as fast as Google V8 for ECMAScript) and that supports the full Ruby language without compatibility issues? * in place of Python
- smitherfield 9y ago
  > However, I don't think i'd feel comfortable with a language that only allows object-oriented programming Ruby is multi-paradigm; in particular it's easily the most "functional"-feeling of the major scripting languages. > and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) I'm unsure what you mean by this. Ruby has one of the most flexible OOP systems in existence, a good deal more flexible than Python's, and lets you create more or less any conceivable relationship between methods and objects. (Which is why Ruby is slow). > Additionally, the MRI is perhaps the slowest implementation of a dynamic language out there (besides "R"). I know there are alternative implementations; is there any implementation that is significantly faster (at least as fast as Google V8 for ECMAScript) and that supports the full Ruby language without compatibility issues? Ruby's not fast, but it's improved quite a bit from the 1.8 days. It's comparable to Python. As for high-performance alternative implementations, there's TruffleRuby,[1] but it still has compatibility issues and isn't ready for production use. There's also Crystal,[2] which is a very similar (but incompatible) compiled language with performance on par with Go/Java/Swift. It's also still in beta but they plan to have a 1.0 release by the end of the year. [1] https://github.com/graalvm/truffleruby https://github.com/graalvm/truffleruby [2] https://crystal-lang.org https://crystal-lang.org
  - flavio81 9y ago
    First of all, thank you very much for your informative reply on the implementations. >I'm unsure what you mean by this. I believe that any OOP system that wants to be flexible, modern, and powerful, should have most of the features that CLOS (Common Lisp Object System) has. Julia (language) did, for example. It would be lengthy to explain all the features and benefits of CLOS here, but in CLOS, methods are not tied to objects, and all methods do multiple-dispatch. This also allows doing OOP in a functional-like way (this is easier to understand once you see how CLOS works.) In comparison, most other OOP systems feel limited and restrictive, and very different from CLOS. >a good deal more flexible than Python's Probably, but OTOH Python's OOP system is perhaps one of the weakest OOP systems out there, and speaking from my 2 years of professional experience with Python. I find it acceptable, but not good.
kendallpark 9y ago
I had to learn Ruby when I got a job as a full stack dev. Before then I mostly used Python and Java. To date I have not found a language that I love more than Ruby. It's a delight to use. I truely enjoy coding in Ruby, whereas I'm usually some flavor of neutral with most other languages (except PHP... blah). Perhaps there are some people that are on the same wavelength as Matz. One thing I found interesting is that when surveying whitespace of Github repos, 100% of Ruby repos surveyed had 2 spaces for indentation. Looking down that list, I wonder why some languages have more conformity of indentation style (other than frameworks helping enforce styles). Perhaps certain languages attract certain types of developers or help foster a particular culture? https://ukupat.github.io/tabs-or-spaces/ https://ukupat.github.io/tabs-or-spaces/
- forgot-my-pw 9y ago
  Wish all languages comes with a fmt tool that will end all stylistic guide debates. We use linters at work, but even setting linter rules will cause a lot of arguments.
  - goatlover 9y ago
    Well, you don't need one for Python.
    - RussianCow 9y ago
      You do when your lines get too long. :)
- AcerbicZero 9y ago
  I came to Ruby from a different direction, working on Puppet/Chef and VMware/NSX, but I came to a similar conclusion. I'd always assumed the reason I liked it so much was because I wasn't a programmer. The language operates generally as expected (to someone without a real coding background) as well as being so much more flexible and powerful than the other options available. Since then I've done a little rails work, learned enough Python to be moderately useful, and stumbled through a few other languages. I still try to be impartial, and to use the best tool for the job, but it's always a joy when I find a chance to use Ruby again.

57 points by jpelecanos 9y ago

deleted 9y ago

[deleted]

16 years ago, but just 6 years after the language was released, and 4 years before Rails came on the scene. In retrospect, I'm not sure how successful Matz has been in upholding the principle of least surprise. In many ways, Ruby is one of the worst offenders.

flavio81 9y ago
>In many ways, Ruby is one of the worst offenders. Can you explain why? I'm curious.
- weaksauce 9y ago
  The powerful metaprogramming features get used to make dsls and also make it harder to know what methods are available or built in or what gem added them in. I love the language and it's a joy to program in but it's not without fault. Also, there are many ways to do something so you need to know multiple ways. I don't find it particularly hard to program in once you get used to a few paradigms though.
- norswap 9y ago
  I actually have a whole series of posts up: http://norswap.com/ruby-dark-corners/ http://norswap.com/ruby-dark-corners/ The three topics (module linearization, scope lookups and method parameters) are constant source of wtfs as soon as you go beyond something basic.
jhbadger 9y ago
Compared to what, though? I really like how everything is a method in Ruby as compared to, say, Python where it seems completely random if something is or isn't -- for example, I have to constantly remember that to get a length of an array in Python I have to do len(x) rather than x.len(). Although I like what Rust and Nim are doing with making the method/function distinction irrelevant -- there, x.f() is just syntactic sugar for f(x) -- so you can use whichever you prefer.
- flavio81 9y ago
  >I have to constantly remember that to get a length of an array in Python I have to do len(x) rather than x.len() On the other hand, in Python lists, tuples and arrays are fundamental data types and thus len() is defined as a fundamental built-in function. I think it makes sense. What i didn't like was when map() and reduce() were moved away from the basic functions.
  - bhaak 9y ago
    > On the other hand, in Python lists, tuples and arrays are fundamental data types and thus len() is defined as a fundamental built-in function. I think it makes sense. But len() is only a fundamental built-in function for fundamental data types and you can implement it on any class by implementing the method __len__(self). For those it doesn't make sense any longer to be able to do len(x).
    - flavio81 9y ago
      I'm afraid you're right...
- steveklabnik 9y ago
  Small note about Rust; you're not 100% right. For example, method syntax will do auto ref/deref on the reciever, for most methods, it'd be f(&x), not f(x), though if f took self by value, it would be! It is true that you can invoke it either way if it's a method, but you cannot if it's a function, as well.
- norswap 9y ago
  Compared to most everything (PHP is probably worse, and there might some that I don't know). I'm not saying it's surprising because it's different, rather it's surprising because it doesn't seem to be very internally consistent. Lots of complicated rules instead of a few simple ones. As I pointed out in another comment, the way lookup is handled for instance is really a clusterfuck (http://norswap.com/ruby-lookups-scopes/ http://norswap.com/ruby-lookups-scopes/) Other OO languages like Java or Smalltalk (the more direct Ruby inspiration) do much better in this regard of having simple rules for lookup (and other things).
steveklabnik 9y ago
Matz has also maintained that it's the principle of his least surprise. You can't be not-surprising to every single possible person.
- ksec 9y ago
  Matz also mentioned Ruby is no longer his project.
griffinmb 9y ago
In general, I think Ruby does a good job of being unsurprising. I like that most things work as I'd expect, with the syntax I'd expect. But then you've got weird things like `File.read("|ls")` that are entirely surprising.
goatlover 9y ago
I don't see why it's one of the worst offenders. I always found that it made more sense that PHP and Javascript, and was a bit more consistent than Python and Java. What is your standard for non-offender? Certainly not C++ or Common Lisp. Scheme, Smalltalk, Go?
- norswap 9y ago
  PHP worse from what I've seen. JS I would say better. Most of what people complain about are wonky implicit conversions -- easily avoided. The retro-fitting of classes onto the prototype is not super elegant (the "Javascript: The Good Parts" approach is better), but can be readily understand with a good explanation and a schematic (1). C++ is probably an offender but for other reasons. My experience is limited, but from I've seen it's mostly vast But when you look at each feature they're not incredibly unintuitive. A huge problem in C++ is that there many ways to do everything (the old way and the new way and the new better way, all which have slightly different semantics). Common Lisp is also vast but seems really solid on its foundations. Scheme, Smalltalk and Go, definitely better. Lua. Java as well excepted maybe the really fine points of generics (captures) -- but in practice understanding that is almost never needed. C, unless you count undefined behavior as against least surprise, then it fails. Python I'm really not practiced enough to tell. All in all, we're probably not using the same criteria for least surprise. I'm not even considering libraries, just baked in language features, and being able to predict what they do. In that sense, Ruby is really much worse than Java. It's really bizarre (see my blog posts in the other comments). And the problem is made worse by the fact that all that weird behavior is not documented anywhere. (1) e.g. https://drive.google.com/file/d/0B0O9lcl5dMLQbDFkYk1kX28xM1U/view?usp=sharing https://drive.google.com/file/d/0B0O9lcl5dMLQbDFkYk1kX28xM1U...

sunseb 9y ago

Is there still some new features coming to Ruby? It seems the language is not this cutting edge technology it was once. I mean we see more changes in Java and PHP than Ruby these days.

rurounijones 9y ago
It is largely a mature language and the inherent flexibility of the language means that a lot of things that require new language level constructs in other languages like Java aren't needed here. The interesting stuff is happening in the runtimes (See TruffleRuby https://github.com/graalvm/truffleruby https://github.com/graalvm/truffleruby )
tcopeland 9y ago
Yes, although many changes are performance optimizations and other under-the-covers sorts of things. Here are the changes for 2.5 which if tradition holds will be out on Christmas: https://www.ruby-lang.org/en/news/2017/10/10/ruby-2-5-0-preview1-released/ https://www.ruby-lang.org/en/news/2017/10/10/ruby-2-5-0-prev...
abstruse 9y ago
What new features does Ruby need? Why does a language need to be "cutting edge technology"? What are the issues with Ruby that need changing? These aren't rhetorical questions, I don't know much about Ruby and am genuinely curious.
- pmontra 9y ago
  They're adding a kind of pipeline operator (actually a method) http://mlomnicki.com/yield-self-in-ruby-25/ http://mlomnicki.com/yield-self-in-ruby-25/
bridge_ro 9y ago
Along with what other people already responded, I think they're also pretty focused on the Ruby 3x3 project (making Ruby version 3 be three times faster), which may be slowing down the general heap of new features Rubyists were used to.

tcopeland 9y ago

> I'm planning a full rewrite of the interpreter for Ruby 2.0 [...] It will use a bytecode engine. And so it did! https://en.wikipedia.org/wiki/YARV https://en.wikipedia.org/wiki/YARV

flavio81 9y ago

I always get tempted to switch to Ruby * whenever i remember that Matz intended to make programmers happy. However, I don't think i'd feel comfortable with a language that only allows object-oriented programming, and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) Additionally, the MRI is perhaps the slowest implementation of a dynamic language out there (besides "R"). I know there are alternative implementations; is there any implementation that is significantly faster (at least as fast as Google V8 for ECMAScript) and that supports the full Ruby language without compatibility issues? * in place of Python

smitherfield 9y ago
> However, I don't think i'd feel comfortable with a language that only allows object-oriented programming Ruby is multi-paradigm; in particular it's easily the most "functional"-feeling of the major scripting languages. > and moreover OOP of the old way (a method must be tied to only one object. This is what prevents me from going to Smalltalk, btw.) I'm unsure what you mean by this. Ruby has one of the most flexible OOP systems in existence, a good deal more flexible than Python's, and lets you create more or less any conceivable relationship between methods and objects. (Which is why Ruby is slow). > Additionally, the MRI is perhaps the slowest implementation of a dynamic language out there (besides "R"). I know there are alternative implementations; is there any implementation that is significantly faster (at least as fast as Google V8 for ECMAScript) and that supports the full Ruby language without compatibility issues? Ruby's not fast, but it's improved quite a bit from the 1.8 days. It's comparable to Python. As for high-performance alternative implementations, there's TruffleRuby,[1] but it still has compatibility issues and isn't ready for production use. There's also Crystal,[2] which is a very similar (but incompatible) compiled language with performance on par with Go/Java/Swift. It's also still in beta but they plan to have a 1.0 release by the end of the year. [1] https://github.com/graalvm/truffleruby https://github.com/graalvm/truffleruby [2] https://crystal-lang.org https://crystal-lang.org
- flavio81 9y ago
  First of all, thank you very much for your informative reply on the implementations. >I'm unsure what you mean by this. I believe that any OOP system that wants to be flexible, modern, and powerful, should have most of the features that CLOS (Common Lisp Object System) has. Julia (language) did, for example. It would be lengthy to explain all the features and benefits of CLOS here, but in CLOS, methods are not tied to objects, and all methods do multiple-dispatch. This also allows doing OOP in a functional-like way (this is easier to understand once you see how CLOS works.) In comparison, most other OOP systems feel limited and restrictive, and very different from CLOS. >a good deal more flexible than Python's Probably, but OTOH Python's OOP system is perhaps one of the weakest OOP systems out there, and speaking from my 2 years of professional experience with Python. I find it acceptable, but not good.

kendallpark 9y ago

I had to learn Ruby when I got a job as a full stack dev. Before then I mostly used Python and Java. To date I have not found a language that I love more than Ruby. It's a delight to use. I truely enjoy coding in Ruby, whereas I'm usually some flavor of neutral with most other languages (except PHP... blah). Perhaps there are some people that are on the same wavelength as Matz. One thing I found interesting is that when surveying whitespace of Github repos, 100% of Ruby repos surveyed had 2 spaces for indentation. Looking down that list, I wonder why some languages have more conformity of indentation style (other than frameworks helping enforce styles). Perhaps certain languages attract certain types of developers or help foster a particular culture? https://ukupat.github.io/tabs-or-spaces/ https://ukupat.github.io/tabs-or-spaces/

forgot-my-pw 9y ago
Wish all languages comes with a fmt tool that will end all stylistic guide debates. We use linters at work, but even setting linter rules will cause a lot of arguments.
- goatlover 9y ago
  Well, you don't need one for Python.
  - RussianCow 9y ago
    You do when your lines get too long. :)
AcerbicZero 9y ago
I came to Ruby from a different direction, working on Puppet/Chef and VMware/NSX, but I came to a similar conclusion. I'd always assumed the reason I liked it so much was because I wasn't a programmer. The language operates generally as expected (to someone without a real coding background) as well as being so much more flexible and powerful than the other options available. Since then I've done a little rails work, learned enough Python to be moderately useful, and stumbled through a few other languages. I still try to be impartial, and to use the best tool for the job, but it's always a joy when I find a chance to use Ruby again.