Get best of the week

Transcript of my interview with Ruby author


During the autumn conference Ruby Russia I, on the organizer's rights, caught on the sidelines of the author and Ruby gave him a hour interrogation interview. I tried to choose questions that were not jaded so that answers would be useful to us, and not “for all good versus all bad”. And grandfather did surprise me, the old plus developer! Under the cut is the transcript of the interview, the non-trivial opinion of Yukihiro Matsumoto about types in general and cutting in particular, as well as the opportunity to discuss all this in the comments. I’m in touch with the Ruby team Evrone . We invite Matsumoto to Moscow regularly, there is an opportunity to come up with interesting questions in advance for future interviews.

As the founder of the language, you get a lot of suggestions and ideas. What are you most often asked about?

People often ask, “I use the X language. Why don't you add a function from X to Ruby?” In most cases, I reply that this is not possible. We have different language designs and different language policies. We cannot just take some functions from X and add to Ruby. But sometimes we still borrow good ideas from other languages ​​such as Python, JS, or Elixir.

Now dynamic languages ​​add the ability to explicitly specify types. This has already appeared in Python, PHP, and JavaScript (TypeScript). What do you think about this, how will work with types in the third version of Ruby develop?

Rust and Go are statically typed languages. In large projects, hundreds of developers create and maintain a lot of code, millions of lines. In such cases, type checking is convenient, it allows you to detect errors. In other cases, we must write a test to make sure the types used are correct. Test volumes increase with the growth of the project. In this, I see the reason for the popularity of static typing, since its use reduces the number of tests.

At the same time, explicit type declaration is redundant information. In the case of Ruby, the language itself can take care of the types and our code will just work. We want the benefits of type checking, but we don’t want the redundancy of their manual specification. As a Ruby language community, we strive to provide developers with all the features. We will use a file with types independent of our Ruby program. Thus, the Ruby program will not contain type information.

A separate type information file, which we call the “ruby signature file”, will contain information about the types used in libraries, gems and your library code. We will also provide a new tool, the “type profiler”, which will collect type information. It can detect type conflicts or conflicts based on the code itself or type annotations.

Using signature files, you can refine the types you use and help the profiler verify your code. Having collected all the type information in the libraries used and your code, the profiler has enough information to find potential errors.

Future versions of Ruby will be able to do static type checking, to some extent. Still, Ruby is a dynamic language, and the main type checks in it are customary to do during the execution of our code. Type checking "first level" uses information about the types in the code and helps the developer to detect from 40 to 80 percent of errors. Type checking “second level” generates type information based on the code itself. In the future, with the help of such tools, we will be able to provide static type checking in Ruby without the need for the developer to explicitly specify them ...

I like this idea and I look forward to future versions of Ruby to see how good this approach will be. It’s great that you are experimenting with the language. What future do you see for Ruby, in what direction are you developing the language?

In fact, I do not control the language or the community. I just provide technology, and the community decides which way to go. We have enough technology for almost all areas to make Ruby flexible and productive. For example, Ruby is mainly used to build web applications. But I want Ruby to be applied in other areas: research and computing, artificial intelligence, machine learning, in the field of innovation. We are trying to make the technology suitable for wider application.

We developers like to call things different names. “This is a sports car,” and this is a “family car.” JavaScript is a web development language. C is a low-level system language. What do you like to call Ruby, position it?

I would call Ruby “a productive programming language." Productivity is one of the main goals, the main tasks of Ruby. It was designed for people, not cars. Sometimes developers complain about the design of the language when some of the syntax is difficult to implement efficiently. Ruby's design is not focused on productivity, but on productivity. This frees developers to solve more complex tasks related to the project itself. We try to make Ruby as productive as possible, and as productive as possible.

Python does not have multiline anonymous functions due to development complexity. It's nice to hear that for Ruby, you and core developers are trying to make life easier for programmers, despite the complexity of the implementation. By the way, if we started talking about complexity. Imagine you have the opportunity to go back in time and give one piece of advice to yourself young when you first started developing Ruby. What advice would this be?

Do not borrow too much from other scripting languages. Your programming language will be the best general-purpose language. A great focus on scripting will become a kind of rudiment in the future.

