I am happy to see Racket make it to the front page. After using mostly Common Lisp for research programming since 1982, I now more often turn to Racket. There are parts of Racket I don’t like, which is most everything *NOT* the compiler, package management system, GUI IDE, Emacs bindings, fun language to use.
I don’t care for much of the programming language research parts of the ecosystem - that is the parts that the computer scientist professors who run the project probably care about the most. More power to them!
So I feel like a freeloader on the Racket project, just enjoying the little parts I like and ignoring the rest, and not contributing anything (except maybe the little Racket book I wrote).
The packet management system, the GUI IDE (which includes a step debugger), the ability to write a cross platform IDE (which is maintained by the core Racket team themselves), and the ability to easily produce runnable binaries make Racket my favorite Lisp hands down.
Those features are so incredibly useful and important, I really can't state it enough. I love Lisps, but at work, I will only use a language if it's the best tool for a job. Because of several of those features, Racket has been the only Lisp I've ever been able to justify using.
Because of the community, tooling and learning resources available, Racket is such an easy language for me personally to recommend to people. There are things I really like about CL and Clojure too, both of which I have used quite a bit, but I would never recommend them to people because of some huge drawbacks that come with each.
I also don't jive with the research parts of the language , nor do I care about the "lang" facilities, and I also kind of strongly dislike HtDP. But my perspective on all that is that they are projects I am uninterested in that happened to be made with a language I love, rather than knocks against the language itself, because I never bump up against them.
I use CL on a day to day basis (and not in research/PL research domain), have never ventured into Racked yet. Can you please elaborate further on parts of Racket you don't like vis a vis CL? Thanks!
What are the 'programming language research parts of the ecosystem'?
The only part of the Racket distribution I can see that is specifically 'programming language research' is Redex.
In the language itself there are the metaprogramming capabilities - but all modern languages have metaprogramming.
My experience of the community is it is generally people talking about real problems.
People do use Racket for PL and other research, so a number of PL research papers and conference talks do reference Racket, but it doesn't dominate any of the discussion.
Having used Racket in college for programing language ecosystem, I can say I don't enjoy that aspect either haha. Racket is easy to get started with and definitely great at what it does. If you're wading into Lisp IMO it's the way to go.
That said, IMO Clojure has a larger and more robust community, that said it's a bit of a bigger pain to set up (uses JVM) & has some more nuance.
Uses the JVM is exactly why Clojure is the Lisp like language I mostly bother with.
What matters are ecosystems and not languages on their own, so when switching between languages it is a great benefit that I can reuse my Java ecosystem knowledge, instead of adding yet another ecosystem to those I jump around between projects.
However, I really like the almost Lisp Machine like experience from using Raket.
IMHO, the Lisp Machine experience is completely different. Those have zero educational aspects, they were designed to write large, and stateful, applications, where the Lisp Machine OS is the big stateful object-oriented operating system (like Symbolics Genera). Interlisp-D is even more different.
One feeling I have is that while Clojure is incredibly tasteful, well-designed and elegant, it is less focused on Correctness as Racket. And this gives me the feeling that if I make some mistake (say, erroneously swapping arguments of a complex function that e.g. computes on list as sets), I do not know what is going to happen.
Clojure's biggest advantage, integration with the JVM ecosystem, is also its biggest drawback. JVM compatibility forces a lot of ugly compromises on Clojure.
One reason is that it has one of the best cross platform native gui solutions out there. It exists because the research side was focused on teaching programming and needed a solution that their students could just install. There is a bit of a learning curve, but once you're over the hump it is just a pleasure to work with. See also things like https://docs.racket-lang.org/gui-easy/index.html.
> One reason is that it has one of the best cross platform native gui solutions out there.
I'm always a bit skeptical of these statements. How does it define "native"? Does it use gtk/libadwaita on Gnome and Qt on KDE? What about windows, does it use Win32, WPF, WinUI2 or WinUI3, all of which could be considered "native"? What about platform-dependent layouts?
How one defines "native GUI" is very simple: it uses the native widgets of the desktop OS, rather than custom-painting its own onto a pixel-level canvas. Buttons, input fields, lists/combos, context menus, the file picker dialog, what have you, are from the host system.
I guess one can think of Clojure as a very Scheme-affine Lisp. Which is not surprising since Scheme was a kind of distilled iteration of Common Lisp as a common denominator.
Are there any Schemes which are as "Batteries included" as Clojure with broad and deep library support? (I think Racket has quite good support!)
Ergonomics. It's extremely easy to use, especially in the GUI department. Generally, many things are super easy to use but not always top performance. Other things (macros) are truly exceptionally powerful, but rather complicated.
So, industry-grade customer-facing code? Not its focus, maybe not. But incredibly easy internal tools? Sure!
It becomes very limited quite quickly though. One quickly has to move to the pasteboard editor functionality, where you basically have to recreate everything yourself in a canvas, as the normal buttons and other graphical elements are not supported inside a canvas since they are native OS widgets.
I started trying to build a complex enough GUI and just quit. There are bugs and the documentation is extremely terse. You have to rely on blog posts by one developer who has sorted it all out, but it's still really difficult to get an explicit handle on the concepts and functionality. Very, very few people use the pasteboard editor for complex things or even simple things. You'll be forging a path of your own for sure.
The common sentiment is "if it's not used in DrRacket, you'll likely be on your own". That's more of a limitation due to the small community than a testament to the GUI framework quality itself, IMO.
how do you deal with the very bad Racket repl? Thats what turned me off the language
edit: I dont reslly understand the downvotes, not trying to be rude or anything. Coming from CL the racket repl is very very barebones, it loses all state everytime you recompile. So I ask him how he deals with that coming from the very nice CL repl
The REPL in DrRacket is like that because it was made by professors, specifically targeting intro students who had never programmed before. They thought a big Run button with a clean slate each time would be less confusing.
You don't have to use DrRacket to use Racket.
People doing real work with Racket tend to have "workflow" setups that are closer to SLIME.
Very few people I know doing real work in Racket have a SLIME-like workflow. In general, Racket discouraging this style is related to us being a bunch of professors, but not really in the way you say. Instead, it's because it's not possible to give a sensible semantics to the top-level, especially in the presence of macros. We care a lot about macros, and we also care a lot about sensible semantics, and thus the attitude towards the REPL. The slogan in the Racket community that "the top level is hopeless" expresses this sentiment.
I think Guile is a good example that one can have an SBCL-like workflow of live coding (with debugging and jumping right into a stack trace) in Scheme.
I have heard that this is not possible because Racket needs to make a stricgter separation of compile time and run time... but I am not sure whether this is actually true.
Regarding the stricter separation, Racket and its module system have nicely clear concepts of phases. (I really like how the Racket module system has been used these to benefit the language.)
But, though I don't know current Racket internals, I'm not sure those need to be a barrier to monkeypatching that approaches CL.
Other than optimizations that make some debugging info and dynamic changes difficult-to-impossible, if the system had a mode to disable these optimizations (or to maintain some information in parallel that permits a cascading unraveling of optimizations affected by a change), I'm not aware of a fundamental reason the system couldn't support more loose poking at things.
Though, one implementation complication that Schemes do have is first-class continuations.
There was a nice extension called DivaScheme that used unchorded keystrokes like vi and allowed structural editing but it stopped working when PLT Scheme reached version 5. (Which I think was when they changed the name to Racket.) https://cs.brown.edu/research/plt/software/divascheme/
I don’t care for much of the programming language research parts of the ecosystem - that is the parts that the computer scientist professors who run the project probably care about the most. More power to them!
So I feel like a freeloader on the Racket project, just enjoying the little parts I like and ignoring the rest, and not contributing anything (except maybe the little Racket book I wrote).