5 ms·

Not only maintaining and growing a DSL is challenging but also designing it at first. You need a lot of both domain and technical experience to achieve a half-d

Not only maintaining and growing a DSL is challenging but also designing it at first. You need a lot of both domain and technical experience to achieve a half-decent result. That's why the "hype" around 2007 didn't lead to widespread practice. DSLs are costly.

scottious 11y ago
I'm currently developing a DSL. I definitely agree with what you're saying. Domain and technical expertise are needed in abundance. Writing a spec is HARD. It takes a certain perseverance to learn good parser design (I've written a great parser generator and I still feel inadequate in this area sometimes). DSLs are costly. My concern is that the cost will outweigh the benefit and people won't like it and we'll be suck with it. My hope is that it'll stabilize and be expressive enough to fit everybody's needs. Did you ever write a DSL used in a production environment? How complex was the DSL, more declarative or closer to a general purpose language?
- sklogic 11y ago
  > Writing a spec is HARD. Chances are that you're severely over-engineering it. Just take the English specification for any particular problem your DSL is supposed to solve and slightly tweak it into looking like a formal language. That's it. Extremely easy with a bit of practice.
  - ExpiredLink 11y ago
    You have no idea.
    - sklogic 11y ago
      Yes, tell me more. I build eDSLs professionally. You can take a look at some of the stuff I'm building: https://github.com/combinatorylogic https://github.com/combinatorylogic
      - ExpiredLink 11y ago
        But where is the domain in your Domain Specific Languages? You built SLs but not DSLs.
        sklogic 11y ago
        In this case domain itself is language construction: I built a system of DSLs that make implementing any other DSLs easy. And I am using this and the other similar toolchains (like Racket) to build DSLs for a very wide range of domains.
- ExpiredLink 11y ago
  I never wrote a DSL for a production environment. Once I wrote a DSL that allowed users to script an existing API for testing purposes. In my experience e.g. EDI and ISO specifications and protocols are also good DSLs.
zapov 11y ago
I actually find compilers for transformation of DSL AST to target languages much more costly then designing the DSL syntax. But that's probably because I don't think using templates for code generation is good enough. At least if you want to do something interesting with it. Language workbenches cut down the cost of DSL design to minimum, but more interesting problem is providing valuable output from it.
- sklogic 11y ago
  > I actually find compilers for transformation of DSL AST to target languages much more costly then designing the DSL syntax. Mind explaining why? What can be costly and complex in a chain of trivial transforms, each being very simple, flat and comprehensible?
  - zapov 11y ago
    When I say DSL I mean external DSL, not a fluent interface. So an example of the problem I deal with is a database migration. Let's say we have an entity with a value entity SqlTable { List<TableColumn> nestedTuple; } value TableColumn { int i; } and if I change column type in value object to long I want my compilers to prepare a DB migration with the appropriate SQL statements for the specific DB I use. Of course, there is nothing too complex about it, but it's not trivial either (in this case you have to prepare a second field, unnest the whole hierarchy to get to the nested field, copy it to new type and compact the hierarchy back again). I find it costly since there are gazillion of such features. And when they start interacting with each other things gets messy.
    - sklogic 11y ago
      > When I say DSL I mean external DSL, not a fluent interface If you're using a meta-language, there is no difference between external and embedded DSLs. External (or standalone) DSLs also should be built exactly the same way, on top of a hierarchy of existing DSL components. In your case, you're likely not compartmentalising your DSLs properly, trying to stuff too much functionality into a single DSL while it must be a chain of different DSLs. E.g., one DSL for describing a schema of the DB you want to migrate (with a tool for inferring it from the existing DB schema), another for representing the intermediate uniform data format and transforms over it, and a third for mapping the uniform intermediate representation on your target DB schema. Of course I do not know any details of your particular problem, just describing how I solved a DB migration problem before. Your specifics could add more to the DSL chain design.
sklogic 11y ago
> Not only maintaining and growing a DSL is challenging but also designing it at first. It's not that challenging if you do it the right way. > DSLs are costly. Plainly wrong. DSLs are the easiest and cheapest way of eliminating complexity. You simply have to follow a proper discipline and use the right tools. When I build a DSL, it's rarely more than 100 lines of code including literate comments, and the resulting DSL is a proper optimising compiler with debugging support, and this new DSL is immediately supported by an IDE (at least with syntax highlighting, autoindentation and autocompletion).

scottious 11y ago

I'm currently developing a DSL. I definitely agree with what you're saying. Domain and technical expertise are needed in abundance. Writing a spec is HARD. It takes a certain perseverance to learn good parser design (I've written a great parser generator and I still feel inadequate in this area sometimes). DSLs are costly. My concern is that the cost will outweigh the benefit and people won't like it and we'll be suck with it. My hope is that it'll stabilize and be expressive enough to fit everybody's needs. Did you ever write a DSL used in a production environment? How complex was the DSL, more declarative or closer to a general purpose language?

sklogic 11y ago
> Writing a spec is HARD. Chances are that you're severely over-engineering it. Just take the English specification for any particular problem your DSL is supposed to solve and slightly tweak it into looking like a formal language. That's it. Extremely easy with a bit of practice.
- ExpiredLink 11y ago
  You have no idea.
  - sklogic 11y ago
    Yes, tell me more. I build eDSLs professionally. You can take a look at some of the stuff I'm building: https://github.com/combinatorylogic https://github.com/combinatorylogic
    - ExpiredLink 11y ago
      But where is the domain in your Domain Specific Languages? You built SLs but not DSLs.
      - sklogic 11y ago
        In this case domain itself is language construction: I built a system of DSLs that make implementing any other DSLs easy. And I am using this and the other similar toolchains (like Racket) to build DSLs for a very wide range of domains.
ExpiredLink 11y ago
I never wrote a DSL for a production environment. Once I wrote a DSL that allowed users to script an existing API for testing purposes. In my experience e.g. EDI and ISO specifications and protocols are also good DSLs.

zapov 11y ago

I actually find compilers for transformation of DSL AST to target languages much more costly then designing the DSL syntax. But that's probably because I don't think using templates for code generation is good enough. At least if you want to do something interesting with it. Language workbenches cut down the cost of DSL design to minimum, but more interesting problem is providing valuable output from it.

sklogic 11y ago
> I actually find compilers for transformation of DSL AST to target languages much more costly then designing the DSL syntax. Mind explaining why? What can be costly and complex in a chain of trivial transforms, each being very simple, flat and comprehensible?
- zapov 11y ago
  When I say DSL I mean external DSL, not a fluent interface. So an example of the problem I deal with is a database migration. Let's say we have an entity with a value entity SqlTable { List<TableColumn> nestedTuple; } value TableColumn { int i; } and if I change column type in value object to long I want my compilers to prepare a DB migration with the appropriate SQL statements for the specific DB I use. Of course, there is nothing too complex about it, but it's not trivial either (in this case you have to prepare a second field, unnest the whole hierarchy to get to the nested field, copy it to new type and compact the hierarchy back again). I find it costly since there are gazillion of such features. And when they start interacting with each other things gets messy.
  - sklogic 11y ago
    > When I say DSL I mean external DSL, not a fluent interface If you're using a meta-language, there is no difference between external and embedded DSLs. External (or standalone) DSLs also should be built exactly the same way, on top of a hierarchy of existing DSL components. In your case, you're likely not compartmentalising your DSLs properly, trying to stuff too much functionality into a single DSL while it must be a chain of different DSLs. E.g., one DSL for describing a schema of the DB you want to migrate (with a tool for inferring it from the existing DB schema), another for representing the intermediate uniform data format and transforms over it, and a third for mapping the uniform intermediate representation on your target DB schema. Of course I do not know any details of your particular problem, just describing how I solved a DB migration problem before. Your specifics could add more to the DSL chain design.

sklogic 11y ago

> Not only maintaining and growing a DSL is challenging but also designing it at first. It's not that challenging if you do it the right way. > DSLs are costly. Plainly wrong. DSLs are the easiest and cheapest way of eliminating complexity. You simply have to follow a proper discipline and use the right tools. When I build a DSL, it's rarely more than 100 lines of code including literate comments, and the resulting DSL is a proper optimising compiler with debugging support, and this new DSL is immediately supported by an IDE (at least with syntax highlighting, autoindentation and autocompletion).