DEV Community

Rory O'Connell
Rory O'Connell

Posted on • Updated on

A new Smalltalk style environment for Ruby: the beginning

The past months I embarked on a book writing project on accident; a book on low level graphics programming. It uses Vulkan though the concepts focus on graphics programming, not Vulkan specifically. I looked at all the notes I gathered the past couple years and realized I had all the material I wished I had when I started learning something new. I estimate it's about one third written, about 40,000 words or a bit over 100 pages so far, leaving out diagramming, proofing and editing. I never say anything about what I'm doing until I'm sure I'm committing to it, so I'm publicly committed to finishing it.

It's a slog writing a book full time. There's bursts of activity and then I have to take a break and focus my mind on something else. I've felt confident lately on my graphics programming and low level programming skills so I attempted something ambitious.

I always loved working in Smalltalk environments. The super tight integration between code, the environment, the debugger, and the editor all being one and the same is so powerful. Modern tooling tries to get there and always fails because today's systems aren't designed with that integration in mind. We're frantically gluing together disparate components trying to achieve the same situation Smalltalk already had. Emacs is pretty close. A modern browser with Javascript is closer than any other major technology we've had before but will never reach the same integration as Smalltalk or even Emacs due to fundamentally how a browser works.

Working within Ruby environments exasperates the disparate component issue. Ruby as a language takes strong influences from the Smalltalk language. Like a Smalltalk environment the only definitive state of a Ruby environment is the state of the VM as it's running. Anyone who's worked with Ruby knows the normal edit file -> run in Ruby VM loop has a fundamental problem. What you write in a separate file may not be what actually runs in the VM at runtime.

So my current side project is exploring a question. Is it possible to build a Ruby environment like a Smalltalk environment?

Here's an example of about three full time days of work without knowing anything in advance about MRuby. Here I have an GUI and MRuby VM connected. Right now it's brittle and will crash easily with the right Ruby incantation. Still, this is a live MRuby VM wrapped in a GUI and the GUI is (currently partially) driven by the Ruby VM. Here you can see using the GUI modifies the state of the Ruby environment and then the GUI reflects the change back since the GUI reads the Ruby environment. Even though it's super hacked together it already feels astonishingly similar to the Squeak or Pharo Smalltalk environments.

This is becoming a really, really cool project I'm surprised nobody did yet from all my research. It's been keeping me up at night with the possibilities.

I still have a book to write though.

Top comments (2)

choallin profile image
Gernot Gradwohl

This looks really interesting!

I'm really impressed with how you setup Ruby within a gui. Am I correct that you are gluing ImGUI with mRuby together? It appears to me that Ruby is running inside your event loop, does it have access to the gui to modify the gui itself as well? What parts of the gui are driven by Ruby? Is there a repository to look at the code?

Two or 3 months ago I took a look into Pharo Smalltalk as well. I was really impressed how well everything seems to work together and what you could achieve with this. But a disadvantage I personally didn't like was that the development wasn't just happening in the source but you would have to create some configuration that were stored in some arbitrary place in the Smalltalk VM. In the end this was the main point that put me off. But the concept behind the whole environment is really great. It would be awesome to have something similar in Ruby as well.

roryo profile image
Rory O'Connell

Yep, ImGUI and MRuby. Right now the Ruby VM triggers on events from the render loop, yes. Similar to how a Ruby VM is idle with Rails until a request comes in. No plans on ticking the VM outside the render loop right now, I'm sure I'll hit some reasons for that soon.

No code publicly yet. This was the results of three days of hacking without knowing anything about what I was getting into in any front. By that I mean the first time I cloned ImGUI, mruby, building, and start gluing. It's extremely fragile at the moment, the vulkan renderer is barely functional and the whole thing crashes with the right Ruby incantation. Once I have more direction and start shoring up the exploratory code I'll put it somewhere.