5 ms·

Funny to see this article—I was interning at a company that used S-expressions instead of JSON internally right around the time this post was written. (Seeing i

Funny to see this article—I was interning at a company that used S-expressions instead of JSON internally right around the time this post was written. (Seeing it for the first time now though.) All I can say is that in practice, s-expressions worked way better than JSON. Easy to read as a human, more flexible than JSON, reasonable syntax for working with alternatives (ie variants or sum types) and, of course, comments. Here's one thing that stood out to me in particular: you could encode formatted text in a way that was pretty easy to read even without formatting: (Here is a sentence with (i some words) (b emphasized) in (i (b different)) ways.) I forget if this was exactly the syntax they supported, but it was something like that. You could do something similar with JSON, but it would be way more verbose and harder to parse visually. Another massive advantage: structural editing in Emacs with Paredit is incredible. Once you get the hang of it, it's way faster and less prone to typos than "normal" text editing. If I ever start my own company, I'd definitely be tempted to standardize on S-expressions as our human-readable format for serialization and config data.

ktpsns 6y ago
Great comment! Can you share some information about the toolchain used around S-expressions this way? Did you really write literals in that way without quoting, etc.? I like S-expressions (data and/or code in S-expressions) a lot and would like to use it more.
- wglb 6y ago
  While this is not a full answer, here is some relevant info: https://sabracrolleton.github.io/json-review https://sabracrolleton.github.io/json-review. Incidentally for the grandparent's comment about formatting, I would use something slightly different: (Here is a sentence with (:i some words) (:b emphasized) in (:i (:b different)) ways.) This is similar to what is used for some of the html-to-S-expression conversions.
- tikhonj 6y ago
  They open sourced some of their core tools for it ([1], [2]) along with some documentation and examples. Since it was designed as a data format (comparable to JSON) rather than a programming-language syntax, there's a lot less need for quoting. [1]: https://github.com/janestreet/universe/tree/master/sexp https://github.com/janestreet/universe/tree/master/sexp [2]: https://github.com/janestreet/universe/tree/master/sexplib https://github.com/janestreet/universe/tree/master/sexplib
ardy42 6y ago
> Here's one thing that stood out to me in particular: you could encode formatted text in a way that was pretty easy to read even without formatting: > (Here is a sentence with (i some words) (b emphasized) in (i (b different)) ways.) That's feels a little like XML, just without attributes and untyped end-tags. I've never really understood the hate for XML and the preference for stuff like JSON. I'm a little biased towards XML because my company uses it heavily and I got very familiar with it early in my career, but it seems to make good trade offs for most use-cases where you'd want to use structured text.
- fao_ 6y ago
  > That's feels a little like XML, just without attributes Attributes: (p :class 'center' (div ...)) > and untyped end-tags. The end tags are implied by the start tag. Why do you need an end tag? It's just another way to mess up. The following situation is not possible using S-Expressions: ... <Start> <Center>500</Center> <Left>10</Left> ... </End>
  - ardy42 6y ago
    > The end tags are implied by the start tag. Why do you need an end tag? It's just another way to mess up. It helps with legibility and error-checking of hand-authored documents (at least in documents with varied tags). It doesn't look like fun to figure out where to insert something in a pages-long document with sections that like like ))))))))))))). It's not another way to mess up, it's another way to make sure you wrote what you meant.
    - wglb 6y ago
      This is a fallacy rooted in SGML. With a proper editor, finding where to insert or delete new stuff.
      - em-bee 6y ago
        ... is easy.
lowiqengineer 6y ago
> Funny to see this article—I was interning at a company that used S-expressions instead of JSON internally right around the time this post was written. (Seeing it for the first time now though.) Weirdly long-winded way of saying you worked at Jane Street.

ktpsns 6y ago

Great comment! Can you share some information about the toolchain used around S-expressions this way? Did you really write literals in that way without quoting, etc.? I like S-expressions (data and/or code in S-expressions) a lot and would like to use it more.

wglb 6y ago
While this is not a full answer, here is some relevant info: https://sabracrolleton.github.io/json-review https://sabracrolleton.github.io/json-review. Incidentally for the grandparent's comment about formatting, I would use something slightly different: (Here is a sentence with (:i some words) (:b emphasized) in (:i (:b different)) ways.) This is similar to what is used for some of the html-to-S-expression conversions.
tikhonj 6y ago
They open sourced some of their core tools for it ([1], [2]) along with some documentation and examples. Since it was designed as a data format (comparable to JSON) rather than a programming-language syntax, there's a lot less need for quoting. [1]: https://github.com/janestreet/universe/tree/master/sexp https://github.com/janestreet/universe/tree/master/sexp [2]: https://github.com/janestreet/universe/tree/master/sexplib https://github.com/janestreet/universe/tree/master/sexplib

ardy42 6y ago

> Here's one thing that stood out to me in particular: you could encode formatted text in a way that was pretty easy to read even without formatting: > (Here is a sentence with (i some words) (b emphasized) in (i (b different)) ways.) That's feels a little like XML, just without attributes and untyped end-tags. I've never really understood the hate for XML and the preference for stuff like JSON. I'm a little biased towards XML because my company uses it heavily and I got very familiar with it early in my career, but it seems to make good trade offs for most use-cases where you'd want to use structured text.

fao_ 6y ago
> That's feels a little like XML, just without attributes Attributes: (p :class 'center' (div ...)) > and untyped end-tags. The end tags are implied by the start tag. Why do you need an end tag? It's just another way to mess up. The following situation is not possible using S-Expressions: ... <Start> <Center>500</Center> <Left>10</Left> ... </End>
- ardy42 6y ago
  > The end tags are implied by the start tag. Why do you need an end tag? It's just another way to mess up. It helps with legibility and error-checking of hand-authored documents (at least in documents with varied tags). It doesn't look like fun to figure out where to insert something in a pages-long document with sections that like like ))))))))))))). It's not another way to mess up, it's another way to make sure you wrote what you meant.
  - wglb 6y ago
    This is a fallacy rooted in SGML. With a proper editor, finding where to insert or delete new stuff.
    - em-bee 6y ago
      ... is easy.

lowiqengineer 6y ago

> Funny to see this article—I was interning at a company that used S-expressions instead of JSON internally right around the time this post was written. (Seeing it for the first time now though.) Weirdly long-winded way of saying you worked at Jane Street.