6 ms·

It's yet another poor re-implementation of S-expressions and Lisp. This: [ { "op": "replace", "path": "/baz", "value": "boo" }, { "op": "add",

It's yet another poor re-implementation of S-expressions and Lisp. This: [ { "op": "replace", "path": "/baz", "value": "boo" }, { "op": "add", "path": "/hello/bim", "value": ["world"] }, { "op": "remove", "path": "/foo" } ] is clearly inferior to: (patch (replace (baz) "boo") (add (hello bim) ("world")) (remove (foo))) Although I suppose the verbosity might be helpful in convincing PHBs that one is getting work done, it gets in the way of understanding.

draegtun 4y ago
>> It's yet another poor re-implementation of S-expressions and Lisp. Or alternatively Rebol, which was one of the inspirations to JSON. With Rebol you could write these patches like this: patch [ replace /baz: "boo" add /hello: ["world"] remove /foo ] patch [ add /biscuits/1: [name: "Ginger Nut"] ]
bowsamic 4y ago
How is it clearly inferior? I prefer it to yours
- shadowgovt 4y ago
  Agreed. The patch key-value syntax is self-describing and extensible. The s-expression syntax's reliance on positional inputs is less self-describing and extension can only be done at the end of the s-expressions. And the s-expressions don't even solve the problem of terseness for wire-format reasons; protobufs beat them out in that category.
  - dgb23 4y ago
    Neither sexpr nor JSON are self-describing. They are both dumb, barely more than syntax formats that you can build stuff on top of if you wish so, which then might be self-describing and extensible. With that said, there's EDN and fressian which solve the problems mentioned. In EDN you could encode an instruction like so for example `(replace :path "/foo" :value 1)` This reads like a function call because it is a representation of a function call. The semantics are already there. Even better you could use namespaced keywords and symbols where applicable and suddenly were in a world where we can convey context without nesting, out of bounds information/schema or funny string formats.
    - shadowgovt 4y ago
      Self-describing, not self-documenting. I'm claiming that `"path": "foo", "value": "bar"` is a bit easier to pick up and learn than `["add" "/path" "value"]`. This is probably a personal-preference thing; speaking from years of slinging both JSON and elisp, I have to go to the docs to remember the contents of a JSON object far less often than I do to remember the relevant positional arguments to a defun.
  - kazinator 4y ago
    Positional syntaxes are extensible: you can add new optional arguments at the tail end, such that when those are missing, the old behavior is provided. The JSON could use positional syntax, since JSON has [ ] arrays, and that would reduce its clutter. The S-exp could use keyword arguments; it would still be nicer. Note that if we do so, we still want the operation to be positionally determined; i.e. to be the first element. (patch (replace :path (baz) :value "boo") (add :path (hello bim) :value ("world")) (remove :path (foo))) JSON becomes even more verbose to achieve something like this ["op", {"kw1" : "arg", "kw2" : 3.1, ...}]
    - shadowgovt 4y ago
      > you can add new optional arguments at the tail end I never claimed they weren't extensible. What you're describing as a feature I'm declaring a bug. Named syntaxes self-describe in a way positional syntaxes don't. (... he says as his IDE helpfully kicks in to tell him what each of the twelve arguments to this auto-generated Java object constructor are in his source code... ;) ). > JSON becomes even more verbose to achieve something like this It doesn't because it has key-value pairs as a top-level construct via the object type. LISP represents those by creating positional local dependencies between positional arguments (which is a fine solution, but at that point they're equivalently verbose and if I go with the JSON approach I can take advantage of the JSON libraries already existing in the client and server of my web applications). In an alternate universe where JavaScript had been just LISP, your approach would be great, but that ship sailed decades ago.
      - kazinator 4y ago
        > I never claimed they weren't extensible Yes you did because you claimed that it was an advantage of the original. The only purpose of such a remark would be to point out a contrast: extensibility is lost in Y, so I'm pointing out that X has it. > Named syntaxes self-describe That's nice but it doesn't connect with the extensibility point. Named can make it easy to know which argument is serving which role, if you already understand the function and its arguments, where you would otherwise have to remember the argument positions: like which of two identically typed arguments is the destination of the data transfer, the other being source. > It doesn't because it has key-value pairs as a top-level construct via the object type. Yes, but this object has no order; there is no way to indicate the first element so you have to use a keyword to indicate the operator too. I believe I communicated this with the example.
