Thank you Neil, George and Matthias.

I'm interested in the HCI advice, where they impact both the language
developer and the language user(s):

   - [avoid]* "Lack of abstraction mechanisms" [DH]*
   - *"figuring out what your composable primitives are." [DH]*
   - [avoid] *"Reinventing lexical scope"* and *"exposing variables as
   mutating a global scope" [DH]*
   - [avoid] *"picking a programming paradigm that is not well suited to
   the problem domain" [GN]*
   - *"Consider whether declarative or imperative is better." [NVD]*

I'm assuming the above advice counts as the HCI aspects of language design,
and ignoring the choice of syntax, be it C-style, sexp, 'blocks', or
something else, is driven by the need to make it suit the intended
audience.  (choosing between global or lexical scope, as opposed to
implementing one or the other)

As far as when to consult a specialist/expert I didn't mean a programming
languages researcher, I was more referring to when you were designing a
little language like a templating system or config file.  Would that be
covered by the compilers course? My alma-mater doesn't offer a compilers
course in their compsci degree
<https://www.cdu.edu.au/study/bachelor-computer-science-wcoms1-2018#!study-plan>
.

I suppose there is a scale:

   1. programmer (without compilers course)
   2. did compilers at degree level (can still remember it and it covered
   design decisions, as opposed to algorithms and data structures)
   3. Beautiful Racket and/or/ https://school.racket-lang.org/#brw
   4. Racket School 'How to design Languages'
   https://school.racket-lang.org/#htdl
   5. http://cs.brown.edu/courses/cs173/ , PLAI, PAPL or a postgraduate
   level (masters?)
   6. PhD and beyond

( I have no idea if the order I made up is right - and I don't remember the
dragon book covering the HCI aspects of language design)

I suppose if you are If you are at (1) and you need help you ask someone at
(2) or above.

I'd pay if PLT/Racket offered different levels of certification in
DSL/Language design at different levels, or licensed someone do do it on
their behalf for a percentage of the income.  (I regret not doing the mooc
version of cs173/ <http://cs.brown.edu/courses/cs173/>PLAI when it was
offered)

S.


On Fri, 8 Feb 2019 at 18:46, Matthias Felleisen <matth...@felleisen.org>
wrote:

>
>
> > On Feb 7, 2019, at 7:32 PM, Neil Van Dyke <n...@neilvandyke.org> wrote:
> >
> > but it might just be easier to just get a professorship instead (also
> nontrivial). :)
>
>
> Absolutely.
>
> * How many academic PL experts do you know that design languages?
> * How many of their languages reach an audience of more than 7?
> * How often do they repeat this?
>
> While there’re clearly some academic PL researchers who do all of this,
> the de facto careerization of the research job has pushed people to where
> the glory is:
>
> - papers
> - more papers
> - yet more papers
> — and as many citations as possible.
>
> So to become a professor with a high citation count, you must follow the
> herd and toe the consensus line. And what is the consensus line at the
> moment:
>
> - verification via proof assistants
> — verification via model checking
> — verification of static properties
> — synthesis, and
> — the desperate need to apply ML-AI to PL (and I don’t mean OCAML here)
>
> In short, there really aren’t many experts. Most of these experts probably
> focus on general-purpose language design not DSL design.
>
> And all of this despite the fact you can easily identify 2,500
> publications on DSLs [see the annotated bibliography of va Deursen et al.
> from 2000 and the survey of Mernik et al. from 2005].
>
> ;; - - -
>
> Now having said that, I would also provide some food for thought since
> y’all live in the Racket universe:
>
> — match is a DSL, most of its patterns aren’t meaningful outside of match
> — syntax pattern variables is a DSL, an extremely small one
> — syntax-case patterns is a DSL that interacts with the DSL on syntax
> pattern variables
> — syntax-case templates is a DSL different from the patterns that
> interacts with the DSL of syntax pattern variables
> — syntax-parse is a different DSL
> — . . . and up the scale
> — #lang info is a DSL
> — #lang datalog is yet a different kind of DSL
>
> While a course on compilers may help — parsing, static checking, code
> generation, and optimization are useful ideas — how well do they apply
> above.
>
> OK. Back to work — Matthias
>
> --
> 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.
>

-- 
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.

Reply via email to