Okay, so the first question that we had was,

oh, anything you want to say before we get started? Yeah, thank you for coming. Well, thank you for coming. I know it's a long way. Yeah, it was a long way. It took me a little bit less than 30 hours. Well, San Diego will be a little closer. Yeah, a little bit closer.

Okay, so, so, dispense with the pleasantries. So, one question that somebody brought up to me is, when will 1.9 be end-of-life? So, one question that I wasn't sure on, is 1.2 officially end-of-life now?

Yes, I think. Right? How long do you see 1.3 going on? I mean, I know that the last year, you talked a lot about people should just switch to 2.0. So, how long do you want to continue with doing 1.3 patches and stuff? We cannot maintain the three versions.

So, after we're going to have the Rui 2.1 in next December, so the maintenance for the Rui 1.9.3 will gradually disappear. Okay. So, you know, another year or so probably for 1.9.3? Yeah, maybe. Okay. Okay. I know a lot of people want to know, you know, what's been going on with mRuby?

You want to talk a little bit about what you've been, what cool stuff has been going on with mRuby? The mRuby is kind of, it's kind of like usable. We are not in the, we cannot declare it as a stable yet, so that we didn't put any version number on it. So, just latest.

Buyer beware. Yeah, but it's usable and some companies still under the experiment in using mRuby in their production like Internet router, so embedded mRuby in the Internet router so that they can write routing rule in Ruby DSL

or some other company is experimenting embedding mRuby in vending machines. Back in Japan, there are vending machines all over the street. Oh, I remember. Yeah. And then most of the vending machines are really computers with vending features. Can you get a computer

from a vending machine yet? Yeah, you know. You can get mRuby from a vending machine that's run off mRuby. That would be amazing. Yeah, so, you know, we have the vending machine with some kind of LED display and then we have the feature to play games

on that or maybe a lottery or something like that, so they got to create a software for new vending machines, so then they need to create tons of software for vending machines, so they need to be productive, so they would love to embed higher level language

to develop their software. That's cool. Yeah, I have seen, I think I saw that there's an NGINX module to run mRuby stuff and stuff like that. I guess that's probably the target. That's the idea of mRuby to begin with, right? So mRuby is started to be embedded for devices and the software, so

a guy was working on both smart mRuby and NGINX mRuby, which both embeds mRuby in the web servers, so that they can write the extend web servers by using Ruby programs. For example, so you can replace the mod relight by

Ruby regular expressions and Ruby light programs. And then the other application is the in combination of the C group, which is the kind of resource management of the functionality of Linux, so you can

say, limit the bandwidth to each request or something like that, so you can control the web servers in a very fine grain. Sure, gotcha. So how much time has, how do you split your time between mRuby and MRI? Is it mostly

mRuby now, or? You know, as a programmer, I spend most of my time in mRuby, so we have tons of the smart developer back there, so I don't need to work as a programmer for mRuby any longer. As a language designer, I still work

on making decisions for the language spec and behavior, so after that, I just order them to implement, so I no longer work as a programmer for MRI. So have you had to do, have you had to sort of delegate

to others more this last year? Has that been harder, or has it been sort of a progression that you've been doing? You mean C Ruby? Yeah, C Ruby. Yeah, you know, do we have one of the smartest programmer in the world as our lead committee, so I don't have to worry about the implementation.

Very good. So another question that we had was if, and we've had this question before, some of these you've heard before, but people like asking you every year, so I figured I'll indulge them. If you had Ruby to do over,

what would you do differently? Like one thing? You must get this question all the time, though. Yeah, and I can think of two things, like the one is to remove the variable inherited from Perl, like dollar, slash, comma, dollar, something, something, so you know, in the very early stage of the Ruby development, Ruby designing,

so I wanted to replace Perl, so we took many features from Perl, but I admit I did too much. So I'd love to remove these kind of global, the special variables. Then the second thing is

you know, 20 years ago when I started designing Ruby, so the multi-core or the parallel programming is not really popular among us, so we only have the computer with one CPU, so we

