00:00:05.720
Hello everyone, my name is Joshua. I work for Ruo, and I have a lot of ideas, but just not enough time.
00:00:08.679
So, I've decided to take up your time to think about my idea, which is a chaotic proposal to reframe the entire typing discussion: statically typed, dynamically typed, weakly typed, strongly typed... it doesn't all matter so much if we consider that we are all human.
00:00:19.800
First, a short introduction: Ruby is a dynamically typed language. This means that when we give the interpreter some code, it performs semantic analysis and will let us know at runtime if there is a type mismatch. For example, it will complain that a float cannot be added to a string.
00:00:40.239
Since Ruby 3, types can also be declared in RBS files outside of Ruby, which means we can now check for type signatures before the code actually runs. With tools like Steep or Sorbet, we can provoke compile-time errors to help us avoid stumbling during runtime. However, I find this configuration unnecessary because, as a Rails developer, I don't like configuration at all.
00:01:07.920
I'm very happy that Matz did not implement annotations in my beautiful Ruby. This allows me to focus on my business problems without having to think about machine problems. There are discussions about whether type annotations are for humans as well. Are they really? Personally, I don't want to delve too deep into this heated debate. For me, it's still all about configuration.
00:01:41.759
I want to propose another solution called conventional typing. We often read type annotations when we look at Ruby code. Let’s make it a guessing game: what types do you think these variables or method names actually are? We can all agree that there’s a class called Numeric. There may exist a function that returns a Boolean, which still doesn't exist in Ruby, like a DateTime include function.
00:02:04.360
The challenge now is knowing how we get from the left side to the right. There’s an RBS prototype that can make RBS files, but we don’t have this for conventional types. I have some, let’s say, naive or basic ideas, and you probably have better ones. Perhaps we could look at our variable names during runtime and record what we see? We could discover our conventions over a fully covered test suite for our projects.
00:02:50.760
Alternatively, we could also build a dictionary using the Par of Gem or Rubocop, or maybe even involve language models in that effort. Naming is a complex problem, and we tackle it continuously.
00:03:01.800
Some questions that remain open regarding conventional typing include how we handle nullable types. The variable name alone cannot account for nil. Can we perhaps extend Sorbet or Steep to drop type annotations and instead look at the names of variables and methods? What even are linters or contracts?
00:03:37.759
These topics could also be included in the typing discussion. My proposal originated from a blog article I wrote four years ago. You can read it if you like and feel free to comment. Thank you very much!