4 ms·

I'm not a big fan of DSLs. Yes, they allow for convenient notation to express things within specific domains, but they also create more barriers. It is both m

by bborud 6y ago

I'm not a big fan of DSLs. Yes, they allow for convenient notation to express things within specific domains, but they also create more barriers. It is both more impressive and more useful if one is able to create abstractions in mechanical sympathy with idiomatic uses of existing languages. Of course, this is harder to do. I think DSLs are a bit of a lazy cop-out. This is not a new idea. The myth of the tower of Babel and the observation that by creating lots and lots of communication barriers and interfaces, you lose the ability to coordinate major efforts is indeed very old.

feanaro 6y ago
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.
kdkeyser 6y ago
Haxl is actually an example of "the more impressive and more useful" approach: it is an abstraction embedded within a Haskell library, that allows you to express your "intent" in simple, standard Haskell code, decoupled from the way this intent will be reached (i.e. the execution is determined/optimized by the library) Haskell allows this to be done in a way that makes if very hard for the user to break this abstraction (the type system will prevent you from doing this), while still allowing the full language power of Haskell to be used.
ImprobableTruth 6y ago
> It is both more impressive and more useful if one is able to create abstractions in mechanical sympathy with idiomatic uses of existing languages. ... so, EDSLs?
HelloNurse 6y ago
Many of those communication barriers and interfaces are a feature, not an obstacle. For example, in a typical enterprise application it's good to know that SQL queries and web resource access control (two typical DSL uses) cannot interfere with one another accidentally.
- bborud 6y ago
  SQL is a DSL that is fairly heavy in that a lot has been invested in it over multiple decades. (It even has extensions or outgrowths that turn it into more of a general purpose language) This results in ample tooling, lots of documentation, multiple implementations, some of which are really good and a lot of community knowledge. One may like or dislike SQL, but it is undeniable that it is useful to and mastered by a great many people. Most DSLs have few or none of these properties. In some environments DSLs tend to be presented as something you can create casually. That it is a lightweight solution. And what starts as a small solution can often grow - usually to a point where not having put in a lot of work in the basic design will make the language unsound. I don't think DSLs are a lightweight solution at all. I think that giving inexperienced programmers the idea that DSLs are is something they ought to be designing probably isn't helpful.

by bborud 6y ago

feanaro 6y ago

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.

kdkeyser 6y ago

Haxl is actually an example of "the more impressive and more useful" approach: it is an abstraction embedded within a Haskell library, that allows you to express your "intent" in simple, standard Haskell code, decoupled from the way this intent will be reached (i.e. the execution is determined/optimized by the library) Haskell allows this to be done in a way that makes if very hard for the user to break this abstraction (the type system will prevent you from doing this), while still allowing the full language power of Haskell to be used.

ImprobableTruth 6y ago

> It is both more impressive and more useful if one is able to create abstractions in mechanical sympathy with idiomatic uses of existing languages. ... so, EDSLs?

HelloNurse 6y ago

Many of those communication barriers and interfaces are a feature, not an obstacle. For example, in a typical enterprise application it's good to know that SQL queries and web resource access control (two typical DSL uses) cannot interfere with one another accidentally.

bborud 6y ago
SQL is a DSL that is fairly heavy in that a lot has been invested in it over multiple decades. (It even has extensions or outgrowths that turn it into more of a general purpose language) This results in ample tooling, lots of documentation, multiple implementations, some of which are really good and a lot of community knowledge. One may like or dislike SQL, but it is undeniable that it is useful to and mastered by a great many people. Most DSLs have few or none of these properties. In some environments DSLs tend to be presented as something you can create casually. That it is a lightweight solution. And what starts as a small solution can often grow - usually to a point where not having put in a lot of work in the basic design will make the language unsound. I don't think DSLs are a lightweight solution at all. I think that giving inexperienced programmers the idea that DSLs are is something they ought to be designing probably isn't helpful.