Comment by IshKebab

Comment by IshKebab 17 hours ago

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 8 hours ago

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.

Reply View 2 replies

IshKebab 7 hours ago

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

Reply View | 1 reply
- vidarh an hour ago
  
  > 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.
  
  Reply View | 0 replies