7 ms·

Go with clojure, it's by far the most mind altering Lisp because of it's extremely nice immutable datatypes. Common lisp by comparison, feels arcane, outdated

by j-pb 7y ago

Go with clojure, it's by far the most mind altering Lisp because of it's extremely nice immutable datatypes. Common lisp by comparison, feels arcane, outdated and non lispy. You have to learn non composable macro syntaxes, and it's often way too low level and concerned about memory and imperative code and OOP. Scheme is nice in terms of self contained purity, but then again not as nice to use and not as mind altering as clojure. Clojure is basically a lisp build around immutable datastructures, common lisp is a lisp build around metaprogramming, and scheme is a lisp build around lambdas.

dunefox 7y ago
> Common Lisp feels non lispy Man, now I've heard everything.
- 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.
  - 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.
- jhbadger 7y ago
  Only because Common Lisp has been around so long that people have forgotten what Lisp was like before it. Old school Lisp hackers like Rodney Brooks were not fond of the dialect, which they felt was bloated (see Brooks and Gabriel, "A Critique of Common Lisp", 1984).
  - lispm 7y ago
    Do you know the rest of the story, too? Brooks/Gabriel developed an implementation for stock hardware (typically Unix systems with RISC CPUs: SUN SPARC, IBM POWER, MIPS, PA-RISC) which largely debunked their own earlier critique: Lucid Common Lisp. See this paper: Design of An Optimizing, Dynamically Retargetable Compiler for Common Lisp, Rodney A. Brooks (Massachusetts Institute of Technology Lucid, Inc.), David B. Posner, James L. McDonald, Jon L. White Eric Benson, Richard P. Gabriel (Lucid, Inc.), 1986 http://rpgpoet.com/Files/cp.pdf http://rpgpoet.com/Files/cp.pdf They even founded a company (Lucid, Inc., 1984), which sold this Lisp very successful for several years. Many companies used it during that time for deployment of Lisp applications. Richard P Gabriel even co-developed the Common Lisp Object System standard and published the spec in 1988: http://rpgpoet.com/Files/concepts.pdf http://rpgpoet.com/Files/concepts.pdf and http://rpgpoet.com/Files/Functions.pdf http://rpgpoet.com/Files/Functions.pdf Rodney Brooks also developed a specialized tiny variant of Common Lisp called L, which he then used in many research and commercial robots. 1995 https://www.researchgate.net/publication/2949173_L_--_A_Common_Lisp_for_Embedded_Systems https://www.researchgate.net/publication/2949173_L_--_A_Comm...
    - jhbadger 7y ago
      I'm not sure Lucid was a great example of Common Lisp success because they eventually converted to being a C++ IDE supplier (albeit one based on Emacs, so still Lisp-related but not CL). I hadn't heard of L, but that seems in line with Brooks' earlier criticism that the language was too big.
      - lispm 7y ago
        > because they eventually converted to being a C++ IDE supplier They followed the market. The Common Lisp product was great. > but that seems in line with Brooks' earlier criticism that the language was too big Lucid CL implemented all of Common Lisp and more. L is a Lisp for embedded systems. It's a subset of Common Lisp - nothing unusual.
pjmlp 7y ago
And me thinking that Clojure had OOP and imperative programming forms as well.
- j-pb 7y ago
  Yeah but it's neither encouraged nor fundamental. Whereas most common lisp code heavily emphasized loops and methods in an impure way. CL is a systems programming language, while clojure always feels like a tool for tought, in the APL sense.
  - pjmlp 7y ago
    With that line of thought, C++ is a safe systems programming language. The features are there and everyone is free to use them, and I am yet to see a Clojure linter against using those features. In fact, Clojure cannot interop with its host platforms without doing any kind of OOP.
    - j-pb 7y ago
      You'd be surprised how well a common philosophy in the community keeps everything nice and tidy. If you look at old clojure libraries like Incanter which were still heavily influenced by CL they're nothing like recently developed ones. The preferred way of doing things is like this: Data > Functions > Interop > Macros. Clojure discourages mutability and side effects. CL embraces them, it doesn't even have immutable datatypes, let alone sane deep equality. I don't see how C++ is relevant since even Rust has unsafe.
      - pjmlp 7y ago
        It is relevant, because the unsafe features are still there, regardless how many use them, language culture and what not. Likewise Clojure contains the main features of CLOS and makes use of them to interop with JavaScript, Java and C#, regardless how many in the community make use of it. A language is made by the language specification and its standard library, not by whatever the community feels as trendy. Present us a full compliant Clojure implementation minus CLOS, and lets see how far it goes.
