David Black

Hi Sam —

If you are a Rails programmer, then you are (or purport to be :-) ) a Ruby programmer. Rails allows you to get something up and running very quickly, but if you try to develop a Rails application seriously without studying Ruby, you’ll hit the glass ceiling quickly and get frustrated.

Hi Carl —

I don’t have my finger on the pulse of most major trends, either up or down — too busy working on Rails to step back and see what the world thinks, I guess :-) But in general I think popularity always has some wobble. It could well be an ongoing process of people exploring what are and aren’t Rails’s sweet spots — that can account, I find, for a lot of the volatility in any technology’s popularity.

Hi Anna —

Very glad you’re finding the book helpful! One big change was the addition of an entirely new chapter on functional programming in Ruby. The book was brought up to date for Ruby 2.5, and lots of examples and exercises were revised or added. A lot stayed the same but the whole book got a big facelift!

Let me add my congratulations too, and many thanks to JavaRanch for inviting me here this past week and to all of you for participating!


David

Hi Tom --

For whatever reason, I've never been bothered by the ability to do things in more than one way, whether in Perl or Ruby. I kind of enjoy it :-) I did a lot of Perl for several years, and I always thought it was incredibly cool. I then fell in love with Ruby (that's the most accurate way to put it, even if somewhat non-technical) and haven't used Perl for a long time.

I think that here and there it's possible that something might be a little too sugary for my taste, or a bit line-noise-ish, or whatever. But overall, I continue to feel that Ruby has the extraordinary ability to be very concise and very clear at the same time. I've always said that the longer you work on a Ruby program, the more code disappears from the screen -- and the more clear the program becomes.

It's certainly true that you can write obscure or cryptic code in Ruby. I suppose there was a brief period when I sort of wanted to convince myself that the language simply wouldn't allow it, but that's too idealistic and definitely not true. There's never been a culture of it in Ruby (the JAPH type of thing), but it certainly can be done.

One thing I wonder about languages -- and libraries and frameworks too, as they evolve -- is the extent to which the new stuff is built on old stuff that the people who have been around a while know about, but newcomers don't, and whether that makes it harder to get up to speed. I think there are a few things like that in Ruby -- like doing this:

array.map(&:upcase)

instead of

array.map {|s| s.upcase }

The former makes sense once you know that Symbol#to_proc exists, and that & forces a call to it, and so on. But I don't think I would have wanted to learn it first.

And as a trainer and mentor, I do tend to encourage people to understand the more elemental parts of the language, rather than just learn the more composite ones and never quite get the hang of what's underneath.

Hi Michael --

My impression has always been that the main point of YARV is the gain in speed. It's definitely had an impact in at least some other areas -- for instance, ParseTree doesn't work in 1.9.1, which I know is a big issue for people who have been doing stuff that involves AST manipulation. (I don't follow that very closely but it sounds like there's progress toward coming up with a new approach that will work.)

Koichi is definitely still at work on the threading model. There's an interesting interview with Koichi on threading and GC.

I'm not sure I understand your question about 1.9 and Rails. Do you mean will Rails start taking advantage of 1.9-only features? If so, I think it will, though as far as I know Rails 3.0 will still run on 1.8 (but I could be wrong about that).

Good question about the future of Ruby. I have no answer, though :-) I think the adoption of Ruby will increase, though there will always be organizations that simply don't look at open-source alternatives at all. It also depends on where in the organization. I've always felt, for example, that Rails is really great for intra-organizational applications, and in many cases it's a lot easier to have wide latitude of tool choice for those than for the public-facing ones.

Ruby after 1.9... well, we haven't heard as much about 2.0 in the recent past as we used to, but I believe in part that's because 1.9 is probably fairly close to what 2.0 will be. At least, as far as I know, 2.0 will use YARV and so forth. I suspect that the 1.8.6 to 1.9.1 transition will be looked back on as by far the most major change in the history of Ruby up to that point.

If I could add a feature to Ruby, it would be to restore some behavior that enumerators had for a little while and then lost. At some point during 1.9.0 development, you could do this:

array = [1,2,3]
enum = array.enum_for(:map, &lambda {|x| x * 10 })
enum.next # 10
enum.next # 20
enum.next # 30

In other words, the enumerator carried inside itself not only the hookup with the object (array) and the method (map), but also a block. That is no longer the case. I exchanged some email with Shugo on ruby-core about it, and I gather it's a performance issue. I think it's really too bad, and frankly it makes enumerators a lot less interesting to me.

An enhancement to the language I would like to see is the removal of class variables. But I don't think I'm going to win that one :-) I'd also like to see :: removed as a method-calling operator (a dot synonym). I keep seeing things like:

Array::new

and I have no idea what the appeal is of it. The dot does the job just fine.

For a long time I've wanted:

class Object
def singleton_class
class << self; self; end
end
end

so then you could do:

some_object.singleton_class.class_eval ...

but I know Matz has been reluctant to add this, partly because of all the disagreement about what singleton classes should be called, and partly because he's not convinced (as I recall) that being able to grab hold of a singleton class is that important or common. Judging by how many times people end up writing that method, though, I think it would be good to have it.

I'm very glad to hear that you're enjoying Ruby and that it's rekindling your interest in programming!

Hi Orjan --

The main thing that springs to mind for me in comparing the two books is that they've got somewhat different aims. "Programming Ruby" (the "Pickaxe book") is a complete language reference (and hats off to Dave Thomas and co. for having done that the first time around and kept it up). My book is entirely devoted to exposition and explanation, and doesn't try to cover everything in the language.