don't have to worry about multi-core or something like that. So the concurrency is for the, you know, the programming architecture, so not for the performance. So that's okay to have some kind of a grand thread. So that's what I did, but you know, I didn't

expect, forecast the current situation. Each PC has several cores and the performance of each core is not growing any longer, so we have to utilize these cores

synchronously. So upon that situation, the programming model should be changed. So if I tell myself, if I could tell myself you could whisper to yourself in a dream.

So I will tell you to remove the threads and then put something different like actors. That's a good segue to another question we have which is, I think we talked about this last year too, is have you had any more thoughts about sort of like immutable data structures?

Should they be part of the core Ruby? I know there's there was some discussion at RubyConf this year about a gem called Hamster that provides a lot of immutable data structures, but it can be slow just because of various things, and it would be, you know, people were asking me, oh, it would be faster if we could have it in the core of Ruby.

Have you thought about that at all? You know, all that oriented programming itself requires some kind of mutability, so that having some immutable data does not help that much if we program in the object oriented way, and Ruby is still

considered as an upstarted programming language, so that's I'm not sure yet that having them in the core would have a very huge performance boost. It seems like we're kind of, that you're, that maybe CRuby is sort of slowly, I know that there was the whole discussion

about frozen strings, the ability to easily make frozen strings, which you know, they're a kind of immutable data structure. So the, you know, I'm, we gradually moving toward some kind of the supporting functional programming, or maybe the

immutable data, so but, you know, just I'm not sure yet. You know, having you know, having C written

gem can be run as fast as the core so you have to be in a built in. I guess that's true, so you know, you've, do you feel more like that you want to see more of that kind of branching out in gems rather than having to figure out how to pull it into the core probably? Yeah, so we cannot provide everything in the core,

so that we need to be keep the standard distribution as small as it could. Okay. Let's see, where should we go next here? This is a good one, this is a really important one. Everybody wants

to know the answer to this question. Is Nobu a robot? It's a very, it's a very important question that we want to know. As far as I know, he is a human being. Okay. He wasn't created in a lab. No. In an NACL lab. No. Okay. No. Alright, well you heard it here

folks. Yeah, but you know, I I didn't watch him 24 hours, 10 days. He may plug into a charging plug when you're not watching, that's what you're saying. Okay, well, so the mystery, the mystery remains. Okay.

You know, you're getting ready to do 2.1 very soon. What do you think is the most exciting thing in 2.1? You know, after 2.0, we we try to keep the

compatibility a lot, so that there's no big change in the language. Sure. But, you know, as implementation, she will be finally introduce a generous regardless correction by, for the sake of Koichi's work. So, the, you know, the memory heavy program

would be much, much, much faster, so that would be, that you can expect the performance boost. Any other little, maybe little things that you're looking forward to? You know, you can We add several suffixes to the number so you can write the rational number or the imaginable number

in literal so you don't have to write about the complex, new, something, something. Instead, you can write one plus one i to create a complex number. Gotcha, that's cool. We've got a mathematician, an imaginary mathematician in the audience, I guess.

You had to work that in, right? Have you thought much about 2.2 yet? I mean, I know it's a ways down, you know, and I know you've got a ways for 2.1, but is there anything that you, while you're working on 2.1 or discussing with the other developers on 2.1 that you said, this is a really great

thing, but we're going to wait for 2.2. Have you thought about that? Anything like that? Anything that we could get excited about? Not yet Right now, we are still focusing on 2.1, so delegate to the future.

Let's see Any questions from the audience? I'm just kind of reading over the questions that I have here. Feel free to get up and use the mics, answer questions. Obviously, you can ask sort of whatever you'd like.

Go back to the mic. I'd ask you to use the mics mostly because it's recorded, and if you don't use the mic, then I have to repeat the question and I might get it wrong and all that kind of stuff. Yeah, so let me take a couple questions. So you mentioned that if you could go back and talk to yourself, you would plan more from the beginning to deal with multi-threaded cores and

