I don't mind the criticism at all. I don't use it often enough to claim expertise. Fair points about my usage.

You can still get proper editor support with Golang (even though it isn't designed for it). I've done so here with VSCode working with a "remote" delve session: https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2...

Thanks :)

My point being, if you wanted to execute the following code: https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2...

You probably wouldn't be able to, without restructuring how you're handling your state that is being used there. A REPL driven made program usually is made that the runtime carries the state and exposes it, so you could just select that part and run it, and see the output of it.

I'm guessing delve is more like a traditional debugger that steps through each line, rather than an REPL, correct?

Correct, but it does allow you to modify values in memory, so you could do the branching and state changes as you go. I admit I could have made that flow more "editable" from the debugger/REPL, however it did serve its purpose in terms of prototyping ideas before I integrated them into the real thing. I also do use it to debug weird state things of issues reported to me, which I do mess with the values at runtime with Delve to simulate.

I may be misunderstanding the "true" REPL development here, but I think the points laid out by the article seems to match my experience to a degree.

That's interesting, didn't know that! Thanks for sharing. I don't think there is anything that is more "true" than something else, it's just varying degree of personal productivity and in the end we all work very differently, so one size does not fit all. I'm glad you're sharing your thoughts with me and seems to be similar to the REPL environment I'm running myself.

I looked into this subject a bit more deeply in regards to Go, and you are right. Go doesn't have a REPL built in, and most of the implemented REPLs only work off of stdin. So, the Clojure style of REPL development is not as straight-forward in Go. However, it does seem like one of the userland REPLs could be adapted to work with an editor (like vscode) if the input source wasn't locked to stdin.

It seems like a ripe target for an opensource library to accomplish this. I may explore this later on when I have more time to devote.

Indeed, I'm going to think about some of the suggestions you mentioned the next time I'm in there playing with it. Perhaps I'll hit a wall with delve that other language tools (like Clojure) handle better.

I kind of practice REPL driven development in Go actually. I usually write 1-2 functions at a time, and simply test them by repeatedly running the program, with tests happening in an init() function.

When everything's well again, I move the bits to a test case.

I guess my point would be that with a REPL driven development in Clojure, there is no moving, as the code is already where it should be, you just executed it from there directly.

And you don't need to extract anything into functions, lisp-syntax kind of already gives you all the separation you need, so you can just execute code in place if you need it to.