- txru 4y ago
  Generally, any time you have a pairing of an "op" to a variadic list of arguments in a transfer format, you have an s-expression. This method, like many others, introduces a bunch of new characters: - "op", "path", "value" - quotes around paths - colons, commas - curly braces In exchange for parentheses. More generally though, we have an isomorphism. If transformation between the forms is trivial, then use what form is more comfortable for you, but I think being able to identify the 'op' -> 'var-args' pairing is a good thing to keep an eye on. It's macros' bread and butter.
  - bowsamic 4y ago
    - deleted 4y ago
      [deleted]
- zeven7 4y ago
  It's inferior because there's a bunch of useless clutter that gets in the way in the JSON patch version. For the same reason > If a person puts such a question to you as: ‘I have divided ten into two parts, and multiplying one of these by the other the result was twenty-one;’ then you know that one of the parts is thing and the other is ten minus thing. is inferior to > x(10-x)=21 The succinctness helps your brain focus on the important information so you don't get lost in the noise. If you find it hard to read at first, your brain can adapt to the patterns just fine.
  - bowsamic 4y ago
    Now try reading your second equation out loud
    - zeven7 4y ago
      And? > X times open parenthesis ten minus X close parenthesis equals twenty one I'm not sure if your point is supposed to be that it's easier to understand if read another way or something, but no matter what the symbol version is the easiest for your brain (which is very good at pattern recognition) to see and pick up on. Maybe I missed your point, so you'll have to be explicit. By the way, I didn't contrive the example. I googled "before math notation" and chose it from the second result[1]. I had seen similar examples of what math looked like before notation, so I looked for an example. [1] http://archive.boston.com/bostonglobe/ideas/brainiac/2014/06/before_symbols.html http://archive.boston.com/bostonglobe/ideas/brainiac/2014/06...
      - bowsamic 4y ago
        Have you ever heard of the expression "comparing apples and oranges"?
        zeven7 4y ago
        Yes, I have. I'd ask some clarification and respond to what I think your point is, but I see you're too clever to get to the point, so I'll move on.
samwillis 4y ago
But now you need an s-expression parser (ok so a very simple thing to do) and a json parser. I don't like JSON Patch but at least its dog-fooding its parser and not invented yet another text representation. Most of the time the patch documents are not being written by a human anyway.
- eadmund 4y ago
  > But now you need an s-expression parser (ok so a very simple thing to do) and a json parser. No, the original document should be S-expressions, too: ((baz . "qux") (foo . "bar")) Also, HTML should be S-expressions, CSS should be S-expressions and JavaScript should be Lisp. I have one hammer, and everything looks like a nail
  - samwillis 4y ago
    I will happily follow you, once you have achieved your goal of unifying all languages and markup in this enlightening new future. I look forward do being issued with a lisp machine.
    - shadowgovt 4y ago
      Given the number of security holes we ended up with in JavaScript and HTML, I think possibly a strong-ish case could even be made that reducing it all to LISP would have made the world objectively worse. "One hammer, and everything is a nail" sounds like a smorgasbord for malicious actors in a world where we know how often SQL injection and HTML injection proved to be common threat vectors (both being "trick the system into interpreting symbols that look the same in a different way" types of attacks). Imagine if all layers of the HTTP story had been the same language. Yikes.
vrfvr 4y ago
For me, the former is easier to understand.
Steltek 4y ago
The impedance mismatch is that JSON is a fantastic data structure format but a poor code language. Sexp's are a poor data structure format (briefly, lacking a dictionary format and mixing function invocation with lists) but a fantastic code language.
krinchan 4y ago
Honest question, why aren't s-expressions in their purest form more prevalent? This seems to happen constantly on HN: Post: "Behold, a data format!" Commenter: "This is just poorly implemented s-expressions!" I know some heavily idolized LISP person out there made the over-quoted statement that all languages end up implementing s-expressions badly. I did LISP in college. I had my moment of transcendence with it. So I get the fandom for it. But I don't get why people keep paraphrasing this one sentence over and over, yet absolutely no one uses s-expressions outside of LISP. The one person I know who uses LISP in the private sector (via Clojure which many people refuse to recognize as a LISP for some reason?) is being hired to do very academia type research and publish white papers about it. The rest of LISP users are quirky members of academia who complain endlessly about Python's prevalence. It just kinda seems like if LISP or s-expressions were truly that great, there would be more convergence around it for expressing data structures.
- patrickthebold 4y ago
  This isn't an answer to your question, but I really like this (somewhat old) clojurescript react wrapper: https://github.com/levand/todomvc/blob/gh-pages/architecture-examples/quiescent/src/todomvc_quiescent/render.cljs#L12-L25 https://github.com/levand/todomvc/blob/gh-pages/architecture... Notice there is no JSX to define react components, just s-expressions. (yes I know you can use React without JSX, but I think it's interesting that in a lisp there's not really much need to introduce something like JSX). Anyway I think it's a neat example on how applicable s-expression are.
