*Disclaimer I know nothing about German and very little about English Grammar*
In German there is a word called "Schadenfreude" whose literal translation into English is Schaden "damage" freude "joy". The actual meaning is roughly ...
The experience of pleasure or joy, that comes from witnessing failures, or humiliation of another.
Because of the "design" of the English language, it is difficult (but not impossible) to relate these complex emotions in the way it is done in German. Because of this we have to say "I am experiencing joy from seeing X person in pain" while the Germans get to say "I feel Schadenfreude". The German way is more succinct. Coincidentally in programming, there are problems which if you are just constrained to the syntax and semantics of your programming language, get solved by saying "I am experiencing joy from seeing X person in pain" instead of "Schadenfreude". By being able to create a new language with less friction than it has been in other programming langauges before, whose design allows you to solve your problem with the word "Schadenfreude" instead of "I am experiencing joy from seeing X person in pain", allows you to create programs that are more expressive, succinct, have less bugs, and be easier to maintain.
You say that, but my (albeit weakly held, so CMV) theory is that any software engineering is just a form of creating a DSL, it just isn't generally explicit.
Given more expressive power, with appropriate training, it could be incredibly empowering, allowing for more expressive and maintainable systems.
It could also create an absolute mess, and some might argue that more power means more ways to shoot yourself in the foot, hence I think that kind of methodology requires the training up front and overall good software discipline.
I am a junior-mid developer so I know squat really.
> Because of this we have to say "I am experiencing joy from seeing X person in pain" while the Germans get to say "I feel Schadenfreude". The German way is more succinct.
To be fair, in English we would just say schadenfreude today.
In substance: easily make a DSL targeted specifically at your problem.
This proposition is often criticized by software engineers for resulting in code that is potentially inscrutable to anyone but the writer. IMO, this misses the forest for the tree. Sure, one-off DSLs probably aren't suited to entreprise codebases you'd use Java for. But what the critics miss is that this truly enables domain experts. In that way, it's a bit like the MS Excel value proposition cast into a (very well-designed) programming language. Which makes it ideal for solo devs, scientists, small teams, etc. (as most lisps). That's what makes Racket interesting to me, at least.
My job is to doing due diligence on tech companies during major investments and acquisitions, and one of the most successful (and interesting) I've seen was doing exactly what you describe. It wasn't Racket, but the code base was an engine with a very sophisticated DSL enabling all their in-house domain experts to work hyper-productively. Their work was split into an engine, which their low level super-senior hackers worked on, and the assets, which were the things customers bought and were made in a DSL by highly educated domain experts. It was really impressive, and they are doing very well. I've long been convinced that this is the logical highest level of "onion/hexagonal/ports and adapters" architecture, and seeing what they had done was really cool.
General purposes programming languages that enable to easily and expressivelly build readable DSLs are useful.
But what does Racket bring over say Kotlin DSLs?
https://kotlinlang.org/docs/type-safe-builders.html
For building DSLs the following features are useful:
Infix/postfix functions,
Operator overloading,
Varargs/spread operator,
Scope controling what is allowed.
Other features??
I'm not a Kotlin expert, but I expect that it enables easily interpreted DSLs. Racket enables easy compiled DSLs through its macro system. So, no interpretative overhead.
Although not similar technically speaking, Graal/Truffle is a better comparison in spirit, IMO. But Graal/Truffle is hugely complex, with many many man-hours in it.
I think the DSL logic is at compile time, the Kotlin annotation generate source code at compile time just like a macro and enable compile time type safety. Also the performance is expected to be order of magnitude better given the JVM.
Also you can really, really change both syntax and semantics: https://docs.racket-lang.org/2d/
Exactly, racket give you much more freedom because of this, I don't know the use cases but it's indeed more powerful.
A comparison with Truffle would be great! I wonder if a higher level/simpler but less powerful abstraction on top of Truffle could bridge the difficulty gap.
Let's say you and your friends wanted to figure out the best
way to share toys so that everyone is happy.
There's a new method to doing that, pioneered by these
Racket folks, called "Language Oriented Programming".
And what it means is that the first step to solve your
problem is to create the simplest language you can think of
to describe your problem.
So let's create a language where you can list everyone's
toys like this "ballToy", "elsaToy", "blockToy". And then we
can list all your friends like this "Adam", "Emily", "Maya".
And then we can list feelings like "Happy", "Sad"...(going
to skip the meat for brevity)...and then we rearrange these
words until we get the program with the most Happys! And
we've solved the problem using "Language Oriented
Programming". We spent our time not on the computer
language, but on creating a new simple domain specific
language customized for our problem.
