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:
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.
> 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.
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.
It was moderately more complicated that this, as it represented the actual program tree structure within XML. Imagine lisp with XML tags in place of parentheses.
> XML means "eXtensible Markup Language" - so pretty much exactly a description of the data it contains.
This is the belief that Eric Browne argued against in 2003[1]. "exactly a description of the data" only works when a human looks at it, which is the same argument for JSON. These two things "describe" the same object:
What I'm saying is that XML is system for defining types, subtypes, relationships, etc. and that this type system can be used by programs that are written to interact with document instances in a way that is not dissimilar from other statically-typed languages. In a sense, you're agreeing when you say that XML has been used for programming languages because, in that case, a document instance might contain blocks of programming statements not instructions for a machine. It must be parsed and compiled first which takes some knowledge of the type system, i.e. how to create AST's and transform them into instructions.
I'm also saying that the problem with XML comes from the inability to reason about type systems in a general way. I can give you my XSD but will you know what to do with my data? And if I give you the XSD, and I tell you what to do with the data, then won't we writing the same program? Wouldn't it be easier to just share a library?
That's because there is no implicit data structure to XML mapping by default. This is a good thing; it makes XML much more flexible.
Of course, that flexibility is what burdened us with SOAP, XBRL, and other monstrosities; but I blame the creators of SOAP, not XML. XML is the "C" of the data markup world (simple but flexible), whereas JSON is more akin to "Java" (heavily restricted in capability, resulting in workarounds to represent complex concepts).
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.
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.
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.
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.
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.
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.
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.
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/jsconte...
I see a lot of folks who are a lot smarter than me crapping on this, but I think it could be really useful. I've thought about the problem before of how to share complex rules between front-end and back-end safely, and came up with a UI for it:
I honestly didn't put too much thought into the actual structure of the JSON, so I wonder if there is someway I can now integrate JsonLogic into the query builder.
I would suggest that, at first glance, your structure is actually preferable for most applications where this would be useful. The real advantage of a DSL is when it provides a concise way to solve a specific problem domain. The OP just provides a verbose way to describe a general problem domain, without any benefit of regularization.
Your schema, on the other hand, uses explicit node names and types, which should make automated analysis much simpler and less error-prone. The few changes I'd suggest are mostly just cosmetic: standardizing the schema (the type radio seems to imply the operator equals), renaming properties (why selectedOperator when just operator will do?), and maybe compressing levels where appropriate, for instance the query-builder-group could itself have the logicalOperator property.
(1) We have a similar sort of "expression language" at my job; in our case, the value it provides is ready access to the pseudo-AST we parse it into. We transform that AST at runtime (along with subexpression results) into a human-friendly error message like "Total Amount must be less than $X when Blah Mumble is under Y". The downside is that that "configuration" data now behaves more like code but doesn't have any of the tooling of the host language: we've had to add specific code to provide a stacktrace-equivalent hint about where expression evaluation failed.
(2) The bummer design decision in JsonLogic, IMO, is the leakage of the JS equality operator into what could have been a language-agnostic description. That's going to be nasty to implement elsewhere.
So, a JSON AST. The whole point of programming languages is to give you something better than an AST to work with. Code is already data and we have functions for evaluating/compiling/interpreting said data natively/in-vms/in-interpreters.
People still make them. Because, you know, "everyone can use them" and they are "simple". In reality, only software developers are able to do anything with such a crap DSL and it takes a lot more effort and workarounds to get anything done vs a sane programming language.
Even if only the developers can use a DSL, that doesn't not mean DSLs don't have a place as a solution and that a generic programming language is always preferable.
In complex enough domains DSLs can be key to tackle that complexity and they can take many forms.
Is there a security statement about this? I don't immediately see any dangerous operations, but code sharing should always be suspect. If this catches on, it won't be long before someone asks for something that would open vulnerabilities.
All that being said, this is a really interesting approach and having a language for shared, declarative logic is often useful.
Looking over the examples, I thought of MongoDB's aggregation pipeline. You pass in a similar tree of JSON-only logic to perform more complex database operations/transformations. In Mongo's case, the idea is to have direct access to "native" calls, skipping Javascript execution altogether.
These mini-languages almost always become really painful to work with. If I find myself needing to implement some sort of configurable shared thing more complex than a table of regular expressions I just jump straight to the endgame and embed lua or a lisp.
I think the target audience of JsonLogic is sharing code on the frontend/backend. I think these days javascript is common for that. A tiny lisp would be suitable as well.
There's a special place in hell reserved for people who make me edit ad-hoc turing complete configuration languages embedded in json or xml.
I believe that eventually software development may move in general to structured serializations rather than plain text. The main thing holding that back is just that programming is defined by cryptic colored text and they are afraid they won't look technical enough if they don't stick to that. I am a programmer myself btw and of course I use text editors.
Possibly another example of the common mistake of web developers - extending "don't put business logic in views" to "don't put logic in views". That leads to invention of the silly things called "template languages", which desperately try (and fail) to avoid being programming languages, and they create a mess because they manually glue HTML (which is a tree) from dumb strings.
Pretty cool. Coincidentally I just spent the last couple days implementing configurable JSON-serialized rules in our app. The bigger part of the challenge for us was coming up with a human-friendly UI for defining the rules.
Been considering the same problem here - how to allow some sort of user-defined rules/ logic flow? The UI is indeed more difficult to (well) do than the data representation of said rules. Anything you can share?
It's funny this discussion comes up now, since I've been working on this exact same problem for an odd week on and off now. Building the syntax, interpreter, serializer/deserializer took a day. Writing the JS to render it? Still working on it. (largely hindered by my being a backend eng masquerading as a terribly incompetent frontend web dev)
My approach however was to treat it as a literal syntax tree. we can represent trees reasonably well graphically, and if you connect the blocks sensibly you can make the visualization even flow well enough. Things start to decay past certain levels of depth; and I've addressed that with modularity. A tree can be "named" and become a single node within another tree. (yes yes rewriting programming languages badly or something).
Thus far the biggest problems I've had with this approach have been primarily just learning the words I need to use to search for the right concepts in web-UX space; I've actually been pretty damn happy with the view.
This does conditional formatting for a report designer. We thought a lot about how to limit the complexity the UI exposes and still have enough power to achieve most things people would need. We worked pretty closely with the customers to make sure it made sense to them (via mockups etc) before building anything.
When you're building a serverless framework with the goal of direct client access to managed infrastructure without writing server side code, rules languages like this are an awesome tool to have. You need to: authenticate users, authorize their actions, validate schema, ensure referential integrity, and perform business logic checks.
Most (if not all) BaaS platforms have something like this:
When used for AuthN/Z, most seem to align with Role Based Access Control (RBAC), while others go for Attribute Based Access Control (ABAC). The former is generally easier to reason about and build, while the latter is more powerful though harder to build and explain.
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.
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.
> 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.
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.
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.
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.
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.
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).
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".
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?
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.
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.
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!
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.
ElasticSearch new Painless scripting language is a secure lava-like DSL language which is a superset to just logic. Although it seems to be jvm opinionated.
We built a system, where user can construct complex search criteria and submitted for result.
We were passing the criteria using a custom dsl (lot of coding in front-end to construct and parsing logic in back-end).
This will be a perfect match for those kind of cases.
I don't understand... Why just dont get all the complex logic from server/client, generate a .js with it and use in server/send to client? Why JSON?
JSON is not designed for this.
One use case might be the backend of a logic engine a la Drools. I imagine that needs a well defined, serializable subset of a full programming language.
Here to say JSON is not a good place to encode logic because JSON doesn’t allow comments, and whenever you are encoding logic, you are going to have to clarify that $conterintuitive_rule is needed because $stakeholder decided $such_and_such.
OK, I’m done shitting all over what’s probably a perfectly cromulent library now…
As a strictly experimental project, i applaud this effort and i hope the author learned a lot about building a library. The web presentation is above average as far as library projects go.
As the library itself, i would't touch this with a 100 foot pole. Serializing logic shatters encapsulation as well as cohesion, both cornerstone object oriented principles. Also, when you serialize logic, you leave yourself handicapped to fix code bugs, as your code bugs are now data bugs by definition. Imagine solving an off-by-one style error in persisted JSON logic. Your choices would be regex (shiver) or a script to parse all json blocks and modify accordingly? Yikes.
As an experiment, this is quite nice. Perhaps too nice. Given the quality of presentation, i feel bad for the shops that decide to adopt this into production usage.
As soon as you begin accepting user data, all your code bugs, even those as simple as forgetting to collect some metadata you might need later, are data bugs. And to the specific point about serializing logic being considered harmful, I'm sure https://www.periscopedata.com/ would beg to differ!
Seriously, though, there's nothing wrong with using this for a presentation layer. Define a group of user-selectable client-side filters in a JSON constants document, which will have a much smaller "error surface" than defining custom filter functions. Just because it looks like JSON doesn't mean it necessarily needs to be serialized.
That said, there are a number of inefficiencies in the implementation. Certainly not production ready, but a great effort.
I agree if we're talking about serialising app logic, but I think this library is for when your data is a ruleset you want to save/execute, some kind of conditional tasker etc.
> Also, when you serialize logic, you leave yourself handicapped to fix code bugs, as your code bugs are now data bugs by definition.
This seems to be an orthogonal architectural problem. If you need to be able to reprocess after changes to logic, chances are that you are storing your original source document somewhere and can retransform if necessary.
In my experience, folks writing code come to need a VCS ("oops, didn't mean to change that"), a debugger ("why did it do that?"), a test environment ("what happens if I change that"), and perhaps an audit trail ("who changed that?").
Set against that, the effort required to parse expressions is trivial.
I don't see why a language like JS couldn't be used for evaluating rules when sandboxed. Looks like there's a project that does just that: https://developers.google.com/caja/
https://github.com/json-schema/json-schema/wiki/switch-(v5-p... http://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/jso... https://www.npmjs.com/package/lib-jsl http://jsonnet.org/language/design.html