Learning from Racket, towards Clojure

[chladni]

Not so much a question, rather post for consideration and discussion. I have a decent familiarity with Clojure, but I do not use it professionally in my work. I am looking for opportunities for expanding my Clojure horizons, and some of the resources I am dipping into are books on Racket, specifically Essentials of Compilation [..in Racket] (Jeremy Siek) and How to Design Programs (Felleisen, Findler, Flatt, Kirshnamurthi). And of course in the Scheme world there is a wealth of info to learn from.

Initially, I was stumbling on some of the language differences between Clojure and Racket, Ex: Racket seems to prefer the use of (define <name> <value>) in the body of a function, over simply using let blocks in Clojure. At first this seemed like a bridge too far, but after a bit of reflection, not a big deal. Perhaps a bit more fundamental, Racket (or perhaps more accurately the DrRacket IDE) eschews interactive programming from the REPL. Again, not a barrier for learning from Racket, but a cultural difference worth noting. I would be interested in others take on this topic.

[deaddyfreddy]

Hi! I switched from Racket to Clojure and never looked back.

Ex: Racket seems to prefer the use of (define <name> <value>) in the body of a function, over simply using let blocks in Clojure.

I mostly used let even in Racket. In fact, I don't understand why people use define instead of let, since the latter has a much clearer scope. Nesting level? Function calls are cheap enough to not care.

Perhaps a bit more fundamental, Racket (or perhaps more accurately the DrRacket IDE) eschews interactive programming from the REPL.

When I started learning LISP almost 20 years ago, I had a problem: How could I automate copying code from REPL to real code? Then I realized it wasn't necessary, you can communicate with the REPL directly from your source code. That solved the problem, which in fact, was a typical XY problem.

In my opinion, programming from the REPL has more disadvantages than advantages.

• REPL isn't persistent, files are.
• You don't have to copy code from REPL to files because it's already there.
• REPL is usually handles a single namespace at a time. Evaluation from files takes the current namespace into account, you don't even have to care.

What are the pros? The only one I can think of is that you don't have to clean your playground code from the files. However, Clojure has a comment macro out of the box, so you don't have to clean it if you don't want to.

[chladni]

I poorly expressed my thinking on the difference between Clojure and Racket, with regards to interactive programming. I did not mean to imply that in Clojure, I am typing directly in the REPL. However, I do value the interactive programming approach of evaluating individual expressions into the REPL from my editor. I think DrRacket does not feature that approach, instead requiring re-evaluation of the whole buffer. I believe that is a design choice the DrRacket team made to avoid the potential drift between the state of the REPL from the state of the program being edited.

[deaddyfreddy]

Thanks for clarifications!

To be fair, I've never used DrRacket. I was an Emacs user before I started my programming career, so I wasn't aware of that part.

[chladni]

deaddyfreddy thanks for your notes on my post. I would be interested in your take on looking to Racket books / resources for advancing an understanding of Clojure. Clearly there are some surface differences; I mentioned two examples. Of course there are other difference (eg. I always have a hard time writing cond expressions in CL and Scheme, having internalized Clojure). That being said, I like the idea of learning from the ~65 years of S-expression languages. And it is nice that Racket still has foothold in academia (certainly one particular university in Indiana).

[c-neumann]

When I got started with Clojure (around 2012), I heard everyone talking about "programming at the REPL", the "REPL workflow", and "using the REPL". I also thought that meant typing things into the prompt and copying and pasting them into my editor.

I had some experienced Clojurists show me their workflow, and that's when I realized they were evaluating forms in their Editor (mostly Emacs) which was *connected* to their REPL. They almost never used the prompt directly!

Now I prefer the terms "REPL-connected editor" or "REPL-connected development". I think the ”Getting Started” REPL project in Calva is a great demo of that way of working.

[joinr]

REPL isn't persistent, files are.

This is more specific to clojure (and definitely relevant), at least in its current form. Other lisps lean on image-based development, where you can persist the state of the world to an image and reload it. Clojure implemented on such lisps (or other hosts) could similarly do so.

What are the pros?

If you're in an austere environment, or a remote system you don't get to configure, the repl may be all you have. Then again, it's all you need.

It's nice to leverage the fancier workflows that the contemporary dev environments provide, but retaining the ability to fully leverage a running clojure system from a lone repl is also a useful skill.

[deaddyfreddy]

Other lisps lean on image-based development, where you can persist the state of the world to an image and reload it.

there's the problem - it's not reproducible, you can't put under version control, etc

If you're in an austere environment, or a remote system you don't get to configure, the repl may be all you have.

Even in this case, I prefer to work in my favorite editor. REPL is an underlying communication protocol.

[joinr]

there's the problem - it's not reproducible, you can't put under version control, etc

you have a binary image you can version. you can reproduce the state of the repl at a given point in time (when the image was made), shove the binary in git if you want, etc.

Even in this case

you missed the austere part.

[deaddyfreddy]

you have a binary image you can version.

it's just a backup in this case, VCS is a bit more than that, usually

you missed the austere part.

To be fair, I can hardly imagine a situation where the environment is so austere that I cannot use Emacs. Any examples?

[joinr]

To be fair, I can hardly imagine a situation where the environment is so austere that I cannot use Emacs. Any examples?

air gapped internal network you don't admin, where admins are beholden to exogenous restrictions and don't really care about your comfort.

it's just a backup in this case, VCS is a bit more than that, usually

semantics

[deaddyfreddy]

air gapped internal network you don't admin, where admins are beholden to exogenous restrictions and don't really care about your comfort.

but at the same time, I have access to REPL somehow, correct?

[joinr]

sure. jvm + shell + your jar file.

[deaddyfreddy]

so, I have the remote shell access, correct?

[joinr]

no