- bogomipz 4y ago
  >"I know some heavily idolized LISP person out there made the over-quoted statement that all languages end up implementing s-expressions badly." Not being at all versed in the LISP world myself might you or someone else share where the original quote came from?

draegtun 4y ago

>> It's yet another poor re-implementation of S-expressions and Lisp. Or alternatively Rebol, which was one of the inspirations to JSON. With Rebol you could write these patches like this: patch [ replace /baz: "boo" add /hello: ["world"] remove /foo ] patch [ add /biscuits/1: [name: "Ginger Nut"] ]

bowsamic 4y ago

How is it clearly inferior? I prefer it to yours

shadowgovt 4y ago
Agreed. The patch key-value syntax is self-describing and extensible. The s-expression syntax's reliance on positional inputs is less self-describing and extension can only be done at the end of the s-expressions. And the s-expressions don't even solve the problem of terseness for wire-format reasons; protobufs beat them out in that category.
- dgb23 4y ago
  Neither sexpr nor JSON are self-describing. They are both dumb, barely more than syntax formats that you can build stuff on top of if you wish so, which then might be self-describing and extensible. With that said, there's EDN and fressian which solve the problems mentioned. In EDN you could encode an instruction like so for example `(replace :path "/foo" :value 1)` This reads like a function call because it is a representation of a function call. The semantics are already there. Even better you could use namespaced keywords and symbols where applicable and suddenly were in a world where we can convey context without nesting, out of bounds information/schema or funny string formats.
  - shadowgovt 4y ago
    Self-describing, not self-documenting. I'm claiming that `"path": "foo", "value": "bar"` is a bit easier to pick up and learn than `["add" "/path" "value"]`. This is probably a personal-preference thing; speaking from years of slinging both JSON and elisp, I have to go to the docs to remember the contents of a JSON object far less often than I do to remember the relevant positional arguments to a defun.
- kazinator 4y ago
  Positional syntaxes are extensible: you can add new optional arguments at the tail end, such that when those are missing, the old behavior is provided. The JSON could use positional syntax, since JSON has [ ] arrays, and that would reduce its clutter. The S-exp could use keyword arguments; it would still be nicer. Note that if we do so, we still want the operation to be positionally determined; i.e. to be the first element. (patch (replace :path (baz) :value "boo") (add :path (hello bim) :value ("world")) (remove :path (foo))) JSON becomes even more verbose to achieve something like this ["op", {"kw1" : "arg", "kw2" : 3.1, ...}]
  - shadowgovt 4y ago
    > you can add new optional arguments at the tail end I never claimed they weren't extensible. What you're describing as a feature I'm declaring a bug. Named syntaxes self-describe in a way positional syntaxes don't. (... he says as his IDE helpfully kicks in to tell him what each of the twelve arguments to this auto-generated Java object constructor are in his source code... ;) ). > JSON becomes even more verbose to achieve something like this It doesn't because it has key-value pairs as a top-level construct via the object type. LISP represents those by creating positional local dependencies between positional arguments (which is a fine solution, but at that point they're equivalently verbose and if I go with the JSON approach I can take advantage of the JSON libraries already existing in the client and server of my web applications). In an alternate universe where JavaScript had been just LISP, your approach would be great, but that ship sailed decades ago.
    - kazinator 4y ago
      > I never claimed they weren't extensible Yes you did because you claimed that it was an advantage of the original. The only purpose of such a remark would be to point out a contrast: extensibility is lost in Y, so I'm pointing out that X has it. > Named syntaxes self-describe That's nice but it doesn't connect with the extensibility point. Named can make it easy to know which argument is serving which role, if you already understand the function and its arguments, where you would otherwise have to remember the argument positions: like which of two identically typed arguments is the destination of the data transfer, the other being source. > It doesn't because it has key-value pairs as a top-level construct via the object type. Yes, but this object has no order; there is no way to indicate the first element so you have to use a keyword to indicate the operator too. I believe I communicated this with the example.
txru 4y ago
Generally, any time you have a pairing of an "op" to a variadic list of arguments in a transfer format, you have an s-expression. This method, like many others, introduces a bunch of new characters: - "op", "path", "value" - quotes around paths - colons, commas - curly braces In exchange for parentheses. More generally though, we have an isomorphism. If transformation between the forms is trivial, then use what form is more comfortable for you, but I think being able to identify the 'op' -> 'var-args' pairing is a good thing to keep an eye on. It's macros' bread and butter.
- bowsamic 4y ago
  - deleted 4y ago
    [deleted]
