00:00:12.389
Hi everyone, I want to apologize in advance for my awful accent, the default theme of Google Slides, and for a lot of other things. But I’ll better start with my talk. I'll explain a bit about who I am later when it would be more in context.
00:00:19.060
For now, I just wanted to give a quick overview of what we will be discussing. I want to talk to you about why the language we are using matters, what the spirit of Ruby is, how it matters, why Ruby should change, how it has changed, and finally, about some aspects that disturb people, including myself, and perhaps you, when Ruby changes, or when it doesn't change as we would like.
00:00:34.649
So, the first part is meant to contextualize our discussion. I wanted to start with a quote from an old sci-fi novel about some alien language which allows its users to pass information super effectively. Please raise your hand if you know this quote and what novel it’s from.
00:00:55.390
It's from the classic *Babel-17*. It's very unusual for a sci-fi classic because it is essentially a linguistic novel. Yes, it has spaceships, wars, and aliens, but it mainly focuses on a language that is more effective than any known languages, and through this, it changes the thinking of those who speak it. This is based on the so-called Sapir-Whorf hypothesis, which states that language shapes how we think. The strong form of this theory has been disproven, but its weak form, which suggests that language affects our thinking, is still a good hypothesis or, at least, a good metaphor.
00:01:36.009
When I wanted to start with this linguistic stuff, I wasn't sure if it was appropriate for a programming conference. But then I stumbled upon this slide; it’s an introduction to a talk by someone we all know, presented about 16 years ago, where he explicitly stated that *Babel-17* inspired him to think about Ruby and to invent Ruby.
00:02:07.050
The first big question of this talk is whether the programming language is really a tool of thought. Because when we are just starting out in programming, we frequently meet people who say that professionals should be able to take any language and write in it, because the principles and the architecture are the same. Principles such as model-view-controller or more recently, domain-driven design (DDD) and hexagonal architecture.
00:02:37.300
My experience suggests otherwise, and my frameworks support that idea. What language I am writing in may not seem that important, but the answer also lies in what language we use and how we think about conveying an idea in Ruby compared to Java or Python.
00:03:02.340
The interesting thing is that these two ways of thinking about problems are not contradictory; we always strike a balance between the two. There are people who mostly ignore the phrase-level thinking and can still be successful. Then, there are those who always contemplate any problem from the phrase level up to the architectural level, and they, too, can be successful.
00:03:20.200
But perhaps the most successful approach is mixing both perspectives. So we can say that our experiences, frameworks, architectures, and so on are our tools, while the language in which we think is our material. Hence, the title of my talk is essentially a lie. I want to discuss programming languages as materials.
00:03:41.049
What are the properties of a good material? First, it needs to be pliable; it should allow you to do what you imagine. Once you have it, you could think, "Yes, I want to make a car out of this material," or, "I want to create a plate from it." A great material allows you to work with it as you expect.
00:04:05.530
However, the very best materials are also insightful. As you start creating with it, you might realize, "Hmm, perhaps I could use this material in a different way than I had initially thought." In other words, it encourages you to consider various solutions to problems. So the ideal material not only allows you to do what you want but also prompts thoughts about possibilities you hadn't considered.
00:04:49.449
In general, this is how creativity works: you start with something you are familiar with and use it to explore areas that you are less familiar with, prompting new ideas and solutions. This concept about the nature of material and creativity ties into the topics I want to discuss in this talk.
00:05:16.420
It’s highly personal and could be sensitive to the audience, as I'm discussing what’s read and what's ugly in Ruby. So, I ask you to try to see things from my perspective, and even if you disagree with any particular slides, that might still help you clarify your own thinking about these issues.
00:05:36.269
Now, I probably should explain who I am and from where I'm coming. I am Victor Shepelev, known to some of you as Barack. I am from Ukraine, hence my awful accent.
00:05:43.430
This is actually the farthest conference I have traveled to. I have attended RubyConf in locations like Kenya, India, Japan, Poland, and many others. Each of these experiences has been awesome in their own right. I have been writing in Ruby for over 15 years, and while I managed to avoid Rails for most of that time, I eventually found myself using it as well. Currently, I work for a small Israeli startup focused on revolutionizing transcribing, including live transcribing. I greatly appreciate the hard work that live transcribers put into their jobs, and I want to specifically thank Stacey for the immense effort she's put into this conference.
00:06:30.750
In addition to my work, I mentor students, both for pay and voluntarily. Occasionally, I even meet people on the street to mentor them in Ruby. I also contribute to open-source projects and maintain a lot of useful Ruby-related projects, such as a formatted Ruby reference based on the official docs. I'm also maintaining a commented Ruby changelog for recent versions, which I find quite helpful. I make many proposals to Ruby; while most of them get rejected, some have been accepted.
00:07:13.940
There’s a disclaimer I would like to make: throughout this talk, I will use Python as a small example, not to suggest that Ruby is good and Python is bad, but simply to demonstrate how different design philosophies lead to different lines of thinking. In my subjective view, the spirit of Ruby can be presented by examining its distinctive characteristics.
00:08:06.889
If we start from a simple example of a Ruby class performing basic functions, it becomes evident that you can write almost identical code in many modern object-oriented languages such as Python, PHP, and Java, or even C++. Yet we know that Ruby is somehow different.
00:08:32.300
The first thing that comes to mind for anyone learning Ruby is that we do not have loops like most typical languages. Instead, we have enumerables and method chaining. Blocks in Ruby are quite unique and might be challenging to grasp for newcomers, but they essentially make functional programming feel natural in Ruby.
00:09:03.000
Blocks provide a distinct context compared to languages like JavaScript, where functions are often standalone. Instead, blocks in Ruby create a psychological context that enhances the chaining of enumerables. This chaining principle allows the object flow to be more visible in Ruby.
00:09:37.280
Everything in Ruby is an object, and this idea extends to nearly every statement we make. When we invoke a method, it aligns with the philosophy that classes are objects, making having methods to define class easier. This characteristic of Ruby creates a discoverable environment in which we work.
00:10:02.270
I remember 15 years ago when I first started using Ruby, I was fascinated by the simple fact that I could call methods, such as 'number.floor', and it would work seamlessly. Other languages, like Python, sometimes deviate from this straightforwardness by making some statements functions rather than method calls, which affects the way we interact with the language.
00:10:29.150
Ruby’s rich and pleasant syntax may not seem essential, as some would argue we could simplify it, but these nuances actually matter. Ruby enables you to express yourself with a richness that is typically absent in other languages.
00:10:50.780
Moving back to our primary discussion, Ruby is a mainstream language characterized by a functional flow based on powerful objects and expressiveness. This leads us to think about how effectively we can define transformations on self-sufficient objects. In my experience, Ruby manages to blend both functional and object-oriented paradigms, making its principles hard to ignore.
00:11:18.640
Now, assuming the language is evolving, why should Ruby change? There are several crucial reasons, some more pressing than others. For example, the fundamental spirit of the language holds great value, but some initial design decisions may need reevaluation.
00:11:39.420
Some historical choices, like those cryptic global variables, were advantageous when Ruby began as a scripting language. Back then, scripts needed to be expressive for transient use, but in today’s context, those elements don’t serve actual projects well.
00:12:07.260
Additionally, the rapid expansion of scripting languages means that large projects now being developed require greater functionality, and our design decisions need to adapt accordingly. The validity of this claim lies in the fact that the world increasingly expects languages to adapt and evolve.
00:12:32.060
However, the most critical reason for Ruby’s evolution is that we strive for clarity and expressiveness. As we refine our ability to articulate thoughts clearly, we find that we can express more complex ideas and develop larger systems that maintain clarity.
00:12:49.750
Just like language, we have to invent new words to communicate about new concepts. It's not enough to just rearrange phrases; we need terms for new ideas—anyone can endlessly discuss mundane concepts, but to communicate effectively, we need specific vocabulary.
00:13:07.390
New words must integrate phonetically, semantically, and practically with the existing language, both in Ruby and in natural language. We cannot simply throw in an arbitrary term and expect it to fit seamlessly. In Ruby, we might need to create structures that, while necessary, harmonize with the rest of the language.
00:13:42.870
In summation, language is alive and continuously evolving, and its evolution hinges on enhancing its expressive power through the gradual incorporation of new concepts already present in the language.
00:14:03.660
Now that we understand the need for changes in language, let’s examine how these changes manifest. One unique property of Ruby is its powerful objects, and as we progress through its versions, the capabilities of its objects continue to strengthen.
00:14:18.930
Every new version brings new methods that simplify how we express ideas. However, refinements have created concerns about the potential for monkey patching, and it’s uncertain what this might mean for object functionality moving forward.
00:14:45.650
Changes in Ruby help shape how we interface with the language, making it less like traditional programming which relies on variables and more of a seamless flow of operations and data.
00:15:10.290
An example of this shift is the introduction of enumerators, which enables us to chain singular operations just as we chain operations on collections. This makes our code cleaner and easier to follow. While I may not have created the concept, I truly believe it is one of the coolest yet underrated features from recent Ruby versions.
00:15:53.820
Within our methods, the input and output flow seamlessly from one value to another without interruption. There’s also new enumerator functionality introduced in Ruby 2.7, which relies on input coming from various sources.
00:16:18.200
All these updates aim to make the flow more visible through blocks and clearly defined processes while ensuring they remain dry and reusable.
00:16:38.340
The ability to pass patterns allows for dynamic matching and enhances our coding strategies, enabling new ways of handling values.
00:16:46.120
The recent versions have focused on increasing the power of blocks, thereby improving the overall expressive capacity of the language.
00:17:05.410
In Ruby 2.7, nested references will allow us to manage links and methods in a more atomic fashion, paving the way for potential applications in various contexts.
00:17:21.840
This leads us into a discussion of the polarizing reactions to language changes. Language modifications often spark mixed feelings, and believe me, I too find it challenging to navigate these changes.
00:17:37.830
During RubyConf, amidst the lively atmosphere, I encountered some frustration with new features. Just two weeks before the conference, a significant change, message reference as enhancements, was reverted unexpectedly, leaving many confused.
00:18:00.360
I reflect on my own thoughts about Ruby's trajectory, occasionally facing humility when my suggestions do not align with the core team.
00:18:33.780
There's a plethora of emotions tied to changes within the Ruby language, especially when syntax modifications are involved, leading to passionate discussions about what constitutes readability.
00:19:01.080
When it comes to performance concerns, most people agree on the benefits, but semantic or syntax changes tend to spark heated debates.
00:19:30.290
As we move forward, we should try to approach new features with an open mind, considering their potential impacts and innovative possibilities.
00:20:06.430
It is essential to recognize that there isn’t a single 'right' way to write Ruby. Different backgrounds will lead to diverse interpretations of what is considered 'good' or 'bad' coding practices.
00:20:29.490
Furthermore, those tasked with evaluating code, such as through tools like RuboCop, will often find varied opinions exist even within the Ruby community.
00:20:52.920
Amid these discussions, it’s pertinent to acknowledge the context that Ruby emerged as a flexible language for expressive programming and quick prototyping rather than for large enterprise applications.
00:21:40.180
Ruby is often put into challenging contexts when its qualities are not recognized or when it is forced into domains where it isn't necessarily natural to thrive.
00:22:19.940
Even for large enterprise applications, I believe Ruby can be incredibly effective as long as we remain clear and expressive about our intentions, thus ensuring transparency across our codebase.
00:22:46.220
As I conclude my discussion, I want to share an insight I have about potential pathways for Ruby. It might be worthwhile to explore how this language could adapt to different spheres, where its capabilities could shine.
00:23:23.230
Just as I started with a quote from a famous novel, I’d like to close with another. This one is from Milan Kundera’s *The Unbearable Lightness of Being*, explaining how light it is to make choices and how we often don’t get a chance to revisit these decisions.
00:23:49.510
We might worry that our window of opportunity has closed, allowing Ruby to become the expressive yet misunderstood language akin to modern PHP.
00:24:09.870
However, I hold on to hope that Ruby and those of us who cherish it can continue to foster growth, making it ever more expressive and valuable in our communities.