processors. Do you have any plans of improving that type of support moving forward? You know, maybe 15 years ago, there were virtually no one using Ruby extensively, but right now, probably millions of people using Ruby, and there's a trillion

Ruby programs, so we don't want to break these all at once, so the change will be must be gradual, so that we have to create some kind of transitional path. That's unfortunate. Hi, this is a question from the

Vancouver Ruby users group. Do you have any plans on separating the development of Ruby from the development of CRuby? What do you mean? So, we Maybe more like, you know, it's been a few years now,

working towards the standardization and looking at the standardization. I know that you've previously said that you consider CRuby the reference implementation of that standard. Would you ever say, like, you know, maybe you continue your work with mRuby and you want to say, OK, this standard, I want to work on this standard, and maybe there isn't a reference implementation

anymore, because maybe you've got multiple, sort of a quorum of implementations doing that. So it appears good in the first look, but you know, we have very limited ability to understand the behavior of the

language without actually experimenting on it, so we really, really, really need reference implementation before making the final decision. So the separating, you know, fixing the language behavior without any implementation, reference implementation, or even

experimental implementation, so there's no, that's, I don't think that's a good idea, so maybe the reference implementation will be changed to say, Rubinius maybe, in the future, but anyway, we still need to have single reference

implementation before fixing the language behavior. OK. We had a question about, you know, sort of concurrency things have obviously come up, and you know, there's a lot of talk about concurrency

here, and you know, is there anything that, you know, the other implementations or the community could do to help with that, to help with concurrency in general? Is there maybe gems that you would, you'd want to see people use more, or things that the other implementations could help out on to, I don't know, to assist with?

Yeah, so, you know, there are so many ideas to improve the concurrency in the Ruby programs, but you know, many of them are just an idea, so we need to prove them to work well

with the Ruby implementation. So, if any of you or anyone before the screen have got any ideas, so just feel free to contact us through the, you know,

the bug tracking system, or any way, or any place so that we can work together to make it to experiment and to be better ideas, so if it turns out to be a good idea, so we would love to improve the Ruby implementation.

Okay, a good example I guess might be, there's a number of actor gems out there. Would it, I mean, would it, do you think it would be good if the authors of those actor gems looked at them and said, oh, well, if Ruby had this feature, my actor gem could work a lot better. That might be something that they could contribute back to say, like,

could we add this feature in so that my actor gem could be more performant or work better or whatever. Yeah, actually, at least we'd love to discuss about this. Sure, okay. Great. Yeah. Hey, I see you're wearing a Go t-shirt. I was wondering, first, are we going to drop C Ruby and just have Go Ruby? No.

But for real, what is it you like about Go and maybe more broadly, what features from other languages do you think we might see in Ruby in the future? I'm a C guy, so I used C, I programmed in C for a long, long time, maybe before

you had been born. Some of you had been born. And I love C pretty much, but still, you know, the C is pretty old, so we need to have some kind of system, modern system programming language. And that could be Go in the future, so

I'm pretty expecting Go, but it's too young, so I just want to watch out. What's your favorite? Have you done much Go programming? Not much, but I love Go routine and channels. Just sort of the multiplexing on top of

like sort of fibers in a way, if you will. And it's object-oriented system is pretty much interesting, like duct typing on top of static typing. Gotcha. And anything in those, the second part of his question, any other features in other languages that you wish we could figure out how to put into Ruby?

Well, as language-wise, there's doesn't have to be just syntax, it could be functionality or something like that. Yeah, the functionality-wise, I'm pretty interested in the behavior of the beams, like an hour-long version machine. So the, you know, we have

language like Alexa or something, so I'm watching it, watching them, and you know, I I'd love to and I like some kind of

the software transaction monitor in language like Clojure. Cool. Okay, let's see what else we got.

So, it seems like this year, there was a number of new people added, new CRuby committers added. And I noticed that most of them were not Japanese. Or they didn't speak Japanese. Has it been hard in integrating more non-Japanese speakers into the mix? I know that

