Simpler playground?

Right now crystal play world’s by transforming your code so that every line is sent through a websocket. That’s fancy but it’s the main source of all playground bugs.

What if we simplified the playground? Instead of that, we don’t transform the code. But, if you use puts or write to STDOUT, that is shown on the browser (the current behavior). That requires no transformations to the code, and it would solve all bugs.

The question is: does someone find really valuable to see the value of every line? I understand it looks nice, I just question its usefulness.

tl;dr; I find it valuable.

Sometimes when in doubt of the result of some expression I put it on playground just to check it… but it’s also useful to see the types of all expressions when you want to test some small piece of code.

1 Like

I find seeing not just the value, but the compile-time type of each line really nice. There have been times I’ve been surprised by that, especially in my earlier experiences with Crystal.


Cool, thanks for the feedback! I guess the next step is trying to make the playground use the interpreter without modifying the original code.


If we remove the introspection features from the playground, it would be just a plain web interface for crystal run. That would work just like And I don’t think there would be much value in having the compiler provide that. If we want such a tool, it could easily be implemented as a separate program that uses crystal play.

But the compiler playground’s introspection features can be really valuable. I think it is a great tool for beginners to understand the typing mechanics. As such it serves at least partially as a debugger, only being really easy to use (which debuggers are often not; they at least look intimidating). And there is much more potential in expanding on that!
It’s currently held back mostly because there are a lot of quirks caused by the instrumentation. That’s a huge blocker to promoting it for getting used more.

Basing it on the interpreter seems like a very logical choice because it allows to apply instrumentation without modifying the source code, thus removing all the shortcomings of that behaviour in the current implementation.

The interpreter also allows much more features to be implemented. I would love to see more debugger features. For example, setting breakpoints, and inspecting the type and value of any expression.

But the main goal should be to keep it simple to use. It should be intuitive and offer a good experience for newcomers to familiarize with the language by being able to look closer at its inner workings.