[ibdknox]

As with all tools you have to consider if it's the right place to use it. Things like the instarepl aren't very valuable in highly side-effecting code, but being able to evaluate some block on command still is. You still have to test if that code that removes a file is doing what you think it is as you write it. That being said, you have full control over what does and doesn't end up eval'd - just don't press cmd-enter :)

[tlrobinson]

just don't press cmd-enter

That seems like a dangerous approach. People could get in the habit of hitting cmd-enter, and accidentally run some destructive code.

Perhaps you could sandbox the execution environment so destructive operations are logged but not actually performed.

[ellyagg]

There are environments that have been behaving just this way for decades (emacs elisp buffers, Satimage Smile for AppleScript text windows) and no one complains or claims it's not well worth the risks. How is typing in any destructive code anywhere or command lines at the shell and just hitting enter different? If you don't know approximately what your functions are doing, you should never call them under any circumstances.

In practice, this has just not been a legitimate concern. Yes, you have to look both ways before you cross a busy street; people are pretty good at looking both ways.

[calibraxis]

Yes, in SQL and filesystems, such security relies on permissions at a lower level than your shell/REPL.

(BTW, this post is written using Light Table, rather than the usual emacs. Nice feel! :)

[joesb]

> If you don't know approximately what your functions are doing, you should never call them under any circumstances.

Then why would I use an editor that its main selling point is how easy it is to do that?

[calibraxis]

Well, if you really want to be on the safe side of that particular power vs. safety tradeoff, the repl code could run from (say) clojail. (https://github.com/flatland/clojail)