especially, you know, I know that Zach had done a lot of documentation and various other things. Has it been hard? Has it been much of a change? Since several years ago, maybe four or five years ago, so the main decision was made in English, so you guys

don't have any problem in tracing our decisions. So having a committers not speak Japanese is not that much problem. But we still have some kind of you know, the issue tracking meeting in Japanese, but it's not that big issue. So we have

the language designers meeting in IRC, you are one of them, so the main so we make the huge, make big decision in English, so you guys having the core committers, non-Japanese core committers

is not a problem any longer. Any other questions out there? I've got a few more on my list, but I wanted to open it up. Oh, we've got one coming up. I thought I'd borrow from a panel discussion in the other room.

Do you believe in good versus bad code, and if so, what is the difference between them? You know, the good and bad are very subjective, so it depends on the context.

In a Chinese proverb, no matter what, white or black, the cat catches the mouse is a good cat. The working code is good code, I believe.

As for the maintenance, some code is less maintainable, and some are not. For the longer project, the maintainability might be more important than others.

Did I answer your question? Yeah, go ahead. As you two are on stage, I would like to hear what do you think about the Rubinius X thing, troll face?

Go ahead. You know, I think, and Brian and I have talked about it, and I think it's a good place to do experiments, to try and figure out what could we take away, where could we see things going in the future, and then once you've kind of figured, you know, it's difficult to know how to get somewhere

unless you know where you're going, otherwise you just wander around and maybe you show up somewhere. It can be very useful to say, okay, well, I want to be out here. I know that I can't get there directly, but I know that I want to be there, and Rubinius X can provide the ability to know where we might want to be with experiments and all kinds of things, and then once we figure that out,

then it becomes, the next discussion is, okay, how do we get to that place now that we know that that's where we want to be? So I think it can be very useful for that kind of thing. I believe it's our responsibility to keep compatibility just because we have to maintain the tons and tons of

Ruby programs running all over the world, so it is kind of difficult to make some kind of drastic change on the language for the Ruby, but, you know, I'm a true believer of diversity. To diverse, you have to make progress.

So without burden to keep backward compatibility, so I consider Rubinius X as that kind of attempt to seek the future, so it may or may not succeed, but that's okay. At least we make

challenge to the future, so to repeat, as a true believer of diversity, so I welcome that attempt like Rubinius X. Yeah, I mean, I think that someone commented recently that, you know, when a language tries to

make a big compatibility change, whether it be from 1.8 to 1.9, which, you know, wasn't really that big, but it still required a lot of time, even, like, Python 2 to Python 3, I guess, is going to be a 10-year transition now. Perl 5 to Perl 6, I don't even have to say anything more than that, I don't think, but it takes a long time

unless there's very small migrations. I mean, there's even, you know, there's lots of C code out there that has never been updated for, like, C89, or let alone 99, for that matter, so it has to be a slow process, but you have to know what that process should, you have to know where you want to be in order

to figure out what the process is. Yeah, I agree. Yeah. Hi, this question is about functional programming in Ruby, but before I get to the question, I just want to say as an aside, I've heard some people complain about the stabby lambda and the dot parenthesis notation, but I think they're brilliant, because if you're doing a lot of functional

programming in Ruby, and you have to use the word lambda and the word call, it just becomes, it's so much more cumbersome, so I really like that. Anything that you'd like to tell us about your view of the role of functional programming in Ruby, and any developments that may be coming in the future with that? Stabby lambda. So I remember

a few years ago that everyone was complaining about stabby lambda. It's really gone now, though, isn't it? No one really, no one's, everyone's like, yeah, fine, whatever, we'll use it. Yeah, I won. You did win. You absolutely won. Well, you know, we've got more Unicode now. Should we, you know, should we put the actual lambda Unicode character as the option for it in the

grammar? Is it easy for you guys to write a lambda character? It's impossible. It's like shift-alt-k-l-m or something like that. I don't know what it is. It's a lot easier to write emoji now than it is to write a lambda character.

