I Think Ruby Isn’t Dynamic Enough…

This is, admittedly, more of a personal ramble than a technical article.

For the past few years, I have become something of a Crystal believer. Looking at recent movements in Ruby from the perspective of a Crystal believer, I sometimes find myself thinking: “That is the area Crystal people have been digging into for years, and Ruby’s real strengths are not really there, are they…?” I have not been able to share this feeling with many people, which has been frustrating.

I myself only really understand Ruby and Crystal, so I have not had much confidence in what I have been thinking, and have spent my time in a somewhat vague state. But if I do not write down these feelings, I will no longer be able to refer back to them, so I decided to summon some courage and write this personal essay.

The incompleteness I feel in Ruby is that many operations lack reversibility. You can define a variable, but it is difficult to cleanly delete it. There is include for modules, but there is no de-include. Mechanisms such as remove_method, remove_const, undef_method, UnboundMethod, and define_method do exist, but there does not seem to be a consistent reversible model for taking methods or behavior out of one structure and safely transplanting them into another object structure.

Ruby is considered a dynamic language, and it permits all kinds of changes at runtime. But that freedom seems to work strongly in the direction of “adding things later.” The freedom to remove what has been added, to decompose structures and reassemble them into another form, or to undo such changes, does not seem to have been systematized very much.

Perhaps Ruby does not have enough of the qualities of a dynamic language.

Ideally, I think it would be interesting if there were a Ruby implementation that, like machine learning, could be given input data and expected output, and then explore at the meta-level, at runtime, how to optimize its object structure. As a foundation for that, I imagine it would need mechanisms that allow it to observe, transform, and reconstruct its own objects. Although I do not know whether such a thing is truly possible.

Even if something like that were realized, in practice it might end up being separated into two stages: “generation of object structures through learning or compilation,” and then “execution.” I feel that would be rather boring.

I am deeply absorbed in Crystal, and have drifted a little away from Ruby. There are several people like that. Seeing this, it would not be strange if some people thought Ruby should also become capable of doing more Crystal-like things.

But what is actually needed is the opposite. Crystal has structural constraints that it simply cannot escape. Crystal is a language that achieves speed and low memory usage by placing constraints on Ruby. Since I am a Crystal believer, I think that if you want to make a language do Crystal-like things, Crystal is better at that. There is nothing interesting about Ruby trying to do the same thing. I want to see what only Ruby can do.

Ruby is, compared with Crystal, an industrial programming language, so I think there are ways in which it cannot move freely. A language that can transform the structure of objects freely at runtime would be dangerous and would probably not be welcomed by industry. Still, isn’t it strange that, among mainstream languages, Ruby is treated almost as if it were the most dynamic language? I cannot shake the feeling that there remains a vast frontier in the world of languages even more dynamic than Ruby.

I hope that someday I will see an attempt to expand the very world of programming itself into an even more dynamic realm.

This post was machine-translated from Japanese into English using ChatGPT.