02:16 - Brian Shirai Introduction

• Formerly known as Brian Ford
• RR 017: What’s Wrong with Ruby?
• RubySpec
• Rubinius
• Engine Yard 05:05 - Ruby’s Design Process

Ruby Conf 12 - Toward a Design for Ruby by Brian Ford

jRuby

MagLev

IronRuby

• JSConf2012 - Brian Ford: Is Node.js Better? 09:55 - Implementations
• Ruby MRI (Matz’s Ruby Interpreter) 11:25 - What does a dying language look like?
• Smalltalk
• Squeak 14:16 - Changing the Ruby Process
• Fragmentation
• m17n (multilingualization) 19:15 - Ruby’s Design Process (cont’d)

Ruby Conf 12 - Toward a Design for Ruby by Brian Ford

A Ruby Design Process: Brian Shirai

A Ruby Design Process - Talking Points: Brian Shirai

RubySpec: A Ruby Design Process (Summary)

People the missing ingredient: Joe O’Brien 25:13 - Point 1: Forming a Council 28:25 - Point 2: Proposing a Change

• Yukihiro Matsumoto (Matz)
• Joe Damato 36:31 - Point 3: Proposal Criteria
• RubySpec
• @brixen 46:43 - Point 4: Accepting/Rejecting Proposals
• Consensus
• Fork

Fist-to-Five Consensus-Building

Refinements

• Developers Meeting

Rails is omakase: David Heinemeier Hansson

A bug thread including Matz's response 01:12:11 - Point 5: Implementing the Proposal 01:18:04 - Point 6: Discussing the Feature 01:27:51 - Point 7: Voting on the Proposed Change

• Challenging Matz
• Power
• Brian followup
• Robert's Rules
• Communication

Book Club

Patterns of Enterprise Application Architecture by Martin Fowler: Read along with us! We will be discussing the book with Martin himself and the episode will air on Wednesday, March 20th, 2013.

Next Week

Picksplosion!

Transcript

