Go compiles so fast you can just pretend there is dynamic eval. People sometimes use the "go run" command to compile and run Go source in one operation, that is not really too different from just invoking an interpreter. Go provides a lot of tools to parse Go source, I imagine between that, Go's fast compiler and GDB support it wouldn't be as hard as many compiled langs to support.

Also if I am figuring out something OBO (off by one) prone sometimes I use this to double check myself: http://play.golang.org/

>Go compiles so fast you can just pretend there is dynamic eval.

Yes, the Go people keep mentioning that. You might as well eat soy and pretend it's a delicious steak.

For people that have used good REPLs, from Lisp machines to iPython, it's not the same thing at all.

You lose your state, you loose context, you loose good introspection, etc etc. And if you try loading stuff that's big (several packages as dependencies etc), the compile time starts adding up too.

The big difference is that you lose state every time you do that, the main goal with the eval in LT is to prevent that :)

If there is a way to consistently inject the input to the program (to lead to the same state), I would be OK with editing a Go program to cause (behind the scenes):

  1. moving a break point 
  2. recompile
  3. run
  4. stopping at new break point

I think that happening behind the scenes could be made to appear like live editing in other languages. Go is fast enough compiling and fast enough executing that I think it could be pulled off as not appear laggy as well. But maybe I'm wrong and I don't understand well enough how LT handles other langs.

Have you ever used a REPL?

It is an interactive process. You are build pieces of the application bit by bit.

There is no complete application state where to set breakpoints.

Relevant: https://github.com/jteeuwen/mitosis

But compiling + running means that every time you have absolutely fresh process without old state, so it's pretty different from what you can do with JS or Python.

Why would a REPL be necessary? They don't handle the problem of inspecting a call in context anyways; e.g. it seems like you are hooking directly into the vm for JavaScript to do live inspection. Fix and continue might be sufficient.

It would be a different direction than what you've done so far, but I'd love to see what you could do for statically typed languages. I'm thinking less about repls and evaluation and more about supercharged autocomplete and refactoring tools.

I know this is already done in any number of big enterprisey IDEs, but you would surely take a fresh and creative approach.

Go would be a perfect test candidate.

There is no reason static languages can't support REPLs and evaluation. All of my live orgiramming work so far has involved rich static typing, though I admit more implicit typing would make the experience better....