[mjmein]

Racket is a really exciting language, especially with its focus on building small languages to solve problems.

However, where it fails for me is in its lack of interactive development. When I investigated it, there seemed to be no way to actually connect a repl to a running program.

Unlike with common lisp or clojure, with racket if you make changes to your code you have to restart the REPL, which destroys your state.

This was a big disappointment to me, because even python with ipython and autoreload allows for more interactive development.

I suspect that this decision was made because of racket's start as a teaching language, because it is simpler, but way less powerful.

[sigstoat]

> When I investigated it, there seemed to be no way to actually connect a repl to a running program.

i (poorly) implemented conditions for racket once, including the ability to drop into a repl at the point of error.

so i think you could put in place some macros that would let you get at a repl wherever you wanted. probably not the sort of thing to leave in place all the time, though

> Unlike with common lisp or clojure, with racket if you make changes to your code you have to restart the REPL, which destroys your state.

that's a different issue. i believe matthias has commented on the mailing list (some years back) that the semantics associated with doing something like that are a mess, and that's why they weren't interested in implementing it.

[mjmein]

To me, being able to make changes to your code while keeping the current state in the REPL is key to interactive development.

My workflow is generally to build up state, and then experiment with functions on that state until I get the correct output.

This workflow is very natural in Clojure, Common Lisp and even Python (with IPython and autoreload).

However, in Racket you have to restart everything on every change. This works ok for smaller applications, but if for example, your state is a large dataset that you pull from a remote database, it becomes a little more difficult.

There are possibly workarounds, and I'm not saying that Racket is bad because of this. There are definite advantages to this approach, mainly for keeping everything simple and predictable. However, this was a roadblock for me, and the main reason why I didn't spend more time working on it.

I also miss the ability to make changes to code, refresh the browser and instantly see the changes (instead of having to restart the server after each change).

Here's a good discussion (in my opinion) of what makes a good REPL for interactive development: http://vvvvalvalval.github.io/posts/what-makes-a-good-repl.h...

[stonemetal]

It isn't in DrRacket by default but it is a common enough requested feature that they keep an example of how to add it in the documentation.

https://docs.racket-lang.org/drracket/Keyboard_Shortcuts.htm...

[mjmein]

Thanks. Do you know if it works with the module system - for example, if I edit function definition in a module, and then send that module definition to the REPL, would any code using that module start using the new definition?

[bad_login]

It works in geiser-mode, i don't know if it works with drracket or racket-mode.

http://docs.racket-lang.org/guide/eval.html?q=namespace#%28p...

[sillysaurus3]

I'm surprised no one has mentioned geiser. It sounds like exactly what you want for racket. http://nongnu.org/geiser/geiser_3.html

[pera]

There is also racket-mode (available on MELPA): https://github.com/greghendershott/racket-mode

[peatmoss]

This is what I use. I find it quite comfortable / very easy to get going.

[ebzzry]

Geiser is fine. However, we can’t compare it with SLIME. The integration of the latter is much better.

[baldfat]

I use Visual Studio Code for Racket. https://marketplace.visualstudio.com/items?itemName=karyfoun...

Before that I would use VIM with a tiled window manager that worked really well.

[maxiepoo]

I believe this is a design decision, because relying on some enormous implicit repl state and updating the code in place is a good way to get yourself into states that are impossible to reach in an actual running program. Racket is a functional language and it is their belief that you should just make predictable ways to startup your interactive development than rely on the entire state of some repl image.

[mikelevins]

You're right; it's a conscious decision. I had a little discussion with Eli Barzilay and Matthew Flatt about some related matters a little while back. It was a nice discussion, but image-based or live programming is just not something they found particularly compelling.

It pretty much keeps me from using Racket, and a bunch of other things that are otherwise very nice. Given a choice, I will always choose the tools that support me in building things by modifying programs as they run. I'm just happier and more productive that way.

So one of my axes of optimization is selecting projects that enable me to work that way.

[mjmein]

My thoughts exactly. Once you are used to this way of developing, it is really difficult to be happy with less.

[maxiepoo]

Ah yes, I remember seeing an interaction that was probably yours, tried to find it for my comment, but never did.

[elibarzilay]

I don't know what this refers to, but it doesn't ring a bell. The most I might have said is that the community in general is not too interested; but personally, this kind of dynamic interaction is something that I very much appreciate. In fact, when I implemented xrepl (which is now the default when you start racket) being able to modify code inside modules was one of the main goals. The only reason I didn't do something like that for Emacs is that my own use of CL/Scheme variants in Emacs was always very simple, but I actively encouraged people to do something similar for Emacs -- and Geiser/Racket-mode are two serious Emacs packages that actually do that kind of interactive use.

[mikelevins]

I asked you guys about image-saving because I was considering using Racket to build a new version of bard, and I thought I might like to both use image-saving during development and piggyback on a Racket implementation of it for use in bard's runtime. As I recall, you guys wanted to know what I found compelling about image-saving, but you didn't find it as compelling as I did.

I still might build a bard on Racket, but if so, I'll most likely build my own VM and implement my own image-saving solution for it.

Assuming, of course, that there are enough hours in the day, and enough years in a life.

[pera]

I'm not sure if this is exactly what you are talking about, but with racket-mode in Emacs you can write some program, run it (C-c C-k), then add some s-expr and evaluate only that (C-x C-e) in the current context.