
How we turned JSON into a full programming language - lelf
https://medium.com/relevant-stories/rel-chapter-1-907ff616bf80
======
pablovidal85
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](https://gist.github.com/aynik/5ffca6ba09ea08b92f71)

------
wircho
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 :)

~~~
pablovidal85
So security through obscurity, well done.

~~~
wircho
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.

~~~
pablovidal85
So your language is not turing complete?

~~~
wircho
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.

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

------
BinaryIdiot
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.

~~~
wircho
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.

~~~
BinaryIdiot
> 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.

------
detaro
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.

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

------
robotina
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?

~~~
wircho
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...](https://gist.githubusercontent.com/wircho/c8f4f5b0ce440b8edd83/raw/8ef09440e96322e75220ff1470fbc4c65d76e6c2/cities_card)
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!

------
meira
Well, you created LISP.

~~~
pablovidal85
[https://en.wikipedia.org/wiki/Greenspun's_tenth_rule](https://en.wikipedia.org/wiki/Greenspun's_tenth_rule)

