Why and how Clojure and Racket – two “most modern” Lisps – differ | Hacker News Reader

Why and how Clojure and Racket – two “most modern” Lisps – differ

klibert.pl

6 pointsklibertp7 comments

This is a kind of a foreword to the promised comparison of Clojure and Racket. It'll take another couple of weeks to get the following two posts out, I'll email those interested. Also, there's RSS feed on the blog now, feel free to subscribe :)

An interesting article. For me the more languages I look at, the more muddied the inheritance tree.

The more I look at Common Lisp, the more I see it's genetic finger print in Clojure. Racket's #sequence abstraction is very similar to Common Lisp's #sequence abstraction. Clojure's #collection abstraction is perhaps, like Racket's #sequence an extension of Common Lisps #sequence, or perhaps a more direct implementation of Smalltalk's #Collection abstract class.

The more I look at Smalltalk, the more likely I think this may be since a lot of the behavior of Clojure #collections looks like message passing -- i.e. Clojure #collections are also functions that accept arguments.

Thanks :)

I think CL's biggest influences on Clojure are in: the namespace system, support for multimethods, and macro system (and keyword lists). Now that you mention it, CL also has sequences, and I can easily imagine Clojure's `into` function to be Rich's answer to CL's `map result-type ...` problem with the generic (but in the meaning of "generic function", not generic multi-method, as noted in [1]) interface. But you're right: in Smalltalk Dictionary is a subclass of Collection, and Clojure collections are famous for working with lists, vectors, sets, and also maps.

I think only Rich himself could say which, CL or Smalltalk, had a bigger impact on Clojure's collections. I know from Wiki that he worked with CL and Java (so maybe, Java collections? I don't know Java...), but don't know what other languages he learned. I now see Ruby is listed among influences on Clojure: how close are Ruby's Enumerable to Smalltalk collections? The inspiration could have come that way :)

[1] http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node141.html

Smalltalk is said, by people who probably know, to be one of Ruby's points of inspiration [1]. Whether Hickey studied it or not when designing Clojure is a matter of speculation, on the other hand, avoiding Smalltalk when designing a language smells a bit like professional incompetence and that's not something I would assume about Hickey...since I assume he thought many magnitudes more about Clojure's design than I have.

My interest in Smalltalk is sort of as background for Ruby just as some of my interest in Common Lisp relates to Clojure...things like Leinigen and namespaces make much more sense after ASDF and (in-namespace...) because ASDF and (in-namespace...) are more in the RTFM tradition their counterparts in the Clojure world and so the abstractions are more explicitly documented. Probably because Common Lisp comes from a time when there weren't blogs and documentation was pretty much all there was.

[1]: https://www.ruby-lang.org/en/about/

Instead of blogs people used to publish/discuss on mailing lists:

http://ml.cddddr.org

The idea of using a language with multimethods/multiple dispatch/protocols as the base for extensible collections was further explored in Dylan, which was kind of a Scheme + CLOS:

http://lispm.de/docs/prefix-dylan/book.annotated/ch12.html

Apple Computer, 1992

Yup, I got interested in Dylan after researching "languages with multi-methods". I started playing with OpenDylan - some FFI to C, a simple HTTP client, things like that, all under 100 loc (I don't have these on GH, but there's a bit at [1]).

The only thing I can say is that I didn't like the syntax, probably mainly because of broken Emacs mode for Dylan. Well, also that it was generally slow when comparing the simple program from [1] with other implementations Dylan was the slowest[2].

I'm 100% sure that could be fixed if more people helped with the compiler, AFAIK the current OpenDylan codebase is rather old and there's one person working on it sometimes. And I didn't even manage to run Gwydion Dylan last time I checked.

Other than that, the uniformity of everything being a multi-method, the type system which is generally dynamic, but which can work statically (to a certain extent) if you want and the macros, which I, unfortunately, didn't have the time to fully explore - felt really nice.

[1] https://github.com/piotrklibert/dirlist/blob/848eb42f074b61f...

[2] Second chart: https://klibert.pl/posts/walkfiles-introduction.html

Reply on news.ycombinator.com