Oh, is there a lambda emoji? Oh, what a missed opportunity that is. Yeah, maybe train character or something. The train character! Definitely not smiley poo, not smiley poo. But the train character I like. There's someone's exercise for tonight. Send the patch in to parse.y. Yeah, maybe fat aloe.

Anyway, so, yeah, stabby lambda, yeah, that was a good invention. I have a question. I wrote this down. This is a good segue. Do you write stabby lambda where the arguments are not in parentheses? Do you ever do that? Do you ever write

hyphen x stab space x comma y curly brace? I find that really hard. That's always my thing. I find that super hard to read. But that's just me. Do you ever write that? Sometimes. All right.

Yeah, I don't know. Eric, was that a Seattle style stabby lambda? Okay, so no Seattle style on the stabby lambda yet. Yeah, maybe in the code golf.

Yeah, we can read these two characters. Anyway, what was the question? Functional programming? The other question was what about dot parens? The actual question was... I'm sorry. It's okay to make a diversion. We've got time to burn.

The actual question was what do you see as the role of functional programming in Ruby development and are there any developments coming in the future you think? It's quite difficult to adapt the full functional programming in the object programming language like Ruby, but some kind of adaptation of the functional

programming is good, like a functional combination or something like that, so it would improve the efficiency or the productivity of your program. So as long as it's good

practice, I'm pretty positive about accepting some part of the functional programming, so if it is useful, as long as it's useful, I'd love to support some part of functional programming.

So 20 years ago this was kind of a pet project that you were working on as a language, and it's grown into something that we all use and is used in many different contexts. I wonder how much risk are you usually willing to take in implementing a feature

and how much you feel like you can't take the risks and put in a feature just because you want to? As long as it doesn't break the existing code, I'm pretty positive about the changing or enhancing programming language.

I have a good example then. You can dig back. You might need your laptop to figure this one out. Okay. I went back and I was playing with writing some new language, whatever, for fun, and this is sort of related to dot parens. I found that in 2007 maybe

that you had put in the ability for if there was a local variable that you could just call that local variable with parens, no dot. Do you remember that? Yeah, I remember. But why didn't you take it out? You know, too many people use local variable p. Oh.

And so they would do p parens and you'd end up calling dot call. Oh. That's the best answer? I would never have thought of that answer. But that totally makes sense. Okay. For those of you who haven't trolled back in the annals of random parser history, there was a patch

and I think it was during the early 1.9 experimentation phase. At first I got that idea. I thought it was brilliant. Yeah, absolutely. So I considered myself as a genius. Yeah.

So soon after that, I must have got troubled. Oh, yeah. Because it was in there for like six months, but it was pretty early 1.9 experimentation branch where there was a lot of things in there. Basically it was that I think you probably got it now, that if there was a local variable

you could just, if you had the name of the local in parens, it would actually turn into dot call on the local variable. And so it's sort of what now dot parens is. But that totally makes sense that, yeah, p would sort of screw it up entirely.

Stupid p. Ruined a good thing. This is another good question. Do you feel like you're, you know, so you've been working on one project, you've worked on other projects, certainly, but one big project for 20 years.

Have you seen your, the style of the code, your style of your code evolve over time in such a way that sometimes you go back and look at something and be like, oh man, why did I ever think this was good style, that kind of thing. Has it been, do you find that interesting? Because it's been one big code base, obviously there's a lot of authors, but you always, sometimes

you go back in and find like, oh, I wrote this back in, who knows how long ago, because I can tell, because the style is weird or something like that. I don't know. My style has been changed for a long time. So, interestingly, so when, I'm a language geek, so I'd love to look into the other programming language,

source code, and when I look into the other language, I don't remember the name anymore any longer, but, you know, that source code looks so familiar. So, and I look back into the Ruby, counterpart of the Ruby source code, it was identical.

It was copied. So, that source code was in my style. Yeah, that was quite amazing. My programming style hasn't been changed for the last 20 years, so, as a

