I Think Ruby Isn’t Dynamic Enough…

Source: Dev.to

Introduction

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 that perspective, I sometimes think: “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 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. Writing these thoughts down helps me keep track of them, so I decided to summon some courage and write this personal essay.

Missing Reversibility in Ruby

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. However, that freedom seems to work strongly in the direction of “adding things later.” The ability 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.

A More Dynamic Ruby?

Ideally, 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.

Comparison with Crystal

I am deeply absorbed in Crystal and have drifted a little away from Ruby. Some people might think Ruby should 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. It achieves speed and low memory usage by placing constraints on Ruby‑like flexibility. Since I am a Crystal believer, I think that if you want a language to 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, compared with Crystal, is an industrial programming language, so 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 probably not 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.

Conclusion

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.