[aoe]

Looks like a good concept, but I really cannot see how this would work for functions with side effects? What if I write `File.rm("something")` and press enter?

And how would this work with, say, Ruby on Rails development?

Can anyone throw some light?

[spjwebster]

This is an issue[1] that SublimeLinter ran into when syntax checking Perl modules. Code in a BEGIN block (which gets executed at compile-time) could actually delete files when using `perl -c` to handle syntax checking:

BEGIN { `rm -rf $ENV{HOME}` }

They had to switch to using static analysis rather than relying on Perl's built in syntax checking to avoid executing code in BEGIN blocks.

[1] https://github.com/SublimeLinter/SublimeLinter/issues/77

[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)

[chr1]

But why would you do that? Press enter only where it makes sense. It's just like with other tools, you can cut your finger with knife, but that doesn't make knives less useful.

[joesb]

If I can do it only when it makes sense, I would default to "don't do it". So what's the point of binding it to oh-so-convenient shortcut key, when I have to think about when I can do it? What's the different from using terminal or Makefile to run it then?

[chr1]

You can't do it only for very specific cases. And even `File.rm("something")` usually works because if you are removing something, you have code for creating it too, and can quickly test both with command+enter, instead of opening whole application and trying to invoke that through your gui or something.

[seanmcdirmid]

If File.rm("something") is undoable, then its not a problem right? We are talking about developer tools anyways, its not inconceivable that a mock environment would be setup for the program with undoable side effects or what not. However, this would require serious programming model changes, which are probably not in the scope of Light Table.

[TuringTest]

Which is a shame. As joesb points out above, this severely reduces the benefits of the "instant execution&feedback" features.

Given that this is an alpha release, maybe it's still time to rethink that approach and allow for sandboxed environments.

[ibdknox]

There's absolutely nothing preventing a sandboxed environment :) Connections are just processes that talk over tcp, if the client wants to sandbox whatever it evals, it can definitely do that.

[seanmcdirmid]

Sorry I wasn't clear, but the ability to "undo" an operation definitely requires a programming model change. The sandbox is only one part of that.

Rolling your own magic sandbox isn't going to help much without more buy in from the environment (though, I'm sure most of us test in sandboxes anyways).

[pufuwozu]

Even GHC's (Haskell) REPL executes side-effects.

[lallysingh]

I'd expect that instead of eval, you'd want to run some sort of unit test for effectful code.

[slewis]

The child process could be run inside a chroot jail, or a virtual machine.

[frugalfirbolg]

To that end the developer could anticipate that their code has a lot of side effects and just run light table in a test vm with snapshots to hop back to in case they really mess up. Setting one up isn't hard, and you only pay the overhead cost of a vm or separate test machine if your use case demands it that way.