5 ms·

>So, if one isn't careful, it's possible to write a very clean, very nice Lisp DSL which is totally incomprehensible to anybody but the author, and thus hell to

>So, if one isn't careful, it's possible to write a very clean, very nice Lisp DSL which is totally incomprehensible to anybody but the author, and thus hell to maintain over time. This is a myth. DSLs in Lisp are almost always done in Lisp syntax, no surprises. The idea of having a higher abstraction is to make the problem domain map more clearly to the code. >totally incomprehensible to anybody but the author Now, what people who like to repeat this myth forget to say, is that when using an OOP language, say, Java, and using another's person code, one also needs to learn the classes that this person has created, the methods and how they interact. And this can be "totally incomprehensible to anybody but the author". >Relevant quote No, not relevant. Joel Spolsky is talking about device abstractions.

kamaal 9y ago
>>And this can be "totally incomprehensible to anybody but the author". It always is. Code isn't magic, so you have to write whatever logic you would write in one language in another, for any application you would write. The only exception if your language provides abstractions on which you can build on. For example in Perl, you can do a lot of file operations and regex work without libraries. In Java you might need a library, sometimes a combination of libraries, whose documentation one might have to read. Same goes with lisp too. The only difference being, every once in a while one might discover a way to do large patterns of code through simple ways using macros.
dustingetz 9y ago
professional clojure programmer here, not a myth, DSLs often abstract in the wrong direction and by departing from a language of values and function composition (eg by introducing macros) a bad dsl in fact becomes a barrier to good abstraction. Consider any DSL for html generation that predates React.js; react isn’t even a DSL at all, react is values and functions, so there’s all this good innovation happening around React that was all dead ends on 100% of pre-React DSLs.
- flavio81 9y ago
  >a bad dsl in fact becomes a barrier to good abstraction. Consider any DSL for html generation that predates React.js; react isn’t even a DSL at all, react is values and functions React isn't a DSL; React includes a DSL for html generation. And by the way, we have had such a thing in Lisp since the existence of HTML. Tons of libraries that allow you to inline HTML into your code.
- flavio81 9y ago
  >and by departing from a language of values and function composition (eg by introducing macros) You are assuming that a DSL is done by using macros; which is incorrect; in Lisp you can easily create your own DSL using plain functions as well.
  - kornish 9y ago
    Sounds like maybe we're talking past each other. Would you mind clarifying how you're defining a DSL?
    - deleted 9y ago
      [deleted]
- deleted 9y ago
  [deleted]
kornish 9y ago
I'm not fully sure what you're disagreeing with. Of course it's possible to write an overly abstracted DSL in Lisp, as it also is in Java or Go. > The idea of having a higher abstraction is to make the problem domain map more clearly to the code. Certainly. And, as per the Spolsky quote, too much abstraction can actually miss the expressivity sweet spot and start to obscure the problem domain. > No, not relevant. It is if you, ah, abstract away the specific context of his story.

kamaal 9y ago

>>And this can be "totally incomprehensible to anybody but the author". It always is. Code isn't magic, so you have to write whatever logic you would write in one language in another, for any application you would write. The only exception if your language provides abstractions on which you can build on. For example in Perl, you can do a lot of file operations and regex work without libraries. In Java you might need a library, sometimes a combination of libraries, whose documentation one might have to read. Same goes with lisp too. The only difference being, every once in a while one might discover a way to do large patterns of code through simple ways using macros.

dustingetz 9y ago

professional clojure programmer here, not a myth, DSLs often abstract in the wrong direction and by departing from a language of values and function composition (eg by introducing macros) a bad dsl in fact becomes a barrier to good abstraction. Consider any DSL for html generation that predates React.js; react isn’t even a DSL at all, react is values and functions, so there’s all this good innovation happening around React that was all dead ends on 100% of pre-React DSLs.

flavio81 9y ago
>a bad dsl in fact becomes a barrier to good abstraction. Consider any DSL for html generation that predates React.js; react isn’t even a DSL at all, react is values and functions React isn't a DSL; React includes a DSL for html generation. And by the way, we have had such a thing in Lisp since the existence of HTML. Tons of libraries that allow you to inline HTML into your code.
flavio81 9y ago
>and by departing from a language of values and function composition (eg by introducing macros) You are assuming that a DSL is done by using macros; which is incorrect; in Lisp you can easily create your own DSL using plain functions as well.
- kornish 9y ago
  Sounds like maybe we're talking past each other. Would you mind clarifying how you're defining a DSL?
  - deleted 9y ago
    [deleted]
deleted 9y ago
[deleted]

kornish 9y ago

I'm not fully sure what you're disagreeing with. Of course it's possible to write an overly abstracted DSL in Lisp, as it also is in Java or Go. > The idea of having a higher abstraction is to make the problem domain map more clearly to the code. Certainly. And, as per the Spolsky quote, too much abstraction can actually miss the expressivity sweet spot and start to obscure the problem domain. > No, not relevant. It is if you, ah, abstract away the specific context of his story.