6 ms·

I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's progra

I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Making a DSL lets me construct a language to express my program that meshes with the way I think. Unfortunately, we all think differently, and what is intuitive and friendly for me is hostile and awkward for others. While reading someone else's program that uses a DSL may be superficially easy, but the minute you try to get under the surface, you're left scrambling to understand what a given term or idea meant to the author. There is no language definition to rely on for common understanding. There are exceptions naturally. I know a lot of people will disagree, and that's fine of course. It's opinions all the way down.

kd0amg 10y ago
While reading someone else's program that uses a DSL may be superficially easy, but the minute you try to get under the surface, you're left scrambling to understand what a given term or idea meant to the author. There is no language definition to rely on for common understanding. I have generally found that this is the same problem as with user-defined functions, and it has the same solution: programmers need to document their code.
- treehau5 10y ago
  Also be consistent with their grammar, naming schemes, and conventions.
- brandonbloom 10y ago
  Agreed. I have two follow up thoughts: 1. Badly designed functions can do less design damage per-function than badly designed languages per construct, but user-defined functions tend to have much higher volume than both language constructs and their usages. 2. Powerful techniques, including DSLs, lead to denser code. Denser code takes more time to read per unit of code. Total reading time may be either more or less, but the cold start ramp is always much steeper. Combined, this means that people are less sensitive to suffering the complexity caused by user-defined functions vs DSLs/etc because that complexity has lower intensity spread out over a greater area. I'll refrain from any further value judgement on this state of affairs; just wanted to share some more insights in to the tradeoffs.
  - lisper 10y ago
    > Badly designed functions can do less design damage per-function than badly designed languages per construct Really? When was the last time you successfully used a C library without reading the documentation?
    - brandonbloom 10y ago
      Straw man. When was the last time you had to check the documentation for the parameter evaluation strategy of a C function call? I don't think it is a controversial statement than a badly designed macro can do more damage than a badly designed function. I believe that this is true, even normalizing for bad macro systems. This is not a statement against macros, so much as it is a statement to consider when making tradeoffs.
      - lisper 10y ago
        What would you cite as an example of a badly designed macro?
      - lisper 10y ago
        It is controversial. The GETS function is probably responsible for a huge number of security breaches with a cost possibly ranging into the billions of dollars (there's no way to really know). What would you cite as a comparable example of a badly designed macro?
        GFK_of_xmaspast 10y ago
        Part of the reason gets() has been such a disaster is that people use it.
- agumonkey 10y ago
  That's one thing that I liked with FP often combinatorics friendly code, you can compose lots out of a common core, it helps tremendously to decrypt the author's idea.
- tigershark 10y ago
  If you need documentation probably you are not writing good code. Documentation is absolutely needed when writing third party libraries, but everyone of your team should know all the aspects of the codebase, at least at high level. If someone doesn't know it then documentation is not the solution. Doing some pair-programming, adding them as reviewers of more pull requests, writing some wiki page that explains the architecture of the various components are much more effective ways. Remember that documentation is not free, you need to spend a certain amount of time to build it and even a greater amount of time to maintain it. Every time that I've seen some attempt at writing documentation in javadoc or whatever is called in .net, there were always missing parameters in the methods, wrong arguments and method names, parameters not existing anymore and so on. Naming is also a very important aspect. Just yesterday I found in a pull request something like "SingleLineTextBoxTextTooLongShowTooltipHandler". This doesn't really add any information and just makes it impossible to understand what is meant to do. I proposed to change it to "TextOveflowTooltipHandler", maybe still not ideal, but I think that is a definite improvement over the original. DSLs in theory should be self documenting. Gherkin is quite easy even if you don't read the documentation and even if you don't write code. If on the other end you write some Lisp-esque ultra compact DSL that has no whatsoever connection with the real world then also in that case the best solution is not to write the documentation, it should be to write a better DSL.
  - Chris2048 10y ago
    > Doing some pair-programming, adding them as reviewers of more pull requests, writing some wiki page that explains the architecture of the various components are much more effective ways You get a new member of the team, how do pull-request reviews and pair-programming help them get familiar with old code? Documentation is a way of stating explicitly what might be learned implicitly from those tasks. > Every time that I've seen some attempt at writing documentation in javadoc or whatever is called in .net, there were always missing parameters in the methods, wrong arguments and method names, parameters not existing anymore and so on So fix that. review the comments as part of code review - if the documentation is in the code this should be easy. From my memory of Java, doesn't eclipse have some sort of doc sting checker? I'm sure I recall the in-comment parameter names changing when you updated the method name...
SwellJoe 10y ago
I think this conceptual disconnect can happen even without a DSL. So, then you have the huge amount of code, plus, a bunch of new and confusing concepts applied in ways that don't fit with your understanding of those concepts. A DSL may mean that the language doesn't fit how you think about a given problem, sure, but a poorly fitting abstraction can happen with or without those language abilities. I tend to think that having those poorly fitting abstractions expressed in a compact form is probably better than having them expressed in libraries with very large surface area and oddly connecting/dependent parts. Now, I don't actually know this to be true; my experience with Lisp projects is very limited. I have worked with Perl and Tcl that made use of higher level capabilities of those languages to create little DSLs for specific tasks, and I didn't find it problematic; but neither is as far along as Lisp on the DSL spectrum. But, I have also worked with big projects in languages like PHP that get the abstractions very wrong (at least, wrong from my perspective), and have found the verbosity to be exhausting...saying so much in order to accomplish so little (and to do it wrongly) seems even worse than tiny amounts of code that don't fit my mental model.
- 8ytecoder 10y ago
  Agreed, in fact a well defined and documented DSL could make it easier than user-defined functions and large chunks of code.
tikhonj 10y ago
This is why it's always important to consider semantics when you define an abstraction—whether it's a DSL or a normal library. Life is a lot easier when your semantics are simple, precise and composable (the semantics of an expression are clearly derived from the semantics of its components). It makes the up-front design more difficult—you can't just muddle through a design without thinking deeply about it—but pays off in the long run. If you have nice semantics, I think the advantages of building a DSL (mostly greater expressiveness and flexibility) vastly outweigh any confusion people might have about the different syntax. If the semantics are genuinely simple, learning how the syntax maps to then should not be difficult. And with unclear semantics, even a non-DSL library is going to be hard to use and understand.
deleted 10y ago
[deleted]
sanderjd 10y ago
> I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Maybe this isn't the case for you, but for me, "myself in a year" fits nicely in the "other people" category, so I'm always asking myself: will I be happy or sad about this if I stumble upon it again while doing something totally different a year from now?
bad_user 10y ago
Creating reusable functions and types and whatnot is also creating your own DSL, as another poster hinted at. However the main problem with bad DSLs is that they aren't composable. Which really means users have to learn the right sequence of events and the right context in which certain actions function properly. People often complain about awkward symbols or unfamiliar constructs, but really, they are missing the forest from the trees. This is why plain pure functions are always better, because they are composable and reusable, being the missing ingredient of many DSL authors.

kd0amg 10y ago

While reading someone else's program that uses a DSL may be superficially easy, but the minute you try to get under the surface, you're left scrambling to understand what a given term or idea meant to the author. There is no language definition to rely on for common understanding. I have generally found that this is the same problem as with user-defined functions, and it has the same solution: programmers need to document their code.

treehau5 10y ago
Also be consistent with their grammar, naming schemes, and conventions.
brandonbloom 10y ago
Agreed. I have two follow up thoughts: 1. Badly designed functions can do less design damage per-function than badly designed languages per construct, but user-defined functions tend to have much higher volume than both language constructs and their usages. 2. Powerful techniques, including DSLs, lead to denser code. Denser code takes more time to read per unit of code. Total reading time may be either more or less, but the cold start ramp is always much steeper. Combined, this means that people are less sensitive to suffering the complexity caused by user-defined functions vs DSLs/etc because that complexity has lower intensity spread out over a greater area. I'll refrain from any further value judgement on this state of affairs; just wanted to share some more insights in to the tradeoffs.
- lisper 10y ago
  > Badly designed functions can do less design damage per-function than badly designed languages per construct Really? When was the last time you successfully used a C library without reading the documentation?
  - brandonbloom 10y ago
    Straw man. When was the last time you had to check the documentation for the parameter evaluation strategy of a C function call? I don't think it is a controversial statement than a badly designed macro can do more damage than a badly designed function. I believe that this is true, even normalizing for bad macro systems. This is not a statement against macros, so much as it is a statement to consider when making tradeoffs.
    - lisper 10y ago
      What would you cite as an example of a badly designed macro?
    - lisper 10y ago
      It is controversial. The GETS function is probably responsible for a huge number of security breaches with a cost possibly ranging into the billions of dollars (there's no way to really know). What would you cite as a comparable example of a badly designed macro?
      - GFK_of_xmaspast 10y ago
        Part of the reason gets() has been such a disaster is that people use it.
agumonkey 10y ago
That's one thing that I liked with FP often combinatorics friendly code, you can compose lots out of a common core, it helps tremendously to decrypt the author's idea.
tigershark 10y ago
If you need documentation probably you are not writing good code. Documentation is absolutely needed when writing third party libraries, but everyone of your team should know all the aspects of the codebase, at least at high level. If someone doesn't know it then documentation is not the solution. Doing some pair-programming, adding them as reviewers of more pull requests, writing some wiki page that explains the architecture of the various components are much more effective ways. Remember that documentation is not free, you need to spend a certain amount of time to build it and even a greater amount of time to maintain it. Every time that I've seen some attempt at writing documentation in javadoc or whatever is called in .net, there were always missing parameters in the methods, wrong arguments and method names, parameters not existing anymore and so on. Naming is also a very important aspect. Just yesterday I found in a pull request something like "SingleLineTextBoxTextTooLongShowTooltipHandler". This doesn't really add any information and just makes it impossible to understand what is meant to do. I proposed to change it to "TextOveflowTooltipHandler", maybe still not ideal, but I think that is a definite improvement over the original. DSLs in theory should be self documenting. Gherkin is quite easy even if you don't read the documentation and even if you don't write code. If on the other end you write some Lisp-esque ultra compact DSL that has no whatsoever connection with the real world then also in that case the best solution is not to write the documentation, it should be to write a better DSL.
- Chris2048 10y ago
  > Doing some pair-programming, adding them as reviewers of more pull requests, writing some wiki page that explains the architecture of the various components are much more effective ways You get a new member of the team, how do pull-request reviews and pair-programming help them get familiar with old code? Documentation is a way of stating explicitly what might be learned implicitly from those tasks. > Every time that I've seen some attempt at writing documentation in javadoc or whatever is called in .net, there were always missing parameters in the methods, wrong arguments and method names, parameters not existing anymore and so on So fix that. review the comments as part of code review - if the documentation is in the code this should be easy. From my memory of Java, doesn't eclipse have some sort of doc sting checker? I'm sure I recall the in-comment parameter names changing when you updated the method name...

SwellJoe 10y ago

I think this conceptual disconnect can happen even without a DSL. So, then you have the huge amount of code, plus, a bunch of new and confusing concepts applied in ways that don't fit with your understanding of those concepts. A DSL may mean that the language doesn't fit how you think about a given problem, sure, but a poorly fitting abstraction can happen with or without those language abilities. I tend to think that having those poorly fitting abstractions expressed in a compact form is probably better than having them expressed in libraries with very large surface area and oddly connecting/dependent parts. Now, I don't actually know this to be true; my experience with Lisp projects is very limited. I have worked with Perl and Tcl that made use of higher level capabilities of those languages to create little DSLs for specific tasks, and I didn't find it problematic; but neither is as far along as Lisp on the DSL spectrum. But, I have also worked with big projects in languages like PHP that get the abstractions very wrong (at least, wrong from my perspective), and have found the verbosity to be exhausting...saying so much in order to accomplish so little (and to do it wrongly) seems even worse than tiny amounts of code that don't fit my mental model.

8ytecoder 10y ago
Agreed, in fact a well defined and documented DSL could make it easier than user-defined functions and large chunks of code.

tikhonj 10y ago

This is why it's always important to consider semantics when you define an abstraction—whether it's a DSL or a normal library. Life is a lot easier when your semantics are simple, precise and composable (the semantics of an expression are clearly derived from the semantics of its components). It makes the up-front design more difficult—you can't just muddle through a design without thinking deeply about it—but pays off in the long run. If you have nice semantics, I think the advantages of building a DSL (mostly greater expressiveness and flexibility) vastly outweigh any confusion people might have about the different syntax. If the semantics are genuinely simple, learning how the syntax maps to then should not be difficult. And with unclear semantics, even a non-DSL library is going to be hard to use and understand.

deleted 10y ago

[deleted]

sanderjd 10y ago

> I find DSLs to be extraordinarily powerful for writing and working with my own programs. I find them painful when I'm trying to work with other people's programs. Maybe this isn't the case for you, but for me, "myself in a year" fits nicely in the "other people" category, so I'm always asking myself: will I be happy or sad about this if I stumble upon it again while doing something totally different a year from now?

bad_user 10y ago

Creating reusable functions and types and whatnot is also creating your own DSL, as another poster hinted at. However the main problem with bad DSLs is that they aren't composable. Which really means users have to learn the right sequence of events and the right context in which certain actions function properly. People often complain about awkward symbols or unfamiliar constructs, but really, they are missing the forest from the trees. This is why plain pure functions are always better, because they are composable and reusable, being the missing ingredient of many DSL authors.