Or... you could just use a programming language that looks good and has great support for embedded domain-specific languages (eDSL), like Haskell, OCaml or Scala.

Or, y'know, use the language you have (JavaScript) properly, eg. add a `sum` abstraction instead of `.reduce((acc, val) => { return acc+val }, 0)`.

In particular, the problem of "all the calculations are blocked for a single user input" is solved by eg. applicatives or arrows (these are fairly trivial abstract algebraic concepts, but foreign to most programmers), which have syntactic support in the abovementioned languages.

(Of course, avoid the temptation to overcomplicate it with too abstract functional programming concepts.)

If you write an XML DSL:

1. You have to solve the problem of "what parts can I parallelize and evaluate independently" anyway. Except in this case, that problem has been solved a long time ago by functional programming / abstract algebra / category-theoretic concepts.

2. It looks ugly (IMHO).

3. You are inventing an entirely new vocabulary unreadable to fellow programmers.

4. You will very likely run into Greenspun's tenth rule if the domain is non-trivial.

> you could just use a programming language ... like Haskell, OCaml or Scala.

Then you run into the problem of finding developers who are competent in these languages. I'm probably not the smartest guy but I've been a competent programmer for nearly 30 years. Haskell is something that seriously kicked my ass the few times I tried to get into it.

Suggest to Raku to that list. All the early Raku devs were Haskell coders (the first Raku parser (PUGS) was written in Haskell).

Since Raku suports both OO and Functional coding styles, and has built in Grammars, it is very nice for DSLs.

"just"

HTML!

Or Lisp.

"Looks good" might be something not everyone agrees on for Lisp, but once you've seen S-expressions, XML looks terrible. Disgustingly verbose and heavyweight.