Hacker News Reader

Comment by nielsbot | Hacker News Reader

It would allow for rapid prototyping perhaps

Can you give me an example of what you would expect it to do that can't be done in the Playground and how you would use it?

It strikes me as quite an expensive[0] change to make just to support slightly different development models.

[0] Potentially requiring different code generation mode embedding type information and other run-time information that wouldn't generally be used and then having a system that can use the information to execute arbitrary code. It might be that much of this is already need for other purposes but I wouldn't assume so without information.

Using Injection for XCode gives you live coding close to a Smalltalk system. So you live code on your actual app, super nice for tuning core image filters, or any thing where small iterations are needed between compiles. I literally save hours in a day by not needing a "recompile, relaunch, find my context, repeat" loop.

I think the intention is that Playgrounds will cover this use case but I can see where the set up is the result of complex and disparate code it might be hard to pull into the Playground and repl in the code is helpful. I do it myself in LLDB and use Pry when working with Ruby/Rails to dig into the state at the context and try things out. I can see this working with a debug build with LLVM/LLDB support.

The OP seemed to be picturing a service that could operate in released software and I find that harder to imagine.

Code injection for swift would be great, but there is no reason it would have to be done using either eval or message passing. The debug symbols are enough for the compiler to do hot code replacement, either directly or through trampolines.

Reply on news.ycombinator.com