4 ms·

I don't agree. For many domains, being able to implement a domain-specific language with a set of expressive rules for the domain is an incredible productivity

I don't agree. For many domains, being able to implement a domain-specific language with a set of expressive rules for the domain is an incredible productivity boost and also prevents many mistakes because you cannot represent them. Not being able to manipulate the AST means that you are restricted on the embedded DSLs that you can provide. And embedded DSLs encompasses code generation for: - state machines - parsing grammars (PEGs for example) - shader languages - numerical computing (i.e. having more math like syntax to manipulate indices) - deep learning (neural network DSL) - HTML templates / generators - monad composition There is a reason most people are not building in Assembly anymore, there is a right-level of abstraction for every domain. A language that provides building block for domain expert to build up to the right level of abstraction is very valuable.

deleted 7y ago
[deleted]
pron 7y ago
The question is, as always, at what cost? Low-level languages (aka "systems programming" languages) already suffer from various constraints that increase their accidental complexity. Is it really necessary to complicate those particular languages further to support embedded DSLs? I don't think there's a universal right or wrong answer here, but there is certainly a big question.
- gw 7y ago
  Ironically, the lack of macros leads to an explosion of ad-hoc, extra-language DSLs. Look at rules engines, for example. In Drools (java), you have to write rules with a special language, DRL. Meanwhile in Clara (clojure) you write your rules in clojure. Macros simplify languages, they don't complicate them.