4 ms·

I disagree. DSLs give you a new set of primitives which is more suited to the problem domain and makes it harder to make mistakes by accidentally encoding thing

I disagree. DSLs give you a new set of primitives which is more suited to the problem domain and makes it harder to make mistakes by accidentally encoding things which don't exist in the problem domain. Of course, just making a DSL isn't enough. Some DSLs are badly designed and inelegant, or their features do not compose well with each other. But a well designed DSL can be a thing of both beauty and clarity. I think this shouldn't be surprising as even modern programming languages are DSLs of a kind when compared to machine code.

fauigerzigerk 6y ago
>DSLs give you a new set of primitives which is more suited to the problem domain and makes it harder to make mistakes by accidentally encoding things which don't exist in the problem domain. But domains are interrelated. If there is no common set of primitives upon which various different domain abstractions are built, then you have to relearn absolutely everything for each domain, even things that are not domain specific at all. You end up with a huge number of special cases. Mistakes are made because only very few people will be able to remember all the semantics of all the DSLs they need for their work.
- feanaro 6y ago
  I agree, and that's why DSLs are not magical pixie dust and have to be used with taste and judiciously. But in cases where they do work, they are strictly better than free form code, IMO.
  - bborud 6y ago
    Designing good DSLs is hard. If you recommend that people construct DSLs to solve their problems they will. Most of the time these DSLs will not be good and they will present either barriers or bottlenecks. The reason DSLs often become a problem is that people often do not think about the cost of maturing and maintaining them. I've seen this happen quite a few times. Someone gets the idea that "we need a DSL for this". It is implemented, but the resources and time to do a proper job isn't there so the documentation, tooling and roadmap is severely lacking or entirely absent. More requirements are uncovered and development becomes hampered by what the DSL can express or how it is implemented. If you are really unlucky, the original architect leaves or loses interest. I've seen entire products grind to a halt for 6 months because the only person with deep understanding of a DSL on which everything hinges has left the company. DSLs, like any programming language in general, can be useful. But they are expensive pieces of software to write and maintain and not the "easy solution" that people tend to be misled into thinking that they are. And if expense is spared in their making, it has to be paid for later in troubles encountered further down the road.

fauigerzigerk 6y ago

>DSLs give you a new set of primitives which is more suited to the problem domain and makes it harder to make mistakes by accidentally encoding things which don't exist in the problem domain. But domains are interrelated. If there is no common set of primitives upon which various different domain abstractions are built, then you have to relearn absolutely everything for each domain, even things that are not domain specific at all. You end up with a huge number of special cases. Mistakes are made because only very few people will be able to remember all the semantics of all the DSLs they need for their work.

feanaro 6y ago
I agree, and that's why DSLs are not magical pixie dust and have to be used with taste and judiciously. But in cases where they do work, they are strictly better than free form code, IMO.
- bborud 6y ago
  Designing good DSLs is hard. If you recommend that people construct DSLs to solve their problems they will. Most of the time these DSLs will not be good and they will present either barriers or bottlenecks. The reason DSLs often become a problem is that people often do not think about the cost of maturing and maintaining them. I've seen this happen quite a few times. Someone gets the idea that "we need a DSL for this". It is implemented, but the resources and time to do a proper job isn't there so the documentation, tooling and roadmap is severely lacking or entirely absent. More requirements are uncovered and development becomes hampered by what the DSL can express or how it is implemented. If you are really unlucky, the original architect leaves or loses interest. I've seen entire products grind to a halt for 6 months because the only person with deep understanding of a DSL on which everything hinges has left the company. DSLs, like any programming language in general, can be useful. But they are expensive pieces of software to write and maintain and not the "easy solution" that people tend to be misled into thinking that they are. And if expense is spared in their making, it has to be paid for later in troubles encountered further down the road.