During the evolution of the Ruby language, you made a lot of changes, did a lot of experimentation. Some of them were successful, some not. What do you consider to be your greatest success in developing a language, what do you like most?

If you need to choose one thing, then these are blocks. Blocks in Ruby are unique; this is a useful abstraction of a higher order function. They are much simpler than in other languages. This gives both limitations and ease of use.

Coincidence, but blocks are what I like best about Ruby. In my own speeches and interviews, I talk about Ruby as a language with DSL, syntactic sugar, and blocks. Blocks are very cool.

In other languages, such as Swift, if another function is specified as the last argument to a function, then this argument function can behave like a block in Ruby. There is a suggestion for such syntactic sugar even for JavaScript. I am very proud of it.

Yes, JavaScript, with its thick arrow syntax, often uses the last argument of a function as “something like blocks in Ruby”. I can not help but ask the opposite question. What can you call the biggest mistake in a project that needs to be fixed or already fixed?

There is some. Let's start with global variables. They were useful for the scripting language, but now they look like a rudiment. I also regret adding streams explicitly - we need a more convenient abstraction for concurrency. Another of my design mistakes is the lack of immunity of some objects. For example, now you can change the time zone for a time object. Instead of just creating a new immutable object. This is what I regret.

Mutability is complex and can easily lead to errors. But enough technical questions! We humans are social creatures, and it would be interesting to learn about your life, how you organize work?

I am a full time Ruby developer. Half of my time I work on the design of the next version of the language. The rest of the time I’m working on an alternative implementation of MRuby. The mainstream implementation is created by core developers, and I only make decisions that they reflect in the code.

The number of commits on your GitHub is impressive, especially the commits on the day you fly to Russia. Recently, developers have talked a lot about burnout. Do you have free time, hobbies and something that protects you from burning out?

Fortunately, I spend all my time working with open source. I have no pressure from clients, I have no bosses, I set myself the tasks. All this allows me to work without stress. I have no deadlines other than the next Ruby release date. This freedom allows me to feel relaxed. I also try to spend time not at the computer, pay attention to my relatives, family, help the local church, walk with the dog and play with my cat.

Many Russian Ruby developers like Japan as a country, its culture. They watch anime, read manga, come to Japan as tourists. As a native Japanese and software developer, what places and activities can you recommend to fellow developers visiting Japan?

Japan is a diverse country. You can visit futuristic Tokyo, where there is a lot of pop culture, such as manga and anime. At the same time, we have mountains, forests and historical sites, such as old shrines and temples. We appreciate the beauty of sakura blossom and the color of autumn leaves. So it all depends on your taste and preferences, you can enjoy many things: food, nature, technology. You can visit many places, especially in Tokyo. I recommend that colleagues pay attention to the diversity of our country and rely on exactly this in your tourist trips.

Is there anything in Japanese culture and language that influenced the creation of Ruby?

We have no control over such cultural influence and it is difficult to evaluate. For example, in Japanese, sentences are glued together. In the same way that “method chaining” works in Ruby. Maybe this is the influence of the Japanese language. Japan is a rich country and we do not need constant hard work. Open source does not bring money, but working on the main job or relying on the money of sponsors, I and the contributors can support and develop the language and make the best technology. This is also the influence of Japan and the opportunities that it gives.

And the last, insidious question. People often imagine themselves in the place of others, think what they would do, how they would act. Is there something in the position of the author of a popular programming language that is not obvious from the outside?

Creating a programming language is not a very difficult technical task. Many students attending courses in developing programming languages ​​at the university can make their own language and there is nothing prohibitively complicated. The difficulty is that language is a way of expressing thoughts. This applies to both programming languages ​​and natural languages: Russian, English, Japanese. Programming languages ​​such as Ruby, Python, or JavaScript - they help our mind formulate thoughts. This is the main task of programming languages. A good programming language offers an approach to formulating thoughts. For Ruby, this approach is “development productivity and the pleasure of writing code." For other languages, it could be “simplicity”, “efficiency”, or something else. Each language has its own approach. And if you like it,what Ruby offers to formulate thoughts is your language.

More articles:


All Articles