This is a repost of a message sent through Gmane that seems to have gotten lost. The original may show up at some point - apologies if you see this twice.
On Wed, 6 Feb 2019 16:25:47 +0000, Stephen De Gabrielle <spdegabrielle-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote: >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: > > - what beginners mistakes should you avoid? > (some in the subsequent tweets I’ve copied below) > - When should you consult a PL specialist? > (and how do you identify a PL specialist?) > >More generally, can you recommend resources a developer (without a >background in language design) should refer to if they are building a >simple templating system, application configuration file, etc. - that >may grow into a little language? > >Kind regards, > >Stephen > >PS please forgive me if this is the wrong list for this question. No offense to Herman, but I think the problem with consulting experts is that there are relatively few language experts who are available to consult. Certainly there are those who are willing to answer questions (at least well defined questions) but most likely are busy with their own work and can't be expected to devote a whole lot of time to helping someone design a new language. I agree with all the pitfalls Herman mentions, and to them I would add: - fascination with C-like or natural language syntax - avoidance of parser tools/libraries - picking a programming paradigm that is not well suited to the problem domain - not using an IR - trying to interpret or compile straight from source text - forgetting about debugging These are just off the cuff - if I were to think about it for a while I probably would come up with more. I think every *serious* developer should read at least an introductory text on compilers. Even if you never try to implement your own language, understanding what happens to your code when its compiled makes you a better programmer. A developer serious about creating DSLs might want deeper study of both compilers and virtual machines [keeping in mind that programming languages always are defined over a "virtual" machine (that then is implemented on a real machine)]. YMMV, George ----- >[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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
