To celebrate the 25th anniversary of Ruby, Koichiro Sumi, CEO of SideCI, Inc.,Tokyo-based tech company, and also a long-time Ruby fan, had a chance to interview Yukihiro “Matz” Matsumoto, also known as father of the programming language Ruby.
Koichiro: Congratulations on the 25th anniversary of Ruby. Can you tell us what makes you happy while developing Ruby?
Matz: It makes me happy when Ruby users reach out and tell me about their positive outcome! For example, a student who didn’t find programming much fun now enjoys coding by using Ruby, someone who has achieved a great job or had a raise. I hear these kinds of stories a lot. I might sound like I am promoting Ruby by saying only good things, but it is great that we can actually bring these positive results.
Koichiro: Definitely. If it had not been for Ruby, I couldn’t have finished my thesis either. Ruby has helped me so much since I was a student. Our product initially targeted to Rails app source code.
The Milestone for Ruby
Koichiro: Ruby has continued growing and getting more recognition. What was the big milestone for Ruby in your opinion?
Matz: In 1999, Keiju Ishitsuka and I wrote and published a book about Ruby. In 2000, Programming Ruby by Dave Thomas and Andy Hunt was released, and the following year, in 2001, the first RubyConf was held. I would say around the turn of the 21st century was one of the significant milestones for us.
Koichiro: Was it around the time Rails 1.0 was born?
Matz: Rails came in much later. It was July 2004 when Rails 0.5.0 was released. If my memory is correct, I was invited to JAOO Conference in Denmark in 2001 and 2003. In 2001, I vaguely remember Dave Thomas, me. And David Heinemeier Hansson(DHH), who was a student volunteer staff and a PHP programmer back then. Three of us had some talk about the programming language or sorts.
Koichiro: Wow. That is exciting. And the conversation lead (DHH) to Rails.
Matz: Maybe. After that, when DHH was remotely working for 37signals (it is now Basecamp), he released a Web framework in Ruby, which is now called Rails.
Koichiro: I see.
Matz: Until around 2004, many people either hadn’t heard of Ruby or had heard of it but hadn’t tried it yet. They would see us as if we were working on something in a completely different world and wished us well from a distance; they thought they had nothing to do with Ruby. In 2005, the number of Ruby users started increasing. It was personally rewarding for me to see that people actually used Ruby.
Koichiro: Since then, Ruby has turned into the programming language that everyone knows. When I started using Ruby in 2009, it was already recognized as a common language.
Matz: I think people saw Ruby as a hot technology around 2009 at its peak. Ruby has become an ordinary programming language. But being ordinary is scary. Something that we take for granted now may fade out eventually when a new technology rises. What the core dev team of Ruby is working on now is how we can continue delivering a new Ruby for the next 25 years, following the current technology. We want Ruby to be the language that is around for a long time and people still use, not the one people used to use.
No More Coding Standards? Standards for Matz
Koichiro: Now, I would like to ask you some questions that are related to our product SideCI. What do you think of coding standards personally?
Matz: I am not the type of person who cares about coding standards much. I am aware that many do care.
Koichiro: Yes, they do.
Matz: Some people would even say they can’t get started without a coding standard. That makes me wonder “are you really working? That is something you should think.” But if things like indent width and whether using spaces or a tab are not unified, editing them will result in many diffs. So, those things should be discussed and unified in advance.
Koichiro: Autoformat may change the parts you didn’t even touch, too.
Matz: I think that should be avoided. But as long as we prevent unnecessary diffs from occuring, I think we don’t necessarily need coding rules. Here is an example. Some rules require us to give a variable a long name. However, if the variable only appears three times, do we care if it has a long name or if the name is the letter i? That is what I think.
Koichiro: If it is used only three times, then it doesn’t matter at all. It could be an issue if i is used globally, but then no one writes such a silly code.
Matz: If we think straight, we can figure out that much. Even if we happen to write such a code, we could have others point out that “this is not enough” when we review the code because we have a legitimate reason that this is not good.
There are quite a few people who are happy with (*the default setting of) of RuboCop among the Ruby community. The default setting of RuboCop is very much different from my preference, and some of its rules puzzle me. I am aware of the value of static analysis tools like RuboCop, and I respect the developers at RuboCop though.
Koichiro: I am not too fond of the default setting of RuboCop myself. We sometimes have reluctant comments on our Slack channel like “this pull request has been merged to RuboCop itself…”
Matz: In general, programmers have an independent tendency, so we should decide what we do. If someone tells you to follow all the rules provided as if they are treating a baby, I think they are not treating you as a programmer appropriately. I don’t want others to treat me like that, and that is why I don’t want to treat other people like that either.
Matz: If there is a good reason such as we can reduce a pain in the neck with assistance by tools, we can incorporate and let the tools check our source code.
Koichiro: As far as SideCI is concerned, we offer users suggestions they can choose whether they accept it or not, so our product doesn’t make them follow our way.
Matz: That is wonderful!
Koichiro: Some people will have a hard time deciding how they should write their code though. It may be a bit extreme to ask you this, but what would you suggest for those people? Do you think they should code freely or try something else?
Matz: It depends, but if it is for a software for their work, then they should probably not deviate from the code their colleagues write. If it is for an individual project, then they can do what they want. In that case, if they write terrible code, the terrible things only come back to themselves(laughs).
Koichiro: I had a few inquiries like this from my clients recently. When they are asked to review some code and take a look, they don’t know what to do because the code meets its functional requirements and works while its maintainability is low due to the numbers of copy-and-pastes in the code. If you were in this kind of situation, how would you react?
Matz: In that case, I would mercilessly reject the code.
Koichiro: Merciless rejection (laughs).
Matz: Actually I would most likely tell them why I cannot accept it, then reject the code. In that case, I would mostly say that I am concerned with the code’s performance or low maintainability due to the duplications, then reject them. In some cases, I would take over the code, rewrite and commit them.
If it is for work, we have a deadline, so this could be a bit tricky. But whether it is for work or an open-source software, I will have to maintain the code I commit. So my criterion for choosing code is this. Will I be able to maintain this code?
Koichiro: And if the answer is yes, you merge, and if no, you reject.
Matz: That is right. Especially for open-source software, someone creating a pull request to me doesn’t necessarily mean that they will be maintaining the code even if the code triggers some problem in future.
Koichiro: Like you can’t get in touch with them or they won’t respond to you (chuckles).
Matz: In that case, I need to decide to take responsibility for the codes when I review the code. Some people harshly refer to pull requests as throwing garbages, and I understand their point. If it is for work, then we can tell the engineer who created the pull request to maintain as the owner of the code.
Koichiro: I understand OSS has that aspect significantly.
Matz: So whether I can accept the code as the code I will maintain or not is one of my standards.
More Interactive Programming will Await us.
Koichiro: SideCI is a development support tool which allows engineers to focus on more productive work at ease by assigning a part of code review process to a machine. If you have any supportive message to SideCI, can we ask that?
Matz: I think software development will become more interactive in future. If the source code we write is grammatically incorrect, machines will still point it out as a syntax error, but maybe future computers would even go further and suggest us the correct source code we intended to write from the wrong source code. Using that kind of assistance from computers, we will be able to create a software with better quality or find errors at its earlier stage. As for Ruby, the language itself will remain compact as it is now, and advanced analysis such as type inference will be done by external tools or something like that. So, we will eventually only see the Ruby code itself. If we want to check something, we will ask IDEs or editors, and they will tell us the type of the variable, which methods can be called, or maybe even tell us that our code is inconsistent overall.
In that sense, the fact tools that support code review like SideCI exist in the software development process is embodying a part of my ideal world.
Koichiro: Thank you very much.
Matz: As I mentioned the language server protocol at my talk today, we cannot assume that interactions between developers and computers remain the same eternally. But it will be ideal for software development if computers could assist us in understanding software and help us code so we can ship appropriate softwares. As computers are becoming more intelligent, it would be great if we can leverage that to make things easier for programmers.
For more information about Sider, please go to our website.