RailsClub 2017. Interview with Luca Guidi, author Hanami: mix FP and OOP in Ruby
Hello! We are preparing for RailsClub , which will take place on September 23 (aaaaa, this is next week !!). The program on the site, 500 cool rubist already registered, we are waiting only for you! You can still have time to drop into the last car and take part in the main Ruby event of the year in Russia.
Pavel Argentov had a very interesting interview with a terrific person. Luca Guidi is a family man, independent OSS developer, author of Ruby, the Hanami framework.
What is your programming experience? How did you get into the Ruby universe?
')
I started programming as a teenager in high school. My professional career started about fifteen years ago - I was working as a webdesign in Java, which was terrible. It lasted a couple of years, it was a pain. Then I switched to Ruby because Rails appeared. Rails made a revolution in those days: web development became less painful. Ever since that was back in the era before version 1.0, Ruby is my main language. In addition to Ruby, I studied Go and a few drops of Elixir: the latter is interesting to me, and I use Go for work.
Do you think Ruby is a better OO language than other languages ​​of this variety?
If you look at things from the perspective of object-oriented programming, much in Ruby looks more natural to the developer, and yes, Ruby is the best OO language. I think Java in this respect is similar to C without frills. Ruby from the very beginning struck my imagination with the fact that everything is an object. Even numbers. A beginner rubist has to get used to this, but having mastered this position, you get access to all sorts of tricks like polymorphism: for example, you pass along objects that behave like integers. Enjoyable flexibility in the design of method signatures with maximum focus on implementation.
On the other hand, I think Ruby has no interfaces. Because of this, it is impossible to strictly determine what kind of behavior is expected from the method, which would be especially useful for authors of libraries. I hope to fix it someday. Also, I don’t think that in the future Ruby will play a significant role of a library in which what is not in the core language will be implemented. New features really work only when they become part of the Ruby core. And of course, the implementation must be done properly.
What do you think are the strengths and weaknesses of Ruby? Does Ruby have a life outside of Rails?
Historically, the greatest strength of Rails is solidity, the fact that Rails has become a “big” platform. This played a role not only in the Ruby ecosystem, but also in the web development industry as a whole.
You will notice that with the advent of Rails language has received an incredible spread. A huge number of people began to use it. This has shaped Ruby's trust. The bad news is that Rails has completely swallowed Ruby, which created unnecessary uniformity. There are a bunch of programmers who know Rails, but don't quite know Ruby as a language. A bunch of gems by default means that you use Rails. Such a situation can be great harm to the language. If you try to work outside of Rails, for example, with Hanami or with system automation, you will definitely have problems. So I’ll say that Rails is the main blessing, and at the same time, the main curse for the Ruby community.
Continuing the theme of the struggle between good and evil, I will say that Ruby is now the best time for the development of an ecosystem. The good news is that if you have a 5-8 year old Rails application in your hands, then despite some problems with switching to new versions of Rails, everything works - because the initial techniques for working with the framework have not changed for more than a decade. So you have everything ok. The bad news is that the ecosystem and language, which do not fundamentally evolve and offer only one way to solve all problems, will eventually disappear. However, many things are happening now that are useful in this regard. First, Hanami has reached version 1.0 this year; more applications are starting to use it in production. Secondly, ROM, which already released version 4.0. Third, Dry-rb is a set of compact libraries for things like data processing and the like. The development of all this is great news. We have a choice: if Rails is the right fit for you as a developer, Rails will give you confidence. If Rails is not suitable, then there are working alternatives.
You wrote Hanami. Why do we need another web framework?
There are already quite a few web frameworks in the Ruby ecosystem, but almost all of them are Sinatra clones. Hanami is different in that it does not repeat Sinatra. It absorbs good ideas from Rails and puts in order those points that need to be improved. I want to advise even those who are not planning to switch from Rails to ever and ever, to look closely at Hanami and other frameworks in order to learn something new.
What gems / ideas do you find most useful in Ruby?
I remind you about ROM and Dry-rb - this is a very interesting mixture of functional and object programming. This is especially noticeable in the Dry libraries. They are very cool, I think that everyone needs to pay attention to them. And not because of HYIP, but because it will help to understand a lot about immunity and deterministic objects. It is important to be able to construct entities so that by supplying something to the input, we get a predictable result at the output.
What do you think the FP should pay attention to the rubists, who mainly deal with OOP?
Immunity and composition again. Not necessarily under pure dressing. Definitely worth a look at how Elixir works. My idea is that it is worth combining FP and OOP. An example that I can give is functional objects. These are objects that, like a function, take some data as input and return a result, but among other things have some stored state or method of calling, in which there is no need to constantly transfer all this state and other dependencies in the parameters. At the same time, by definition, a functional object is designed to qualitatively perform one single task, which is consistent with the principle of single responsibility.
Thus, combining composition and immobility, a functional object always behaves predictably. This is still an experimental and controversial concept, but this is exactly what I want to show in my report at RailsClub. This will be a report about our future - a new way to make web applications with Hanami.
So what are you going to talk about at RailsClub?
I will talk about how to combine OOP and FP. How this became the driving idea in Hanami 1.0. More specifically, I will talk about actions. Actions are objects that “show” a single method that accepts input and returns output — an HTTP response that meets the Rack specification. There are still validators that behave in the same way. The idea is to evaluate what we have now - and standardize the behavior in version 2.0. Another idea is to try to build an application for each yuzkeys, for every feature that is in monolithic applications - to make something like a pipeline from functions combined with each other. When you receive data to the input, you validate, type, manipulate, process, and then return something to the user. I want to show something like this, I want to standardize the set of objects at our disposal. This is already beyond MVC, because in MVC you make a request to the controller, you make a bla-bla-bla, and you absolutely do not know what is happening inside there. And we all would like to have a well-defined workflow, to know when and where the answer will return to us. At this level, our goal is to create a data conversion pipeline. If you describe what an application does, it turns out that it takes data as input, somehow it processes it with the help of a database and gives what came out as output. If you think in terms of data conversion, everything can be broken down into successive steps. If the previous step is completed successfully, you can proceed to the next. If not, sort out the exceptions and errors that the previous step returned. In my opinion, all this can and should be standardized.
What do you advise to read for beginners and experienced rubists?
I recommend the “Practical Object-Oriented Design in Ruby” by Sandi Metz. There is nothing about FP, but this is an important book that helps to understand the OOP part. It would be unnatural to use Ruby as a purely functional language, no one has canceled all the good OOP things that Ruby already has, and they are well described in the book.
The second book is “Exceptional Ruby” by Avdi Grimm. This is a short book that sorts out why in the Ruby ecosystem we use exceptions to signal errors. In theory, exceptions should be used for really exceptional situations, such as “oh, we have lost the database”, but not at all for such things as checking the database for consistency. In new programming languages ​​like Go and Elixir, we never encounter exceptions, only errors, and this makes the virtual machine less heavy. And this approach makes the code more natural. This short, but very serious book shows a concept that strongly influenced my way of thinking.
I also suggest reading about how functional programming works and what we can borrow from there. I can not name a specific book, personally I just taught Elixir on guidelines. It is very useful to have an idea of ​​what is happening outside the Ruby community.
How would you invite programmers to participate in open source?
This is a question of return. For example, Rails, as an open source project, is free in the sense that we do not pay money for their use, but at the same time they help us make money. Therefore, you need to realize the value that the principle of open source carries for the developer and his company, and begin to give something in return. This does not mean that you should deal with open source fultime - it is enough just to help others from time to time. For example, I started practicing Hanami for 30 minutes every day, I am generally a big fan of the concept of small steps. Open source is not required to become a second job. Being an open source developer is more about the relationship, and not about the specific commits to projects. For example, adding a couple of words to outdated documentation takes 5 minutes, but can be very useful for the community. Found a bug - get an issue. And there is also a mercantile side: what you contribute to popular projects looks great in a resume. Yes, with this approach we have to work asynchronously, but I think that this is the future that awaits us. You learn to be patient, get into this philosophy, you get used to adapt to different conditions and concepts. Open source will help you get used to new jobs faster, learn Ruby better, and teach you to read someone else's code. In short, you get a lot of skills that will help you a great job. Or - find a new one if you get bored on this one. Open source helps not only to be a good programmer, but also teaches a bunch of important things besides programming, which can be very useful.
If you want to talk with Luka personally (and this is very inspiring!), There is no place to put off buying a ticket! Registration is here , the ticket price is 9000 rubles.
Read the interview in English - on hype.codes
Thanks to the companies that support the conference:
See you at RailsClub !
Pavel Argentov had a very interesting interview with a terrific person. Luca Guidi is a family man, independent OSS developer, author of Ruby, the Hanami framework.
What is your programming experience? How did you get into the Ruby universe?
')
I started programming as a teenager in high school. My professional career started about fifteen years ago - I was working as a webdesign in Java, which was terrible. It lasted a couple of years, it was a pain. Then I switched to Ruby because Rails appeared. Rails made a revolution in those days: web development became less painful. Ever since that was back in the era before version 1.0, Ruby is my main language. In addition to Ruby, I studied Go and a few drops of Elixir: the latter is interesting to me, and I use Go for work.
Do you think Ruby is a better OO language than other languages ​​of this variety?
If you look at things from the perspective of object-oriented programming, much in Ruby looks more natural to the developer, and yes, Ruby is the best OO language. I think Java in this respect is similar to C without frills. Ruby from the very beginning struck my imagination with the fact that everything is an object. Even numbers. A beginner rubist has to get used to this, but having mastered this position, you get access to all sorts of tricks like polymorphism: for example, you pass along objects that behave like integers. Enjoyable flexibility in the design of method signatures with maximum focus on implementation.
On the other hand, I think Ruby has no interfaces. Because of this, it is impossible to strictly determine what kind of behavior is expected from the method, which would be especially useful for authors of libraries. I hope to fix it someday. Also, I don’t think that in the future Ruby will play a significant role of a library in which what is not in the core language will be implemented. New features really work only when they become part of the Ruby core. And of course, the implementation must be done properly.
What do you think are the strengths and weaknesses of Ruby? Does Ruby have a life outside of Rails?
Historically, the greatest strength of Rails is solidity, the fact that Rails has become a “big” platform. This played a role not only in the Ruby ecosystem, but also in the web development industry as a whole.
You will notice that with the advent of Rails language has received an incredible spread. A huge number of people began to use it. This has shaped Ruby's trust. The bad news is that Rails has completely swallowed Ruby, which created unnecessary uniformity. There are a bunch of programmers who know Rails, but don't quite know Ruby as a language. A bunch of gems by default means that you use Rails. Such a situation can be great harm to the language. If you try to work outside of Rails, for example, with Hanami or with system automation, you will definitely have problems. So I’ll say that Rails is the main blessing, and at the same time, the main curse for the Ruby community.
Continuing the theme of the struggle between good and evil, I will say that Ruby is now the best time for the development of an ecosystem. The good news is that if you have a 5-8 year old Rails application in your hands, then despite some problems with switching to new versions of Rails, everything works - because the initial techniques for working with the framework have not changed for more than a decade. So you have everything ok. The bad news is that the ecosystem and language, which do not fundamentally evolve and offer only one way to solve all problems, will eventually disappear. However, many things are happening now that are useful in this regard. First, Hanami has reached version 1.0 this year; more applications are starting to use it in production. Secondly, ROM, which already released version 4.0. Third, Dry-rb is a set of compact libraries for things like data processing and the like. The development of all this is great news. We have a choice: if Rails is the right fit for you as a developer, Rails will give you confidence. If Rails is not suitable, then there are working alternatives.
You wrote Hanami. Why do we need another web framework?
There are already quite a few web frameworks in the Ruby ecosystem, but almost all of them are Sinatra clones. Hanami is different in that it does not repeat Sinatra. It absorbs good ideas from Rails and puts in order those points that need to be improved. I want to advise even those who are not planning to switch from Rails to ever and ever, to look closely at Hanami and other frameworks in order to learn something new.
What gems / ideas do you find most useful in Ruby?
I remind you about ROM and Dry-rb - this is a very interesting mixture of functional and object programming. This is especially noticeable in the Dry libraries. They are very cool, I think that everyone needs to pay attention to them. And not because of HYIP, but because it will help to understand a lot about immunity and deterministic objects. It is important to be able to construct entities so that by supplying something to the input, we get a predictable result at the output.
What do you think the FP should pay attention to the rubists, who mainly deal with OOP?
Immunity and composition again. Not necessarily under pure dressing. Definitely worth a look at how Elixir works. My idea is that it is worth combining FP and OOP. An example that I can give is functional objects. These are objects that, like a function, take some data as input and return a result, but among other things have some stored state or method of calling, in which there is no need to constantly transfer all this state and other dependencies in the parameters. At the same time, by definition, a functional object is designed to qualitatively perform one single task, which is consistent with the principle of single responsibility.
Thus, combining composition and immobility, a functional object always behaves predictably. This is still an experimental and controversial concept, but this is exactly what I want to show in my report at RailsClub. This will be a report about our future - a new way to make web applications with Hanami.
So what are you going to talk about at RailsClub?
I will talk about how to combine OOP and FP. How this became the driving idea in Hanami 1.0. More specifically, I will talk about actions. Actions are objects that “show” a single method that accepts input and returns output — an HTTP response that meets the Rack specification. There are still validators that behave in the same way. The idea is to evaluate what we have now - and standardize the behavior in version 2.0. Another idea is to try to build an application for each yuzkeys, for every feature that is in monolithic applications - to make something like a pipeline from functions combined with each other. When you receive data to the input, you validate, type, manipulate, process, and then return something to the user. I want to show something like this, I want to standardize the set of objects at our disposal. This is already beyond MVC, because in MVC you make a request to the controller, you make a bla-bla-bla, and you absolutely do not know what is happening inside there. And we all would like to have a well-defined workflow, to know when and where the answer will return to us. At this level, our goal is to create a data conversion pipeline. If you describe what an application does, it turns out that it takes data as input, somehow it processes it with the help of a database and gives what came out as output. If you think in terms of data conversion, everything can be broken down into successive steps. If the previous step is completed successfully, you can proceed to the next. If not, sort out the exceptions and errors that the previous step returned. In my opinion, all this can and should be standardized.
What do you advise to read for beginners and experienced rubists?
I recommend the “Practical Object-Oriented Design in Ruby” by Sandi Metz. There is nothing about FP, but this is an important book that helps to understand the OOP part. It would be unnatural to use Ruby as a purely functional language, no one has canceled all the good OOP things that Ruby already has, and they are well described in the book.
The second book is “Exceptional Ruby” by Avdi Grimm. This is a short book that sorts out why in the Ruby ecosystem we use exceptions to signal errors. In theory, exceptions should be used for really exceptional situations, such as “oh, we have lost the database”, but not at all for such things as checking the database for consistency. In new programming languages ​​like Go and Elixir, we never encounter exceptions, only errors, and this makes the virtual machine less heavy. And this approach makes the code more natural. This short, but very serious book shows a concept that strongly influenced my way of thinking.
I also suggest reading about how functional programming works and what we can borrow from there. I can not name a specific book, personally I just taught Elixir on guidelines. It is very useful to have an idea of ​​what is happening outside the Ruby community.
How would you invite programmers to participate in open source?
This is a question of return. For example, Rails, as an open source project, is free in the sense that we do not pay money for their use, but at the same time they help us make money. Therefore, you need to realize the value that the principle of open source carries for the developer and his company, and begin to give something in return. This does not mean that you should deal with open source fultime - it is enough just to help others from time to time. For example, I started practicing Hanami for 30 minutes every day, I am generally a big fan of the concept of small steps. Open source is not required to become a second job. Being an open source developer is more about the relationship, and not about the specific commits to projects. For example, adding a couple of words to outdated documentation takes 5 minutes, but can be very useful for the community. Found a bug - get an issue. And there is also a mercantile side: what you contribute to popular projects looks great in a resume. Yes, with this approach we have to work asynchronously, but I think that this is the future that awaits us. You learn to be patient, get into this philosophy, you get used to adapt to different conditions and concepts. Open source will help you get used to new jobs faster, learn Ruby better, and teach you to read someone else's code. In short, you get a lot of skills that will help you a great job. Or - find a new one if you get bored on this one. Open source helps not only to be a good programmer, but also teaches a bunch of important things besides programming, which can be very useful.
If you want to talk with Luka personally (and this is very inspiring!), There is no place to put off buying a ticket! Registration is here , the ticket price is 9000 rubles.
Read the interview in English - on hype.codes
Thanks to the companies that support the conference:
General partner: Toptal
Gold Partner: League of Digital Economy
Bronze Partners: Mkdev , VoltMobi , Revo , InSales
See you at RailsClub !
Source: https://habr.com/ru/post/337862/
All Articles