
An Interview with the Creator of Ruby (2001) - jpelecanos
http://www.linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html
======
kendallpark
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
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
Well, you don't need one for Python.

~~~
RussianCow
You do when your lines get too long. :)

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

~~~
jhbadger
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
> _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
> 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
I'm afraid you're right...

------
flavio81
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
_> 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
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.

~~~
jasonwatkinspdx
There are plenty of lispers in the ruby world. "Ruby is an acceptable lisp" is
a decently common saying.

While Ruby's OO is not a verbatim copy of CLOS, it is much more versatile than
you've described above. The best way to think of it is it's delegation under
the hood using a little syntax sugar to resemble classes. It's not multiple
dispatch, but methods can be aggregated into modules that can be mixed into
classes or objects arbitrarily. Dispatch is dynamic and structural (duck
typing). All of this combined with ruby's meta programming features make for
an expressive system. It's not restrictive, in fact it runs the risk of the
opposite problem, which is people over use the flexibility and write overly
magic code that proves difficult to maintain down the road.

~~~
flavio81
_> "Ruby is an acceptable lisp" is a decently common saying._

I got excited the first time I read that phrase (i think it was Matz who said
it?), but they are very very different languages; for example metaprogramming
is a piece of cake in Lisp, while it is something reserved for advanced Ruby
users, to put just one example. And for me, metaprogramming is extremely
important.

In any case, I think i'll give Ruby a second look.

~~~
eropple
I wouldn't say that metaprogramming is for "advanced Ruby users" at all, FWIW.
I find writing dynamic/"unfolding" Ruby code _much, much easier_ than
wrangling Lisp macros.

It is worth your time.

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

~~~
abstruse
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
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/)

------
tcopeland
> 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)

