5 ms·

If LISP had a widely-accepted standard, non-turing-complete subset to represent the equivalent persisted data structures JSON does, it would still be less reada

If LISP had a widely-accepted standard, non-turing-complete subset to represent the equivalent persisted data structures JSON does, it would still be less readable than JSON. There are reasons JSON is the lingua franca of modern API interaction and LISP is not.

Spivak 10y ago
Whatever example I give you're just going to complain that it's not widely accepted because it's not JSON/YAML/XML. Since just about every scripting language uses similar syntax to JSON there's an argument to be made that familiarity is the most important characteristic. However, that doesn't mean that LISP is unfit for the job from a technical perspective. If we're going to start evaluating JSON as code then there's a strong argument to be made that a LISP is better suited since that's one of its core principles and is already well developed. '( (first-name john) (last-name smith) (age 23) (parents jane jim) ) { "first name": "john", "last name": "smith", "age": 23, "parents": ["jim", "jane"] }
- falcolas 10y ago
  Might change that a bit to more accurately represent the same type of objects described in your JSON. '( (first-name "john") (last-name "smith") (age 23) (parents ("jane" "jim")) ) Of course, for a pure set of such simply formatted data (hashes, lists, strings, numbers), you could use almost any data serialization format. S-Exs don't really offer anything special here that can't also be done in XML, MessagePack, SQL, protobuff, bencode, thrift, or any of a dozen other serialization formats. Then again, JSON doesn't really bring much special to the table in this case either (other than having an encoder built into most Javascript intrepreters).
  - mypalmike 10y ago
    How do I know that ("jane" "jim") is a list (like ["jane", "jim"] in JSON) rather than an associative array (like {"jane": "jim"} in JSON)? S-exs can represent the difference certainly, but not in a way that is as clearly readable by humans. The difference between lists and associative arrays is quite unambiguous and readable in JSON. This helps make the language editable by non-expert users, which is a critical benefit.
    - db48x 10y ago
      In general if you're making an alist in Lisp then you're going to use keys for which comparisons are cheap; you would use atoms instead of strings as the keys: '((name "Jane") ...) instead of '(("name" "Jane") ...). Strings must be compared byte-by-byte, atoms are interned and compared by pointer identity. In fact, in some Lisps (such as Common Lisp) you would probably use a special type of atom called a keyword. Keywords are just atoms with a colon at the front to indicate that they belong to the special KEYWORD package; code in two different packages can then compare them without any namespacing fuss. It would look like '((:name "Jane") ...). Lisp just takes the logic out of the syntax and puts it into the semantics of the language.
      - lispm 10y ago
        What you call 'atom' is actually called 'symbol' in Lisp. Keywords are in Common Lisp a subset of symbols, those who are in the package 'KEYWORD'. Keywords also have themselves as value. Thus keywords evaluate to themselves. 'atom' means something else: 'not cons'. Anything that is not a cons cell (the two-pointer building block of linked lists) is an atom: numbers, characters, strings, symbols, arrays, ... Thus a string is an atom, too. CL-USER 1 > (typep "foobar" 'atom) T CL-USER 2 > (typep 4 'atom) T CL-USER 3 > (typep 'foobar 'atom) T CL-USER 4 > (typep '(foo . bar) 'atom) NIL True though, symbols (not atoms) are often used as keys for key/value data structures like assoc lists, property lists, hash tables, CLOS instances and others. Common Lisp also allows symbols to have arbitrary names. It uses | and \ as escape characters in symbols. CL-USER 11 > '((person |Marvin Minsky|) (|KNOWN FOR| |Artificial Intelligence Research|) (lab |MIT AI Lab|)) ((PERSON |Marvin Minsky|) (KNOWN\ FOR |Artificial Intelligence Research|) (LAB |MIT AI Lab|)) CL-USER 12 > (setf mm *) ((PERSON |Marvin Minsky|) (KNOWN\ FOR |Artificial Intelligence Research|) (LAB |MIT AI Lab|)) CL-USER 13 > (assoc '|KNOWN FOR| mm) (KNOWN\ FOR |Artificial Intelligence Research|) Symbols are by default interned in a special data structure and are looked up at read-time. Thus they are compared by pointer identity. In Common Lisp this data structure is called a package and there can be more than one package.
        10y ago
