I love Scheme and Racket. Personally, I prefer Scheme over Clojure and Common Lisp. It supports multiple paradigms well but not too bloated as Common Lisp, having a really good optional gradual type system, really easy to use reader macro system, etc.
I always wanted to use Racket in a bigger project to have a deeper understanding of macro/language creating. I always believe to achieve real 'domain driven design' is to create a layer of real business language which could interpret to a software system.
However, every time I want to do this I found Clojure is actually a much better choice. I guess to be fully practical is not #1 priority for Racket right now. But I really hope Racket can improve some of the following:
1. Encourage efficient data structures by default. I know lists are the soul of lisp but it's not good to use lists for everything. Clojure by default let you use highly optimized persistent data structures -- namely vectors and hash maps. These two data structures are highly practical, performant in most of the cases.
On the other hand, lists are more like write-heavy data structure, with really bad reading performance. This is like, a plain file system writes faster than databases, but most of the websites use a database because most of the business has much more reads than writes.
2. ClojureScript. JavaScript is a big thing until WASM fully arrives. Clojure has several really solid ClojureScript workflow, which makes me feel ClojureScript is really a first-class citizen.
3. IDE and debugging. I use Emacs + Geiser for editing, but Drracket for debugging. Drracket is really good, but still not great for editing hundreds of files. For Clojure, Cider and Cursive are IDEs makes me feel solid and complete.
4. Frameworks. I guess if the other 3 points are really good there would be many good frameworks come out every day.
> 1. Encourage efficient data structures by default. I know lists are the soul of lisp but it's not good to use lists for everything. Clojure by default let you use highly optimized persistent data structures -- namely vectors and hash maps. These two data structures are highly practical, performant in most of the cases.
Scheme has vectors, and Racket adds hash tables and structs:
There are some older libraries where lists (or alists) are used, when today you'd probably use hashes or structs. We could consider this an educational opportunity: there are still times when knowing how to do old-school list-processing is exactly what you need, and it's pretty fundamental data structures (e.g., singly-linked lists, trees), so we could consider it practice. :)
BTW, one difference between modern Racket lists and Scheme's is that Racket's default pairs are immutable. This turns out to be useful for optimizations, as well as encourage a healthy amount of functional programming.
Regarding #2, good point. I raised the WASM issue a couple years ago, and my thinking then (and now) is to build it for the forthcoming Chez backend, while getting plugged into the WASM standards work in the meantime. There are various ways to do JS with Racket (a big HTML5 Offline app of mine does it by generating JS and HTML from Racket), but WASM seems most promising.
Regarding #4, there are Web frameworks, and the main Racket Web Server (which you don't have to use; you can also do things like SCGI or proxy another HTTP server implementation), and you can also whip up your own frameworks very rapidly in Racket unlike many languages. I'm hoping a couple startups use Racket to get to launch, and release the light frameworks that they make along the way.
Li, Xiangqi; Flatt, Matthew - Medic: Metaprogramming and Trace-Oriented Debugging (2015)
Building on top of Medic, but unfortunately still not packaged (unlike Medic), Li & Flatt developed (the somewhat ill-named, due to that name overlapping with something from the cryptocurrency crowd) 'Ripple', which makes debugging Domain specific languages a lot slicker:
…and currently unfortunately represents the only way one can acquire the Ripple source code - and the artifact consists of a 2.4GB VM! :| (I understand why, and I consider it good scientific praxis - but I'd still appreciate a public repository in addition.)
I always wanted to use Racket in a bigger project to have a deeper understanding of macro/language creating. I always believe to achieve real 'domain driven design' is to create a layer of real business language which could interpret to a software system.
However, every time I want to do this I found Clojure is actually a much better choice. I guess to be fully practical is not #1 priority for Racket right now. But I really hope Racket can improve some of the following:
1. Encourage efficient data structures by default. I know lists are the soul of lisp but it's not good to use lists for everything. Clojure by default let you use highly optimized persistent data structures -- namely vectors and hash maps. These two data structures are highly practical, performant in most of the cases.
On the other hand, lists are more like write-heavy data structure, with really bad reading performance. This is like, a plain file system writes faster than databases, but most of the websites use a database because most of the business has much more reads than writes.
2. ClojureScript. JavaScript is a big thing until WASM fully arrives. Clojure has several really solid ClojureScript workflow, which makes me feel ClojureScript is really a first-class citizen.
3. IDE and debugging. I use Emacs + Geiser for editing, but Drracket for debugging. Drracket is really good, but still not great for editing hundreds of files. For Clojure, Cider and Cursive are IDEs makes me feel solid and complete.
4. Frameworks. I guess if the other 3 points are really good there would be many good frameworks come out every day.