DAVID:  Your Facebook status is still ‘It's Complicated’, isn't it?[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]**[This podcast is sponsored by New Relic. To track and optimize your application performance, go to RubyRogues.com/NewRelic.] **CHUCK:  Hey everybody, and welcome to Episode 91 of the Ruby Rogues podcast. This week on our panel, we have James Edward Gray. JAMES:  Hello everyone. CHUCK:  Josh Susser. JOSH:  Hey, good morning. CHUCK:  David Brady. DAVID:  Hello from the frozen tundra of Utah. CHUCK:  Katrina Owen. KATRINA:  Hello from the slushy not so much tundra of Oslo. CHUCK:  I'm Charles Max Wood from DevChat.tv. Before we get going too much, I did want to make a quick announcement on my own behalf. I'm going to be teaching a Ruby on Rails Course, in a couple, in like four weeks, in a month. It's going to start March 6^th. I know not everybody is terribly interested in this because we have a lot of competent Rails developers. But I keep getting requests for coaching based on the podcasts. So, I just wanted to let the folks know who want to learn Rails from me that you can go sign up at RailsRampUp.com. The in-person courses cost around $2000 and sometimes you have to travel to those. And what I'm providing is it’s an online thing. So, you don't have to pay for travel. The course is $1200, but if you put in the code ‘podcast’, you can get it for $1000. You get eight weeks basically of webinar-type training. So it’s in-person, well, not in-person. It’s online training. You get mentorship from me as much as you need, online forums, so you can collaborate with other people, and you get your copies of the video when it’s all said and done. Which means you can go back and replay the lessons. So, if you're interested in that, then go to RailsRampUp.com and sign up. DAVID:  Chuck, I am worried that you're wasting peoples' time. This is the ‘Everybody Already Knows Ruby Rogues’ podcast. So, I wanted to remind you. [Laughter] JOSH:  Okay, okay. We have plenty of listeners who are not Ruby developers. [Laughter] JOSH:   And we love them too. CHUCK:  Yup. JOSH:  We love all our listeners equally. JAMES:  And we also love our guest. CHUCK:  We do. We have a guest. And this is Brian Shirai, formerly known as Brian Ford. He's been on the show before. But why don't you introduce yourself again, Brian. BRIAN:  Hey! Greetings from rainy Portland, Oregon. Yeah. So, most people know me from my work on either RubySpec or Rubinius. Rubinius is a Ruby implementation. And Evan created that in 2006. And I've been working on it almost since the day he announced it. RubySpec is a project to create an executable implement -- or sorry executable specification for the Ruby programming language describing all those great things that Ruby does. JOSH:  So Brian, I have a question about the Rubinius team. Is there some agreement that you all made that when the men who work on Rubinius get married, they change their name? BRIAN:  That's a really good question. So, yeah. So, Evan changed his name. Evan and Abby, they actually picked a new last name together. I just really hated my last name for my entire life. So, I was happy to change it. JOSH:  There we go. So what keeps you more busy, Rubinius or RubySpec? BRIAN:  Well, they go together, like sort of hand and glove. We write RubySpec for everything that we add to Rubinius that is Ruby related as much as we can. There are certain internal VM things that we have some C++ tests for. It’s really a lot of back and forth between the two. But definitely there is -- I think there are -- now that we've been working on RubySpec for so long, we have about somewhere around 45,000 examples for 1.9. So now, a lot of work is just focused on compatibility with Rubinius. But we discovered new areas that aren't covered in RubySpec pretty much everyday. So, it’s still a lot of shared effort between the two. DAVID:  How long does it take the test suite to run? Just out of curiosity. BRIAN:  Well, we run -- in 1.8 mode, we run in about 130 seconds. And 1.9, because we have a bunch of process and spawn specs that altogether take about 30 seconds to run. The total run time for 1.9 gets up around, I think around 220 or something seconds. DAVID:  All the people out there with 200 tests that take 14 minutes to run, I hope you heard that. That is freaking awesome. CHUCK:  Four minutes on 1.9. DAVID:  Four minutes for 43,000? How many thousands? BRIAN:  Well, there’s about 45,000 examples, there’s about a 150,000 expectations. DAVID:  That is awesome. Make your tests faster, kids. CHUCK:  [Laughs] No kidding. JAMES:  So Brian, we asked you here today because there’s been a lot of discussion in the Ruby community lately about Ruby’s design process. And I think that was pretty much kicked off by your Ruby Conf talk at the end of last year where you kind of laid out some problems that you see and their impact. And I was wondering if maybe you can tell us a little about that. BRIAN:  Sure. So, the very short version is that we’ve been writing RubySpec since 2006. That’s quite a long time and we’ve written lots and lots and lots of RubySpec. And in the process, we’ve discovered a lot of areas of Ruby that are difficult for different implementations. So once upon a time, Ruby only had one implementation. And so, the semantics of the language are defined by the implementation and it’s really easy, if you’re the only one doing this, for things to get in there by accident. And also, when we first started RubySpec or what was to be RubySpec, it was just a spec suite in Rubinius. When we started that, there were not a great number of tests. There were a couple projects, there was a Ruby test project, there was a test in MRI, but there were not a great number of tests. There was not a lot of awareness of how complex Ruby was. Many people knew it was a big language and a complex language. But there are so many subtle and oftentimes very confusing aspects of Ruby behavior that, I want to say they were mostly just taken for granted. But honestly, I think many people did not even know them. I think I wrote one time about a 40-line file where each line was one example of how an argument passed to a block would be processed in 1.8. And there was something like 40-some cases, I think. So over time, as we implemented more and more of Ruby and more and more of RubySpec, certainly as other implementations like jRuby and MagLev and Iron Ruby made progress, it became apparent that it would be helpful if there was a way for us to discuss things that were perhaps challenges across implementations. Or at least, have a more precise definition or figure out a way that things, that might be implementation or platform specific like fork, could be described in a way that they are not excluding other implementations whose platforms don’t allow that functionality. In the old days, it was just Windows versus Linux or UNIX, right? Then it became much more complicated. We had a Smalltalk Environment, we had a JVM Environment, CLR, DLR Environment. So at one point a while ago, we actually did have some Ruby design meetings. We got on IRC and we chatted about some stuff. We did that a few times and then they fell off. And then after years of working on this -- and one other thing that I think is really important, we might want to touch on in more detail. But after seeing repeatedly people move -- first it was Erlang. When Erlang came in, the Ruby community people were super excited and they started doing Erlang, primarily for concurrency. And then Closure started becoming big and people were really excited. And one of things that people often said about going to Closure is concurrency and data structures. And then Node.js got really big and I gave a talk, ‘Is Node.js better?’ where I was looking at, why do I see Ruby people leaving Ruby for Node.js? And then there’s Scala. So that concern along with the complexity of implementing Ruby and the work we did on RubySpec started to make me very concerned about Ruby. Then I had a conversation with someone who was doing an implementation of Ruby that’s not yet public yet, and he said to me something that really made me pause. He said, “You know, I’ve often wondered what a dying Open Source project looks like?” And I responded to him and I said, “Well, I’m wondering what a dying language looks like?” And there’s no good guide for that sort of thing. And so, that got me to propose the talk for Ruby Conf. And I wasn’t sure it would be accepted because it sounded pretty controversial, but it was. And so ultimately, I came to the point of giving that talk through those things I’ve described. We can talk about the talk more but that’s why I gave the talk. It’s out of a great deal of love for Ruby and the people that I know in Ruby and the things that I’ve seen done in Ruby, and a great deal of concern about the well being of the language and the people who use the language. CHUCK:  I want to ask a really quick question because a lot of what you’re saying is kind of focused more around the implementers and implementations. Concurrency is something that I think we would all like to see Ruby and MRI in particular handle better. But besides that, I mean, what’s the trade off for the users of the language, just the lay developer that’s not an implementation person? Why do we care if some of these things are hard to implement in the other implementations, especially if we may or may not be using them? BRIAN:  Well, the reason that people may care is because they might be on one of those platforms and they may really love Ruby and they might not have the opportunity to use it. So, if jRuby has a lot of specific things that the JVM -- it has a lot of features that it provides, but it has things that are limitations relative to MRI. And so, if those features are important but they’re not available, and you're sort of constrained to that platform for whatever reason - it might be the only thing available at your work and you want to explore Ruby, your opportunities might be very limited. So, my great concern over the unity of the Ruby language and the ability of developers to use it is because I think Ruby is a fantastic language. And I would like to see everybody who wants to use it be able to use it. CHUCK:  I can see that. JOSH:  So Brian, I just have a little tangent off of something you said a moment ago. When you said, “What does a dying language look like?” And everyone knows I used to do Smalltalk. And Smalltalk was a dying language for a while. And it was starting to fade into irrelevance in, I guess, probably the 90’s. And then, the Squeak project came along and I think it breathed a lot of new life into Smalltalk and so, there’s still people doing Smalltalk today. BRIAN:  Squeak was the first Open Source for Smalltalk, wasn’t it? JOSH:  Oh, yeah. BRIAN:  So, would you say that Open Source saved a dying language there? JOSH:  I think that was part of it. I don’t think it was just that it was Open Source, although I’m sure that was a significant part of it. But it was that it made Smalltalk accessible in a whole new way, not just because it was Open Source but because Squeak made all of the tools that you needed to create a new Smalltalk available right there in Smalltalk itself. Smalltalk has always been a self-hosted language, with a very small kernel to do and then most of the language was written in Smalltalk itself. But then Squeak turned it into, not just the stuff written in Smalltalk was written in Smalltalk but even the kernel of the language, the VM could be written in Smalltalk. BRIAN:  Self-hosting language. Okay, yeah. JOSH:  So, it just took the Smalltalk idea and pushed it sort of to the ultimate level that you could manage. And that gave people a lot of interest in playing with it and it just made it more accessible in new ways. But my point is that Smalltalk was, I think, on the road to ruin. It was doing the slow fade and the Squeak project brought it back from oblivion. It’s never dominated the way that many of us would have liked to have seen but it still has some vitality left in it. Anyway, that’s just a little side bar on that. BRIAN:  Well, I think it’s a great point, Josh. But at the same time, like I demonstrated in my talk, in 2006, there were a tiny handful of us being paid to write Ruby. And now at a Ruby Conf or a Rails Conf, everyone’s paid to write Ruby. And if we were to look at people who wanted to be paid to write in Smalltalk and the number of people who actually are, I think the disparity, the ratio there would be pretty great. While Ruby won’t disappear, the number of people who are paid to write Ruby now compared to before and the number of people -- I’ve never met someone who said, “You know, I’m forced to write Ruby everyday and I hate it. I sure wish I could write in X language.” And so, while I think you make a great point, I’m just concerned that I don’t want people to add that to the reasons not to care about this issue. I don’t think that Ruby will go away but that doesn’t mean that people will be paid to write it. CHUCK:  I have a question for you. Do you think that there's a chance maybe that if Ruby and some of these implementations diverge one way or another that that might be something that saves Ruby or changes the way that Ruby works or changes the way the process works? BRIAN:  It’s possible. But my concern there is that we have historical references, right? We can look at Smalltalk, we can look at Lisp, and I don’t think that -- when we want to talk about developer pain, if you’ve ever had to port something from one platform to another, you spend a great deal of time and the feeling. I’ve done this, I’ve ported from Windows to Linux, I’ve ported from Linux to Windows, I’ve ported between different operating systems that were supposed to be very similar, the feeling that you get after doing all of that work is, “I’ve wasted a lot of time for no good reason, really.” It’s like, “Now, I’m back to where I started, it’s just on a different platform.” And so, I feel like if we allow Ruby to fragment, maybe it will flourish in certain areas but I think that it’s a big black mark against the language. We already have a lot of black marks, this dynamic language that doesn’t care about safety supposedly. If we throw types in there, we could be a safe dynamic language or something. JOSH:  Are you trolling us? [Laughter] BRIAN:  No, I am totally not trolling you. Believe me, I’ve heard pretty much every proposal for the things that would fix Ruby. But one of the possibilities is that Ruby will fragment. But my work from the very beginning -- I kid you not, if only Rubinius channel on IRC had a transcript, the first question I asked Wilson Bilkovich when I entered that channel was, “Are you guys planning on making an implementation that is compatible with MRI or are you planning on changing the language?” Wilson was like, “No, we’re going to be exactly what MRI does.” And I was like, “Cool. I’m in.” So, I don’t want to see the language fragment. Could it be good? I think only in a very limited way in that it might thrive in some particular domain but it would be bad for the language in general. Bad for the people who look at it and say, “Why should I pay my developers to write in this language?” JOSH:  I think some languages’ fragmentation or from a geneticist’s perspective, adaptive radiation can be advantageous because it gives you access to different communities of developers. Smalltalk went through this fragmentation where it went from Smalltalk 8 that ran only on Xerox machines. And then, they got alternate implementations including Smalltalk V which was a variant that ran on -- it had two different variants that would run on Windows and Mac and they were mostly the same, but there were some porting issues. But I think that that let Smalltalk reach many more people and then eventually it sort of coalesced into one dominant player and a few other small players. But I think that Ruby is much more mature and there are many, many more users out there. So, I don’t think there’s an advantage in fragmentation to try and reach more people, is what I'm saying. BRIAN:  I also think that Ruby is a very, very complex language. And so, the incompatibilities that we could get would make the effort to port between things even more difficult than other languages. JOSH:  I could see that, yes. JAMES:  So, just to kind of speak to that a little bit. Brian’s talking about, how does this affect us lay developers? When m17n was introduced into Ruby, it was right about the same time that faster CSV replaced the old CSV library. So, I had to go in and put the new CSV library in there. And in doing so, I had to make it m17n savvy so it worked with the new encoding engine, and m17n standing for multilingualization, of course. In doing that, I was working with a system that was still very new and fresh and really complicated and not well-documented at all. And so, there were like a few people that understood how it worked and I had to ask them some questions and kind of reverse engineer some things with some tests and figure out how all that works. The processes that I found it was a very complex system and it still had bugs, obviously and I flushed several of those in writing the initial CSV implementation. We found a lot of those cases and they actually had to fix stuff just so we could get it working. So yeah, it does actually affect us. CHUCK:  Right. I kind of want to move along a little bit and talk about this proposal that you made. You kind of did it in your talk, and we’ll put a link to the talk in the show notes. But we also have a link that we’ll put in the show notes to your proposal for the Ruby design process. Do you want to just talk briefly about what the points are? And more interesting to me is what problems they are trying to solve because we’ve talked about some of them, but not all of them. BRIAN:  Sure. The summary is up at RubySpec.org/design and it has links to some other information, other implementations and my talk, and stuff like that. The reason I put this up as a bullet point thing was to try to be as concise as possible, but that’s challenging in communicating. So, one thing that I would point out is that this is -- let me quote Evan. He said one time and I’m sure he’s not the only one to say this, “Most problems in technology are people problems,” which is not to say that people are problems. But that most things that we struggle with in technology have nothing to do with technology but more with the way we are interacting with people, or the communication or the emotional involvement and stuff like that. So, being very concise is not necessarily an advantage in trying to communicate something that is emotional and really touches people deeply because they care about Ruby. JOSH:  That’s a great point, Brian. I just want to put a footnote in here and recommend that people watch Joe O’Brien’s ‘People Patterns’ talk. He’s done it a couple of places and there’s videos of it all over. We’ll put one in the show notes. I know he did it at GoGaRuCo last year too, but he also did it at Steel City and a couple other places. And that just totally speaks to what you’re talking about. And he even says that quote of, “Never seen a project fail for technical reasons, it’s always the people reasons.” So, continue. BRIAN:  That’s great. I haven’t actually seen that talk. I will watch it. I can run through these points, there are seven points. And my intention -- I can give you the rationale for each point. My intention here is to make the lightest weight process that will result in the best decision for Ruby. And since I’ve used two qualifiers that are lightweight and best, I need to explain what my standard is for those things. Lightweight means that it requires the least amount of synchronization in a sense. The least amount of, “We all need to get together and have a long conversation about some aspect of it.” Ruby is very complex. The behaviors of just something like the keyword arguments could take hours and hours of conversation. There are at least four, if not five or six, significant implementations of the Ruby programming language. Every one of the developers on all of those projects are very, very busy. We have a ton of work to do. We have a ton of really awesome things we would love to bring to Ruby developers. And we spend 95% of our time just trying to get compatibility down. Fortunately, we have RubySpec, right? But even that has holes. So when I say lightweight, it’s very important to me because I’ve worked very hard for years now to get Ruby features out to people and I don’t want to waste time on aspects of process that would not give good return. The other qualification which is sort of the best decision for Ruby, my concern there is opening up so far. The decisions about Ruby have been made by a very small group of people that do not necessarily represent the interest of stakeholders. And we’ve been very, I think narrow in our definition of the Ruby community. Mostly, we’ve discussed people who write Ruby code. In the Ruby community, we actually have implementers, we have people who write Ruby code, we have people who use applications written in Ruby but they have no idea probably of what Ruby is. All of our relatives have probably used some application. Ravelry.com is a knitting website. So many people I know, people in their 60’s and 70’s and 80’s that are friends with my wife’s mother who use that website have no idea what Ruby is or Ruby on Rails or anything else. So, there are users of those applications written in Ruby. There are businesses that pay people to write those applications in Ruby. And those businesses can be something like the company I work for, Engine Yard who is very, very deeply into Ruby, to companies that don’t even really care what Ruby is. They just want a website written. What I want to do is expand the definition of the Ruby community widely and look at all the different people who participate in that community and where their concerns may influence Ruby design decisions or where Ruby design decisions may adversely impact those people. CHUCK:  That makes a lot of sense. And I think you really have kind of outlined the number of people that can be impacted by these decisions. BRIAN:  Yeah, a lot of people. CHUCK:  Can we talk about some of these points? I’m just looking at RubySpec.org/design. I’m not going to go into the details. BRIAN:  Do you want to bring them up, or do you want me to just sort of read through each one and give you the rationale for it and then we can like go off on a discussion of those? JAMES:  Let’s do it point by point. I have questions. CHUCK:  I’ll read the points and then you guys can ask questions. How does that sound? DAVID:  Sounds good. BRIAN:  How about this? You read the point, I’ll give you my short rationale and then, we’ll have questions. CHUCK:  Okay, that sounds good. Because then, we’ll have some context. A Ruby Design Council made up of representatives from any significant Ruby implementation, where significant means able to run a base level of RubySpec (which is to be determined). BRIAN:  My emphasis here is on significant Ruby implementation and the reason for that is because Ruby is very complex. And I have watched a lot of proposals over time for features in Ruby that make absolutely no sense. And people that have spent literally thousands of hours implementing Ruby and care deeply about Ruby have a level of insight into Ruby that I think is required for making good decisions. And so, I think that we have to have an opportunity for each of those people to have a voice in decisions about the design of Ruby. And point two will go into a little bit more detail around that. JAMES:  I just wanted to say that I don’t feel this one is very controversial. I mean, if you go far enough as to implement what is on some level working Ruby, it makes total sense to me that you get a seat at the table. And I’m pretty sure everybody shares that view. JOSH:  Oh, James. [Laughter] JOSH:  I’ve seen people yakking on this one saying, “Oh, my God! This excludes most people who are stakeholders in Ruby.” Just because you aren’t implementing Ruby doesn’t mean that you shouldn’t have a seat at the table. JAMES:  Let’s address that when we get to the lower points because I think he kind of specifies what the Council is for and stuff. JOSH:  We can wait but I just want to… JAMES:  Okay. So, it’s not universally accepted. But also, I just want to point out that it’s really common, like for something like Linux. Of course, there’s Linux up at the top but then he has his various sub-lieutenants basically that focus on things like the kernel or the I/O system or things like that. So, I think this kind of thing is pretty common. CHUCK:  I think it could work. I have to wonder a little bit out loud as to whether or not Matz is willing to give this a try? JOSH:  Should we hold that for a moment? JAMES:  Well, Brian probably knows this better than me. But in my experiences with Matz, he is 100% open to talking with people and accepting their input and ideas. That’s my opinion. CHUCK:  Right. But will this Design Council have kind of the final say as to what goes into the language? Or would that stay with Matz? JAMES:  You’re getting ahead of yourself. That’s why I was saying I didn’t think this point is very controversial. Point number one just forms a council. It does not outline their powers or anything like that. CHUCK:   Okay. JAMES:   That’s my opinion. BRIAN:  They are good points. We will definitely get an opportunity to address those. CHUCK:  Okay. Sounds good. Point number two: A proposal for a Ruby change can be submitted to any member of the Ruby Design Council. If a member of the larger Ruby community wishes to submit a proposal, they must work with a member of the Council. JAMES:  You missed one word there, Chuck. And it actually changes the meaning. It’s ‘Proposal for Ruby change can be submitted BY any member of the council’. You said ‘TO any member of the council’. It’s ‘BY’. CHUCK:  Okay. BRIAN:  Now, we get into -- so, we have a Design Council and now, we talk about what they do. The point of a Design Council is to look at proposals for Ruby changes. So, changes to Ruby. The point here is that everyone has equal opportunity to propose a change to Ruby. And the reason that that’s important is because, like I said, there’s different implementations that face very different challenges on their particular platform, and Matz doesn’t know about that. Matz has said repeatedly at his keynotes and his Q&A’s at Ruby Conf that he’s not a threading guy. And yet, there’s decisions that Matz can make the impact, deeply impact the language when it comes to concurrency. So, the point here is that the different Ruby Design Council members may have expertise in a particular area and they are most suited to put together a detailed proposal that addresses those issues. And then, shepherd that and bring that to the Council as a whole. In this particular point -- I’m going to pre-empt someone who’s going to ask me. But this particular point is very controversial and it’s related to the formation of the Ruby Design Council. But it’s more about, “Hey, what if I do Ruby and I’m very knowledgeable about Ruby, why can’t I propose something?” The challenge, the criticism that I’ve received here is that this process is closed but if you’ll note that MRI is a significant implementation of Ruby, MRI would obviously be on the Design Council. And right now, if you want a change to Ruby, you go and you ask Matz if he’ll change it. So, this process that I’m proposing is no more closed than the existing process because anybody can submit a proposal to MRI as a member of the Design Council. But it’s actually more open, in that you could work with an implementation like MagLev on a Smalltalk VM who has potentially very different platform issues and put together something. Including even writing the code, because maybe you don’t write C, and you don’t write C++, and you don’t write Java, and you don’t write C# but you might write Smalltalk. So, you can certainly participate in a way that you are right now excluded from here. So, that’s the rationale and that’s why I think it’s more open. CHUCK:  One thing that I do like about this is that because the members of the Council are implementers, if you put something in, then they can at least address why it might or might not be something that is feasible or easy. They know what the repercussions are better than somebody who simply uses the language. JAMES :  This is the point where Josh mentioned that now it seems like we’re cutting people off because they don’t have a seat at the table. But I just want to say that I agree with Brian that this process is actually more open. The current process is if you want to get a feature in Ruby, your options are: (a) lobby Matz; (b) lobby Matz; or (c) lobby Matz, right? [Laughter] CHUCK:  Or, (d) learn C and then lobby Matz? [Laughter] JOSH:  Okay. So, I think that in general, mostly what you’re talking about is right. But as always, there are exceptions and I think some are worth noting just because they -- what is it, ‘the exception that proves the rule’? Many people know who Joe Damato is. He’s basically a C developer. He started playing around with Ruby years ago and started digging into the C implementation, learned a lot about it, implemented some fixes that helped Ruby’s performance a lot. And then, he just eventually sort of lost interest in working with Ruby because of problems he was perceiving. And I don’t know that he does anything with Ruby anymore but I haven’t really been following. But this is just someone who wasn’t even a Ruby developer. He just sort of like looked at the language, played around with it, learned some stuff, made some patches and then got into Ruby. These kind of weird things can happen because somebody smart does something valuable. But I agree that there’s not a process around it. JAMES:  And so, Joe’s patches, he made patches and then he submitted those wherever. But in the end, was it Matz that made that call? BRIAN:  It was indeed. I think Joe’s a great case because Joe is a terrific developer, deep knowledge of C and the computer hardware that runs C and he left the Ruby community. We don’t actually get to benefit from his insight and input anymore because he was extremely frustrated with the reception that he got from some of those patches and also deep architectural issues in MRI that he couldn’t really work around. I think that someone like Joe wouldn’t be excluded under that process because he could certainly have worked with us in Rubinius, for instance, on some of that stuff to see if it worked better or maybe he would have switched to Smalltalk. But the fact that Joe did do a lot of work but ultimately became very frustrated and sort of, I hate using the phrase, but sort of rage quit the Ruby community is somewhat of a disgrace, I think. So while I think he’s a great case to consider, I don’t think he’s an example of someone who would be excluded under this process. JAMES:  I think I agree with that. Again, this is common. Linux works this way, right? If you want to make a change to the I/O system, you end up working up the train until you eventually get to the sub-lieutenant who’s primarily in charge with the I/O system and then you guys work out your change. And then, he takes that change to the group, and he basically becomes your champion. So then, you’re not John Smith proposing a change. It’s, “This change has come to us and we think this has value.” And then, takes it to the larger body. I think it actually increases the chances of something getting in because it provides that lower level filter where things that are silly or not well-thought out or whatever don’t get past that barrier. And then, when somebody does chose to champion an idea and get it that far then we know that it’s something we should probably take seriously. BRIAN:  I would even elaborate a bit on that which is, I saw this Tweet the other day where someone said, “Every significant idea in our society today began as somebody just messing around with some silly thing.” So even those silly ideas may, through nurtured iteration at the level of one of the implementations, become a significant idea. So, it’s even less about filtering, as it is. It’s more about giving the attention and the resources to it at the right level. Without drawing in all these implementers to talk about an idea that may not go anywhere, or may be so confusing at a particular point that it doesn’t even make sense to discuss. So by forcing people to work with an implementation, develop the idea completely which is what we’ll get to in the next section, again, I think it makes for a more efficient process that leads to better decisions. CHUCK:  Yes. Number three has three points to it. Do we want to tackle those each on their own? JAMES:  I think we can do it as a whole. CHUCK:  Okay. The proposal must meet the following criteria: 1. An explanation, written in English, of the change, what use cases or problems motivates the change, how existing libraries, frameworks, or applications may be affected. 2. Complete documentation, written in English, describing all relevant aspects of the change, including documentation for any specific methods whose behavior changes or behavior of new methods that are added. 3. RubySpecs that completely describe the behavior of the change. BRIAN:  So here, we focus on the meat of a proposal itself. And I think that these three points are essential and this gives me a great opportunity to clarify something else. Some people have read this and thought, like 2. A proposal can only be submitted by Ruby Design Council, or 3. The things we just discussed meant that you couldn’t do anything except these things. That’s not true. That’s not what I’m saying. What I'm saying is these are the fundamental things that must be met. Without this, you don’t have a proposal. I didn’t mention code in here, because code is implementation specific. And I can’t imagine anyone getting a proposal together that meets these three criteria where they didn’t write any code. But there is a great deal of objection to the idea that Matz and some other Ruby developers couldn’t discuss code in Japanese over lunch or write some code and talk about it on the ruby-dev mailing list where the language is primarily Japanese because this says that to do a proposal, you have to explain it in English. I want to really, really clarify that every implementation is free to do whatever they want to do, wherever they want to do it, in whatever language they want. I don’t care how they test their code, whether they write tests, what language they write it in, or what language they discuss it in. This is only saying, “At the point that you want to propose a change to Ruby, you need to meet these three criteria. Otherwise, it doesn’t meet the threshold of a proposal to change Ruby.” And again, the rationale is simply that without a clear explanation of why it’s needed, it’s difficult to understand. And again, we have multiple implementations on multiple different platforms. And so, they need to be able to judge things and make good decisions from the information given them where they may not be experts in that domain. The documentation is extremely important because we’ve struggled with poor or lacking documentation in implementing Ruby. And so, understanding exactly what the things do enable us to make a good decision. And finally, RubySpec is there because it’s the only thing that we have that provides a level of specificity to ensure that the very complex behavior in Ruby doesn’t get twiddled here and there and you spend lots of developer time debugging things that are incompatible when they don’t need to be. So, these three criteria are only the base threshold. You can do tons more things. You could make a movie about your future or you could talk about it at a conference or anything else. Definitely, people are probably going to write code because how are you going to know that your RubySpecs are accurate. You can discuss it in any language you want, anywhere you want. It’s just that at the point that you make a proposal, it’s written in English, it has complete documentation, it has complete RubySpec. JOSH:  Okay. Brian, RubySpecs, having this as part of the criteria for proposals, is that an onerous requirement for proposals? Or is everybody who is doing implementation work already bought into RubySpecs? Or is it somewhere in between there? BRIAN :  It’s definitely somewhere in between. Every aspect of this is onerous. It would be a wonderful world if we just sat down one morning over coffee and tea and gummy bears and chatted on podcasts about how great Ruby was. The reality is, I spend hours and hours pulling my hair out, very, very frustrated figuring out how things like in encoding actually work. So, every one of these elements of this Ruby design process are onerous because I believe that the value of good decision making about Ruby outweighs many, many fold the effort to go into this. So, writing RubySpecs is, I will admit, onerous. It’s one of my least favorite activities and I spend a great deal of time doing it. I do it because it has tremendous value to Rubinius and the other Ruby implementations because I know precisely whether things are compatible or not. I simply run them. I can’t have any bias in my mind changing the outcome. So, writing RubySpec is, I think, essential to the level of specificity that allows all the implementations to implement the behavior correctly. Not everybody has bought into RubySpec. I have talked to Matz about RubySpec repeatedly. He always nods politely and smiles and tells me it’s a good idea but there’s very little participation from the MRI core developers to RubySpec. There are some. JOSH:  I thought that there were definitely Ruby core developers who are contributing and writing RubySpecs. BRIAN:  There are like one or two. Yugui wrote a ton of stuff to get 1.9 ready and she actually said, “Look, 1.92 will not ship until it passes RubySpec.” That was a decision that she made. Matz deferred to her on that. But if she hadn’t made that decision, a ton of RubySpec work on 1.9 would not have been done, but she’s the one person. JOSH:  It sounds like MRI is, at least, participating in RubySpecs. That’s a good thing. BRIAN:  This is a good point. It’s not to -- there are a couple of developers on the MRI core team that participate in RubySpec. It is not accepted. There are many other core developers on MRI. I’ll put it this way, there are many other core developers on MRI who do not like RubySpec, think that it’s inappropriate, inaccurate. There’s a number of different criticisms of RubySpec. So, it’s not accepted by MRI, in general. I think that’s accurate. KATRINA:  I have a couple of questions about RubySpec. When you write new specs, what do you write them against? Where does the specification start? BRIAN:  That’s a wonderful question. MRI, right? So RubySpec, it intends to accurately describe the behavior of Ruby and MRI because that’s Matz’ Ruby implementation is the one that says how things work. So, if you add two to two and get five, RubySpec has to basically say, “You get five.” We do try to, obviously, we don’t accept segfaults, we don’t accept clearly erroneous behavior but there’s a lot of subtle behavior where it will file bugs and it will be like, “No, that’s the way it is.” So that’s the description of the behavior that goes into RubySpec. So, we write this against the behavior of MRI. KATRINA:  Do other implementations also use RubySpec? Like, you said that not very many of the developers in MRI use RubySpec. But what about Gem Ruby, or Iron Ruby, or Macro? BRIAN:  Every significant implantation of Ruby that exists and ones that I have only briefly heard of, all use RubySpec. KATRINA:  Is RubySpec independent of implementations or do you feel that it’s very tightly tied to Rubinius? BRIAN:  No. It’s its own project. So we put a ton of effort into making RubySpec basically work well. We have implementation guards, we have platform guards, we have version guards. So RubySpec can tell you what the behavior of 1.86 is, 1.87, 1.92, 2.0 although there’s a lot of gaps for 2.0. And it has specific guards that make it possible for Ruby to say the JVM, for instance, only provides 64-bit integers. So, their integers are not 32-bit on a 32-bit platform. We have guards that make it very clear that these implementation’s specific behaviors are different and this is why. So yeah, versions, platforms and implementations are from the core design of RubySpec supported. Does that answer your question? JAMES:  Just to clarify there, Brian. You’re saying the Rubinius team does not own RubySpec. It belongs to all of us. Is that right? BRIAN:  Yeah. It’s its own project in RubySpec.org. CHUCK:  I have to say I do like the complete documentation because then if it makes it into Ruby, we have documentation. JAMES:  Yes, we can only hope that spreads like wild fire, right? But it won’t. CHUCK:  Because everybody likes writing documentation. JAMES:  I know it is a horrible part. But I firmly believe in what Brian said, that you know, if it’s a feature that’s going to change the language itself, then that feature is not done until it’s documented and tested. I believe that. BRIAN:  A quick side note too. If you’re interested or if anyone is interested, anyone listening is interested in a common documentation project, please contact me. Because years ago, we actually started looking at this and it makes no sense to have our own Ruby documentation and see an MRI, and then Ruby and Rubinius, and then Java and jRuby. The whole R dot thing I think was a horrible Fork in the road that people took a long time ago. And what I’d love to see is an extraction of that documentation into a common place with easy ability to link from any of those different code bases. It’s on sort of one of my lists of things to do with RubySpec. If anyone’s interested in that, I think it would be fantastic, if that makes sense. CHUCK:  Interesting. So what’s the best was to contact you about that? BRIAN:  @brixen on Twitter. CHUCK:  Alright. Point number four: When the Council is presented with a proposal that meets the above criteria, any member can decide that the proposal fails to make a case that justifies the effort to implement the feature. Such veto must explain in depth why the proposed change is unsuitable for Ruby. The member submitting the proposal can address the deficiencies and resubmit. BRIAN:  So, the point of this is to actually put a barrier up to changing Ruby. And as soon as I say that, people get really upset. They have responded very emotionally to that point and I've said, “What Ruby needs is more change, we need to do more,” this sort of thing. So, there’s obviously something about saying this that touches people emotionally. I’m not sure I can change that emotional reaction but I can explain why I feel like this is important. Again, it goes back to the efficiency and good decision making. And I think that you have to make a minimum threshold for your proposal but that has to be enforced. And if there’s not a specific process that enforces that, then it won’t be a part. And I think it’s such an important thing to the quality of decision making that we have a good proposal that I want to make it a step that you have to go over. And that’s why this is here. Again, it supports efficiency and good decision making. DAVID:  I like that you’ve balanced the fact that any Council member can veto but the Council member vetoing must provide a detailed explanation of why. So it’s not just, “I don’t like that feature. I don’t want it.” BRIAN:  Yeah. It’s a great point because many people, Yehuda Katz talked to me for a long time about how consensus has to work, and Steve [inaudible] person. I’m not an expert on all of these topics. But I’ve been around the block a bit and when you get a group of people together who have a common goal and are united and you do as much as you can to keep that unity, you don’t have rogue people who are just like, “Screw this.” And if someone was behaving that way, one, I would be shocked; two, there’s a bunch of different social tools that we have at our disposal like sitting down and talking to them and trying to understand what’s going on; and three, if we were encountering that situation, we could come up with another rule that kicks a member off the thing if they don’t do it. So I’m not going have someone be an obstructionist here. But I am really concerned when I hear people say, that we should just ignore someone who has got a great depth of knowledge and has invested a great deal in Ruby, that we should just ignore them when they say, “This proposal is really not a good idea.” And so, they explain it in-depth and no one on the Council is going to be sabotaging. I just think that’s a bizarre thing to assume about a group of people that have literally spent thousands of hours of implementing Ruby. JAMES:  Okay. Now is the point where I want to disagree. I don’t know that I have as much faith as you do in that. And I don’t think that it has to be malicious. For example, it makes total sense that the Windows team, whoever that is in my imaginary scenario, is not going to love a feature like fork, right? And doesn’t necessarily mean they would veto it which I think is your point. But I don’t know, I do suspect that there could be a pushback there. So, I am not a fan of unanimous consent because I think it’s too hard. And actually, we see that a lot on Western society versus Japanese society where they do typically favor something close to unanimous consent. And I think it’s harder to build that consensus that way and reach the final goal. It makes change slower because of that. While I think I understand what this point is trying to do, I’m still not 100% sure I buy into it because somebody may have that reason for blocking it, like Windows doesn’t have fork. So, let’s think about that for a minute. If Fork had been blocked in Ruby, if it hadn’t been put there because there was some desire to keep it ridiculously cross platform, or something that basically cripples Ruby getting to the point where it was today. It didn’t have a good threading implementation to fall back on. So, Fork was how we did multiprocessing web servers, which is basically what got us here. It’s a significant lynchpin, right? And it exists only in UNIX and that kind of environment. The JVM kind of supports it. Not well, I don’t think, in my opinion. JOSH:  I think that’s a little hypothetical for an argument. It would be much more concrete if we had an example where something actually did get vetoed or blocked rather than hypothetically wording that something might have been. BRIAN:  Can I say two things then? One, absolutely Josh. And I think that what you’ve pointed out is something that is fairly common in all the criticisms that I’ve seen. So for instance, we shouldn’t have a process because XML/HTML 5, every other attempt at a process has failed, right? Which I think is way too hypothetical. JAMES:  Okay, I want to respond to that but do your other point. [Laughter] BRIAN:  But it’s also an opportunity to clarify again something. This is a description of Ruby as this unified language. Platform specific things, you know. You can do things on jRuby that you can’t do on MRI or Rubinius because they have Java integration. And to say that in order to be a compliant Ruby implementation and to have a unified language, you all have to do the same thing misses a big part of the picture. Also, creating processes is perfectly possible on Windows. It’s a very peculiar aspect of creating processes in UNIX that uses fork. It’s not impossible to create processes and groups of work or processes on Windows. So, the fact that you can’t fork on Windows doesn’t mean that you can’t do the same models, and it doesn’t mean that Ruby will be held back significantly. And if you want to look at a platform that is astoundingly successful that doesn’t really support fork, that is the JVM. If you fork, you basically give up every guarantee about any sort of threads. We do a ton of work in Rubinius to support Fork while we have these background worker threads like jet compiler thread, the garbage collector, finalizer thread. Before you can exec on OS 10, if you have more than one thread, you get a system error. So you have to throw all those threads off, then fork, then start all those things back up. Fork is a great example because it’s so complex and it’s actually very difficult. And it can be done in different ways on different implementations. And this proposal would not prevent something like Fork from existing in Ruby. But it may not be in the unified definition of Ruby, it may be in a platform specific thing that can still have a consistent specification. CHUCK:  So basically, the idea being, this isn’t required for you to be a canonical Ruby but if you do implement it, implement it this way? BRIAN:   Absolutely. JAMES:  I think I agree with almost everything you just said. I guess, I would like to see separate things, like the JVM specific things, or the UNIX specific things, or whatever. I guess I would like to see flushed out, how those would be defined and managed or whatever. But that’s kind of an aside. Just to be clear, I was not saying I do not believe that we should have a process. That’s not what I said. I said that I’m not a big believer in unanimous consent. So, to go back to the running example, I have been using of Linux kernel, there are the sub-commanders in charge of the separate areas and things that they work on. But Linux remains a dictator, right? And he can overrule and say, “Well, I think Fork is that important that we put it in and we’ll support it where we can. If we can’t, then those implementations will make it clear that they don’t support that,” or whatever. And he has the ability to make that decision or override. That’s all I’m saying is that, I think, I would choose a different means of consensus than unanimous consent. BRIAN:  Could you define what consensus would be without unanimity? JAMES:  So you have tools in, like I’ve recently been involved in these public meetings that are very official. And one of the tools you can use in something like that is called Fist-to-Five. And basically, it means that at every point, everyone holds up a hand that says something like, the number of fingers you have up clarifies your current level of support for a thing. So basically, no fingers, it gets blocked. One finger, I still have major concerns, two fingers I have minor concerns, whatever. Up to three fingers where it’s like, “Well, it’s maybe not perfect but I don’t have any blocking concerns,” or whatever. Actually, as soon as the room hits everyone who’s three fingers or higher, then it happens. You don’t have to be in full support or something to not be against something, right? BRIAN:  That’s great. And I think that illustrates exactly what I’m saying here which is that these are the minimum things, all kinds of other stuff is possible. Well in consensus, we can do the same thing. I don’t expect everyone to agree 100%. But James, what you just said is that if everybody says at least three, it’s adopted. To clarify, if there are any zeros, would it be blocked? DAVID:  Yes. Sorry, I’m not James. But yes. [Crosstalk] JOSH:  Okay. We’ve used the word consensus and consensus process and there is so much information written about consensus process and consensus decision making that you can Google. And I’ve been involved in groups that use a very formal consensus decision making process. And sometimes, they are completely aggravating to work with because people become rule lawyers. It’s all like, “You’re out of order,” kind of crap, but when it works… JAMES:  No, you’re out of order! [Laughter] JOSH:  Yeah, I know. But when it works, it’s a really great thing to be part of and it feels very empowering. It’s not like,” Oh, nobody listens to me.” So, there’s way too much to talk about here and there’s maybe a lot that can be learned from like the huge body of knowledge and wisdom around that, that can feed into this process too, Brian. BRIAN:  That sounds wonderful. Yeah, that’s a great idea. DAVID:  I have a pick that’s going to play with this whole consensus thing. JAMES:  I agree basically with what Brian said that a veto does count as like a closed fist, so it’s the block. I think my problem is that I worry that somebody would use that veto because they’re in Windows land and they don’t want to support something like fork, thinking that they’re saying, “I don’t support that feature,” or whatever. And in doing so, they would block the language itself. So I guess what I’m asking for, is clarification for how we get like implementation specific add-ons or whatever, they can’t be blocked by somebody that they are not affected by. CHUCK:  I was going to say something similar in just saying, who decides whether or not them vetoing. When they write their explanation, whether that actually justifies or explains properly whether it fails to make the case. JOSH:  And this is why there is so much written about the consensus decision making process. ALL:   Right. DAVID:  So, Brian, I think we came dangerously close to hitting a really interesting thing here and we veered away from it because we’re afraid of some controversy. So, I’m going to go ahead and pour some gasoline on this just because I think it would be funny. CHUCK:  I’ve got a match. DAVID :  Alright. So, about the consensus, there’s two extremes that I think we’re trying to avoid, right? The biggest one I think that causes the biggest blow outs in the Ruby community is when you have a developer who puts in a ton of effort, invests a huge amount of their life and energy and effort and then becomes completely disenfranchised by the process. Like the SlimGems, Lauren just felt completely shut down after putting blood, sweat, and tears into RubyGems. So, he went off and did SlimGems. And it was a big thing until some of those feathers got smoothed over. On the other end of the spectrum, we have people just kind of executing unilateral control and just kind of ramming things through. A current example of this is refinements in 1.9 which is an interesting idea. To me, it appears to be an interesting idea. But right now, it’s kind of out there as, “Well, here’s a patch.” You can compile it into your Ruby and it can be part of your Ruby and down the road you go. And it’s completely up in the air whether this is part of the standard, whether it should be part of the standard, whether it should be vetoed. And so people are really wound up on both sides of this. So Josh, you mentioned about this being hypothetical. Brian, given those two concrete examples, how do you feel the design process helps or addresses? BRIAN:  They are important examples. At the most recent Ruby Developers Meeting, I’m air quoting, which is a group of us that meet on IRC from different implementations. You know Matz, basically the decision was that refinements are in, they’re not going to be a compile time flag. They’re not going to be some sort of ‘from future import refinements’. They’re in and Matz has basically said he’s not going to remove them. He said, “I’m pretty sure I won’t remove them.” That’s a quote. So, it doesn’t matter how much objection there is, how broken they end up being or any other sort of negatives that are possible, Matz has already said, “I’m pretty sure I’m not going to remove them.” JAMES:  Brian, can we clarify on that just a little? I believe they actually did remove some of peoples’ most troubling complaints with them, like they removed that focus from refinements from now. Am I wrong in that? BRIAN:  No. You’re right. It’s a very complex topic. And so, there are refinements in some form. They’ve definitely been modified. They’ve been dialed back a bit but there are things, like ‘send’ that doesn’t respect refinements in place. Or if you use the introspective things like methods, you won’t see that refined method. Some of these things are very troubling. And there is a Wiki page that’s written up that sort of specifies what refinements do. The point that I’m making is not really the features of refinements but the fact that they’re in as an experimental feature in MRI; MRI still outweighs usage of other Ruby implementations by many, many fold, so they’re in. And Matz has already said, before we’ve even seen what sort of consequences play out in our life that he’s unlikely to remove them. Now, that certainly could be -- he certainly could change his mind but consider things like the magic globals. The scope-oriented regex match things that Matz has repeatedly said that he regrets adding, and yet there is no plan. And I don’t think I’ll see the day that they’ll be removed. They’re extremely difficult to implement. If you want to find out why, talk to jRuby there. They cause performance degradation that’s not necessary in jRuby simply so that we can use ‘$1’ instead of some variable and access on the first match. My concern is that when you have one person making the decisions and then they make decisions when there’s no process to sort of roll back or change that decision overtime and you simply have to lobby them, bad decisions can get in the language and stay in the language for a very, very long time. KATRINA:  I have a question. JOSH :  Go ahead. KATRINA:  If a Council was created and if points one, two, and three were implemented and maybe even four but the consensus for the actual final decision was still made by Matz, would you feel that there was an improvement in the current process? BRIAN:  I think that all of the things that are in those other things would be a huge improvement. And that, we would have much more explicit process and we would have things that support, I think, good decision making. So certainly, we can dispense with the seven which we haven’t reached yet.  But I’ll answer ‘yes’ without qualification. Yes, that would be an improvement but I would want to talk a little bit about why we would make that choice, at some point. JOSH:   Yeah. KATRINA:  The only reason I’m asking is that, that would be a choice that is a lot closer to what is there already. And very big changes are often really, really hard to implement and it’s sometimes easier to take smaller steps and let people in the community acclimatize, is that even a word? Get used to a way of functioning and finding a new balance and finding ways that it helps in ways that are still where the process is still impeded. JOSH :  I agree with that. That’s a good point. Brian…? JAMES :  Is that one more point before we move off of this one? [Crosstalk] JOSH:  I’ve got something to say, and that’s about Matz’ track record. I think you mentioned one or two things that I agree there are issues with Ruby. But if you look at Ruby as a whole, I think Matz has done a really [faded off]. DAVID :  Matz has done way better than Skype. JAMES:  I’ve lost him too. BRIAN:  It’s a great point. And it is a point that other people have raised and I think it’s important to address because nothing that I’m saying here is saying that Matz has been a terrible steward of the Ruby programming language or, “Gosh, Matz is really an ogre,” or he’s this evil dictator and we have to dethrone him, right? I’m certainly not saying any of those things in here. JOSH:  Okay. It looks like my sound cut out. DAVID:  Yeah, it did. Welcome back. JOSH:  I don’t know where I stopped talking. Yeah, I think Matz’ track record all in all is pretty good. Ruby is a good language. There’s definitely decisions that I would have preferred were made differently in various points. But I don’t know that having this process in place, we would have necessarily come out with a better outcome on any of those particular pieces. BRIAN:  So yes, Matz has been a fantastic steward of the language. He’s created a wonderful language as an implementer who’s worked with the language and as someone who’s written tens of thousands of RubySpecs. I would disagree a bit that Matz made a lot of good decisions. I think some of those things are open to interpretation. But I don’t think that basically having a process and even having a process where Matz is a dictator should be considered an affront to Matz. And also, I think that decisions can be made, right? You only have to make one catastrophic decision for it to be a catastrophic decision. So, while Matz has made a lot of great decisions about the Ruby language, not all of them have been great. And I think it’s possible that Matz can make some decisions that could be very bad for the language. And the reason that I even gave the talk at Ruby Conf is because I felt like that was what we were approaching with things like refinement, no good concurrency story, an extension API that makes it impossible really to use C extensions well on other implementations and no security story, right? We’ve seen sort of astounding exploits recently and there’s more coming. And we don’t have any good discussion about security. Things like $SAFE in Ruby are not sufficient. So, I want to be really clear that Matz has made a terrific language and I love Ruby very much. I don’t think that asking Matz to accept that we may, as a group, like all of us may say, “Matz, this is a bad idea.” I don’t think that Matz should say, “You know what? Too bad, I’m going to do it anyway.” And I think that considering the consequences of decisions like that and what that sort of says to the Ruby community, I think, is important. And I think it’s reasonable to ask those things and consider those things without being accused of insulting Matz. DAVID:  I don’t think we’re in any danger of changing the slogan to Matz is Omakase. And so, we are Omakase. BRIAN:  Okay, that’s good. JAMES :  Just a couple of things I wanted to respond to there. One, I guess we should say Matz has responded to these points. I’ll put a link in the show notes to the thread on Redmine Tracker and Matz did respond in there. He’s against being removed as the dictator. One of his points is, “Community members can show their opinions, vote or persuade other members in discussion that follows a proposal. The dictator will make the decision. Community members can persuade him to change his mind with rationale.” Another point is, “Appendix: community members can deprive of power the dictator when he apparently lose his ability to make rational decision. After deprivation, the community will make up new rules, hopefully flexible ones. I don’t want that situation but the day will come sooner or later.” So I feel like he says he does want to remain dictator but that he does realize there will probably be a point when that has to change but he’s not interested in doing that today. The other thing that I wanted to mention that Brian said was, and this may be wrong. I had a totally different view of refinements. My view was that they were in an experimental stage in Ruby 2 and that the actual official unveiling of them had been delayed. So, if I’m wrong in that, I apologize. BRIAN:  You’re right. Let me make sure we don’t give false information. They are marked as experimental but they are in the language. They are marked as experimental. The final is sort of slated for 2.1. So, they’re going to work out some things. But Matz has already said, and this is a quote from the Ruby Design meeting, “I’m unlikely to remove refinements from the language.” JAMES:  Gotcha. So, the only thing I wanted to add to that is that the reason they are currently experimental and they were dialed back and all of that is because of the case that Charles Nutter made to Matz. So, I just want to clarify that it’s not like this process isn’t happening at all. Some of it is happening on at least some level, right? Charles did lobby to Matz. So Charles, being the JVM guy, did lobby to Matz that this feature was problematic and basically exercised some form of a veto. I guess we have yet to see where that’s actually going to land. But this is kind of happening, on some scale. CHUCK:  One other thing that strikes me with a lot of this is that if we have this Council regardless of whether or not Matz is willing to really push any control to the Council, it still does give us a process for submitting improvements and basically backing it up with code samples, other documentation, explain the impacts one way or the other. And I think it really will give us a way of appealing to Matz in a well-reasoned way by having these proposals and having them reviewed by implementation members. JAMES:  Yeah, I think so. Let’s do the other points. CHUCK:  Okay. If a proposal is accepted for consideration, all Council members must implement the features so that it passes the RubySpecs provided. So if it passes, they have to build it. BRIAN:  Yeah. So, if everybody basically -- if the proposal meets the requirements, so no one on the Council objects for a valid reason then to move forward, everyone needs to implement it. And I think this is another point that’s been really misunderstood. It doesn’t mean that you can’t have already implemented it. You certainly can. Any number of the Council members and maybe all of them could certainly collaborate on any proposal. It’s not like one person has to go do it, “No talking over there. This is a test.” No, it’s like any behavior that promotes the quality of the proposal is certainly acceptable. At least one Council member has to make a proposal that meets these criteria, and then everybody has to agree that it makes sense to move forward and then everybody implements it. So that -- and you’ll notice that we haven’t had any discussions yet, right? So that when we get to the point of discussing it, everyone has code in hand that runs. They can do their own performance, checks, they can look at how it impacts their libraries, what sort of platform things they had to address? What sort of things users of their platform may have found? So, we have precise RubySpec so we should all be able to agree that we haven’t munted it correctly. One of the challenges with refinements is that there’s some documentation, very few tests, almost no RubySpecs and it’s really confusing what the behaviors are expected to be. And that the discussion on the thread is a bunch of little code samples, and should this method call this one or not? It’s so confusing. And how do you make good decisions when everybody is kind of confused and constantly having to clarify how something is supposed to work? So RubySpecs are there. We all implemented it. It all works and it all passes RubySpec and now we can move forward. JAMES:  So, I hate to play bad cop but I have concerns. [Laughter] JAMES:  How about we start with what I think is the easiest objection? Brian, I have serious concerns about the demand on your time if we put something like this in place. I mean, if I’m not misunderstanding, Rubinius is still catching up to 1.9, I think. And so, it’s clear that there’s a lot of work for you to keep pace and keep the specs up and stuff. And I’m worried that if you have to implement all the features that we’re just considering adding to the language, that that’s a significant time barrier. BRIAN:  Could I clarify, because I’m not going to be writing all the RubySpecs. I can certainly assist but the people who are making the proposal write the RubySpecs, right? JAMES:  I was referring to the implementation. BRIAN:  Okay. So, the implementation. What we’ve done is we’ve made sure that a really good idea is being proposed before we’ve gotten to the point of having to implement it. And I think that we can use refinements as a perfect example. Yes, my time is limited. And one of the things that is very, very frustrating, being really concerned about the well-being of Ruby, is trying to follow threads on Redmine which has terrible UX and no technical support for sort of understanding the discussion. And the discussion evolves by a series of code samples that aren’t always even rendered correctly and then a person telling you what that code should do. That is a tremendous drain on time and makes me not want to participate because of the effort and feeling like I can’t even make a good decision without a tremendous investment in time. So, the pieces of this proposal that I put together are things that should help every implementation focus their attention on really productive actions and give them good understanding so that they’re able to communicate while give good input, give good criticism, and ultimately, arrive at a good decision. CHUCK:  So, are you saying that this is going to actually save you time? Or this could save you time? BRIAN:  Yes. This would save everybody a lot of time, everybody. JAMES:  Brian, would you ever entertain the idea of, “It must be implemented in any one implementation to get this far?” Could that be enough of it where we could actually play with it and discuss it. I realize that if that one implementation chosen were jRuby, then it might have Java specific things and maybe we couldn’t maybe understand the full impact at various levels and stuff like that but would it be enough that we could get value out of it? BRIAN:  I would give an unequivocal no. That’s part of the process, and the people proposing it would have implemented it and provided the RubySpec and everything. But for us to discuss it and understand it, no, I don’t think so. Refinements are a particularly complex case because they’re adding a language feature that we don’t have a lot of reference from other languages to understand. But let’s talk about something that could be extremely critical and even more complex. Let’s talk about security or consider like a memory model that’s consistent across implementations, some that have a global interpreter lock and some that have the JVM under them or a Smalltalk VM. The decisions that need to be made for Ruby are significant. We’re not just talking about, should this particular method take two arguments or one? So I think that any interest in short circuiting this process is not good for Ruby. Does that answer your question, James? JAMES :  Yeah, I think so. CHUCK:  Point six is: Once all Council members have implemented the feature, the feature can be discussed in concrete terms. Any implementation, platform, or performance concerns can be addressed. Negative or positive impact on existing libraries, frameworks or applications can be clearly and precisely evaluated. Any thoughts on that? BRIAN:  So again, my rationale is simply efficiency and good decision making. I really don’t think it’s possible from my experience working with this, to reach a good decision with an efficient utilization of implementer time and something that’s inclusive among the different implementations if we don’t have something concrete to talk about. So, we basically eliminate [inaudible], we eliminate misunderstandings about semantics, we ensure that we have at our disposal or the ability to easily produce stuff like performance, regression, information, or how it impacts existing libraries and how it could potentially impact existing customers from the sense of someone who’s actually paying people to produce Ruby code. How it’s impacting businesses if we have the discussion at this concrete level. So, that’s the rationale. JOSH:  Brian, this is I think one of the more problematic pieces of the process just because six is based upon the assumption that everyone has implemented the feature and that if one of the Council members, one of the implementations doesn’t do that work, that seems like that blocks this step tin the process. And it’s sort of an implicit veto where somebody just refuses to participate in doing that implementation. I don’t see anything in the process that talks about, what do you do when somebody is being intransigent, whether it’s intentionally or they just don’t have the resources to do the work, or who knows what? BRIAN:  Yes, it’s a great point. It’s something that people are concerned about. But Josh, I would offer the same criticism that you offered to James earlier which is that’s rather hypothetical. We’ve never seen people be, that people that participate in Ruby be obstructionist or just say, “No, I’ve got my arms folded. And I’m sitting here pouting and there’s no way I’m going to do it.” JOSH:  Okay. So, that’s hypothetical. But people having limited resources is not hypothetical. And we can just look at Rubinius and the support for 1.9. You have limited time, that’s something that you really want to achieve. But all that encoding stuff and all the other 1.9 differences make it really hard to get it done. So, if somebody comes up with some feature that’s just a lot of work for you to get done and you can’t get it done in Rubinius, how does the process deal with that kind of exception? I don’t think we need a huge in-depth answer right now but I think that that’s a problem with the process. BRIAN:  Okay. Well, consider this. One, I probably wouldn’t have spent half as much time on encodings had I had documentation of RubySpec at my disposal. I’ve had to write most of the RubySpec for encodings. Encodings, the feature itself has some terrible, terrible behavior that I think could have been avoided. There are people who would not use 1.9 because you can concatenate a couple of strings that may work this time and the next time, it will throw an exception. So, there’s lots of things. Encoding is a good example to consider under this scenario because would we have come out with a better feature or would it have been easier to implement? And more importantly, would the effort to implement it have been more evenly distributed or even reduced? jRuby spent a bunch of time implementing Oniguruma in Java because there’s no good way to use a C library really, or a C extension in jRuby without limiting what they can do with threads and stuff, right? So, it’s a really good thing to think about. Would we have been able to get encodings implemented on a number of implementations much more easily, much more quickly and with less investment overall, how do we have something like this proposal is requesting? JOSH:  It sounds like step six is sort of like a stealth feature. It’s like looking for canaries. If a feature is so complicated or requires so much effort to implement that one of the Council members can’t get their implementation up to snuff, then that is information about how suitable the feature is in general. BRIAN:  I think that’s an important point, yeah. And another thing to consider is remember, this process does not -- you’re not like embargoing from deploying the feature because it hasn’t reached consensus yet. It’s simply saying that once we’re going to say this is part of Ruby so that people can come in and say, “Dudes, Rubinius is not supporting refinements, it’s part of Ruby. What’s wrong with you guys?” Before you can do that, it has to be part of the official language, right? So, it can be in use in these other implementations. An implementation can lag. It hasn’t reached consensus, that doesn’t limit anyone from using it in all those other implementations. It’s not something that you can’t deploy until it’s actually reached consensus. CHUCK:  That’s an interesting point. And it’s one that I think would be interesting as far as which features are implemented by which Ruby implementations. But yeah, I happen to agree with Josh. I mean, what does happen if it doesn’t get implemented and there really isn’t a performance or feasibility or other thing that can really attribute that failure? JAMES:  So, I think Josh raised a good point that I was definitely concerned about. I have one more minor concern and that’s that I think I understand why the discussion was placed after the implementation. But I have concerns that there are some things that a good discussion can save us from the need to implement. There’s some things where I think given the idea, we can have an initial discussion point and that somebody might raise a super valid blocker that nobody has a good answer for, that saves us from needing to pay that penalty on the implementation. I think I would like to see some form of discussion before we go to the implementation phase. Am I alone in thinking that? CHUCK:  Isn’t that where the veto comes in, though? DAVID :  That’s right there in point four, right? Any member can decide if the proposal fails to make a case that justifies the effort to implement the feature. BRIAN:  I think the point there is exactly what you’re saying, James. There’s a good reason to consider the feature but if you look at how discussions typically progress, and again, I’m not saying there’s not more than one way to do it. I am saying that my concern has been efficiency and good decision making and I think all these things support those. So, certainly people could discuss. And you could implement at that level and say, “You know hey, I’m going to just hack in some quick code here and check this real quick before I think it’s okay.” Nothing says that you can’t do that as an implantation. And if there are concerns, certainly in discussing them, we might end up implementing some things and then come back and say yes, or no, or whatever and we’ll go at that level. I’ve put sort of blockers in a sense in here for the reason that I think that rolling right over those and a ‘hey, let’s all get along and do things together’ way is not going to necessarily result in the best decision making, and I want it to be efficient. I don’t want to have to struggle to understand what refinements are supposed to do before I can give an adequate reasoned response in opposition. So, I wanted to make it as simple as possible for everybody to understand, agree, implement, vote, and these sort of things, if that clarifies. DAVID:  Is this, this isn’t necessarily a waterfall process, right? I mean, if everybody goes off to implement this and somebody says, “Whoa!” This all seems like a good idea on the surface but I’m implementing this and this is going to make garbage collection impossible. Are you guys seeing this? There’s nothing stopping everybody from going back to point four and saying, “I would like to change my vote to a veto.” BRIAN:  I hadn’t actually considered that sort of ‘can we go back in time’ thing. I think it’s more fruitful to have the discussion at that point. Because implementation -- here’s one of my concerns about Ruby. Many implementation details have become defined semantics of the language and that’s troubling. So when we get to the point of implementing it, implementation details should be implementation details. Nothing says that a good feature is going to have the same exact performance profile across all the different platforms. But if it’s a good feature, it should be a good feature and then the platform figures out how to implement it well. And if we discover something like the extension APM makes it impossible to do threaded concurrency without a global interpreter lock, then that’s a deficiency that could stop the thing. Once we’ve got it implemented, we are certain this is the way it works. People have helped us figure out a better way to implement all these things. Hopefully we’d say, “No, I can’t vote for this. It’s just not going to work.” DAVID:   Yeah. CHUCK:  And that kind of leads us to number seven which is:  Finally, a vote on the proposed change is taken. Each implementation gets one vote. Only changes that receive approval from all Council members become the definition of Ruby. And we’ve talked about the consensus. BRIAN:  The only point that I would make here is because everyone who’s objected to taking away the ultimate dictatorship that Matz holds right now, everyone who’s objected to that, no one that I have talked to has objected to it in a way where they have any ill intent or anything. They have simply said, “You know, do we really have to take that extra step?” And what I want people to consider, remember from the beginning, I want people to question these things. So, what I want people to consider is, how would you feel, as an implementation who’s struggled and worked very hard and poured far more than your eight hours a day that you’re paid for into something, weekends and nights, and thinking and travelling and talking and doing all this stuff. How would you feel if you give your best effort and someone simply says ‘no, I really don’t like that’? CHUCK:  Yeah, the counter point to that is you know, what if you were a person who invented a programming language, had worked on it really hard for 20 years, and then the people who are using your programming language basically come and say, “Thanks, bye!” DAVID:  Yeah, “We’re taking this away from you now.” BRIAN:  So, let’s actually tease out a few points in there, right? So that’s the sort of objection, right? It’s like we’re somehow -- what I’m suggesting is somehow a mean thing to Matz. And I want to consider that because I’ve honestly been accused of insulting Matz or something. And there’s nothing in what I’m proposing here that is intended as an insult to Matz, even indirectly or not intended, it’s still an insult. No. Matz created a language. Let’s examine the responsibilities and the privileges of such a thing. Matz created a language. It’s a fantastic language and have a very interesting group of people using it, myself included, before Rails was even conceived. Rails came along and popularized Ruby to an extent that it is today really, right? Rails is still something that people compare their frameworks to. People like Rails, people hate Rails. It’s very rare that someone doesn’t say, “We do it this way in contrast to Rails.” Not just in Ruby but in many different programming languages. So Matz deserves, and I think he’s been given a great deal of respect and deference and I would truly say love, by the Ruby community. But that doesn’t mean that Matz doesn’t have certain responsibilities, I think. I’ve actually heard people say that, “No, Matz does not have any responsibility to the people that use Ruby. That’s his language. He can do whatever he wants with it.” But I would challenge that because there are developers whose salaries are paid for writing Ruby. There are companies whose well-being depends on how well Ruby applications work. There are consumers and other people in the world that are trying to deal with technology that interact with Ruby applications or Rails applications. And I think that if Matz wants to say, “No, I am the one that makes these decisions regardless of what anyone else may think,” then I think he has the responsibility to consider the consequences of those decisions. But that’s a very difficult thing. How does one person consider the consequences of all their actions? So, I think simply having a Council where everybody has to agree is the best way to make sure that good decisions are made about Ruby. We still might make a poor decision but it won’t be for any reason that I think is easily avoidable. When you look at issues like concurrency in Ruby or security in Ruby, I think that there are things that we could do to avoid some of the situations that we’re in today. But Matz doesn’t know everything, can’t know everything. He’s a great guy but he’s not perfect. And so, instead of looking at this as like an insult to Matz, why can’t we look at it as a way to help Matz and ensure that we make really good decisions about Ruby. JAMES:  Brian, are you of the opinion that we need Matz’ permission to make this change and remove him as the ultimate dictator? Or are you of the opinion that that’s something the community can do because we’ve decided it’s important? BRIAN:  That’s a great question, James. And I think it’s an important one to consider. I have, I keep reiterating but I have worked very hard to make sure Ruby stays a unified language. And I don’t think that we can say to Matz, “You can’t be the dictator anymore,” without fragmenting the language. And just for the same reason that I want consensus on these decisions, I want Matz to agree that this is the best thing for Ruby at this point in time. I’m worried that that’s not the way things are going to happen. If the situation continues, I think that it’s very possible that other implementations may agree to implement other things and that we start seeing a split between MRI and other industry sort of implementations. And I’m concerned about that because I think that’s way worse for Ruby than having Matz say, “Okay, you know what? I will accept a veto.” Because it’s hypothetical whether we’d even veto anything, right? It’s just merely the possibility that we’re asking him to accept. And at the point that we veto it, Matz can still say, “You know what? I don’t care, you vetoed it. I don’t care. It’s still going in MRI and people can use it there if they want to use it.” We’re not putting Matz in a chair and strapping him down and holding him there and saying, “Matz, you’re not getting out of this chair until you agree with us.” Nothing is saying that. We’re simply saying that Matz could say, “Hey, let’s try it. Let’s try it for a year. Let’s see if someone vetoes me. And at the end of the year, I could change my mind.” Any of these things are possible. My proposal doesn’t limit the realm of possibility but it does describe things that I think are essential and I think why. JOSH:  I think there’s something subtle in there that is worth pointing out. And that’s the process you’re talking about, these kind of things often come down to issues about power and who wields power. In the United States, we live in a constitutional democracy and we’ve all basically agreed, “Okay, we’re going to follow these rules.” And therefore, the government has a lot of power. Okay, that’s a poor analogy but I’ll try and make it work. What you’re talking about with this process doesn’t really change the power of anything. It doesn’t prevent Matz from making decisions that affect MRI. It doesn’t enable Matz to make decisions that effect Rubinius anymore than he does already. What it is, is an agreement for a framework where people who have an interest in working together can work together because they realize that it’s in their interests to be more collaborative. And it’s not like it’s taking anyone’s power away. It’s because people come to the process and want to participate because they think that it’s in their benefit. BRIAN:  That’s absolutely true. I mean, you could certainly have a Ruby implementation that shows Matz to participate in this. And you know, I think that one of the things that I will redirect people’s attention to is that Ruby is often called out as a great community of great people. And I think it’s like most of the objections have been very suspicious and sort of, “I don’t really know my neighbor. So, I’m not going to leave my jar of cookies on the back porch because they might come steal them.” I hate that we sort of immediately go there in a discussion like this. And so, I would say, you know, Ruby’s a great community. Ruby is a great language. Matz is a great leader of the community and I think we can make a great process. CHUCK:  One thing that I just wanted to point out is that, again, regardless of whether Matz accepts the Council or not, or however this goes, whether he gives up his power or not, so to speak, it does put a process in place where we can have these discussions. And honestly, Matz seems like a reasonable guy to me. And so, even if he does retain his benevolent-dictator-for-life kind of status, we can still take these proposals to him. And if they’re well-written and well-considered, and have the buy-in from the other implementers, it’s probably something that he’ll at least look at. And so, under those circumstances, we can inform his decisions that way and ideally then if he wanted to add something to the language, then he would participate in this process too. But even if he didn’t, I still think there are some big wins in the way that this is set up that we could then kind of have a voice and have an organized system for bringing these things up. BRIAN:  I agree. JAMES:  I have one other thing, I guess, that I wanted to go into. First, we should probably mention that after this proposal came out, there was a meeting which I believe Brian has mentioned and they discussed it. There was the Redmine thread which I’ve mentioned before. And then, Brian posted a follow up blog post outlining a lot of the talking points and his responses to them. We’ve covered a lot of those here but maybe not all. So, that’s probably worth a look. But what I wanted to say was that there has been some change. The implementers meetings were restarted. So these are -- I’ve never been to one, so I may get this wrong. But they are IRC meetings with the various implementers. And I think they’re actually using kind of like the modified form of Robert’s Rules or something to try to control the meetings and discuss various topics. Brian, do you feel that’s had any value or is that improving your opinion of the current process at all? BRIAN:  You’re right. We’ve had two. There are more scheduled upcoming as Ruby 2.0 gets close to release. Yes, you’re right. They are on IRC and Aaron is doing the Robert’s Rules on meetings sort of thing. So, we have a moderator where you essentially do an IRC equivalent of raising your hand when you want to speak and exclaim to speak, question mark to ask a question, these sort of things. We did do something like this before and they sort of fell off. So, it’s always great to have people communicating. Communication is good. But my criticisms of this process would include these things. One, IRC is a terrible medium for high bandwidth or nuance discussions. It’s just painful. They’re limited to an hour. They have to be synchronous. And we have a world with many different time zones and people who are implementing Ruby spread across all those time zones. So, finding a good time that works for them that isn’t 1:00 AM in Amsterdam where [inaudible] is, is difficult, right? It’s also difficult to prepare for something when it’s still very ad-hoc right? It’s like, “Okay, we’re going to discuss something about keywords.” Okay, scramble, figure out. Where’s the tickets on keywords? Where’s the docs on keywords? I haven’t had a chance. There’s not an easy way for me to understand what the discussions are or what the controversy is around keywords. How do I get my input? Those sorts of things to me encourage apathy. I can’t invest the amount of time to do a good job and do a good input. The input that I give is not necessarily, it doesn’t necessarily look like it’s considered in a way that is sort of respectful of what my input is. And so, I tend to want to disengage from that process. And I don’t feel that it actually promotes the sort of unity of Ruby that I'm looking for. Then finally, most of it is focused on MRI discussions. Again, we’re stuck in this ad-hoc process that basically looks at a lot of Ruby semantics as implementation details of MRI. And I object to that because most of the other implementations are not MRI. So, it’s interesting that they were started up. Aaron is someone who’s always doing a lot to try to bring good cheer and happiness to the Ruby community and I think he’s well intentioned. But I don’t think that they’re productive. And I really dislike the fact that -- there’s probably a quote, I don’t know if I can say it correctly, but often the imperfect is -- so, there’s that quote about, “The perfect is the enemy of the good.” Well, there’s another side to that which is that if something imperfect exists, most people won’t cast that aside to do something better. So the idea of Linux or UNIX being kind of crappy, but it’s good enough that we don’t build something better. And so, that aspect of it I don’t like. I don’t like it diverting people like, “Hey, they’re having this IRC meeting.” I said, “Yeah, it’s ad-hoc.” Mostly focused on MRI, very difficult to have a good discussion about, very difficult to prepare for, and very difficult to sort of organize. KATRINA:  I’d like to ask a question about that. How would you, without just -- because obviously, some people have made the effort to start talking, and this is a good thing. How would you improve that at first? How would you say, “Okay, there are these problems with what’s already there,” but we could address the issue with the ad-hoc, or the issue that it’s mostly about MRI, or even somehow address the issue of time zone. I’m not sure how you would do that. But how would you address some of the issues that are present while not throwing away the aspect that people are already making an effort? JOSH:  So, it’s evolution versus revolution. KATRINA:  Or re-factor versus rewrite. CHUCK:  Nice. BRIAN:  I think those are great considerations, right? Can we just iterate on this? Well, I will point back to my talk. There are two things that I think are important to consider. One is, everything’s fine. There’s a shark about to eat you but everything’s fine. And the other one is we just need to go faster. We just need to do more of the same. I don’t see this process as being a helpful change in directions, it’s more ad-hoc. It’s more, we’re substituting a one hour IRC meeting which is hard to organize, from meaningful discussion or even investing in building some technology that helps us communicate better in a way that’s asynchronous or something like that. So, I am not opposed to people putting effort into improving things but why don’t we put effort into looking at some of the aspects of my proposal versus these IRC meetings. And I expressed my concerns to Aaron. I was there for the previous ones. I saw how they went. All of my concerns were expressed to Aaron. Nothing was changed from expressing those. JAMES :  Do you feel that a new tool is required for this? Like I got the impression you didn’t think IRC was good and maybe you preferred some asynchronous communication instead of synchronous. But if I remember right, I don’t think you’re also a big fan of the Redmine thing. Do you feel we need an entirely new tool for this process? BRIAN :  So, we considered possibly using Google Hangouts so we could all have better bandwidth which is good. And the discussion, these are complex technical discussions and some of the issues are nuance, right? So, it would be nice if we had something like that. But then, we have the challenge still of synchrony, right? It’s synchronous. So, everybody has to be there regardless of what time it is for them. Now, we have language issues. So, most of us can write English fairly well, not necessarily speak and understand it easily. So, it introduces upping the bandwidth and changing medium introduces other challenges. Redmine, I should point out that there’s this sort of common Ruby thing now on Redmine. Redmine is MRI’s bug tracker. One of my criticisms for a long time has been that features and bugs are wrapped together in this long list and there’s lots of discussions of bugs. It’s hard to filter that well. It’s hard to understand it. And then, the technology of Redmine doesn’t -- you know, when someone replies to an Email and it sort of scrambles it all. It’s so hard for me to read and get good stuff out of. So, I actually have started an effort to make what I think is going to be a better technology for discussing these things and associating comments with points and having a document that has a structure and links to code, and links to RubySpec and all those sort of things. It’s going to take a little bit of work to implement that but I’m going to continue working on it regardless of whether we ultimately use it. I think some of them will find it useful. But I think, again, the effort that I’m talking about, like I acknowledge that there’s effort in the process that I'm proposing and that I think there’s effort in implementing certain technology to support it. I think that effort is worth it for the quality of decision making for a unified Ruby language for bringing everybody together. CHUCK :  Alright. I think we’re way past our time. But are there any other points that we need to discuss before we wrap up the show? KATRINA :  I have a question. One of the things that --we’ve talked about a lot of the things that don’t work. And I was wondering, what are the things in the current process that actually do work? BRIAN :  We’ve obviously been able to create at least four or five really significant implementations of Ruby. I mean, you can run Rails, right? You can run real Ruby code. So RubySpec, I think, has been a good tool for the Ruby implementations. Matz is, anybody can walk up to Matz and talk to Matz. Matz is a very personable and kind to people and he encourages people. And in the Ruby community, there’s a whole bunch of people. I work for Engine Yard. Engine Yard sponsors my work on this open source project. They’ve never once asked me to do anything that I’ve considered harmful to the project as an open source project. jRuby was sponsored at Sun Microsystems and then Engine Yard and that Red Hat. We have a community of people who have corporate backing for different projects and interests. And we’re still all working on our own, essentially, without any process toward our unified Ruby language and working altogether. So, I think those things are admirable and they deserve to be respected. But I caution people who think, “It’s working okay. Let’s just do more of this.” I caution that, that is not necessarily going to be sufficient. And I will point to a couple things. What I’ve seen is talents bleed away from Ruby to other languages because Ruby couldn’t do things like concurrency well. These recent exploits in Rails and stuff are of great concern. We already have strikes against us as a Ruby language for a bunch of reasons and what we really don’t need is big companies who pay developers to say, “You know what? We’re not using Ruby. There’s no Ruby going to be on my server because I’m not having someone exploit my servers.” Point and click, and you have a remote shell, right? So, I think there’s some very serious things facing Ruby. And while we’ve done a lot really, really well, there’s tons of us who are really happy writing Ruby. I don’t want to sound like a doomsayer but I am concerned enough that I’m willing to try to put these ideas out there and get people thinking about them. JAMES :  I just want to say thanks to Brian because I think it’s a very complicated issue and he’s put a lot of thought into it. And while it’s clear, there’s plenty of areas to debate around it, I think we could all agree that at least some of this would be so wonderful if it was adopted. And I just appreciate the effort he’s put into it. JOSH :  Ditto on that. DAVID :  Absolutely. BRIAN :  Thank you. CHUCK :  Alright. Let’s get into the picks. Josh, do you want to start us off? JOSH :  No, I don’t. We had a really long episode. So, I’m just going to skip my picks. CHUCK:   Okay. JOSH:   So there! CHUCK :  Is that the general feeling or should I continue to ask other people? DAVID :  I have one wafer thin pick just because it’s related to the show. CHUCK :  Okay. DAVID :  Check out Nomic, or Nomic, N-O-M-I-C on Wikipedia. It’s a game about changing rules of the game. And you get into the things like, how do you change a rule? What happens if there’s [inaudible] and that sort of thing. It’s a really, really interesting game for how do you amend something? And that’s all I’m going to say about that. CHUCK :  Alright! KATRINA :  I have picks related to the show as well. CHUCK :  Okay, go ahead. KATRINA :  Three books that all talk about introducing change. One is called ‘Fearless Change’, it’s by Linda Rising. I’m not even going to talk about it, just go look it up. ‘Driving Technical Change’ by Terrence Ryan, and the third pick is kind of related. It’s called ‘The 33 Strategies of War’ and it uses historical, philosophical, religious stories and documents. It’s very well-written and it does talk about change from the other side of things. Like the two first books are very cooperative and the third book is very focused on achieving results. BRIAN :  Those sound awesome. I have one. Can I give my pick? CHUCK :  Absolutely. BRIAN :  I just have one pick, ‘Software Security: Building Security In’ by Gary McGraw. Unfortunately, it’s not on Kindle which bums me out. But yeah, security. CHUCK :  Okay. Alright. Well, we’ll go ahead and wrap up the show then. Thanks for coming, Brian. Really appreciate your input and your passion for this. DAVID :  Yes. BRIAN :  Well, thank you very much. You folks are fantastic. Thank you very much for having me. And if I can leave you with one thought, it’s just that Ruby is a fantastic language. The Ruby community is fantastic. We can build fantastic things together. Please, let’s not take the negative aspect. Let’s not accuse people of bad things. Let’s try to figure out how we can make this even better. DAVID :  I think the reason this episode went so long is because it’s a controversial topic. But we were listening instead of shouting over each other. This could have been a really short show. CHUCK:   Yeah. JAMES :  For sure. CHUCK :  Alright. Well, we’ll wrap this up. We’ll catch you all next week.