5 ms·

Please not another DSL. We already have a way to express logic; it's called code. If you want to make a different programming language that's fine. Data is cod

Please not another DSL. We already have a way to express logic; it's called code. If you want to make a different programming language that's fine. Data is code. Maybe what you really want is a finite state machine? http://machina-js.org/ http://machina-js.org/

ng12 10y ago
I've worked on a service that did something like this, except everything was passed through a middleman who was managing a bunch of live-reloading Groovy code where the actual business logic was stored. Would this have been a better approach? Maybe! But at the very least its an interesting idea and even if interesting ideas fail they might serve to inspire something new. I don't see a reason to be openly hostile just because it's a "DSL".
- sandGorgon 10y ago
  interesting!! can you please talk about the architecture? how was the groovy code stored(db/disk files)? was it user editable.. what about security then? why groovy?
asciimike 10y ago
Sure, but what if you're building a serverless framework or other multi-tenant system and the goal is for an external developer to not write backend code? You need a compact way to represent and evaluate authentication and authorization, maintain schema or referential integrity, or do simple business logic checks.
- andrewstuart2 10y ago
  This is code. Instructions codified into a machine-readable format. It's just really verbose and complex code. It reads almost exactly like Polish notation [1], assembly code, an abstract syntax tree. Except encapsulated in JSON trees rather than space-separated lists. The problem is that it's almost entirely optimized for a machine to read, and not for a human. Next thing you know, you've written something a little complex in this new format and realized it's pretty hard to maintain. So what should you do? Create a program to generate it, perhaps, from a higher level, easier to read, representation. In other words, a compiler. [1] https://en.wikipedia.org/wiki/Polish_notation https://en.wikipedia.org/wiki/Polish_notation
  - asciimike 10y ago
    I don't think I ever said it wasn't code, I said it wasn't "backend code". We've exchanged some config (sure, basically an AST) for writing some express/django/rails middleware. I'd much rather check authentication status by writing "{"!=", [request.auth, null]}" than writing more backend code, especially if someone else has done a bunch of the work for me. That said, I'd argue this notation probably isn't a super concise representation for config over code. Implementing a JS evaluator so you could instead write "request.auth != null" and having JS like expressions is easier than the Prefix notation. Cool idea nonetheless!
    - deleted 10y ago
      [deleted]
- inopinatus 10y ago
  All configuration is programming. Glib but true. It's practically axiomatic. And it follows immediately that all configuration can be represented by code. Learning that it should be is a matter of experience.
ta834939874 10y ago
Code is fine in a trusted environment, however sometimes you need to give another process/user/actor a limited environment. You could give them a limited run time environment, however that is often difficult For example, consider you have a stream of events that you need the user to be able to filter server side, such as all events that have a field of "name":"bob". I will agree with you that these systems often increase in complexity until you have finally built a small language runtime. It can be difficult to distinguish where the descriptive language ends (eg binary operations) and the other begins ends and the other begins (eg sliding window, custom algorithms).
- deleted 10y ago
  [deleted]
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.

ng12 10y ago

I've worked on a service that did something like this, except everything was passed through a middleman who was managing a bunch of live-reloading Groovy code where the actual business logic was stored. Would this have been a better approach? Maybe! But at the very least its an interesting idea and even if interesting ideas fail they might serve to inspire something new. I don't see a reason to be openly hostile just because it's a "DSL".

sandGorgon 10y ago
interesting!! can you please talk about the architecture? how was the groovy code stored(db/disk files)? was it user editable.. what about security then? why groovy?

asciimike 10y ago

Sure, but what if you're building a serverless framework or other multi-tenant system and the goal is for an external developer to not write backend code? You need a compact way to represent and evaluate authentication and authorization, maintain schema or referential integrity, or do simple business logic checks.

andrewstuart2 10y ago
This is code. Instructions codified into a machine-readable format. It's just really verbose and complex code. It reads almost exactly like Polish notation [1], assembly code, an abstract syntax tree. Except encapsulated in JSON trees rather than space-separated lists. The problem is that it's almost entirely optimized for a machine to read, and not for a human. Next thing you know, you've written something a little complex in this new format and realized it's pretty hard to maintain. So what should you do? Create a program to generate it, perhaps, from a higher level, easier to read, representation. In other words, a compiler. [1] https://en.wikipedia.org/wiki/Polish_notation https://en.wikipedia.org/wiki/Polish_notation
- asciimike 10y ago
  I don't think I ever said it wasn't code, I said it wasn't "backend code". We've exchanged some config (sure, basically an AST) for writing some express/django/rails middleware. I'd much rather check authentication status by writing "{"!=", [request.auth, null]}" than writing more backend code, especially if someone else has done a bunch of the work for me. That said, I'd argue this notation probably isn't a super concise representation for config over code. Implementing a JS evaluator so you could instead write "request.auth != null" and having JS like expressions is easier than the Prefix notation. Cool idea nonetheless!
  - deleted 10y ago
    [deleted]
inopinatus 10y ago
All configuration is programming. Glib but true. It's practically axiomatic. And it follows immediately that all configuration can be represented by code. Learning that it should be is a matter of experience.

ta834939874 10y ago

Code is fine in a trusted environment, however sometimes you need to give another process/user/actor a limited environment. You could give them a limited run time environment, however that is often difficult For example, consider you have a stream of events that you need the user to be able to filter server side, such as all events that have a field of "name":"bob". I will agree with you that these systems often increase in complexity until you have finally built a small language runtime. It can be difficult to distinguish where the descriptive language ends (eg binary operations) and the other begins ends and the other begins (eg sliding window, custom algorithms).

deleted 10y ago
[deleted]

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.