Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I haven't jumped ship from Common Lisp to Racket just yet

fare.livejournal.com

Post reply on HN
Print view View original

1–10 of 101 posts

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#3

Post by 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.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#4

Post by sigstoat »

mjmein wrote: post #3

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…

> 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.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#5

Post by mjmein »

sigstoat wrote: post #4
mjmein wrote: post #3

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…

> 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 cloj…

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...

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#6

Post by stonemetal »

mjmein wrote: post #5
sigstoat wrote: post #4

Earlier quoted context omitted.

> 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 cloj…

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. T…

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...

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#7

Post by sillysaurus3 »

mjmein wrote: post #5
sigstoat wrote: post #4

Earlier quoted context omitted.

> 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 cloj…

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. T…

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

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#8

Post by mjmein »

stonemetal wrote: post #6
mjmein wrote: post #5

Earlier quoted context omitted.

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. T…

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...

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?
Post reply on HN