flavio81 7y ago
>Common lisp by comparison, feels arcane, outdated and non lispy. Only if your knowledge of Common Lisp is at the level of "armchair specialist".
- j-pb 7y ago
  Said the "armchair clojure specialist" ;)

by j-pb 7y ago

dunefox 7y ago

> Common Lisp feels non lispy Man, now I've heard everything.

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.
- 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.
jhbadger 7y ago
Only because Common Lisp has been around so long that people have forgotten what Lisp was like before it. Old school Lisp hackers like Rodney Brooks were not fond of the dialect, which they felt was bloated (see Brooks and Gabriel, "A Critique of Common Lisp", 1984).
- lispm 7y ago
  Do you know the rest of the story, too? Brooks/Gabriel developed an implementation for stock hardware (typically Unix systems with RISC CPUs: SUN SPARC, IBM POWER, MIPS, PA-RISC) which largely debunked their own earlier critique: Lucid Common Lisp. See this paper: Design of An Optimizing, Dynamically Retargetable Compiler for Common Lisp, Rodney A. Brooks (Massachusetts Institute of Technology Lucid, Inc.), David B. Posner, James L. McDonald, Jon L. White Eric Benson, Richard P. Gabriel (Lucid, Inc.), 1986 http://rpgpoet.com/Files/cp.pdf http://rpgpoet.com/Files/cp.pdf They even founded a company (Lucid, Inc., 1984), which sold this Lisp very successful for several years. Many companies used it during that time for deployment of Lisp applications. Richard P Gabriel even co-developed the Common Lisp Object System standard and published the spec in 1988: http://rpgpoet.com/Files/concepts.pdf http://rpgpoet.com/Files/concepts.pdf and http://rpgpoet.com/Files/Functions.pdf http://rpgpoet.com/Files/Functions.pdf Rodney Brooks also developed a specialized tiny variant of Common Lisp called L, which he then used in many research and commercial robots. 1995 https://www.researchgate.net/publication/2949173_L_--_A_Common_Lisp_for_Embedded_Systems https://www.researchgate.net/publication/2949173_L_--_A_Comm...
  - jhbadger 7y ago
    I'm not sure Lucid was a great example of Common Lisp success because they eventually converted to being a C++ IDE supplier (albeit one based on Emacs, so still Lisp-related but not CL). I hadn't heard of L, but that seems in line with Brooks' earlier criticism that the language was too big.
    - lispm 7y ago
      > because they eventually converted to being a C++ IDE supplier They followed the market. The Common Lisp product was great. > but that seems in line with Brooks' earlier criticism that the language was too big Lucid CL implemented all of Common Lisp and more. L is a Lisp for embedded systems. It's a subset of Common Lisp - nothing unusual.

pjmlp 7y ago

And me thinking that Clojure had OOP and imperative programming forms as well.

j-pb 7y ago
Yeah but it's neither encouraged nor fundamental. Whereas most common lisp code heavily emphasized loops and methods in an impure way. CL is a systems programming language, while clojure always feels like a tool for tought, in the APL sense.
- pjmlp 7y ago
  With that line of thought, C++ is a safe systems programming language. The features are there and everyone is free to use them, and I am yet to see a Clojure linter against using those features. In fact, Clojure cannot interop with its host platforms without doing any kind of OOP.
  - j-pb 7y ago
    You'd be surprised how well a common philosophy in the community keeps everything nice and tidy. If you look at old clojure libraries like Incanter which were still heavily influenced by CL they're nothing like recently developed ones. The preferred way of doing things is like this: Data > Functions > Interop > Macros. Clojure discourages mutability and side effects. CL embraces them, it doesn't even have immutable datatypes, let alone sane deep equality. I don't see how C++ is relevant since even Rust has unsafe.
    - pjmlp 7y ago
      It is relevant, because the unsafe features are still there, regardless how many use them, language culture and what not. Likewise Clojure contains the main features of CLOS and makes use of them to interop with JavaScript, Java and C#, regardless how many in the community make use of it. A language is made by the language specification and its standard library, not by whatever the community feels as trendy. Present us a full compliant Clojure implementation minus CLOS, and lets see how far it goes.

flavio81 7y ago

>Common lisp by comparison, feels arcane, outdated and non lispy. Only if your knowledge of Common Lisp is at the level of "armchair specialist".

j-pb 7y ago
Said the "armchair clojure specialist" ;)