As much as I like Racket, I’d agree w/ the underlying sentiment of that statement.
At its core, Racket isn’t anything all that special (to an average programmer): it’s a VM with a language sitting on top of it. No different than Python, Ruby, Erlang, etc. People can - and have - implemented languages in other VMs (targeting bytecode) as well. Again, nothing truly special. After all, I can create a Java program that has Scala code, Clojure code, Kotlin code, etc. all together (</vomit>).
Where Racket sets itself apart is that - because it’s a Lisp - its AST is the language (as opposed to the aforementioned JVM languages which are required to target the underlying VM bytecode or going through some multi-stage compilation using files on disk as intermediate steps). Because of that, it’s conceptually quite simple to use the language itself to target itself. But trying to describe how that’s better to a non-Lisper is difficult. The best I’ve ever done is explaining that with “compile to X” languages, you first compile to X and then use another tool (the X compiler) to compile your output. But then proceed to remind then that’s only a trivial amount of the work (for their language):
• Do they want to report runtime errors back to their language’s filename, line #, function name, etc.? That’s more work. • Want to be able to use other libraries from language X? That’s more work. • Want to use libraries written in language Z that also targets X? That’s potentially an insane amount of extra work. • The list goes on… Macros and syntax objects just happen to be a couple (powerful) methods of facilitating the above, but they aren’t necessary. Then, the #lang feature adds yet another simple-yet-powerful feature that isn’t really explained too well to newcomers. In my experience, they see it no differently than a “Create new X project…” in an IDE. They don’t realize that every file in your project can be a different #lang. And then there’s another big “ah-ha” moment when they realize that #langs can also be data.
I can easily envision myself making a project in Racket that has all of the following files together as siblings, each doing what they do best:
• A typed/racket #lang server • A text-adventure DSL #lang that is run by the server • A datalog #lang that is a DB of the adventure rules, objects, etc. • A SQL #lang with functions for updating a sqlite DB of runtime data • An HTML #lang that is the rendered response of the server But, the above is something difficult to express/explain to a Racket newcomer. The homepage talks about “Language-Oriented” programming, but really doesn’t do it justice. Not that I have better suggestions. A landing page should be short and sweet, which the site already is.
My 2p.
Coming to racket from common lisp I still find CL’s metaprogramming much more intuitive and ubiquitous than in racket (and I guess scheme in general). In CL when I want to write a macro I just think to myself “a defmacro that returns a list” while in scheme my brain context-switches to a completely different world where I have to worry about syntax->datum and whether I want to use syntax-parse or syntax-case or whatever else. Then syntax-parse is usually what I go with but I never remember all the keyword arguments so I have to re-read the documentation… It’s just not as easy as CL. Sometimes I even prefer template haskell to racket.
By the way I found is a nice and quite advanced CL book recently called “let over lambda: 50 years of lisp” by Doug Hoyte
Lets build something like this as a component to BR to showcase LOP! It’s really neat next to, say, python, where SQLis either some weird mapper or strings
Its not just « return a list », is it ? You have to deal with gensyms, explicit hygiene, pulling apart the input list, generating good error messages, etc. At least for a good experience. Racket (mostly) just does that for you, especially with syntax-parse.
Gensym and explicit hygiene is trivial and nothing worth getting worked up over IMO. The error messages (line #, etc) from syntax objects is a nice advantage, though. Everything else in my experience is just added abstraction. Some people like it more, some people (like myself) like it less. To each their own. :wink:
The question is, can I write SQL DSL within another #lang and interoperate easily? If not, it might not be very useful to me.