- junke 10y ago
  Just a remainder: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-.... Don't rely on first and last names. Also, the age keeps changing, store a date (unless the age is what the user inputs, and is later converted to a date). (#1=(person ...) #2=(person ...) (person :names ("John Smith") :date-of-birth @1993-10-04T05:03:00.000000+01:00 :parents (#1# #2#)))

Spivak 10y ago

Whatever example I give you're just going to complain that it's not widely accepted because it's not JSON/YAML/XML. Since just about every scripting language uses similar syntax to JSON there's an argument to be made that familiarity is the most important characteristic. However, that doesn't mean that LISP is unfit for the job from a technical perspective. If we're going to start evaluating JSON as code then there's a strong argument to be made that a LISP is better suited since that's one of its core principles and is already well developed. '( (first-name john) (last-name smith) (age 23) (parents jane jim) ) { "first name": "john", "last name": "smith", "age": 23, "parents": ["jim", "jane"] }

falcolas 10y ago
Might change that a bit to more accurately represent the same type of objects described in your JSON. '( (first-name "john") (last-name "smith") (age 23) (parents ("jane" "jim")) ) Of course, for a pure set of such simply formatted data (hashes, lists, strings, numbers), you could use almost any data serialization format. S-Exs don't really offer anything special here that can't also be done in XML, MessagePack, SQL, protobuff, bencode, thrift, or any of a dozen other serialization formats. Then again, JSON doesn't really bring much special to the table in this case either (other than having an encoder built into most Javascript intrepreters).
- mypalmike 10y ago
  How do I know that ("jane" "jim") is a list (like ["jane", "jim"] in JSON) rather than an associative array (like {"jane": "jim"} in JSON)? S-exs can represent the difference certainly, but not in a way that is as clearly readable by humans. The difference between lists and associative arrays is quite unambiguous and readable in JSON. This helps make the language editable by non-expert users, which is a critical benefit.
  - db48x 10y ago
    In general if you're making an alist in Lisp then you're going to use keys for which comparisons are cheap; you would use atoms instead of strings as the keys: '((name "Jane") ...) instead of '(("name" "Jane") ...). Strings must be compared byte-by-byte, atoms are interned and compared by pointer identity. In fact, in some Lisps (such as Common Lisp) you would probably use a special type of atom called a keyword. Keywords are just atoms with a colon at the front to indicate that they belong to the special KEYWORD package; code in two different packages can then compare them without any namespacing fuss. It would look like '((:name "Jane") ...). Lisp just takes the logic out of the syntax and puts it into the semantics of the language.
    - lispm 10y ago
      What you call 'atom' is actually called 'symbol' in Lisp. Keywords are in Common Lisp a subset of symbols, those who are in the package 'KEYWORD'. Keywords also have themselves as value. Thus keywords evaluate to themselves. 'atom' means something else: 'not cons'. Anything that is not a cons cell (the two-pointer building block of linked lists) is an atom: numbers, characters, strings, symbols, arrays, ... Thus a string is an atom, too. CL-USER 1 > (typep "foobar" 'atom) T CL-USER 2 > (typep 4 'atom) T CL-USER 3 > (typep 'foobar 'atom) T CL-USER 4 > (typep '(foo . bar) 'atom) NIL True though, symbols (not atoms) are often used as keys for key/value data structures like assoc lists, property lists, hash tables, CLOS instances and others. Common Lisp also allows symbols to have arbitrary names. It uses | and \ as escape characters in symbols. CL-USER 11 > '((person |Marvin Minsky|) (|KNOWN FOR| |Artificial Intelligence Research|) (lab |MIT AI Lab|)) ((PERSON |Marvin Minsky|) (KNOWN\ FOR |Artificial Intelligence Research|) (LAB |MIT AI Lab|)) CL-USER 12 > (setf mm *) ((PERSON |Marvin Minsky|) (KNOWN\ FOR |Artificial Intelligence Research|) (LAB |MIT AI Lab|)) CL-USER 13 > (assoc '|KNOWN FOR| mm) (KNOWN\ FOR |Artificial Intelligence Research|) Symbols are by default interned in a special data structure and are looked up at read-time. Thus they are compared by pointer identity. In Common Lisp this data structure is called a package and there can be more than one package.
      - 10y ago
junke 10y ago
Just a remainder: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-.... Don't rely on first and last names. Also, the age keeps changing, store a date (unless the age is what the user inputs, and is later converted to a date). (#1=(person ...) #2=(person ...) (person :names ("John Smith") :date-of-birth @1993-10-04T05:03:00.000000+01:00 :parents (#1# #2#)))