zeven7 4y ago
It's inferior because there's a bunch of useless clutter that gets in the way in the JSON patch version. For the same reason > If a person puts such a question to you as: ‘I have divided ten into two parts, and multiplying one of these by the other the result was twenty-one;’ then you know that one of the parts is thing and the other is ten minus thing. is inferior to > x(10-x)=21 The succinctness helps your brain focus on the important information so you don't get lost in the noise. If you find it hard to read at first, your brain can adapt to the patterns just fine.
- bowsamic 4y ago
  Now try reading your second equation out loud
  - zeven7 4y ago
    And? > X times open parenthesis ten minus X close parenthesis equals twenty one I'm not sure if your point is supposed to be that it's easier to understand if read another way or something, but no matter what the symbol version is the easiest for your brain (which is very good at pattern recognition) to see and pick up on. Maybe I missed your point, so you'll have to be explicit. By the way, I didn't contrive the example. I googled "before math notation" and chose it from the second result[1]. I had seen similar examples of what math looked like before notation, so I looked for an example. [1] http://archive.boston.com/bostonglobe/ideas/brainiac/2014/06/before_symbols.html http://archive.boston.com/bostonglobe/ideas/brainiac/2014/06...
    - bowsamic 4y ago
      Have you ever heard of the expression "comparing apples and oranges"?
      - zeven7 4y ago
        Yes, I have. I'd ask some clarification and respond to what I think your point is, but I see you're too clever to get to the point, so I'll move on.

samwillis 4y ago

But now you need an s-expression parser (ok so a very simple thing to do) and a json parser. I don't like JSON Patch but at least its dog-fooding its parser and not invented yet another text representation. Most of the time the patch documents are not being written by a human anyway.

eadmund 4y ago
> But now you need an s-expression parser (ok so a very simple thing to do) and a json parser. No, the original document should be S-expressions, too: ((baz . "qux") (foo . "bar")) Also, HTML should be S-expressions, CSS should be S-expressions and JavaScript should be Lisp. I have one hammer, and everything looks like a nail
- samwillis 4y ago
  I will happily follow you, once you have achieved your goal of unifying all languages and markup in this enlightening new future. I look forward do being issued with a lisp machine.
  - shadowgovt 4y ago
    Given the number of security holes we ended up with in JavaScript and HTML, I think possibly a strong-ish case could even be made that reducing it all to LISP would have made the world objectively worse. "One hammer, and everything is a nail" sounds like a smorgasbord for malicious actors in a world where we know how often SQL injection and HTML injection proved to be common threat vectors (both being "trick the system into interpreting symbols that look the same in a different way" types of attacks). Imagine if all layers of the HTTP story had been the same language. Yikes.

vrfvr 4y ago

For me, the former is easier to understand.

Steltek 4y ago

The impedance mismatch is that JSON is a fantastic data structure format but a poor code language. Sexp's are a poor data structure format (briefly, lacking a dictionary format and mixing function invocation with lists) but a fantastic code language.

krinchan 4y ago

Honest question, why aren't s-expressions in their purest form more prevalent? This seems to happen constantly on HN: Post: "Behold, a data format!" Commenter: "This is just poorly implemented s-expressions!" I know some heavily idolized LISP person out there made the over-quoted statement that all languages end up implementing s-expressions badly. I did LISP in college. I had my moment of transcendence with it. So I get the fandom for it. But I don't get why people keep paraphrasing this one sentence over and over, yet absolutely no one uses s-expressions outside of LISP. The one person I know who uses LISP in the private sector (via Clojure which many people refuse to recognize as a LISP for some reason?) is being hired to do very academia type research and publish white papers about it. The rest of LISP users are quirky members of academia who complain endlessly about Python's prevalence. It just kinda seems like if LISP or s-expressions were truly that great, there would be more convergence around it for expressing data structures.

patrickthebold 4y ago
This isn't an answer to your question, but I really like this (somewhat old) clojurescript react wrapper: https://github.com/levand/todomvc/blob/gh-pages/architecture-examples/quiescent/src/todomvc_quiescent/render.cljs#L12-L25 https://github.com/levand/todomvc/blob/gh-pages/architecture... Notice there is no JSX to define react components, just s-expressions. (yes I know you can use React without JSX, but I think it's interesting that in a lisp there's not really much need to introduce something like JSX). Anyway I think it's a neat example on how applicable s-expression are.
bogomipz 4y ago
>"I know some heavily idolized LISP person out there made the over-quoted statement that all languages end up implementing s-expressions badly." Not being at all versed in the LISP world myself might you or someone else share where the original quote came from?