5 ms·

This is why I call Clojure a "Lisp", whereas I somewhat pedantically refer to previous languages in this family as "LISPs", as originally coined from "LISt Proc

by hga 11y ago

This is why I call Clojure a "Lisp", whereas I somewhat pedantically refer to previous languages in this family as "LISPs", as originally coined from "LISt Processor". But it's still a Lisp, I went straight from old half-remembered mainline LISP and Scheme to Clojure in a recent small web server project without difficultly. The dynamic style of development is the same as is the typing, if you're not using lists, then the OPs problems don't come up (idiomatic Clojure web programming uses maps, key value pairs), the syntax is still s-expressions, albeit polluted by arrays denoted with square brackets where it makes sense. And I believe the article is wrong in one sense, the JVM treats non-tail recursion like other languages, growing the stack. It's tail call optimization (TCO) that's the issue: mandatory in Scheme, don't know about its prevalence in Common Lisp implementations, and it's awkward in Clojure but wasn't much of a jump from SICP for the typical cases. And I think it might be a good idea to require signaling when you intend to tail recurse, it's easier and much quicker to find in compilation than when you blow the stack running it.

olewhalehunter 11y ago
There's something very off about working with a lisp and not being able to inject stateful inline expressions for prototyping. In other lisps you find the fluid abstraction/computational nature of sexps holding up very nicely while in Clojure you find yourself having to rewrite larger portions of functions just to test or fix something. A lot of my turnoffs from Clojure is that it takes away the whole "geometrical logic glue" aspect of sexps and leaves behind what feels like a neutered stack-based language for the JVM in lisp's clothing.
- hga 11y ago
  Hmmmm; I haven't worked with Clojure enough, and that after a decade break from programming and several from serious LISP programming, but ... while I like it, I don't find it very tasteful in many ways, including that very sort of way. It's a language I like to program in, but not one I think I'll ever fall in love with like mainline LISP and then Scheme. While I very much like the first class syntax for arrays, maps, and sets, there's a tremendous advantage to having one main or even exclusive built in composite data type, e.g. I hear that a strength of Lua, which I gather has been very successful. LISP's DNA, as well as Scheme's I'm pretty sure, was established in the days when that was lists.
  - GFK_of_xmaspast 11y ago
    "While I very much like the first class syntax for arrays, maps, and sets" Don't lisp advocates usually say it has no syntax.
    - yarrel 11y ago
      It has whatever syntax you create for it. ;-)
    - 59nadir 11y ago
      Clojure explicitly makes '()' and '[]' different, as well as a few other delimiters. '(1 2 3) is a list like in Lisp tradition, but [1 2 3] is a vector. That is the syntax that the parent is talking about.
      - WildUtah 11y ago
        Yes, specifically [:whatever] is syntactic sugar for (vector :whatever) and {:what :ever} is syntactic sugar for {array-map :what :ever}. CL has the #() syntactic sugar for the first and the #'acons syntactic sugar for the second. So, in fact, Clojure is no more unLISPy than CL in the most quoted respect. (Quote from CLtL: Many people have suggested that brackets be used to notate vectors, as [a b c] instead of #(a b c). This notation would be shorter, perhaps more readable, and certainly in accord with cultural conventions in other parts of computer science and mathematics. However, to preserve the usefulness of the user-definable macro-character feature of the function read, it is necessary to leave some characters to the user for this purpose. Experience in MacLisp has shown that users, especially implementors of languages for use in artificial intelligence research, often want to define special kinds of brackets. Therefore Common Lisp avoids using brackets and braces for any syntactic purpose.)
  - agumonkey 11y ago
    Clojure tried to push the homoiconicity as a first class rule, so it felt logical to have a literal for built-in types. But at the same time I .. how to say that, don't want syntax. First lisps had the minimum of it: sexp, symbol. jmc lisp stopped there, they then added numbers and strings for ergonomic sanity[1], and it feels the right balance, the proximity of metalevel and language, the adt/dsl feel since everything will be an sexp based abstraction (SICP ate my mind?). So clojure tried principled consistency, I like the logic of it, but not the result. Erik Meijer and Brett Victor claim it's a good thing to do. Find a concept and go all the way down with it. [1] it would be fun to be denotational even for these. (arithmetic-sum (number two one three) (number six six six)), yes it would be.
