3 ms·

The origins of lisp are that of a mathematical tool. Clojure is much closer to math with its referential transparency, immutable datatypes, deep proper object e

by j-pb 7y ago

The origins of lisp are that of a mathematical tool. Clojure is much closer to math with its referential transparency, immutable datatypes, deep proper object equality, and data first philosophy, than common lisp with its systems programming, lisp machine, need for speed approach.

travv0 7y ago
If we're talking origins of lisp, the original description of lisp[1] spends much of its time describing cons cells, something that clojure lacks completely. [1] http://www-formal.stanford.edu/jmc/recursive/node4.html http://www-formal.stanford.edu/jmc/recursive/node4.html
- j-pb 7y ago
  Yeah and the original cons cells had proper equality defined on them, which common lisp doesn't have. Also the original lisp wasn't a lisp-2. In clojure you can trivially use your own cons cells and get equality for free, in common lisp you can't build the proper mathematical properties without essentially reinventing clojure.
  - flavio81 7y ago
    >Yeah and the original cons cells had proper equality defined on them, which common lisp doesn't have. Substantiate your claims.
    - j-pb 7y ago
      Sure! Most things in common lisp don't work with 'equal', which "poisons" the well so to speak. For example hash tables. (defparameter my-hash (make-hash-table)) (defparameter thy-hash (make-hash-table)) (setf (gethash 'one-entry my-hash) "one") (setf (gethash 'one-entry thy-hash) "one") (print (equal my-hash thy-hash)) NIL while in clojure every immutable datastructure you encounter in the std-lib or syntax has proper equality. (= {'one-entry "one"} {'one-entry "one"}) true To which McCarty had to say: > I considered it important to make these expressions obey the usual mathematical laws allowing replacement of expressions by expressions giving the same value.
      - kazinator 7y ago
        Fixed in TXR Lisp: This is the TXR Lisp interactive listener of TXR 236. Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet. 1> (defparm my (hash)) my 2> (defparm thy (hash)) thy 3> (set [my 'one-entry] "one") "one" 4> (set [thy 'one-entry] "one") "one" 5> (equal my thy) t 6> (set [thy 'two-entry] "two") "two" 7> (equal my thy) nil Or, briefly: 7> (equal #H(() (a b)) #H(() (a b))) t 8> (equal #H(() (a b)) #H(() (a c))) nil Also this: [1]> (equal '(1 2) '(1 2)) T [2]> (equal '(1 2) '(1 2.0)) NIL [3]> (equal #(1 2) #(1 2)) ;; oops, WTF? NIL [4]> 1> (equal '(1 2) '(1 2)) t 2> (equal '(1 2) '(1 2.0)) nil 3> (equal #(1 2) #(1 2)) t 4> (equal #(1 2) #(1 2.0)) nil
        j-pb 7y ago
        Nice to hear, not CL tho ;P The (equal '(1 2) '(1 2.0)) is really a tricky one. Clojure also fails the (= 1 1.0) test. But I'm really not sure if that's a bad thing. I mean (= [1] #{1}) (an ordered vector and an unordered set) is also false, so it kinda makes sense to argue that distinct types are always distinct. However in clojure (= '(1) [1]) which I find a lot harder to defend It's caused by an automatic conversion to sequences which are then compared, and I think I might even add that one to the "warts" list.
        lispm 7y ago
        Compare that with the rules of equality of Clojure: https://clojure.org/guides/equality https://clojure.org/guides/equality
flavio81 7y ago
> Clojure is much closer to math I didn't know that having leaky abstractions on top of the horrible Java standard lib was "being closer to math"
- j-pb 7y ago
  Clojure has it's own std-lib. You can even share a significant part of your code between clojure and clojurescript.
lispm 7y ago
The origins of Lisp is 'list processing', hence the name, which is an abbreviation of 'List Processor'. John McCarthy et&al. designed & developed a programming system for list processing as a tool for symbolic AI programming. Earlier he experimented with list processing in Fortran, but wanted to have a whole new programming system.
- j-pb 7y ago
  Turns out we're both right. > Anyway, I decided to write a paper describing LISP both as a programming language and as a formalism for doing recursive function theory. > One mathematical consideration that influenced LISP was to express programs as applicative expressions built up from variables and constants using functions. I considered it important to make these expressions obey the usual mathematical laws allowing replacement of expressions by expressions giving the same value. The motive was to allow proofs of properties of programs using ordinary mathematical methods. This is only possible to the extent that side-effects can be avoided. Unfortunately, side-effects are often a great convenience when computational efficiency is important, and ``functions'' with side-effects are present in LISP. From http://www-formal.stanford.edu/jmc/history/lisp/node3.html#SECTION00030000000000000000 http://www-formal.stanford.edu/jmc/history/lisp/node3.html#S...
  - lispm 7y ago
    Functions with side-effects are common in LISP. That's why LISP functions are more like traditional procedures and less like mathematical functions. There was a mathematical 'theory' presented, but it differed from the actual programming language LISP (see the LISP 1 Programmer's Manual, 1960): https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Programmers_Manual.pdf https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Pr...
    - j-pb 7y ago
      Did you even read the piece by McCarty? He talks about how it was meant as an alternative to the computational models based on turing machines in addition to a symbolic computation tool for AI and therefore used side effects for convenience but also tried to keep mathematical properties, like referential transparency. Tbh it seems pointless discussing this with you because the idea of common lisp being the embodyment of the lisp philosophy seems to have become personal to you. Sorry my energy reservoirs are drained, I'm just gonna ignore your posts, and head back to work, there's a large CL codebase that needs to be rewritten to clojure and that's stressful enough.

by j-pb 7y ago

travv0 7y ago

If we're talking origins of lisp, the original description of lisp[1] spends much of its time describing cons cells, something that clojure lacks completely. [1] http://www-formal.stanford.edu/jmc/recursive/node4.html http://www-formal.stanford.edu/jmc/recursive/node4.html

j-pb 7y ago
Yeah and the original cons cells had proper equality defined on them, which common lisp doesn't have. Also the original lisp wasn't a lisp-2. In clojure you can trivially use your own cons cells and get equality for free, in common lisp you can't build the proper mathematical properties without essentially reinventing clojure.
- flavio81 7y ago
  >Yeah and the original cons cells had proper equality defined on them, which common lisp doesn't have. Substantiate your claims.
  - j-pb 7y ago
    Sure! Most things in common lisp don't work with 'equal', which "poisons" the well so to speak. For example hash tables. (defparameter my-hash (make-hash-table)) (defparameter thy-hash (make-hash-table)) (setf (gethash 'one-entry my-hash) "one") (setf (gethash 'one-entry thy-hash) "one") (print (equal my-hash thy-hash)) NIL while in clojure every immutable datastructure you encounter in the std-lib or syntax has proper equality. (= {'one-entry "one"} {'one-entry "one"}) true To which McCarty had to say: > I considered it important to make these expressions obey the usual mathematical laws allowing replacement of expressions by expressions giving the same value.
    - kazinator 7y ago
      Fixed in TXR Lisp: This is the TXR Lisp interactive listener of TXR 236. Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet. 1> (defparm my (hash)) my 2> (defparm thy (hash)) thy 3> (set [my 'one-entry] "one") "one" 4> (set [thy 'one-entry] "one") "one" 5> (equal my thy) t 6> (set [thy 'two-entry] "two") "two" 7> (equal my thy) nil Or, briefly: 7> (equal #H(() (a b)) #H(() (a b))) t 8> (equal #H(() (a b)) #H(() (a c))) nil Also this: [1]> (equal '(1 2) '(1 2)) T [2]> (equal '(1 2) '(1 2.0)) NIL [3]> (equal #(1 2) #(1 2)) ;; oops, WTF? NIL [4]> 1> (equal '(1 2) '(1 2)) t 2> (equal '(1 2) '(1 2.0)) nil 3> (equal #(1 2) #(1 2)) t 4> (equal #(1 2) #(1 2.0)) nil
      - j-pb 7y ago
        Nice to hear, not CL tho ;P The (equal '(1 2) '(1 2.0)) is really a tricky one. Clojure also fails the (= 1 1.0) test. But I'm really not sure if that's a bad thing. I mean (= [1] #{1}) (an ordered vector and an unordered set) is also false, so it kinda makes sense to argue that distinct types are always distinct. However in clojure (= '(1) [1]) which I find a lot harder to defend It's caused by an automatic conversion to sequences which are then compared, and I think I might even add that one to the "warts" list.
      - lispm 7y ago
        Compare that with the rules of equality of Clojure: https://clojure.org/guides/equality https://clojure.org/guides/equality

flavio81 7y ago

> Clojure is much closer to math I didn't know that having leaky abstractions on top of the horrible Java standard lib was "being closer to math"

j-pb 7y ago
Clojure has it's own std-lib. You can even share a significant part of your code between clojure and clojurescript.

lispm 7y ago

The origins of Lisp is 'list processing', hence the name, which is an abbreviation of 'List Processor'. John McCarthy et&al. designed & developed a programming system for list processing as a tool for symbolic AI programming. Earlier he experimented with list processing in Fortran, but wanted to have a whole new programming system.

j-pb 7y ago
Turns out we're both right. > Anyway, I decided to write a paper describing LISP both as a programming language and as a formalism for doing recursive function theory. > One mathematical consideration that influenced LISP was to express programs as applicative expressions built up from variables and constants using functions. I considered it important to make these expressions obey the usual mathematical laws allowing replacement of expressions by expressions giving the same value. The motive was to allow proofs of properties of programs using ordinary mathematical methods. This is only possible to the extent that side-effects can be avoided. Unfortunately, side-effects are often a great convenience when computational efficiency is important, and ``functions'' with side-effects are present in LISP. From http://www-formal.stanford.edu/jmc/history/lisp/node3.html#SECTION00030000000000000000 http://www-formal.stanford.edu/jmc/history/lisp/node3.html#S...
- lispm 7y ago
  Functions with side-effects are common in LISP. That's why LISP functions are more like traditional procedures and less like mathematical functions. There was a mathematical 'theory' presented, but it differed from the actual programming language LISP (see the LISP 1 Programmer's Manual, 1960): https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Programmers_Manual.pdf https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Pr...
  - j-pb 7y ago
    Did you even read the piece by McCarty? He talks about how it was meant as an alternative to the computational models based on turing machines in addition to a symbolic computation tool for AI and therefore used side effects for convenience but also tried to keep mathematical properties, like referential transparency. Tbh it seems pointless discussing this with you because the idea of common lisp being the embodyment of the lisp philosophy seems to have become personal to you. Sorry my energy reservoirs are drained, I'm just gonna ignore your posts, and head back to work, there's a large CL codebase that needs to be rewritten to clojure and that's stressful enough.