[IshKebab]

I mean... that sounds like a pretty horrible dev experience. Every time I want to understand a piece of code I have to actually run it? Insane.

For example I'm trying to understand Gitlab's merge train behaviour. Do I have to set up an entire Gitlab instance from source, then create a project, set up CI, run a merge train, all while running Gitlab in a debugger and then set a breakpoint and then finally I can see where the code is called from?

I've also done a lot of work on VSCode which is similarly large but mercifully written in Typescript. For that I just right-click->find all references. It takes 3 seconds.

[vidarh]

In practice it is not. And no, you don't have to run it, but it makes things a lot easier to do so.

And no, you don't need to do what you suggest, you just need to load all the code into a running Ruby REPL.

It is one consequence of Ruby being as dynamic as it is, but another is that the codebases tends to be far smaller. Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.

[IshKebab]

> load all the code into a running Ruby REPL

That counts as running it if you ask me. And I don't see how just loading the code would help you find the callers of a function?

> Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.

That sounds highly implausible.

[vidarh]

> That counts as running it if you ask me. And I don't see how just loading the code would help you find the callers of a function?

Loading it lets you introspect the code for calls. It's not necessarily always trivial to know what the type of the target object will be unless you're prepared to execute candidate methods, but it's rare for this to be an actual issue in practice. The more typical way of doing this would be to call piece of the code but without the elaborate setup you argue you'd need.

You can also use Ripper or Parser to analyse the code if you insist on not loading the code, but you're then making things harder for yourself for no good reason.

And that's really what it boils down to: If you insist on doing things the way you would for a static language, then yes, you will have a bad time.

That's a you issue, not a tooling issue.

> That sounds highly implausible.

It's nevertheless true. I've translated multiple projects feature for feature from C, C++ and other languages to Ruby over the years. It's only implausible to people inexperienced with Ruby.

[IshKebab]

> The more typical way of doing this would be to call piece of the code but without the elaborate setup you argue you'd need.

But how do you call the code if you don't know where it's called from?

Let's have a concrete example. In this `initialize` method how do I know what the arguments are meant to be?

https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitla...

There's no type annotation so the main ways to know are documentation (haha) and seeing what it is called with in existing code. But how do you find where that method is called?

(Note this isn't the best example because I would imagine the `initialize` isn't magically generated, but it is still difficult to search for so it's almost as bad as the magic identifiers.)