- grandalf 11y ago
  > inject stateful inline expressions for prototyping would you give an example of this? Just curious as someone who has spent more time in clojure than in lisp.
- thom 11y ago
  I'm ashamed to say I don't know what either of your points means. Your Clojure experience on GitHub seems nontrivial so I'd love to hear more!

by hga 11y ago

olewhalehunter 11y ago

There's something very off about working with a lisp and not being able to inject stateful inline expressions for prototyping. In other lisps you find the fluid abstraction/computational nature of sexps holding up very nicely while in Clojure you find yourself having to rewrite larger portions of functions just to test or fix something. A lot of my turnoffs from Clojure is that it takes away the whole "geometrical logic glue" aspect of sexps and leaves behind what feels like a neutered stack-based language for the JVM in lisp's clothing.

hga 11y ago
Hmmmm; I haven't worked with Clojure enough, and that after a decade break from programming and several from serious LISP programming, but ... while I like it, I don't find it very tasteful in many ways, including that very sort of way. It's a language I like to program in, but not one I think I'll ever fall in love with like mainline LISP and then Scheme. While I very much like the first class syntax for arrays, maps, and sets, there's a tremendous advantage to having one main or even exclusive built in composite data type, e.g. I hear that a strength of Lua, which I gather has been very successful. LISP's DNA, as well as Scheme's I'm pretty sure, was established in the days when that was lists.
- GFK_of_xmaspast 11y ago
  "While I very much like the first class syntax for arrays, maps, and sets" Don't lisp advocates usually say it has no syntax.
  - yarrel 11y ago
    It has whatever syntax you create for it. ;-)
  - 59nadir 11y ago
    Clojure explicitly makes '()' and '[]' different, as well as a few other delimiters. '(1 2 3) is a list like in Lisp tradition, but [1 2 3] is a vector. That is the syntax that the parent is talking about.
    - WildUtah 11y ago
      Yes, specifically [:whatever] is syntactic sugar for (vector :whatever) and {:what :ever} is syntactic sugar for {array-map :what :ever}. CL has the #() syntactic sugar for the first and the #'acons syntactic sugar for the second. So, in fact, Clojure is no more unLISPy than CL in the most quoted respect. (Quote from CLtL: Many people have suggested that brackets be used to notate vectors, as [a b c] instead of #(a b c). This notation would be shorter, perhaps more readable, and certainly in accord with cultural conventions in other parts of computer science and mathematics. However, to preserve the usefulness of the user-definable macro-character feature of the function read, it is necessary to leave some characters to the user for this purpose. Experience in MacLisp has shown that users, especially implementors of languages for use in artificial intelligence research, often want to define special kinds of brackets. Therefore Common Lisp avoids using brackets and braces for any syntactic purpose.)
- agumonkey 11y ago
  Clojure tried to push the homoiconicity as a first class rule, so it felt logical to have a literal for built-in types. But at the same time I .. how to say that, don't want syntax. First lisps had the minimum of it: sexp, symbol. jmc lisp stopped there, they then added numbers and strings for ergonomic sanity[1], and it feels the right balance, the proximity of metalevel and language, the adt/dsl feel since everything will be an sexp based abstraction (SICP ate my mind?). So clojure tried principled consistency, I like the logic of it, but not the result. Erik Meijer and Brett Victor claim it's a good thing to do. Find a concept and go all the way down with it. [1] it would be fun to be denotational even for these. (arithmetic-sum (number two one three) (number six six six)), yes it would be.
grandalf 11y ago
> inject stateful inline expressions for prototyping would you give an example of this? Just curious as someone who has spent more time in clojure than in lisp.
thom 11y ago
I'm ashamed to say I don't know what either of your points means. Your Clojure experience on GitHub seems nontrivial so I'd love to hear more!