Ruby, like Lisp, really really heavily prefers and benefits from REPL-driven exploration and development.
You don’t necessarily have to figure out how to call the calling function, but you will want to use the REPL to evaluate the above code in an instance’s binding with instance_eval or the like, or use Class.method(:blah) to get the method object, or etc. Or if this is Rails, stick a binding.pry in the controller and get a REPL at the point while you’re interacting with the app in a browser, etc.
The ability to get a full REPL anywhere and explore and manipulate the program interactively is one thing I deeply miss when working in less dynamic languages.
Also true, but worth noting that this is generally a trivial thing to do for Ruby codebases
I switched from Ruby to java/kotlin and am consistently frustrated how hard to impossible it is to start a jvm app locally. But also realize that doing so is fairly useless since there’s no interactive repl anyway.
It’s just a different way of programming I suppose.
Yes, its easy to run, but I found that re-creating 'production' input parameters annoying. In rails, that might be setting the request state (set current user, gen a jwt tokens, etc.) which is required for debugging views or controller code.
I also found ruby made me worse at leetcode problems, since my default debugging taught me to run the code, instead of think through program state.
With Ruby, there is more state stored in the classes than more functional languages (e.g. go-lang or python). Setting that state with ruby in rspec tests is annoying since its not always clear what types and mocks you need without running the code.
Since golang is typed and uses dependency injection, its very easy to know what inputs you need or mocking out values.
Huh, that prompts the thought that it could be cool to have some sort of tracing tool that captures all the state changes associated with a particular HTTP request. I wonder how easy that would be to put together?
