3 ms·

You can be skeptical of DSL's but still recognize that they provide a time/complexity trade-off. I agree that it's probably not the right decision to write your

You can be skeptical of DSL's but still recognize that they provide a time/complexity trade-off. I agree that it's probably not the right decision to write your own DSL for something but to dogmatically crusade against all DSL's feels silly to me when there are so many popular projects using them. Ansible is popular because it is accessible to devop type roles (previously known as sysadmin or IT services) that may know some programming but would fail to produce results nearly as fast if they were simply left with python libraries. It would not be as popular as it is today if it were simply a python library. Criticizing this project for using a DSL as it's interface over some programmer purity test BS is completely missing the forest for the trees.

erikpukinskis 7y ago
> they provide a time/complexity trade-off I think that’s too specific of a claim for such a broad category as DSLs. I think in specific cases there is a time-complexity tradeoff you can exploit, those are the (IMO extremely rare) cases where a DSL is worth considering. But in a lot of cases it’s just added complexity. Functions are pretty powerful. And they are also easier to reason about. Often the DSL adds “time” because you’re like “why the heck isn’t this working” and it’s because of some weird state you can’t inspect that’s deep inside your parse tree. “Guess I better start reading the source code of my DSL runtime. Oh look, someone hacked a corner care into the parser.” My rule of thumb would be something like: 1) if you have time to make your DSL superbly executed, and 2) you are very certain it can make an entire class of problems go away, and 3) you don’t expect weird corner cases to ever show up in a future project that break the model ...then it’s worth considering. As a professional coder though, I don’t see a lot of situations like that. In particular the “build this module superbly” is generally not an option on the table. Nor is “you can model the domain of future needs thoroughly” But I work at startups, I bet at a BigCo if you are a very senior person DSLs are on the table more often.
- debaserab2 7y ago
  Your whole argument boils down to "use a DSL only when appropriate" - no argument here on my end. Still, I don't think that makes a DSL a bad fit for this specific project, even by your own standards. > 1) if you have time to make your DSL superbly executed, and 2) you are very certain it can make an entire class of problems go away, and 3) you don’t expect weird corner cases to ever show up in a future project that break the model ...then it’s worth considering. #1 yes, just like any code you write, right? #2 yep, this is the same thing as complexity/time trade off #3 maybe? you can still have edge cases that you can't solve with your DSL but that doesn't invalidate its usage if the benefits from #2 are great enough. And #4, which is the biggest reason and the reason to use it on a project like this: it provides a more accessible interface to your project for a broader audience of people.

erikpukinskis 7y ago

> they provide a time/complexity trade-off I think that’s too specific of a claim for such a broad category as DSLs. I think in specific cases there is a time-complexity tradeoff you can exploit, those are the (IMO extremely rare) cases where a DSL is worth considering. But in a lot of cases it’s just added complexity. Functions are pretty powerful. And they are also easier to reason about. Often the DSL adds “time” because you’re like “why the heck isn’t this working” and it’s because of some weird state you can’t inspect that’s deep inside your parse tree. “Guess I better start reading the source code of my DSL runtime. Oh look, someone hacked a corner care into the parser.” My rule of thumb would be something like: 1) if you have time to make your DSL superbly executed, and 2) you are very certain it can make an entire class of problems go away, and 3) you don’t expect weird corner cases to ever show up in a future project that break the model ...then it’s worth considering. As a professional coder though, I don’t see a lot of situations like that. In particular the “build this module superbly” is generally not an option on the table. Nor is “you can model the domain of future needs thoroughly” But I work at startups, I bet at a BigCo if you are a very senior person DSLs are on the table more often.

debaserab2 7y ago
Your whole argument boils down to "use a DSL only when appropriate" - no argument here on my end. Still, I don't think that makes a DSL a bad fit for this specific project, even by your own standards. > 1) if you have time to make your DSL superbly executed, and 2) you are very certain it can make an entire class of problems go away, and 3) you don’t expect weird corner cases to ever show up in a future project that break the model ...then it’s worth considering. #1 yes, just like any code you write, right? #2 yep, this is the same thing as complexity/time trade off #3 maybe? you can still have edge cases that you can't solve with your DSL but that doesn't invalidate its usage if the benefits from #2 are great enough. And #4, which is the biggest reason and the reason to use it on a project like this: it provides a more accessible interface to your project for a broader audience of people.