Clojurians Log v2

I do this "scratch" files approach too. Some of then are even used on real developing by others, like "generating migration file/run database migrations" or "run tests and create a coverage file"

I began working with scratch files because where I worked previously, most people would type directly in the REPL or rely on Cursive's static analysis, so there where some simple, usual commands like "stop the servers" that I would need because of the REPL but they didn't need 🙂

I can see the value in an ever-growing scratch file. But I’m not convinced of the virtue of forcing that way of interacting yet. Think of it like immutability: generally a good idea, but mutability is still available when needed. Just because it suits Stu’s workflow doesn’t mean it’s good for everyone. In particular, while I think it works ok for maintaining a history, I think it adds mental friction, too. If I were to treat the scratch file as append-only, there’d be a lot of stuff in the file, forcing me to search when I wanted something, and obscuring the other commands necessary to resetup some state. If I were to curate it, I run the risk of being unable to run them in order to set something up again at a later date. The entire file maintenance part feels worse to me than an automatically-generated REPL history, which is what I already use. About the only thing that I really like about this setup is always being able to retrieve old code, but the way I work, things either end up in code, or end up in a git branch/stash that does a better job of grouping my experiments than a scratch file would. Not to mention, this is very unfriendly to beginners following tutorials 🙂

@kingmob Yeah, it's unfortunate indeed that so many tutorials just say "Start a REPL at the command line and type into it"... but of course that is the quickest way to walk someone through exploring a library, for example. It's just not a good workflow to stick with once you are actually building stuff.

And part of that is because, as a library author (for example), you have no idea what editor setup your users might have so it's really hard to offer specific instructions. I mean, it's already a bit of a pain to have to specify dependencies in two formats and explain which belongs to which of the three main tools for running code 🙂

And some of these workflows take effort to set up above and beyond just the actual tooling.

By no means am I suggesting typing directly at the REPL should be the default. But I disagree that the functionality shouldn’t be present, and more to the point, I don’t even think 100% file-based REPL is superior, even for experienced people.

Err, not all people, I mean

My team mate and I use different editors and different ways to start a REPL, but we've managed to agree on some common dev/build tooling setup to support both our workflows.

Re: Chlorine -- yes, it would probably make sense for the REPL panel to be interactive because that's generally what folks expect from REPL integration in other editors. I'm not against it being enhanced to support that. I'm just saying that I think it's a better workflow to not do that (and therefore I don't consider it a big deal that it doesn't support that -- and that's true of most Chlorine users I suspect). Since Chlorine doesn't attempt to start a REPL for you, pretty much everyone is starting a REPL manually (somehow) and exposing a Socket REPL (somehow) and then connecting Chlorine to that... and I'll bet nearly all of those manually started REPLs can be typed directly into...?

@kingmob when you say "I'm not convinced of the virtue of forcing that way of interacting yet", are you referring to the fact that Chlorine does not let you type input forms directly into its REPL frame? I'm not advocating for forcing that way of interacting, either -- I actually use inf-clojure inside of Emacs much more than Chlorine, where there is the choice to type directly into the REPL.

@andy.fingerhut Yeah, that’s what started this conversation yesterday. I asked in channel if I was doing something wrong when trying out Chlorine because I couldn’t get that to work 🙂

BTW, do you use inf-clojure with nREPL or a socket REPL?

socket REPL. I do find that even with the choice to type directly into the REPL, I probably do that less than 5% of the time.

Oh, I agree. I said roughly the same thing higher up.

@seancorfield For sure, I could alt-tab over to the terminal REPL to type directly, but that falls under the category of adding mental friction to me (e.g., different namespaces, state, etc), so I’d prefer not to leave the editor.

If there isn't already a Github issue requesting this feature for the Chlorine project, seems worth creating one and see what happens.

I have 0 knowledge of the technical difficulties with implementing such a change.

I filed a request. Even if the authors don’t want to change the behavior, it would be nice to clarify that, maybe by removing the ability to type in the REPL entirely, or adding a note, or something

Yeah, since typing my last message I quickly checked the Github issues and saw yours. If you haven't already, you may want to add a comment saying that among other choices, your personal favorite would be enabling forms typed into the REPL pane to be evaluated.

Oh, I thought that was implicit, but I suppose I could be more straightforward there.

…added