6 ms·
Why not go all the way and use a format capable of expressing code and data? I refer, of course, to S-expressions. They also have the benefit of properly handl
by eadmund 5y ago
Why not go all the way and use a format capable of expressing code and data? I refer, of course, to S-expressions.
They also have the benefit of properly handling numbers. Some might look at the absence of maps as a negative, but I think alists are preferable anyway due to their constant ordering.
- kbrazil 5y agoThat’s a good debate to have. I settled on JSON due to its readability and ubiquity in web APIs. It’s something people all the way down and up the stack are very familiar with these days.
- eadmund 5y agoTrue, folks are very familiar with JSON, but it does have problems, and the best time to pick the best solution is before one has to deprecate a lesser solution. Computing is built atop a pile of decisions which made sense at the time and cannot be changed now due to compatibility (spaces in Makefiles, anyone?): there is no time like the present to simply choose to do the most correct thing. 'But folks won't use it!' Well, they might not. But if one gives folks a choice between the capability they need using an unfamiliar technology and not having the capability at all, they will learn the unfamiliar tech.
- selfhoster11 5y agoI'd rather avoid mixing the two. Shell injection is already a danger.
- lfnoise 5y agoYes. I never understood why JSON over s-exprs. The absence of maps is not a negative. S-exprs can represent maps. There are no maps in JSON, really anyway. It is just text. How that data is represented in memory is the output of parsing. You could just as well parse (dict (a 1)(b 2)(c 3)) into a hash table if you wanted. You could also have sets (set 1 2 3) or whatever other data structure.
- pjmlp 5y agoFear of parentheses, basically.
- u801e 5y agoBut json already has quotes, commas, brackets and braces :-)
- pjmlp 5y agoYeah, apparently finding misplaced quotes, commas, brackets and braces is magically easier than misplaced parentheses. :)
- asoneth 5y agoYou jest, but I find it easier to visually parse code organized using parentheses, quotes, commas, and brackets compared to code organized using parentheses, parentheses, parentheses, and parentheses. The latter approach is simple and elegant but makes it hard for me to read someone else's code. I think the first reason is that the distinct characters provide a kind of visual checksum which makes me (slightly) more confident when initially matching a closing character to the correct starting character. The second reason is that each character has a conventional meaning which makes it possible to form an initial guess as to its purpose. Having said this, I freely admit this opinion may be colored by my only (paid) experience writing Lisp which was for a sprawling 20 year-old AI codebase mostly written by professors and graduate students who were often learning Lisp as they went.
- iainmerrick 5y agoYou could do any of those things, but you have to pick a convention and other people have to agree on it. JSON is nice in that it has just enough structure to do a good number of tasks in one obvious way. The biggest omission is probably some kind of time and/or date type (but ISO8601 in a string is the obvious solution there). It’s not a coincidence that JSON was reverse-engineered from a language with convenient literals for dictionaries and arrays, and most languages provide those two collection types because they cover most use cases, so JSON fits most languages fairly well. It’s just handy having both arrays and dictionaries available, rather than stretching one data structure to cover both, whatever Lua or Lisp might say.
- quasarj 5y agoMostly because S-expressions are terribly hard for humans to read... and everyone is already familiar with javascript syntax.
- geysersam 5y agoI feel that depends on the formatting. Non-pretty JSON isn't very readable either. ``` (dict :name apple :ip 192.168.1.1 :nested (dict :property value ) ) ``` Is almost JSON.
- johnlorentzson 5y agoS-expressions aren't inherently more difficult to read than JSON, it's just a matter of getting used to it.
- HKH2 5y agoChinese isn't more difficult to read than English; it's just a matter of getting used to it.
- cylinder714 5y agoRivest's proposal includes an "advanced transport" representation, a more human-readable version. Here's a sample: http://people.csail.mit.edu/rivest/sexp-sample-a http://people.csail.mit.edu/rivest/sexp-sample-a
- pjmlp 5y agoSpecially because it keeps being forgotten that Lisp Machines and Interlisp-D workstations shells were basically a graphical based REPL. To put it in 2021 terms, Jupiter Netbooks in 1980's instead of PDP-11 green phosphor terminals.
- johnlorentzson 5y agoEven the best Unix shells are a mere toys in comparison to what Lisp machines were doing in the 80s. I don't wanna say that using a Lisp machine was "life changing" or anything but let's just say I don't like Linux anymore.
- pjmlp 5y agoI may look like very anti-UNIX, ironically I was big into UNIX, my first experience was with Xenix. However my university library had a very good section on all kinds of OSes and programming languages since the dawn of computing, thus I could see how the future might have been and there was definitely a much better path, specially when coupled with my own experience across Amiga, Windows and Mac OS. It is like the bulb paradox, just applied to OSes.
- cylinder714 5y agoObligatory links: Rivest's proposal, with source code: http://people.csail.mit.edu/rivest/sexp.html http://people.csail.mit.edu/rivest/sexp.html McCarthy's Common Business Communication Language: http://jmc.stanford.edu/articles/cbcl.html http://jmc.stanford.edu/articles/cbcl.html