5 ms·

How we turned JSON into a full programming language

13 points by lelf 11y ago

detaro 11y ago
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 11y ago
  Also the possibility to use your own code base as data and manipulate it with JSON functions, aka macros :)
pablovidal85 11y ago
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
meira 11y ago
Well, you created LISP.
- pablovidal85 11y ago
  https://en.wikipedia.org/wiki/Greenspun's_tenth_rule https://en.wikipedia.org/wiki/Greenspun's_tenth_rule
wircho 11y ago
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 11y ago
  So security through obscurity, well done.
  - wircho 11y ago
    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 11y ago
      So your language is not turing complete?
      - wircho 11y ago
        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 11y ago
        Understood, I stand corrected. Anyway, I would have used some kind of non-turing complete stack language.
robotina 11y ago
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 11y ago
  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/c8f4f5b0ce440b8edd83/raw/8ef09440e96322e75220ff1470fbc4c65d76e6c2/cities_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!
BinaryIdiot 11y ago
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 11y ago
  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 11y ago
    > 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.

13 points by lelf 11y ago

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 11y ago
Also the possibility to use your own code base as data and manipulate it with JSON functions, aka macros :)

pablovidal85 11y ago

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

meira 11y ago

Well, you created LISP.

pablovidal85 11y ago
https://en.wikipedia.org/wiki/Greenspun's_tenth_rule https://en.wikipedia.org/wiki/Greenspun's_tenth_rule

wircho 11y ago

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 11y ago
So security through obscurity, well done.
- wircho 11y ago
  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 11y ago
    So your language is not turing complete?
    - wircho 11y ago
      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 11y ago
        Understood, I stand corrected. Anyway, I would have used some kind of non-turing complete stack language.

robotina 11y ago

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 11y ago
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/c8f4f5b0ce440b8edd83/raw/8ef09440e96322e75220ff1470fbc4c65d76e6c2/cities_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!

BinaryIdiot 11y ago

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 11y ago
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 11y ago
  > 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.