Fork me on GitHub
#protorepl
<
2017-08-26
>
sparkofreason19:08:31

@seancorfield Curious as to what you find frustrating about autoeval, in the interest of improving it, since I think the concept is good. I first tried proto-repl about a year ago (?) and thought it was definitely not ready for prime time, particularly autoeval. This time around I find autoeval tolerable, albeit with some obvious areas for improvement. Big ones for me would be to clean up (or avoid) the transient error messages and indicators, and to be more selective about re-evaluation when an expression is edited. On the last one, it seems like there should at least be an option to only eval from the edited s-expression to the end of file, since we're often working near the end of the file anyway. Probably still need an option eval the entire file for code that is not functionally pure.

hmaurer19:08:56

@dave.dixon Totally agree regarding transient error messages. The spinner that appears mid-typing and does not go away without ctrl-shift-C is a no-go for me

hmaurer19:08:24

I am not sure whether I would use autoeval for actual development, but it definitely seems useful for quick experimentation and/or teaching

hmaurer19:08:51

As a beginner being able to type things in a file and get the results instantly is very neat

sparkofreason19:08:02

Yeah, so far I've been able to live with ctrl-shift-C, but it is a drag.

hmaurer19:08:24

you can work as if all computation was reactive, and not have to worry about re-evaluating bindings (and get unexpected behaviour if you forget to)

seancorfield19:08:50

First off, auto-eval is pretty darn dangerous around code with side effects (like accessing a database). Second, I don't agree with "often working near the end of the file" -- I don't find that at all, in my workflow. Third, having to hit alt-cmd-b to evaluate a block of code isn't onerous to me -- and I'd rather have it evaluate code when I'm ready, not whenever it feels like it.

hmaurer19:08:10

@seancorfield I agree with you for development, but for teaching Clojure it still seems auto-eval could be valuable. Having to re-evaluate bindings that may have been affected by a change in the code can get a bit confusing

seancorfield19:08:22

I used LightTable for a quite a long time. Beyond that first "half hour", I did actually go back and try auto-eval several times, but it just didn't sit well with my workflow.

seancorfield19:08:53

@hmaurer Based on my experience with ClojureBridge and LightTable, I think auto-eval gets in the way of learning: students get distracted by the constant results popping up -- or more likely the constant error messages from incomplete (or incorrect) s-exprs being typed in.

hmaurer19:08:45

@seancorfield I don’t have hands-on experience with teaching so I trust you on that, but the part about constant error messages is precisely what @dave.dixon was suggesting should be fixed, if I understood correctly

hmaurer19:08:26

(/s/should be fixed/should work differently)

sparkofreason19:08:11

Definitely need to turn off autoeval for code that has (non-idempotent) side-effects.

sparkofreason19:08:30

And I'm going to have to ponder whether it's actually autoeval that I like, or inline results.

sparkofreason20:08:44

After playing around a bit, I do think that most of what I like about autoeval is just the inline display of results. It's just that "Load Current File" doesn't display those results inline, only "Execute Block" does, and "Execute Selected" only displays the inline result for the last block in the s-expression. It would be cool if inline results could be generally displayed for all of these scenarios, because I tend to agree with @seancorfield that choosing which code to execute and when to do it is generally more desirable than having it done automagically.