programming style-wise, I haven't that kind of feeling, but, you know, as knowledge-wise, I have improved, I believe, so maybe the algorithm I chose was wrong sometime, and maybe the data structure

I chose was wrong back in 20 years ago, but the programming style-wise, I haven't changed. Another sort of soft question, if you will. Has your, like, development setup changed much?

Do you still do most of your work on Linux? Yeah, I still use Linux, and I still use Emacs. I'm an old guy. Have you upgraded your laptop recently? Yeah, but my laptop is two years old, so maybe it's time to upgrade.

So, I'm sure you could find someone to get you a laptop, if you're going to need it. Yeah, we have a question. What's... How Ruby is changing Japan? Changes what? How Ruby is changing Japan?

Do you see a lot of Japanese programmers? I know that for a long time, Ruby was bigger in the US than it was in Japan. Do you feel like it's changed over time? Maybe, I don't know. I know that one thing that we talked about

years ago was it was harder, that one of the reasons to do the standardization was you wanted to allow Ruby to be used in more Japanese companies, because a lot of times they required using a standardized language. Has that helped, or do you know? I guess so. Some, you know, the

government subsidiary organization requires that kind of standard to use language in their systems, and having ISO standards that could help to choose Ruby as the implementation language. Maybe some bigger company

like a Japanese industry is basically controlled by bigger companies like Toshiba, Hitachi, NNC or something like that, and Fujitsu. These companies gradually accepting Ruby to implement their systems. So, you know, a few years ago

also, you know, Ruby is used as a hobby programmer, or the small startups, which is not as popular as in the States, but currently, Ruby is used from bigger company to small company, so

as long as in the web field, Ruby is pretty popular in Japan as well. So that's a good segue. I know that Ruby World is coming up, and I know that we've also got the Ruby Association. Do you want to give us a preview of what's going to go on at Ruby World? And the other question I had

was, do you feel like, you know, has the Ruby Association been has it helped Ruby inside Japan, or helped Ruby in general? Do you think it's been, has it been nice to have? Back in 1927, I guess? You know, the open source world and the IT

industry world are pretty separated back then, so one of the purpose of the Ruby Association is to bridge the gap between the suit people, the geek people. So we are doing pretty well as they see in Japan, so we have some kind of

certification to provide proof to be a Ruby programmer, to suit people, and then some kind of grant to help

the TD works to the geek people, like maintaining 193 or something. Yeah, yeah, yeah. It's supporting Ruby itself. Yeah, supporting itself. And we have some kind of grant like helping scientific Ruby to enhance the

Ruby application to the scientific computing, or maybe some kind of improvement of the web, or even mobile world. So, what kind of stuff

is going to go on at Ruby World? I don't think probably most of the people here have been to Ruby World. Yeah, the Ruby World conference is held in Japan in two weeks later, I guess? And it will be held in Matsui, Japan, which is my hometown, and the local government sponsored

that conference. And the conference itself is mostly focused on businesses, so maybe half of the attendees wear suits. It's kind of exceptional for Ruby conferences. Yeah, and part of the

purpose is to introduce some kind of the use case of the Ruby in the IT field, like our suit people want to know how other companies use Ruby for their businesses. So the sessions, half of the session is focusing on

the use cases. The other half is focusing on introducing new technology to people. And we invited Mojombo off GitHub as a keynote speaker, so he introduced some kind of social calling to Japanese people.

Cool. And it's his world conference, so we have the attendees and the speakers from other countries as well. It's beautiful there if you guys ever get the chance to go. It's a lot of fun. Yeah, we have a question. I came in a few minutes late, so I apologize if someone already asked.

But Matt Amenetti told me this morning that you told him we should be using a different version of the malloc C library called tmalloc. Jmalloc, I guess. Jmalloc. That it would allow us to run, you know, back to garbage collection. It would help us run our programs faster

or release memory back to the system more quickly. Can you explain what you meant? The C Ruby delegates the underlying memory management to malloc and free, so it's up to this implementation to how to return these pages to

