Hi,
Dave Herman recently tweeted[1] that consulting a PL specialist was a good idea for little languages to avoid common foundational mistakes, specifically mentioning templating systems and configuration files.
So when designing(or evolving) a little language:
[1] https://twitter.com/littlecalculist/status/1092160821944213504?s=21
It's frustrating that PL is considered such a specialization that PL people only get brought in for big languages. There are vastly more little languages everywhere. People often don't realize their little language needs better underpinnings until very late, if at all.
Common mistakes tweeted by Dave Herman in subsequent thread;
Scenario-solving: language design at its heart is figuring out what your composable primitives are. Too often, people think of use cases one scenario at a time and just sort of glue them together w/o generalizing and simplifying.
Reinventing lexical scope: many systems start by using string concatenation as their core model, instead of composing modules with a rationalized notion of scope. Another common scoping mistake is exposing variables as mutating a global scope.
Lack of abstraction mechanisms: when you don't think of yourself as designing a language, you put up with boilerplate and copy-pasta.
Lack of strategy for general-purpose logic: ultimately most DSLs end up needing general-purpose programming language—often it's in a minority of cases but when you need it you really need it. The best ones IMO have clear extension points and contracts with a general-purpose PL.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[...]
I don’t think this is a linear order. It’s more like a landscape with dots and connections and hyper-edges and such. In particular,
— the PLAI course at Brown belongs into the “compiler” equivalence class,
— a PhD does not a good DSL designer or expert consultant (on this topic) make,
— the first bucket is way too coarse
(some programmers have good “native” taste for DSLs, others should never ever program).
And I understood that you were asking about experts who can do DSL x Domain stuff.
But NVD’s remark and my long-time observation of where PL research is going triggered my rant. Sorry
— Matthias