Live data from Hacker News

Jid – Drill down JSON data incrementally

github.com

31–40 of 55 posts

Re: Jid – Drill down JSON data incrementally

#31
post #5

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()". Yesterday, state machine programming in JSON. Today, an inspector.

Any data serialization format which could be represented by S-Expressions could be said to be emulating Lisp.

Doesn't mean they are.

But yes, I agree with the core of your comment, though I usually harken to XML for a more visceral reaction. First there was a self-formatted schema and tooling to verify it. Then an RPC specification. Followed by parsers built to fit special needs (such as comments). Inspectors, transformers, pretty printers, incremental parsers, bash integrations, namespaces...

Programming history is definitely cyclical.

Re: Jid – Drill down JSON data incrementally

#32
post #5

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()". Yesterday, state machine programming in JSON. Today, an inspector.

Any data serialization format which could be represented by S-Expressions could be said to be emulating Lisp. Doesn't mean they are. But yes, I agree with the core of your comment, though I usually harken to XML for a more visceral reaction. First there was a self-formatted schema and tooling to verify it. Then an RPC specification. Followed by parsers built to fit special needs (such as comments). Inspectors, transf…

I expect that will eventually happen whenever you have a popular enough data format and stick with it long enough. All the same tools get reinvented. Start over with a new format and the tools all have to be rebuilt from scratch.

But this isn't to say that new languages should never be invented. Just that there's a lot more work involved than anyone would expect.

Re: Jid – Drill down JSON data incrementally

#33
post #27

Earlier quoted context omitted.

Can you point me to an example of a serialization that was reinvented?

JSON vs S-expressions

Ah I always figured S-expressions were "representations" as opposed to "serializations", but that makes sense. Any others?

Re: Jid – Drill down JSON data incrementally

#34

Earlier quoted context omitted.

Any data serialization format which could be represented by S-Expressions could be said to be emulating Lisp. Doesn't mean they are. But yes, I agree with the core of your comment, though I usually harken to XML for a more visceral reaction. First there was a self-formatted schema and tooling to verify it. Then an RPC specification. Followed by parsers built to fit special needs (such as comments). Inspectors, transf…

I expect that will eventually happen whenever you have a popular enough data format and stick with it long enough. All the same tools get reinvented. Start over with a new format and the tools all have to be rebuilt from scratch. But this isn't to say that new languages should never be invented. Just that there's a lot more work involved than anyone would expect.

That's an interesting way of viewing it, I guess it applies to JavaScript as well. There is a lot of discussion regarding how the Javascript community is re-inventing the wheel, but I guess once enough impetus arives to a language then re-tooling is inevitable.

Re: Jid – Drill down JSON data incrementally

#35
post #5

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()". Yesterday, state machine programming in JSON. Today, an inspector.

Except JSON has a huge advantage Lisp doesn't: it's close to, or in some cases identical to, the data-structure syntax of several popular programming languages. Lisp's particular s-expression syntax is not close to or identical to any programming language other than Lisp.

In other words: once you decide you don't want to program in Lisp, Lisp's way of representing data stops being a useful syntax for representing your data. Undervaluing this realization (and worse, reacting smugly when interacting with people who don't share your undervaluing of this) is a big part of the gulf between Lispers and the rest of the world.

Re: Jid – Drill down JSON data incrementally

#36
post #5

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()". Yesterday, state machine programming in JSON. Today, an inspector.

Except JSON has a huge advantage Lisp doesn't: it's close to, or in some cases identical to, the data-structure syntax of several popular programming languages. Lisp's particular s-expression syntax is not close to or identical to any programming language other than Lisp. In other words: once you decide you don't want to program in Lisp, Lisp's way of representing data stops being a useful syntax for representing you…

> In other words: once you decide you don't want to program in Lisp, Lisp's way of representing data stops being a useful syntax for representing your data.

Even if you code in C++, you can find Lisp's surface syntax simple enough to read and write. Now, if your language already defines a "read" function, sure, go with it.

Re: Jid – Drill down JSON data incrementally

#37
post #36

Earlier quoted context omitted.

Except JSON has a huge advantage Lisp doesn't: it's close to, or in some cases identical to, the data-structure syntax of several popular programming languages. Lisp's particular s-expression syntax is not close to or identical to any programming language other than Lisp. In other words: once you decide you don't want to program in Lisp, Lisp's way of representing data stops being a useful syntax for representing you…

> In other words: once you decide you don't want to program in Lisp, Lisp's way of representing data stops being a useful syntax for representing your data. Even if you code in C++, you can find Lisp's surface syntax simple enough to read and write. Now, if your language already defines a "read" function, sure, go with it.

As I said: if I wanted to write Lisp I'd write Lisp. I've already chosen not to write Lisp. I have no incentive to make my language parse Lisp when something much closer to my preferred language's data structure syntax is available.

The mere fact that a solution exists for a problem does not mean it is the best possible solution for all possible people in all possible cases, nor that there can never be a reason to develop or prefer another solution.

Re: Jid – Drill down JSON data incrementally

#38
post #36

Earlier quoted context omitted.

> In other words: once you decide you don't want to program in Lisp, Lisp's way of representing data stops being a useful syntax for representing your data. Even if you code in C++, you can find Lisp's surface syntax simple enough to read and write. Now, if your language already defines a "read" function, sure, go with it.

As I said: if I wanted to write Lisp I'd write Lisp . I've already chosen not to write Lisp. I have no incentive to make my language parse Lisp when something much closer to my preferred language's data structure syntax is available. The mere fact that a solution exists for a problem does not mean it is the best possible solution for all possible people in all possible cases, nor that there can never be a reason to d…

I didn't say it is the best solution in all possible cases. Just that even if you choose not to write Lisp, using a data format that follows Lisp's approach is not a stupid thing to do.

> Undervaluing this realization (and worse, reacting smugly when interacting with people who don't share your undervaluing of this) is a big part of the gulf between Lispers and the rest of the world.

You are the one setting the tone with your exclusionary rhetoric.

Post reply on HN