Comment by heads | Hacker News Reader

Comment by heads | Hacker News Reader

It’s cool to see code in an interpreted language being edited at the repl. Ruby’s style of building everything at runtime using the language itself has always felt delightfully consistent, but also very hard to reason about with static analysis — the usually tool for helping developers in their IDEa and LSP clients.

Far nicer to just execute the program and put a breakpoint at the cursor…

  COLORS.each{ |c|
    define_sheep_class(c)
  }
  sheep1 = Sheep::Bl|

This feels like the only way my editor stands a chance of completing this to Sheep::Black. Is this how Ruby IDE support works (e.g. in the JetBrains product.)

It's too dangerous to execute the code to provide completion support. IDE support has to rely on static analysis.

I suppose you could run the unit test suite?

No, you couldn't. If running the code is too dangerous, then so is running the unit test suite. You'd have to prove that it doesn't do anything observable, like accidentally deleting your home directory, or, if the code is actively malicious, uploading your SSH key somewhere. And if you can do that, you probably also have enough information to provide good completion without running the code.

You can get quite far by symbolic evaluation of a fairly small subset of Ruby - the most common patterns used use a fairly small number of methods.

Frankly I think not going further is a good thing in that it'll discourage people from going unnecessarily far with the dynamic features.

Reply on news.ycombinator.com