2 ms·

I find (given enough time for it that is), more and more, that if code is duplicated or bad or both, that I can rewrite it into some (unexisting) DSL that makes

I find (given enough time for it that is), more and more, that if code is duplicated or bad or both, that I can rewrite it into some (unexisting) DSL that makes it elegant. Then when trying to rewrite it to the language at hand, it becomes (a lot more) inelegant again. So is low hanging fruit there an Alan Kay strategy of writing DSLs for specific domains (which would put languages like Lisp, Ocaml or Haskell in a good place) or should language designers find ways to make the language itself better for these kind of problems (and is that possible, for instance; advanced types OR elegant macros?). The other comment about Django (which would also work for Rails); a lot of times, big enough libraries/frameworks written in a language, are actually DSLs which would suggest we lean toward the 'Alan Kay' 'make everything a DSL' solution. The mathematician/CS person in me wants the 'improve the language' solution. But low hanging fruit for language design I don't see here.

qznc 9y ago
I think the continuum is: boilerplate, library, standard library, language. Boilerplate is the most flexible. Language is most unifying. Things tend to move towards language, but if you move too fast, you are stuck with bad decisions, because changing a language is near impossible.
Joeri 9y ago
The thing about DSL’s (or really any programming language abstraction) is that they make it easier to understand the intent of the code at the expense of making it harder to understand the effect of the code. I find that the cognitive load of maintaining a project with lots of DSL’s is high. The advantage of e.g. java over scala is that while java code is often more verbose and ugly, it holds fewer surprises. Like anything there is a trade-off here, adding more DSL’s can be better or worse.
- dwc 9y ago
  There's a lot of variability here. In the best case, the DSL or abstraction doesn't leak and the effect of the code matches the intent so that you don't need to peek under the hood to make sure it's doing what you want/think. In that (rare) case, cognitive load remains low because you can work close to the problem domain and stay there without worrying about the specifics of the underlying code.
- tluyben2 9y ago
  > find that the cognitive load of maintaining a project with lots of DSL’s is high Yes, that is currently why I design that kind of scenario in a (possibly blue sky) DSL 'on paper' (if there isn't one handy) and then translate that back to libraries and structures in the language i'm working in. I just notice that this becomes annoying sometimes if the existing solutions really do not match the DSL I envisioned.
- kazagistar 9y ago
  > java code is often more verbose and ugly, it holds fewer surprises Last I checked, things like AoP, reflection, Spring/Hibernate contexts, and other magic metaprogramming and annotation shenanigans were commonplace. At least with macros, you can usually just expand them and read what your code is doing.
mpweiher 9y ago
> ...writing DSLs ... or make the language itself better Emphatically: YES. :-) To clarify, hopefully, just a little bit: the DSL approach certainly appears the most promising so far. But there are a few issues. One is that language creation, maintenance, interoperability and comprehension become critical issues very quickly, even with amazing tools. (One could argue that amazing tools make the problem worse, because they hasten proliferation). Then you notice that even some apparently pretty radical DSLs actually have quite a bit in common. And the things that separate them are just variants of a few simple architectural elements (dataflow, constraints, storage, data-definition). You also remember from Guy Steele[1] that languages should not be "a thing", but rather a "pattern for growth", and from natural languages that we don't really invent entire new languages for specific domains, at most we add some vocabulary/jargon. So DSLs should not be a thing, what should be a thing is a language that allows us to build APIs that have the benefits we want from DSLs. And so while Lisp Macros certainly point the way, I don't think they're the answer. Smalltalk's keyword syntax is closer, despite or maybe because it is less powerful[2], and Grace's extension of keyword syntax gets us even closer. So we need a language that allows us to build what we would consider DSLs as APIs. For that, it will also need to abandon call/return as the dominant/only generalized abstraction mechanism[3] [1] https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf [2] https://youtu.be/P2mh92d-T3Y?t=564 https://youtu.be/P2mh92d-T3Y?t=564 [3] http://objective.st/ http://objective.st/
- omegaworks 9y ago
  I'm really interested in seeing the evolution of Kotlin with regard to its use in building DSLs. I saw a talk by Christina Lee and Huyen Tue Dao that builds one on the type system (lambda extension fimctions) that feels very intuitive. https://www.youtube.com/watch?v=OmwjrVawHqA https://www.youtube.com/watch?v=OmwjrVawHqA

qznc 9y ago

I think the continuum is: boilerplate, library, standard library, language. Boilerplate is the most flexible. Language is most unifying. Things tend to move towards language, but if you move too fast, you are stuck with bad decisions, because changing a language is near impossible.

Joeri 9y ago

The thing about DSL’s (or really any programming language abstraction) is that they make it easier to understand the intent of the code at the expense of making it harder to understand the effect of the code. I find that the cognitive load of maintaining a project with lots of DSL’s is high. The advantage of e.g. java over scala is that while java code is often more verbose and ugly, it holds fewer surprises. Like anything there is a trade-off here, adding more DSL’s can be better or worse.

dwc 9y ago
There's a lot of variability here. In the best case, the DSL or abstraction doesn't leak and the effect of the code matches the intent so that you don't need to peek under the hood to make sure it's doing what you want/think. In that (rare) case, cognitive load remains low because you can work close to the problem domain and stay there without worrying about the specifics of the underlying code.
tluyben2 9y ago
> find that the cognitive load of maintaining a project with lots of DSL’s is high Yes, that is currently why I design that kind of scenario in a (possibly blue sky) DSL 'on paper' (if there isn't one handy) and then translate that back to libraries and structures in the language i'm working in. I just notice that this becomes annoying sometimes if the existing solutions really do not match the DSL I envisioned.
kazagistar 9y ago
> java code is often more verbose and ugly, it holds fewer surprises Last I checked, things like AoP, reflection, Spring/Hibernate contexts, and other magic metaprogramming and annotation shenanigans were commonplace. At least with macros, you can usually just expand them and read what your code is doing.

mpweiher 9y ago

> ...writing DSLs ... or make the language itself better Emphatically: YES. :-) To clarify, hopefully, just a little bit: the DSL approach certainly appears the most promising so far. But there are a few issues. One is that language creation, maintenance, interoperability and comprehension become critical issues very quickly, even with amazing tools. (One could argue that amazing tools make the problem worse, because they hasten proliferation). Then you notice that even some apparently pretty radical DSLs actually have quite a bit in common. And the things that separate them are just variants of a few simple architectural elements (dataflow, constraints, storage, data-definition). You also remember from Guy Steele[1] that languages should not be "a thing", but rather a "pattern for growth", and from natural languages that we don't really invent entire new languages for specific domains, at most we add some vocabulary/jargon. So DSLs should not be a thing, what should be a thing is a language that allows us to build APIs that have the benefits we want from DSLs. And so while Lisp Macros certainly point the way, I don't think they're the answer. Smalltalk's keyword syntax is closer, despite or maybe because it is less powerful[2], and Grace's extension of keyword syntax gets us even closer. So we need a language that allows us to build what we would consider DSLs as APIs. For that, it will also need to abandon call/return as the dominant/only generalized abstraction mechanism[3] [1] https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf [2] https://youtu.be/P2mh92d-T3Y?t=564 https://youtu.be/P2mh92d-T3Y?t=564 [3] http://objective.st/ http://objective.st/

omegaworks 9y ago
I'm really interested in seeing the evolution of Kotlin with regard to its use in building DSLs. I saw a talk by Christina Lee and Huyen Tue Dao that builds one on the type system (lambda extension fimctions) that feels very intuitive. https://www.youtube.com/watch?v=OmwjrVawHqA https://www.youtube.com/watch?v=OmwjrVawHqA