5 ms·

I wish Symbolics had a better run. The Windows registry/powershell approach has the niceness of passing pieces of data instead of one big blob of text that has

I wish Symbolics had a better run. The Windows registry/powershell approach has the niceness of passing pieces of data instead of one big blob of text that has to be re-parsed at every step, but with the drawback of verbosity and fussy static typing. Being able to directly pass s-expressions between between programs without the format/parse/typing hokey-pokey of Unix and Windows would be nice.

teddyh 10y ago
S-expressions are very nice, and have the unequalled property of being simple enough to serve as a syntax for an entire programming language, but as a data type it is at best on the level of JSON. If one were to design a new data format for pipes, I would hope one would aim a little higher than that. Going from plain text lines to JSON or sexps would simply not be worth the infrastructure retooling.
- rocqua 10y ago
  What lies above JSON or S-expressions, XML? Or some binary format? If I had to guess, I'd say the issue with JSON and the like is how to deduce types (and the limited types available) combined with the issue of special characters in names and strings. XML goes a long way towards fixing that, but at the cost of a lot of extra bloat. A binary format with a nicely defined header might work, but those formats tend to not be so good about inserting stuff. There is something to be said in favor of plain text. If all solutions suck, go for the simplest and most flexible solution.
  - teddyh 10y ago
    The ability to pass whole objects (which would have to be serializable) would certainly qualify as being "above" JSON and sexps, but I’m not convinced objects would be a good idea to use in this way, which is why I didn’t specifically suggest them as an alternative.
- jstewartmobile 10y ago
  Being able to use the same syntax for code and data is no small thing. This aspect alone puts it above JSON. That, and for most LISPS, S-expressions have a broader vocabulary than JSON (symbols, complex numbers, etc.).
  - teddyh 10y ago
    JSON also has hash tables (which they confusingly call “objects”), which sexps do not. One may argue that one is or isn’t slightly better than the other, but the point was that they are very close.
    - jstewartmobile 10y ago
      S-expressions can express whatever the LISP can express (like Clojure's built-in hash table syntax), or the s-exp could just pass a lambda to generate the data on-the-fly at the next step, and since the lambda itself is a list, the receiver has an easy built-in facility for inspecting/altering/extending passed-in code. JSON is just arrays, objects, bools, numbers, strings, and null. How are they "close"?
      - teddyh 10y ago
        If you have to run “eval” on it, it’s not an s-expression. If the “eval” is implied, what you are describing is serialization of data, not actual data. You could do what you describe with JSON too – it’s just encoding and decoding. Would you therefore be able to claim that JSON is capable of transmitting, say, tabular data? Of course not.
nunez 10y ago
and latency if you're trying to do anything with PS objects over a slow link. (try doing a 'get-childobject' on a SMB share or loading the registry on a host behind a slow connection; i'll wait)
tinus_hn 10y ago
The main advantage is of course that the system provides apis for using the registry and all programs use them. But another is that the format does not provide for comments. This means that it is easy to automatically manipulate unlike the unix text files.
eschaton 10y ago
Symbolics Genera doesn't pass S-expressions (i.e. text) between processes, it passed objects. Everything runs in a single address space so this is cheap and accurate. Also, ZetaLisp and Common Lisp have way more types than those supported by S-expressions. For example, they have real vectors/arrays, structures, and full objects. Don't assume all of the Lisp world uses just the subset of Scheme used in the first couple chapters of SICP.
- jstewartmobile 10y ago
  Only knowing Genera from a user perspective, I just assumed that process-to-process communication gives preference to the internal representation when it is available.
- gkya 10y ago
  Well if at the end in your programmes you got to manipulate structured data (represented by sexps which whatever extensions), then the guts are irrelevant.
sedachv 10y ago
> Being able to directly pass s-expressions between between programs without the format/parse/typing hokey-pokey of Unix and Windows would be nice. Genera did not have programs, it is all just function calls. There was a multi-user LMI Lisp machine that ran Unix concurrently, that used streams to communicate between the two Lisp and one Unix processors: http://www.1000bit.it/ad/bro/lmi/LISP-MachinePR_Photo.pdf http://www.1000bit.it/ad/bro/lmi/LISP-MachinePR_Photo.pdf Formats for inter-process communication are hard and far from a solved problem. Just look at what has come out in the past 10 years: Thrift, Protocol Buffers, Cap'n Proto, FlatBuffers, SBE, probably twice as many others I haven't heard of.
- jstewartmobile 10y ago
  How about: Being able to directly pass s-expressions ... would be nicer than putting an alphabet soup of parameters on one program to have it output text in just the right way for the next program to re-parse it with another alphabet soup of parameters. I'm not saying that this is the one true way. I'm just agreeing with the article that there is a lot of room for improvement in how things get piped and config-ed in *nix.

