I wonder why they didn't use plain JSON arrays and a lisp interpreter, so much structure seems unnecessary.

https://gist.github.com/aynik/5ffca6ba09ea08b92f71

Hi everyone. The author here. A couple of answers to much asked questions:

Why JSON? Mainly because it makes it natural to embed JSON objects into code that's otherwise purely functional. Also, as @detaro pointed out, it saved us the time to build our own parser.

Why not use an interpreter/compiler for an existing functional language? Building our own language allows us to control the reach of the code and prevent malicious stuff. Having our own compiler is also useful when threading and networking matters as much as it does to us, since there is simultaneous front end and back end processing.

The result is a very simple syntax for API aggregation where we take care of all the hard part in the background :)

So security through obscurity, well done.

It's more straightforward than this. Think of it as a more comprehensive Yahoo Pipes or IFTTT, where the nice graphical interface is not yet released publicly. So for now developers can just write the raw JSON. Yes, a LISP interpreter would have done that job (as would a library written in some other programming language). However you are not allowed to download code into an iOS app (precisely for security reasons), and so we're downloading items from a predefined documented list of macros. This simplicity, in turn, makes creating a graphical interface a lot easier, without sacrificing the fact that the structure is as flexible as a functional programming language.

So your language is not turing complete?

I would say it's not, since it lacks conditional branching, although one could argue that you can simulate a Turing complete system on a Relevant card by having a user indefinitely tap on a button that refreshes it at the next state.

Understood, I stand corrected. Anyway, I would have used some kind of non-turing complete stack language.

This is...ugh, I don't want to use the word but gross seems to be most fitting. I really don't understand why anyone would do this. Worst yet if your iOS app is interpreting and executing this from an external source than it's against the Apple ToS for the App Store.

All the logic is executed on the back-end. Front-end is called only for user input and location.

We've been using this syntax for a while and it works well for us internally, but we're soon releasing more appealing tools. Read comments below for more details.

> All the logic is executed on the back-end. Front-end is called only for user input and location.

Fair enough; that wasn't clear to me from reading the article.

I still think this is a solution to a non-existent problem. Essentially interfaces solved this type of problem 30 years ago. Today you can implement a set of interfaces and, depending on your language of choice, hot swap / add/ delete them as needed and those can all do exactly what your fancy JSON does but without the proprietary, new syntax and language being introduced.

Maybe I missed it, but what benefit does it have to squeeze that into JSON structures, except making it harder to write for humans? Only to save part of the parser-building?

That said, an easy but powerful tool to digest and display APIs sounds very useful.

Also the possibility to use your own code base as data and manipulate it with JSON functions, aka macros :)

I'm a bit confused. Assuming that I'm designing an API, should it confirm to your language and return the results as your fancy JSON?

No. With REL it is possible to aggregate and manipulate any JSON API. The only thing that has to be written in REL is the card file itself. This JSON file is to be hosted anywhere on the web. For example, this is a Hello World card https://gist.githubusercontent.com/wircho/c8f4f5b0ce440b8edd... hosted on GitHub.

If you are releasing a JSON API, I'd be happy to try it out and make a card for it. Let me know if you have more questions!

Well, you created LISP.