the system or not. So some implementation malloc keeps every page allocated inside to improve the performance. But that means the process will grow and grow and grow. So a friend of mine working in a program named

Fluentd, which is kind of the high performance distributed logging system, and they had some kind of memory program. So the process will grow using the glibc malloc.

So they doubt about that garbage collector, so there should be memory leaks. I worked with them and found out it's malloc that keeps memory. So they later, they replace

the malloc from clib malloc to je malloc, which returns the memory pages, the unused memory pages, and then the process size will reduce dramatically. So it's quite easy to use that. Just use the LD play world.

So then for them, it has a dramatic effect. So maybe you have some kind of the malloc problem, the memory size problem, at least you can try je malloc if you are using Linux. A real pro tip here, people. Pro tip, thank you.

I think we've got time for a couple more questions. So, yeah.

I think people realized why it makes and we plan to implement so then

I expect this situation can be improved next year or something. That's good news. So after that, you don't have to worry about je malloc. Double pro tip. Look at that.

I find the internal C code that you wrote for the MRI to be very elegant and a source of inspiration, but at the time you were writing it, C++ seemed to be very in vogue. Why did you not use C++ for Ruby? Can you talk about that a little bit?

It was the early 90s. C++ was cool. You wanted to be cool. You were a young kid. There are several reasons. The biggest one is having C++ object system and the Ruby object system

will confuse my brain very much. So the C, not having object system, is much better for me. The second one is, I used to be a C++ programmer and I was troubled. I hate

C++ back then. Back then we didn't have the templates, we didn't have the multiple inheritance, but the compile time was so slow it would take hours to compile. So that's one of the reasons I didn't use

C++. I don't know, I've never asked this question to you. Were you thinking at the time, this is just a hobby, I'll open source it. You probably weren't thinking in the terms open source, but I know that when you were talking with your friends and you put the source code up, were you thinking at the time,

I'll just let anybody play with this and that kind of thing. Is that true? Yeah, I was raised by the free software. I learned programming through reading Emacs source code and I used GCC to compile programs, so I learned a lot from

reading other free software, free implementation of programming languages. So it's quite natural for me to make my software as open source. So I'm a free software guy. So I didn't have any trouble

to think about free software. To get back to his question, if you were reading a lot of free software, a lot of free software at the time was all in C. There probably wasn't very much free software in C++. I don't think GCC got C++ support until after that anyway. So it would be very difficult to be a piece of free software and be C++. That might be another sort of good reason.

So this is another question that came to me. Maybe wrap up a fun question for the end. Do you want to tell the story about how it was almost called, like it started off as a LISP implementation before it turned into Ruby?

Do you want to tell that story and then we'll kind of close on that? I have been a big fan of LISP programming language for a long time. But I am just a wannabe. I have been just a wannabe. I never had a chance to

program in LISP in reality. I just write some small piece of LISP code and this is quite nice. This language has a lot of features. This language gave me a lot of freedom. So I like this programming language. Then at the time I started to

create my own programming language, so I wanted to make my programming language as free as LISP, as powerful as LISP, but with parentheses and object system. In that way, I implemented

some kind of LISP version machine and then I put some kind of the subset of small talk object system and put the pro functionality on top of the object system so that is kind of like the

process to create the design and the implementation of the Ruby programming language. Did it look like, was there a time where it was actually a LISP before you started being like, I think I want my own syntax. No, it is like that from the beginning.

I actually have two questions. First, did you know that grape nuts are neither a nut or a grape? He's just being silly. Grape nuts are a cereal.

They are a cereal. And they are neither a grape nor a grape. Don't worry about it. I'm sorry. So the second question is, and this is I'm just asking this because it's a RubyConf tradition.

When are we going to get a macro system in Ruby? That's a good list. I will return you a traditional answer. Never. Well, I think that's probably a great place to end. If no one has any other questions,

thanks again for coming everybody to RubyConf this year. Be sure to say thank you to everybody working in the registration desk on the way out and I will see you all in San Diego next year. Thank you. See ya.