Live data from Hacker News

Differences with other Lisps

clojure.org

81–90 of 108 posts

Re: Differences with other Lisps

#81

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?

Very slow startup for one.

Re: Differences with other Lisps

#82
post #75

The 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.

They're not hygienic, but the usage of auto-gemsyms on quasi-quote and the fact that symbols are automatically expanded to their namespaced forms solves most of the problems that unhygienic macros have: http://clojure-doc.org/articles/language/macros.html#macro-h...

Re: Differences with other Lisps

#83
post #81

Earlier quoted context omitted.

Curious - why is running on JVM bad?

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

#84

Maybe 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.

> 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

#85
post #3

I 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.

The upside of `recur` is that: * just by looking at the code you can tell if it's a tail call or not * easy to debug; no trampoline magic * guaranteed to work on any platform, whether it supports TCO or not * Javascript is a very popular target, via ClojureScript * who wants to test and remember if Chrome or Firefox or Safari implement TCO? or implement it properly? and which version(s) of those browsers implement TCO properly? * if you wanna want a trampoline, you got it! (https://clojuredocs.org/clojure.core/trampoline)

Re: Differences with other Lisps

#86
post #33

Earlier 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.

Sounds useful for an interactive shell. Perhaps even Fish shell could adopt it.

Re: Differences with other Lisps

#87
post #70

Earlier 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…

Right, as data literals my program is going to use they're great, I fell in love with Python a long time ago in part because of its convenient data syntax. Clojure's values-are-values philosophy is also amazing. How much value are they though as core syntax forms? Take keyword parameters for instance. In Clojure you pass to defn something like [a & {:keys [x y]}]. In Common Lisp, that would be (a &key x y). If you want to add default values, in Clojure you'd change to [a & {:keys [x y] :or {x 1, y 2}}]. In Common Lisp, that would be (a &key (x 1) (y 2)). They're both data structures, they both require interpretation by the human and the defn/defun implementation, they're both not eagerly evaluated like other uses of data literals would be (neither the sequences nor the symbols need to be quoted). Apart from Clojure strangely bucking tradition with everything by making the top structure a vector instead of a list, and a quibble of repeating yourself for default mapping, I don't really think one is definitively better than the other, but that also means I don't think Clojure improved on anything with that choice.

Re: Differences with other Lisps

#88
post #67

Earlier 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?

I just didn't want it to sound like an advertizement.

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

#89
post #81

Earlier 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.

This solves the startup-time of (static) applications, but not the startup time of for example executables, which include the development environment.

Re: Differences with other Lisps

#90
post #75

The 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.

All of the features mentioned seemed to be in favor of Clojure, like it doesn't mention the lack of CLOS and conditions/restarts, which were both major eye openers for me in learning Common Lisp. Just a personal point, I much prefer macros in CL as well.

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.

Post reply on HN