The Pickaxe book, which I consider to be of the greatest importance in the history of Ruby (it was the book that really got Ruby recognized on a wide scale outside of Japan), was how I got into Ruby: I discovered the book quite by accident in a bookstore around the time it came out, in 2000, and was immediately hooked. I'm a big fan of it, though I haven't seen the third edition yet.


David

Hi Jason --

For those who don't know, it appears that why the lucky stiff, a very prolific Ruby programmer, author, and artist (hard to describe him in brief) has withdrawn from the Ruby world completely -- all his websites and projects are gone, and he himself seems to be unreachable. So that's the big news in the Ruby world today. Very mysterious.

Anyway -- I think some of the other Ruby implementations have changed Ruby in a couple of different ways. First of all, having more implementations means having a community of implementors, and that's made discussions of features and performance and version differences and so forth very lively and productive. Also, some of the people involved in alternative implementations have also put a lot of energy into things like RubySpec, which is a comprehensive test suite designed to provide a minimum level of compliance for all Ruby implementations.

People in the community who are not actually Ruby implementors have always been involved in the process of the evolution of Ruby -- which, to put it another way, really means that Matz has always been interested in what people have to say, and in discussing the features of the language and listening to ideas for changes and additions. That's one of the things I like most about the Ruby world. Admittedly it leads to some pretty sketchy ideas being proposed now and then :-) But it also makes for a very interesting and engaging on-going conversation about the language.


David

Hi --

I never learned Python in any depth (partly because I discovered Ruby, and fell in love with it, right around the same time I was tinkering with Python), but I've noticed that people say very similar things about the two languages. In fact, I remember an "Intro to Python" talk -- I think it was at OSCON -- where I literally felt like if you substituted "Python" with "Ruby", it could have been an intro to Ruby talk, just about. It was all about clean syntax, the power of the language, how it stays out of your way, how directly it translates your thoughts into code, etc.

I thought it was interesting that the commentary on the two languages, at least at the intro/overview level, was almost interchangeable.


David

Hi --

Threading is a bit of a moving target in Ruby, especially as between 1.8 and 1.9, and between MRI (Matz's Ruby Interpreter, the original/canonical version) and other implementations, JRuby in particular. JRuby makes use of Java threads, so it can do whatever Java can do, thread-wise. Ruby 1.8 had pure green threads; the whole thread system was written entirely in the interpreter, with no dependence on any underlying OS components. In 1.9, the basic 1.8 thread functionality is there, and there's also support for OS threads if they're present.

The topic that seems to come up the most with regard to Ruby threads recently is the "global VM lock" or "global interpreter lock", which is present in the 1.9 threading model and which, as I understand it, severely restricts true concurrency, because everything has to wait until that one big lock is available. If you want more info on this, and on the work that's going on toward true concurrency, here's an interview with Koichi Sasada, the main architect of YARV, the 1.9 VM.


David

Hi Razvan --

In general, at least in the original interpreter, an array is internally an array of VALUE pointers, where VALUE is the type representing Ruby objects. If you do:

str = "hi"
array = [str]

then array[0] is basically a pointer to the str object.

There are some optimizations involving handling of integers, but I'm not sure how much of a difference that makes in array handling.


David

Hi Himalay --

There's no Web development material in the book, and no Ruby/Java examples; it's all focused on the Ruby language itself. You can certainly develop standalone Web apps with Ruby, either with some of the basic tools like the CGI library or by rolling your own. There's also the Rack library, which implements a very simple spec for Web apps that make it almost trivial to write one.


David

Hi Toren --

Wow, I almost feel like if a program has run for 50 years, it should be allowed to keep running out of sheer respect :-) But I know what you mean.

I think one way to get Ruby into organizations that are skeptical about it is JRuby, which can blend nicely into the Java scenery. I'm not advocating subterfuge -- nor need it be done that way, since the claim would be that JRuby is just something that runs in the JVM, and indeed it does. I don't know whether that's relevant for your situation, though.

Another strategy is to work on a small, intra-organizational scale -- meaning, write some Ruby stuff that's flying under the radar, and find people who you think might be enthusiastic about using Ruby in ways that don't require permission, aren't public-facing, etc. It's hard to predict but at some point if Ruby develops a track-record of usage, and there's anyone in a decision-making position who's willing to look at what it's done, something could start to shift.


David

Hi Andy --

I'm not a PHP or Java programmer, so it's hard for me to comment too concretely, but I can tell you that what I love about Ruby, among other things, is how expressive it is -- expressive in the technical sense that a small amount of code can do a great deal. In my experience, the more you work on a Ruby program, the more code disappears from the screen. Moreover, as the code gets smaller, it gets clearer, not more cryptic. (I guess you can do "obfuscated" Ruby code, but that's another matter.)

I've often said that I don't think it's a coincidence that Rails is written in Ruby, because there's such a good fit between a language that has such extensive support for dynamic operations, and a framework that, in some ways, reads your mind. Ruby is great for "convention over configuration" because it's so easy to do things like intercept unknown messages, create methods on the fly at runtime, and so forth. That doesn't mean that Ruby is the only language a system like Rails could be written in, but I think it's a really great fit.


David

Hi everyone, and thanks for the welcome!

I'm very happy to be involved in this event, and I'll do my best to answer your questions and comments. I'm going to be traveling and consulting the rest of this week, so my reply sessions will probably be bunched early and/or late in the day -- but I'll definitely be here!


David