 Good morning. This is great conference so far. I'm afraid this one would not disappoint you. Since I have been a member of the LDS Church for most of my life, visiting Utah is very thanks. Utah is kind of a special place for me. This is my third visit to Salt Lake City, but the first for the Ruby conference. So this is my pleasure to speak before you. So I'm gonna talk about Ruby 14c41 plus and many asked me what the heck the number. This one is from the old science fiction book Ralph 124c41 plus a romance of the year 2660. This is the very early science fiction book. The storyline is in the year 2660 a genius inventor Ralph 124c41 plus. In that age they have their first name and the numbers this encoded from the both place and the bus areas and then like that. So this is his name. The Ralph 124c41 plus saved his girlfriend kidnapped by a bad merchant chasing him using his own spacecraft. The cheap story though. But it's written by Hugo Gansburg who is very famous for the early days of the science fiction and he's known as one of the fathers of science fiction and it's written in 1911. So it was almost 100 years ago. So the it is very cheap story but it is just because it's written in very old age and in that book the Hugo is predicted a lot of modern inventions. Remember that in 1911 we don't have any just plain rockets aircraft or rockets to the star or no television no no commercial telephone no nothing you know no technology. And in that book he predicted the television and solar power of the aircraft. There was many modern inventions. So in that sense that was quite incredible. And Hugo Gansburg is the famous Hugo Howard of the science fiction books. It's named after his name. The Czech Wikipedia. Ralph 124c41 plus. So the title itself is the kind of town 124c41. So the Hugo knows Hugo knew that he could foresee the future if he can have enough input and insight. So it means if we have enough input and insight we can foresee the future too. Even the future of the Ruby. So that's the name the Ruby 124c41 plus. So in this presentation we try to foresee the future of the Ruby language. So the most the influential vector of the industry is Moore's law. Named from Mike Moore here. Not that Moore though. Gordon Moore who was the president of the Intel company. He wrote the paper in 1964 I guess. And in that paper he quoted that he said that this quote the number of the transistor in the LSI doubles every 24 months. That means that the newest means the power of CPU or computer grows exponentially. So now we have the very fast computer like a PC is not in current days or even part of the supercomputers in 20 years ago. So we have very fast computer and it's getting cheaper and cheaper. We can buy a laptop PC at the plant store for $400 or $300 or less. And then we have very cheaper connection like 50 bucks or less for 100 meg optic fiber connection at least in Japan. And then you don't have them. And in Japan most hotels provide the free Wi-Fi connection. Anyway we have bigger streets to be around and bigger HD hard drive. And you know when I start working with the computer the personal computer it has I don't know 32 K RAM and 320 kilo floppy disk. And think about that. We now have 4 gig memory on the laptop or laptop even bigger. So it's I don't know millions of millions of times bigger than it used to be 20 something years ago. But the Moore's law still exists but the clock loss is getting saturated like this. So the number of transistors goes exponentially like this. But the the gloss of the clock and the power of the CPU is saturated like this just because you know it's it's too fast. And no and it's too hot. And in current days the core of this the CPU is half like the flying up in oven. But maybe in the near future in that late this rate the the temperature of the the CPU core would be something like the burning burning engine the several thousand the Celsius. So it would melt down. So so they had to do something to make it faster. So they try to take they are going to take a the path of many cores in the chip. We had the dual core CPU on a laptop or even quad core or we are getting the more and more cores in the tip. So you know I don't I don't I'm not going to surprise when I see the maybe thousand chip that scores in the chip in 10 years. And then we will have even a data center in the chip in the near future. And the computer is getting ubiquitous. And this one is the cell phone in Japan from Panasonic company. And actually this one is my daughter's cell phone and it has everything. You know of course you can call and texting and the internet access. You had browsers and it has music player in it. And you can pay pay tickets or something and from by this the this phone in with building some kind of the IC payment or something like that. And it is even JVM on it or TV receiver digital TV receiver in it. She watched TV programs via her cell phone. So it is a it is a computer. So we computers are very ubiquitous. Everyone has computers. Even everyone has many computers these days. So in summary how do trends in ID field is faster, cheaper, more ubiquitous and more cores. And the hardware changes because just cause software changes in the software. The runtime efficiency is this becomes less important just because the computers are very fast these days. So probably the 30 years ago the language like Ruby is nothing. It is too slow. But these days who cares? Some cares of course I do. But most of them the Ruby is fast enough for most of the case. And we don't see the assembly of the lately so we don't need them. So and then software becomes more important in many fields. Like I flew from Japan but with the computers no jet plane flies, no reservation system runs, no no airport business. We need software. We need computers. Computers need software. So if we want to start anything in business we need to write some software. So software becomes more and more important. At the same time the software becomes more complex. I think the software is the most complex existence in the history of mankind. Even more complex than any buildings or any machines or anything. It's very complex and very tightly coupled with the part of part. So we just need more software in more in a shorter time. So we need productivity. So that allows us the abstraction like object oriented programming or functional programming. So this abstraction makes, does not make impossible possible. Like if one can implement something in object oriented programming so the other can implement in any procedure way the same software. But with using this paradigm so we can make software faster or more convenient. So the faster computer allows us to use this paradigm to make us more productive. So in summary runtime efficiency is less important and we can emphasize human factor of the programming. So we can consume the power of the the CPU computer to make us happy or make programmers happy. So more abstractions and more comfortable tools are allowed now just because we have more power than the previous days. And now we have the information explosion and from some paper we will produce 988 exabytes in the year in 2010 exabytes. It's 988 exabytes is nearly one Yotta byte which is million... million teller... Meg, gig, teller, peter, exa, Yotta. So it's a billion, billions teller byte. Billion teller byte. We produce billion teller byte data in a year. So it's bigger than the human kind have ever produced in the year. So we have faster machines and we have cheaper connection and we need more software and we have huge amount of data. So these are our starting point and background to predict the future. So let us talk a little bit about the past. So back in 1993, I have the Motorola 6800 machine and the 200MHz and the 200MHz hard drive and the BSD Unix. This is the machine I started working on Ruby. In the year 1993, we worked mostly on C or some C++. At the time, the dominant OS was Windows 3.1 or SunOS and MacOS prior to OS X. Most of them working in C or Pro 4, Pro 5 is not there yet. And we work on OUK and no one uses object-oriented programming in scripting field. So if someone wants to program object-oriented way, so they have to go to the C++ or small talk. So there was no Java yet in 1993 and there was Objective C there. But it's virtually unknown for most of us. So at the year, I was an object-oriented programming fanboy at the time. Actually, I was object-oriented fanboy at the language geek since I was a high school boy. So it has been, I don't know, 30 years or something. And I was a Unix hacker then. So I was thinking about the object-oriented scripting. I knew Pro and it was good too. It was convenient too. But as a language geek, as a language, as a programming language, yeah, I can say it, but I think I could improve the language. There's possibilities for better language in that field. And as an old fanboy, I thought that language should be object-oriented programming language. But everyone told me it would be too slow or too complex or object-oriented programming is just too much for scripting. But no one stopped me. The project, I started working on Ruby on February 24, 1993, which day I chose the name Ruby. I chose the name Ruby just because it's beautiful. You know, I respect Pearl and Raleigh Wall who invented Pearl. And I wanted to choose the name from Joel, the precious stone. But I can do diamonds, wire, and these names are too long. But Ruby is short and beautiful. So I took the name. And afterwards I found out the pearl, the jewel pearl is the birthstone of the month of June. And then Ruby is the birthstone for month of July. So it's a great name for the language came after Pearl, but it's afterthought. And the one thing I regret is the Google ability. So in the early days of Ruby, so we had trouble Googling the language, you know, the Ruby, the cheap Ruby, or great Ruby from Thailand or something like that. We have this kind of problem all the time. But remember in 1993, we don't have Google yet. And I don't know, there was any search engine there? Maybe out of your stuff from digital equipment. And yeah, by the way, according about Google ability, Google had a problem. You remember the language named Goal? I think which is great as a language, but you know, this is the worst for the Google ability, you know, Goal. How can Google it? Yeah. It's only to we have problem to Google a Google product. Anyway, so it took me six months for simple hollow world. Just because, you know, to print hollow world, we have to, I had to implement the string object. To implement string object, I had to implement the object as a super class of the string class. To implement object class, I had to implement the class system. And to implement the class system, I had to implement the method invocation system or something like that. So it's kind of like a chain of the implementations. So it took me six months. So can you imagine how I'm glad to see Mayor Hollow World printed on my console after six months of good effort? But soon after I implemented the Hollow World, that made me realize we need GC. So it's soon it classed, you know, no memory. We allocated too much object. So I tried to implement the GC, then there are other things, arrays, the IOs or something like that. It is a continuous effort until we have something usable. And I released publicly version 0.95 on December 25, 1995. So in a sense, this day is the birthday of Ruby since 1995. Interesting thing is for Java, it was started 1993 and released on 95. So Ruby is exactly the same age as Java. So Ruby is the longest. At the first, I didn't expect that Ruby becomes this big, you know, this big. But Ruby has proven that the object-oriented programming for scripting or teeny, teeny tasks like the scripting, text processing, the web programming or something is very useful. And object-oriented programming can be simple and easy, like the daily scripting. And the most importantly, the programming can be fun again. I started my programming from the language basic. The language was crap at that time, at least. But it was fun. But the days after when I became the professional programmer, the programming is no longer fun just because I have to make money on it. But after Ruby, I and many others agreed with me. And Ruby made my programming fun again. So it's very important. So some say it's Ruby as an Azure language. I don't know about how Azure Ruby is, but I very agree with the attitude of the streaming programming. So if code review is good, so make everything code review by pair programming. Or if test is good, always test. Like even test first as a test-driven development. So from the same attitude, if object-oriented programming is good, make everything object. If scripting is good, make everything scripting. If DSL is good, make everything DSL. That's what Ruby did. By using Ruby, every task like making a website is kind of like a scripting. Very cheap task. Or the C rails, it's very complex in the magical. But it makes our web programming is like a DSL. Rails is a DSL for web programming. So we have a lot of other DSLs. So Ruby makes programming is kind of like designing DSL for a task. So if higher order function is good, allow every method to be higher order function by allowing them to accept blocks. If mixing, which used to be a usage of the multiple inheritance, but DSL, if mixing is good, we disallow multiple inheritance at all and allow only a mixing by using module. So I tend to take the extreme design choice in designing the language. Ruby. So here's the mid-time summary. As a forecasting background, and machines are faster, cheaper, and ubiquitous, we have more cores, even bigger than previous, and connections are very cheap. And we need more software and products become more and more important. And we have a huge amount of data, 988 X of Y this year. And Ruby focuses on programmers, not the users, not the computers. We focus on programmers, developers. And we focus on the productivity of the programmers. And Ruby tends to choose the extreme design choice. The future. What do you think from these backgrounds? What do you think? I expect Ruby, future Ruby, to be faster by allowing multiple VM in the process so that we can maximum utilize the multi-core we have, or we can have the GC implement. So Ruby's GC is written by me, and very optimized for the scripting, very small task. And so it requires what? I don't remember the word. The performance in the scripting program. But these days, Ruby is used for every area, like writing demons, like a long-life process. The current GC is not good at these long-life, huge object allocating programs. So we see rooms of improvement of that area, so we can work on that. For example, Ruby Enterprise Edition did some work that improved the Ruby garbage collector in a certain situation. But the reason I didn't merge it into the core, the standard distribution is just because it slows down other cases. So we have to work on it more seriously. And Ruby can be made faster by using Zit, just-in-time compiler. And we are vaguely planning to work on it. So the future, I expect the future of Ruby to be more powerful through distributed programming, like DRuby or Rinder or some kind of message queues so that we can even utilize more cores or the more process, more computers at the same time. We can provide the faster IPC, like the message pack library written by some of my Japanese friends, and it would be more multi-core-aware. So I expect the future of Ruby to be broader applications, like in a small field, we may be able to use Ruby in embedding field or high-performance computing field. In embedding field, the computers in some appliance or the small computers are small machines, small gadgets are getting more powerful each day. So I saw the digital DVD recorder, the very prototype of the very intelligent DVD recorder from Toshiba company, and which runs on Cell Processor, and its menu systems was run by Ruby. So it was just a prototype and not commercialized, but at least the people behind the appliance company, the thinking about making Ruby or other higher-level language into these kind of the intelligent appliances. Yeah, we expect the alternative implementation for the smaller computers like a cell phone and teeny-tiny controllers, but not planned yet, but I expect to see some day. And the student in the University of Tokyo is working on a project named Atomic Ruby, which is to make our Ruby more pluggable, like a pluggable garbage collector, pluggable string handling. So in smaller computers, we don't need any unicode, any legacy encoding, we just need ASCII. So in the Atomic Ruby project, they try to make these features pluggable, so they can remove these features if the smaller computer doesn't need it. So in the hyper-muscle computing field, we're thinking about improving NRA with LibJet, so the jetting, the processing can make NRA even faster. Well, the MPI, this is very famous in HPC field, so we can provide MPI Ruby ahead of time compiler, so compile Ruby into machine code, so it's slower than the C++, but you can remove some verdance from the runtime system. By ahead of time compiler. A professor in the University of Tokyo is working on the project for Ruby for HPC. And the future of Ruby would be more modular. For example, select a namespace or class box or traits. The select a namespace, some may know or some may not. So it is the limit effectiveness of the name overriding. So we currently have the library named MathN, which replaces the definition of some mathematical operation, so that the one divided by two becomes the rational one, the one-half. But since it replaces the method operator, so its influence is very huge, its impact is very huge, so it may broke other libraries. So if once we introduce a select a namespace in Ruby, so you can limit the effectiveness of this kind of overriding or method replacement into the certain scope, so that you don't have to worry about the breaking other systems or libraries. So we are planning that for the Ruby 2.0, but the only problem is it is quite easy to implement it, but it is quite difficult to make it efficient. So once if I implement the select a namespace in very naive way, it slows down the Ruby by factor of five or something, so we have to do something before making it true. Traits is operational combination of the features or methods. So like the module a plus b becomes a new mail module or something like that. So by adding module, so it is checked, the name conflict would be checked so that we can tell the name class beforehand. So trace is much easier. So I will implement trace soon after I started that Ruby 2.0 work. And the future Ruby would be more functional by explicitly declaration or enamelator as a lazy list. The functional Ruby would be explicit comparing to the pure functional language like Haskell. To retrieve a method in the language like Haskell or even Python, you can only do the object.foo, but we need the object.method by name foo. It's tedious, but in the daily scripting or programming, it is quite few to remove the method. So I tend to choose the object of foo as the invocation of the method without parentheses. And in some language like foo parentheses is called the function assigned to the variable foo, but we have to call the foo.call explicitly or foo square brackets or in 1.9 foo dot parentheses. These are all same. And it's more explicit than this like the Python way or the Haskell way, but it makes us very easy for daily scripting. And we have to do more explicit, like the above one, take 10 lines, this is the Haskell way and this is Ruby way, have dot each dot take 10. But if I called f dot lines, we took everything into the single array, so it reads the whole file, but these are lazy way, so that by this and this, it reads only 10 lines from a file, head of the file. And in Ruby, method like map do not work for the infinite enamelable, just because the map creates the array as a result, but I'm vaguely planning about something like mapX or the name is not decided yet, but some other version of map that would return enamelator to implement the lazy list. So that we have two versions of the map function, which is eagerly evaluate the list or the lazily evaluate the list, just because the lazy one is much slower than the eager one. And so when we don't have to work on the infinite list, we don't have to use any lazy version. Well, in summary, the future of Ruby would be the faster, more powerful, and broader, and more modular, and more functional. And we will keep moving forward. We are not fast to progress, I admit, but we keep moving forward. We are not going to stop, and stay tuned to see the very bright future of Ruby language and help us to make Ruby better, even better. And if you want to help us, we have a lot of things to do, the improving documentation, the exchanging ideas and opinions, and even make an enhancement or debug. We have a lot of things to do, so see the Ruby core mailing list if you want to help us. Then I'm going to make the world better. Yeah. I'm very proud I can influence the world, like influencing the language, other software, and influence so many people. And in that way, we will rule the world. Thank you.