In many ways I feel like Clojure is a better Lisp than Lisp itself. Syntactic niceties like support for vectors/maps/sets are, once you've gotten used to them, hard to do without. And although it's orthogonal to the syntax, I also appreciate its focus on immutability. I just with there was a Lisp like it that didn't run on the JVM.
Curious - why is running on JVM bad?
Differences with other Lisps
81–90 of 108 posts
Re: Differences with other Lisps
#82The difficulty with these lists is they always have huge blind spots. For instance, any scheme user would reasonably want to know if macros were hygienic.
Re: Differences with other Lisps
#83Earlier quoted context omitted.
Curious - why is running on JVM bad?
Very slow startup for one.
* https://convexhuman.com/graalvm-clojure.html * https://nitor.com/en/articles/fast-cold-starts-for-clojure-i... * https://www.innoq.com/en/blog/native-clojure-and-graalvm/
Since development in the REPL is so common (watch any Clojure live coding session), JVM startup time isn't much of an issue in practice.
Re: Differences with other Lisps
#84Maybe a more seasoned LISP-`aterian` can answer me ? I'm in the process of learning ClojureScript - real fun so far. I have of course also looked at other LISPs and have noticed that in CJS the use of square brackets[] for vectors, let and `function params` (defn myfunc [] (let [some-var (:some-key some-state)]) (.log js/console some-var) ) I almost never see square brackets in other LISPs (yes I'm truly a beginner a…
In Clojure, `[1 2 3]` is a vector, which is a distinct data type from a list, which looks like `(1 2 3)`. A vector in Common Lisp is written using `#(1 2 3)`. Using vectors for function arguments is unique to Clojure, and I'm not entirely sure why they chose to do it that way.
Once you understand how destructing works in Clojure, it becomes obvious
Re: Differences with other Lisps
#85I like this list. I don’t agree with every choice but so what: they are all thoughtful choices (except why do you need `recur`?) that reflect an opinionated position which I appreciate.
Re: Differences with other Lisps
#86Earlier quoted context omitted.
The reality is that just about every single lisper will insist how they don't see the parenthesis and they are not a problem, and just about every single lisp has some ugly ad hoc hacks to reduce their clutter. They just differ somewhat between lisps. Scheme (and descendants like racket) went so far as to make [] and () interchangeable. So you will in fact see brackets in some scheme most e.g. (let ([a 1] [b 2]) ...)…
There have been LISP dialects where a single closing square bracket was used to close all the remaining open round parentheses.
Re: Differences with other Lisps
#87Earlier quoted context omitted.
Neat, I don't remember hearing about the "command" justification before. I suppose this is a rationale behind e.g. the 'ns macro separating its command-keywords that map to functions with parens? Still, I always thought the full syntax of 'ns and the individual things inside of it was a bit wild. Thank goodness for Slamhound... Like, take (import [package thing-in-package other-thing-in-package]) -- the first element…
Oh yeah, you're right, multi-arity fns are also a big exception to the empirical "rule" I mentioned. And yes, (ns) macro looks like a historical mess indeed. > but I am saying that I don't think Clojure's introduction of [] and {} for core syntax on top of their roles as data literals actually made things any better I think of it as embedded JSON so that it's easier to type data structures, and with Clojure you end u…
Re: Differences with other Lisps
#88Earlier quoted context omitted.
The commercial Common Lisp I use, also has large amounts of extensions to CL. Including a function to split sequences/strings, parallel and concurrent extensions, ... ;-) It's actually the same commercial Common Lisp which Rich Hickey used years ago to write his first Lisp programs and where he developed his first ideas for Clojure.
Are you working under an NDA or something? Are you being threatened? Blink three times if you need help. Seriously, is there a reason you have to hint about what Lisp you use?
If you are interested, I'm using LispWorks http://www.lispworks.com>. The other large commercial Common Lisp implementation is Allegro CL https://franz.com/products/allegro-common-lisp/>.
Re: Differences with other Lisps
#89Earlier quoted context omitted.
Very slow startup for one.
Yeah, somewhat agree. The Clojure community has put so much effort into working with GraalVM. * https://convexhuman.com/graalvm-clojure.html * https://nitor.com/en/articles/fast-cold-starts-for-clojure-i... * https://www.innoq.com/en/blog/native-clojure-and-graalvm/ Since development in the REPL is so common (watch any Clojure live coding session), JVM startup time isn't much of an issue in practice.
Re: Differences with other Lisps
#90The difficulty with these lists is they always have huge blind spots. For instance, any scheme user would reasonably want to know if macros were hygienic.
There are parts of Clojure I like, such as the data structures and de-structuring. Maybe it was primarily the JVM, but I just couldn't get into Clojure...it doesn't give the same feeling as working in CL. I really wanted to like it though.
I do wish that someone would take some of the modern data structure ideas and backport them to Common Lisp (as a new lisp obviously). The historical cruft in lisp and lack a strong modern standard library are major reasons I don't play with it day-to-day.