teddyh 10y ago

S-expressions are very nice, and have the unequalled property of being simple enough to serve as a syntax for an entire programming language, but as a data type it is at best on the level of JSON. If one were to design a new data format for pipes, I would hope one would aim a little higher than that. Going from plain text lines to JSON or sexps would simply not be worth the infrastructure retooling.

rocqua 10y ago
What lies above JSON or S-expressions, XML? Or some binary format? If I had to guess, I'd say the issue with JSON and the like is how to deduce types (and the limited types available) combined with the issue of special characters in names and strings. XML goes a long way towards fixing that, but at the cost of a lot of extra bloat. A binary format with a nicely defined header might work, but those formats tend to not be so good about inserting stuff. There is something to be said in favor of plain text. If all solutions suck, go for the simplest and most flexible solution.
- teddyh 10y ago
  The ability to pass whole objects (which would have to be serializable) would certainly qualify as being "above" JSON and sexps, but I’m not convinced objects would be a good idea to use in this way, which is why I didn’t specifically suggest them as an alternative.
jstewartmobile 10y ago
Being able to use the same syntax for code and data is no small thing. This aspect alone puts it above JSON. That, and for most LISPS, S-expressions have a broader vocabulary than JSON (symbols, complex numbers, etc.).
- teddyh 10y ago
  JSON also has hash tables (which they confusingly call “objects”), which sexps do not. One may argue that one is or isn’t slightly better than the other, but the point was that they are very close.
  - jstewartmobile 10y ago
    S-expressions can express whatever the LISP can express (like Clojure's built-in hash table syntax), or the s-exp could just pass a lambda to generate the data on-the-fly at the next step, and since the lambda itself is a list, the receiver has an easy built-in facility for inspecting/altering/extending passed-in code. JSON is just arrays, objects, bools, numbers, strings, and null. How are they "close"?
    - teddyh 10y ago
      If you have to run “eval” on it, it’s not an s-expression. If the “eval” is implied, what you are describing is serialization of data, not actual data. You could do what you describe with JSON too – it’s just encoding and decoding. Would you therefore be able to claim that JSON is capable of transmitting, say, tabular data? Of course not.

nunez 10y ago

and latency if you're trying to do anything with PS objects over a slow link. (try doing a 'get-childobject' on a SMB share or loading the registry on a host behind a slow connection; i'll wait)

tinus_hn 10y ago

The main advantage is of course that the system provides apis for using the registry and all programs use them. But another is that the format does not provide for comments. This means that it is easy to automatically manipulate unlike the unix text files.

eschaton 10y ago

Symbolics Genera doesn't pass S-expressions (i.e. text) between processes, it passed objects. Everything runs in a single address space so this is cheap and accurate. Also, ZetaLisp and Common Lisp have way more types than those supported by S-expressions. For example, they have real vectors/arrays, structures, and full objects. Don't assume all of the Lisp world uses just the subset of Scheme used in the first couple chapters of SICP.

jstewartmobile 10y ago
Only knowing Genera from a user perspective, I just assumed that process-to-process communication gives preference to the internal representation when it is available.
gkya 10y ago
Well if at the end in your programmes you got to manipulate structured data (represented by sexps which whatever extensions), then the guts are irrelevant.

sedachv 10y ago

> Being able to directly pass s-expressions between between programs without the format/parse/typing hokey-pokey of Unix and Windows would be nice. Genera did not have programs, it is all just function calls. There was a multi-user LMI Lisp machine that ran Unix concurrently, that used streams to communicate between the two Lisp and one Unix processors: http://www.1000bit.it/ad/bro/lmi/LISP-MachinePR_Photo.pdf http://www.1000bit.it/ad/bro/lmi/LISP-MachinePR_Photo.pdf Formats for inter-process communication are hard and far from a solved problem. Just look at what has come out in the past 10 years: Thrift, Protocol Buffers, Cap'n Proto, FlatBuffers, SBE, probably twice as many others I haven't heard of.

jstewartmobile 10y ago
How about: Being able to directly pass s-expressions ... would be nicer than putting an alphabet soup of parameters on one program to have it output text in just the right way for the next program to re-parse it with another alphabet soup of parameters. I'm not saying that this is the one true way. I'm just agreeing with the article that there is a lot of room for improvement in how things get piped and config-ed in *nix.