4 ms·

I recently implemented a DSL for an environment that I wrote for a fairly niche purpose, accompanied with a graphical application to build "programs" in that DS

by GuiA 10y ago

I recently implemented a DSL for an environment that I wrote for a fairly niche purpose, accompanied with a graphical application to build "programs" in that DSL, because my users are non programmers that need to express domain specific logic. It has saved us hundreds if not thousands of man hours on something mission critical to the company, all while empowering the end users, giving my programmers more latitude to operate, and separating nicely the generic environment from the specifics that are irrelevant to it. There are many ways to solve a problem, and the right one is highly context dependent. Dismissing something just on the basis of "we already have a way to express logic; it's called code" seems very narrow minded and not like the best way to produce solid engineering work. I can also highly recommend Fowler's "Domain Specific Languages" book, which gives me the backing to say that I am far from alone in having success with that approach. http://martinfowler.com/bliki/DomainSpecificLanguage.html http://martinfowler.com/bliki/DomainSpecificLanguage.html

iamleppert 10y ago
Can you explain a few more details on the application? I'm wondering why you didn't just design an API and embed a super simple scripting language at that point if you really needed that kind of power. If I'm thinking what it is, the graphical editor/composer is what has saved you a lot of time, not the DSL. Your users likely are never touching the DSL, they are simply using your GUI application to build their use cases at that point. This is a common pattern that has nothing to do with DSLs; you just happen to target one as the intermediary format. It's important to understand this distinction. But feel free to provide more details if this is not the case.
- GuiA 10y ago
  The gist of it is researchers needing to design flows of arbitrary complexity to gather data, that can be composed together in many ways and might change over time (and need to be versioned), with a strong graphical component to it. Yes, I could have embedded Lua or Python or JS and made them interact with an API that the environment exposes, but designing my own DSL let me make it a declarative affair, which greatly simplified things, as well as take various shortcuts in representing some abstractions that'd have been much more of a pain otherwise. This was in a CPU/memory bound environment, where the declarative, compact DSL approach (with all of the properties of the resulting program inferrable at parse time) turned out to work quite well. And generating that DSL is much more straightforward than generating code in a full scripting language. The graphical editor was indeed a big reason for the success, and my users didn't interact with the DSL, but my developers did and it was much more straightforward for them than having to deal with lua/Python/etc. Ultimately we'd have still ended up with a DSL, albeit one represented in a programming language where 99% of the features are unused. I'm not sure I get why you're so opposed to the notion altogether. Sure, there's plenty to quibble with if one so desires with OP's implementation in a vacuum, but perhaps consider that people just as experienced and knowledgeable as you have found value in the DSL approach over others for certain projects. If you're interested in diving more into it, check out Fowler's book.
  - hvidgaard 10y ago
    Is that company code, or something you have opensourced? It sounds bery useful for a problem I will face in about 6 months.
hvidgaard 10y ago
A DSL is fine, encouraged even, for solving specific problems. JsonLogic however seems like a general tool looking for a job, but I maybe I just haven't seen its usecase yet. It looks as a way to move business rules entirely to the backend, but still have the frontend executing them. I can see the value in that if you desperately need to reduce the load on your backend.
- GuiA 10y ago
  > JsonLogic however seems like a general tool looking for a job From the looks of it, I agree. It feels like an AST serialization format in JSON, but it's unclear whether it's optimized for any specific use cases or merely a toy implementation.
- softawre 10y ago
  Javascript is the way we execute the same rules on the front/back.
  - pmontra 10y ago
    Or any language that runs in the backend and compiles to JS for the frontend. Rxample: if you have a Rails backend you might consider to use Opal for the code shared between the server and the browser. This JSON logic would be there.
crdoconnor 10y ago
If the DSL logic is complex enough to require something approaching a turing complete language - which it looks like "jsonlogic" is, it's better to just provide the functionality in a python library with a clean API rather than trying to invent your own DSL. Turing complete markup-based DSLs have been created before - e.g. ant/maven/xslt - and in those cases it was a huge mistake to create an entirely new language that powerful. If the DSL logic doesn't require a turing complete language - something much less powerful, it might be worth doing a DSL that has limited computational power. IMHO this is a core principle underlies most computer languages: https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power

by GuiA 10y ago

iamleppert 10y ago

Can you explain a few more details on the application? I'm wondering why you didn't just design an API and embed a super simple scripting language at that point if you really needed that kind of power. If I'm thinking what it is, the graphical editor/composer is what has saved you a lot of time, not the DSL. Your users likely are never touching the DSL, they are simply using your GUI application to build their use cases at that point. This is a common pattern that has nothing to do with DSLs; you just happen to target one as the intermediary format. It's important to understand this distinction. But feel free to provide more details if this is not the case.

GuiA 10y ago
The gist of it is researchers needing to design flows of arbitrary complexity to gather data, that can be composed together in many ways and might change over time (and need to be versioned), with a strong graphical component to it. Yes, I could have embedded Lua or Python or JS and made them interact with an API that the environment exposes, but designing my own DSL let me make it a declarative affair, which greatly simplified things, as well as take various shortcuts in representing some abstractions that'd have been much more of a pain otherwise. This was in a CPU/memory bound environment, where the declarative, compact DSL approach (with all of the properties of the resulting program inferrable at parse time) turned out to work quite well. And generating that DSL is much more straightforward than generating code in a full scripting language. The graphical editor was indeed a big reason for the success, and my users didn't interact with the DSL, but my developers did and it was much more straightforward for them than having to deal with lua/Python/etc. Ultimately we'd have still ended up with a DSL, albeit one represented in a programming language where 99% of the features are unused. I'm not sure I get why you're so opposed to the notion altogether. Sure, there's plenty to quibble with if one so desires with OP's implementation in a vacuum, but perhaps consider that people just as experienced and knowledgeable as you have found value in the DSL approach over others for certain projects. If you're interested in diving more into it, check out Fowler's book.
- hvidgaard 10y ago
  Is that company code, or something you have opensourced? It sounds bery useful for a problem I will face in about 6 months.

hvidgaard 10y ago

A DSL is fine, encouraged even, for solving specific problems. JsonLogic however seems like a general tool looking for a job, but I maybe I just haven't seen its usecase yet. It looks as a way to move business rules entirely to the backend, but still have the frontend executing them. I can see the value in that if you desperately need to reduce the load on your backend.

GuiA 10y ago
> JsonLogic however seems like a general tool looking for a job From the looks of it, I agree. It feels like an AST serialization format in JSON, but it's unclear whether it's optimized for any specific use cases or merely a toy implementation.
softawre 10y ago
Javascript is the way we execute the same rules on the front/back.
- pmontra 10y ago
  Or any language that runs in the backend and compiles to JS for the frontend. Rxample: if you have a Rails backend you might consider to use Opal for the code shared between the server and the browser. This JSON logic would be there.

crdoconnor 10y ago

If the DSL logic is complex enough to require something approaching a turing complete language - which it looks like "jsonlogic" is, it's better to just provide the functionality in a python library with a clean API rather than trying to invent your own DSL. Turing complete markup-based DSLs have been created before - e.g. ant/maven/xslt - and in those cases it was a huge mistake to create an entirely new language that powerful. If the DSL logic doesn't require a turing complete language - something much less powerful, it might be worth doing a DSL that has limited computational power. IMHO this is a core principle underlies most computer languages: https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power