6 ms·

Adding computation to a data description language is always a bad idea. I've seen this done with XML. XSLT is a great example of why this sucks. This has bee

Adding computation to a data description language is always a bad idea. I've seen this done with XML. XSLT is a great example of why this sucks. This has been done with JSON before anyway. Here are several examples: https://github.com/json-schema/json-schema/wiki/switch-(v5-proposal) https://github.com/json-schema/json-schema/wiki/switch-(v5-p... http://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/json/src/tpc/db2z_jsonlogicaloperators.html http://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/jso... https://www.npmjs.com/package/lib-jsl https://www.npmjs.com/package/lib-jsl http://jsonnet.org/language/design.html http://jsonnet.org/language/design.html

dirtyaura 10y ago
Why is it always a bad idea? For example there can be content that is triggered by rules and these rules need to be edited by non-programmers. Furthermore these rules need to be evaluate in different execution contexts (in our case in Android and iOS) This is a situation that requires describing simple logic alongside data.
- vbezhenar 10y ago
  IMO it's always strictly better to use something real, like LUA. WoW uses lua as a programming language for user interface and users can make their additions (addons and macroses). A lot of users, who don't know anything about programming, can successfully use those lua snippets. Also when real programmers have to interact with those systems (and my practice shows, that business users don't want to program, they ask programmers to do it), it's so much pain to use those GUI languages or whatever and it's so easy just to write some code in sane language.
  - josephearl 10y ago
    Apple has restrictions on downloading executable code, which downloading a Lua script would likely fall afoul of. It's also a potential security risk - the downloaded script could perform things other than logic and so would require sandboxing/whitelisting of commands. Putting logic in JSON avoids both of these issues since the actual handling of the logic is performed by a client-side library.
    - jfroma 10y ago
      Serious question, whats the difference between executable lua and executable json regarding apple restrictions?
      - michaelmior 10y ago
        JSON is not executable. Although I suppose you could argue that embedding an interpreter for a DSL like this inside your app is violating the restriction.
        boomlinde 10y ago
        Lua isn't executable either. The point at which it results in some corresponding machine instructions wouldn't be much different in this case.
        MichaelBurge 10y ago
        ELF binaries aren't executable either: They require the kernel to interpret them, preparing virtual memory and granting it a pid. Alone, they're just sequences of bytes.
        boomlinde 10y ago
        What's your point? That you are willing to extend this principle to ELF binaries doesn't really affect my argument. My point is that for the purpose of letting some non-trusted instructions run safely in a program, encoding them as JSON or Lua will come with the same caveats. Ultimately, they are both interpreted and can be sandboxed thus. Neither contain any code that will be passed off as-is for the CPU to execute. In some cases, neither does an ELF blob.
    - dirtyaura 10y ago
      To my understanding those restrictions have been lifted years ago. They used them strategically to kill Flash from becoming an app development platform and still probably can use them to kill cross-platform programming kits. But having scripting code in the app is not a problem anymore - they even offer Javascript execution context library in iOS SDK that makes it easy to run Javascript without UI. https://developer.apple.com/reference/javascriptcore/jscontext https://developer.apple.com/reference/javascriptcore/jsconte...
keithb- 10y ago
Okay, first of all, the current fascination with JSON is not fundamentally different from the previous fascination with XML. The only thing that anyone can agree on is that JSON is easy to parse just like its predecessor. This is why XSLT came into existence: firstly, it was easy to parse, secondly, ..., thirdly, profit (i.e. reuse, generalization, performance, etc. etc. etc.). On the other hand, this language is bananas because the programmer is writing the AST and that is what a parser is supposed to do for him/her. Manually coding the AST is like harvesting an acre of corn by hand. If you can find a more inefficient method, then by all means use it. And just for good measure, XML is not a "data description language", it is a type system; probably the most complex type system I've ever seen and it wasn't a bad idea, it was simply more complex than any application would ever need. I don't dislike XML, and I think it will continue to live just like Haskell because every generation will come to understand that its extreme faith in generalization has little practical use just about the same time that a new generation first discovers it. So while one is dying to simplify, the other is dying to espouse the existential core of computer science.
- falcolas 10y ago
  > XML is not a "data description language", it is a type system XML means "eXtensible Markup Language" - so pretty much exactly a description of the data it contains. Granted, you can mark up a bit of data with a type, but you can mark it up with anything else as well. I've even seen entire programming languages built upon XML.
  - drostie 10y ago
    I actually don't think that would be all bad if you in addition paired some parsers and serializers for other formats in your standard library. That could actually be a really fun language: "you can write this in Haskell-syntax, Python-syntax, or C-syntax, we don't care, just make sure that you enclose it in the corresponding <parse-as lang="c"> // ... </parse-as> and then `myprogram.c.x` will get compiled to `myprogram.x` which is a standard XML file, which you can then edit with `x-to-py myprogram.x >myprogram.py.x && vim myprogram.py.x` and have a field day of it." Sort of like the PL equivalent of Lennon's Imagine.
cabalamat 10y ago
> Adding computation to a data description language is always a bad idea. Unless it is Lisp s-expressions.
Corrado 10y ago
I agree. This really makes me think of XSLT and all of the horrors that go along with it in real world usage. Maybe I'm not seeing the bigger picture but I don't really know how/where JsonLogic would be used and why it would be a better alternative than a programming language. Are there any examples that might clear it up for me? The linked site is documentation for the language but it's not helping me understand the need for this project.
formula1 10y ago
While I agree this has been tried many times before, I still think there is room for another syntax. - html/xml has become the definitive declarative ui language since it generally acts exactly how we expect it - css queries and xpath have been effective at providing a way to search a structured tree - regexp hqve provided us a way to search or structure strings I dont find it absurd to believe that there can be a language for transformations

dirtyaura 10y ago

Why is it always a bad idea? For example there can be content that is triggered by rules and these rules need to be edited by non-programmers. Furthermore these rules need to be evaluate in different execution contexts (in our case in Android and iOS) This is a situation that requires describing simple logic alongside data.

vbezhenar 10y ago
IMO it's always strictly better to use something real, like LUA. WoW uses lua as a programming language for user interface and users can make their additions (addons and macroses). A lot of users, who don't know anything about programming, can successfully use those lua snippets. Also when real programmers have to interact with those systems (and my practice shows, that business users don't want to program, they ask programmers to do it), it's so much pain to use those GUI languages or whatever and it's so easy just to write some code in sane language.
- josephearl 10y ago
  Apple has restrictions on downloading executable code, which downloading a Lua script would likely fall afoul of. It's also a potential security risk - the downloaded script could perform things other than logic and so would require sandboxing/whitelisting of commands. Putting logic in JSON avoids both of these issues since the actual handling of the logic is performed by a client-side library.
  - jfroma 10y ago
    Serious question, whats the difference between executable lua and executable json regarding apple restrictions?
    - michaelmior 10y ago
      JSON is not executable. Although I suppose you could argue that embedding an interpreter for a DSL like this inside your app is violating the restriction.
      - boomlinde 10y ago
        Lua isn't executable either. The point at which it results in some corresponding machine instructions wouldn't be much different in this case.
        MichaelBurge 10y ago
        ELF binaries aren't executable either: They require the kernel to interpret them, preparing virtual memory and granting it a pid. Alone, they're just sequences of bytes.
        boomlinde 10y ago
        What's your point? That you are willing to extend this principle to ELF binaries doesn't really affect my argument. My point is that for the purpose of letting some non-trusted instructions run safely in a program, encoding them as JSON or Lua will come with the same caveats. Ultimately, they are both interpreted and can be sandboxed thus. Neither contain any code that will be passed off as-is for the CPU to execute. In some cases, neither does an ELF blob.
  - dirtyaura 10y ago
    To my understanding those restrictions have been lifted years ago. They used them strategically to kill Flash from becoming an app development platform and still probably can use them to kill cross-platform programming kits. But having scripting code in the app is not a problem anymore - they even offer Javascript execution context library in iOS SDK that makes it easy to run Javascript without UI. https://developer.apple.com/reference/javascriptcore/jscontext https://developer.apple.com/reference/javascriptcore/jsconte...

keithb- 10y ago

Okay, first of all, the current fascination with JSON is not fundamentally different from the previous fascination with XML. The only thing that anyone can agree on is that JSON is easy to parse just like its predecessor. This is why XSLT came into existence: firstly, it was easy to parse, secondly, ..., thirdly, profit (i.e. reuse, generalization, performance, etc. etc. etc.). On the other hand, this language is bananas because the programmer is writing the AST and that is what a parser is supposed to do for him/her. Manually coding the AST is like harvesting an acre of corn by hand. If you can find a more inefficient method, then by all means use it. And just for good measure, XML is not a "data description language", it is a type system; probably the most complex type system I've ever seen and it wasn't a bad idea, it was simply more complex than any application would ever need. I don't dislike XML, and I think it will continue to live just like Haskell because every generation will come to understand that its extreme faith in generalization has little practical use just about the same time that a new generation first discovers it. So while one is dying to simplify, the other is dying to espouse the existential core of computer science.

falcolas 10y ago
> XML is not a "data description language", it is a type system XML means "eXtensible Markup Language" - so pretty much exactly a description of the data it contains. Granted, you can mark up a bit of data with a type, but you can mark it up with anything else as well. I've even seen entire programming languages built upon XML.
- drostie 10y ago
  I actually don't think that would be all bad if you in addition paired some parsers and serializers for other formats in your standard library. That could actually be a really fun language: "you can write this in Haskell-syntax, Python-syntax, or C-syntax, we don't care, just make sure that you enclose it in the corresponding <parse-as lang="c"> // ... </parse-as> and then `myprogram.c.x` will get compiled to `myprogram.x` which is a standard XML file, which you can then edit with `x-to-py myprogram.x >myprogram.py.x && vim myprogram.py.x` and have a field day of it." Sort of like the PL equivalent of Lennon's Imagine.

cabalamat 10y ago

> Adding computation to a data description language is always a bad idea. Unless it is Lisp s-expressions.

Corrado 10y ago

I agree. This really makes me think of XSLT and all of the horrors that go along with it in real world usage. Maybe I'm not seeing the bigger picture but I don't really know how/where JsonLogic would be used and why it would be a better alternative than a programming language. Are there any examples that might clear it up for me? The linked site is documentation for the language but it's not helping me understand the need for this project.

formula1 10y ago

While I agree this has been tried many times before, I still think there is room for another syntax. - html/xml has become the definitive declarative ui language since it generally acts exactly how we expect it - css queries and xpath have been effective at providing a way to search a structured tree - regexp hqve provided us a way to search or structure strings I dont find it absurd to believe that there can be a language for transformations