Clojurians Log v2

Hi guys, I'm trying to find the best channel for asking my question and I was told to use this. I took part of a good discussion with colleagues yesterday about the requirements a language should have to be considered as part of the Lisp family. In this case, they argued that LFE is not effectively Lisp, but just a language with syntax similar to Lisp, because for instance it doesn't have homoiconicity (I'm not sure about this statement). Why is it this way exactly? The same rationale would apply to Clojure?

What is LFE?

Lisp Flavoured Erlang https://lfe.io/

A project headed by Robert Virding, one of the Erlang's creator.

@gustavobertolino Clojure definitely has homoiconicity: Clojure code is also well-formed Clojure data, and that's how macros work, by being "just" functions that take code as data as arguments and return updated data that can be read as code.

Yes, Sean, I definitely agree with you. When I was discussing one of my colleagues explained in the same direction, which makes totally sense for me. I just thought a bit strange LFE to be not considered Lisp just because its semantics is different, as some guys argued during the discussion. I mean, semantics in this case for LFE is all the process and entities running (and existing) on BEAM.

A quick look through the docs seems to indicate it follows Common Lisp syntax more closely than Clojure does, and instead of Clojure's (some-ns/some-fn arg1) it uses (some-module:some-fn arg1). I can't understand why your colleagues think LFE is not "a Lisp".

I do not know if you have come across a particular individual who seems to argue that anything that is not Common Lisp is not a Lisp -- hopefully you haven't. If so, I would ignore that particular person.

Yes Sean, exactly! I didn't see the point to not consider it as a Lisp for real, because even though it might not have read/eval capabilities, it has macros and, thus, the ability to deal with code as data, which seems an essential part of Lisp. One of the guys made exactly that point that not being able to read/eval is enough to not consider it as a Lisp, but I don't think it's a good criteria.

I was not sure @andy.fingerhut, I just gave the benefit of doubt for all for the sake of the arguments and discussion at that moment 😀. But you're right, I agree... We should take care to not falling into traps like that.

ClojureScript doesn't have eval either -- but it is definitely still a Lisp 🙂

There are #other-lisps and #other-languages channels which can often be good spaces to discuss/compare languages (but this channel was a good place to ask the initial question).

There are a lot of lisp zealots who are very eager to gate keep what is and is not a lisp

Many consider Clojure not a lisp, for many reasons

For instance, it’s heretic use of literals like [] and {} 😁

yeah. i've also never really learned anything from those discussions either. and the weird definition used is quite arbitrary. and even if it excluded Clojure, it doesn't change Clojure, it just withholds their own bespoke stamp of approval.

Yeah. Ultimately what is a lisp or not is not really useful. It’s fair enough to say it’s in the family of languages borne from lisp, and we can colloquially refer to those languages as lisps because who cares 😜

the conversation in #beginners about namespaced keywords is way more interesting to me than talking to someone who's definition of a lisp is whether it can run character for character programs from mccarthy's 61 paper. that argument is not exaggerated but what i remember

Hum, interesting... I didn't know cljs doesn't have eval. But doesn't this short gist article show the quite contrary? https://gist.github.com/mfikes/66a120e18b75b6f4a3ecd0db8a976d84

Core ClojureScript doesn't have eval (the implementation throws), but alternative implementations can bind in their own version of eval, e.g., the various self-hosted ones, using whatever machinery they want. How much of "Clojure" is evaluated by such things is implementation-defined @gustavobertolino

It's an interesting read... as it says, you can patch the main ClojureScript system to have a limited form of eval, but a lot of what is really needed for eval simply isn't available in the JS runtime version of the compiled code. The self-hosted implementations have more capability.

What would it be "self-hosted" in this context?

I didn't get this idea of "self-hosted" implementations of eval. In this case, you meant that eval ability is hosted in those specific repl server's implementations, @seancorfield?

The discussion above reminded me of a long standing question: as someone who learned Clojure as their first lisp (I came from Python), what value (if any) is there in learning some other lisp? Is it worth it? (The question is deliberately a bit vague, as I'm looking for opinions.)

I was actually thinking the same thing. I played around with CL some and leafed through the paulg lisp books, but it seems to me that Clojure is just plain better. This is not an answer though, just a comment XD

the hardest part of using other lisps is figuring out how to declare dependencies and projects. messing around at the repl is nice but figuring out how to require other things is quite tricky in my experience. This makes it hard to do much (for me) beyond simple programs. However learning scheme or common lisp, just as learning any other language, almost always conveys some benefit

Might be worth learning elisp if you have any interest in getting into hard-core emacs stuff.

elisp for emacs, and scheme for SICP (rather, Scheme through and for SICP). Although, I've been putting off learning emacs for a long time now.

@gustavobertolino the ClojureScript compiler is written in Clojure, so it needs a JVM to compile code. That being said, when you are running ClojureScript you probably don't have a JVM available

Self hosted means ClojureScript compilers that are written mostly in ClojureScript, with probably a thin layer of JS just to be able to bootstrap the compiler

As these implementations don't need a JVM, they support eval out of the box

I also came to Clojure from python, so I can't tell you what the experience will be like going from "lisp-y language A" to Clojure is, but I can make some generalizations about the reverse. TL;DR: Although there's a bit more of an overhead, I think you actually get a lot out of starting with Clojure, rather than another lisp. In spite of a lot of all the elitist blather out there about Clojure not being a real lisp, I found that after putting in the time to learn how to use Clojure most of those skills translated completely to languages like Scheme, CL, and of course some of Clojure's modern descendants like Fennel and Janet (disclaimer, have only played around with these as toys). Clojure is kind of special, in that there was an extraordinary amount of thought put into the implementation of the language, and this is where an enormous portion of the value in Clojure is, beyond it being a lisp. If you started with Scheme, you might learn the value associated with using a lisp, but you probably wouldn't learn the value of first-class immutability and the wonderfully designed CSP paradigm you get with core.async. And finally, for what it's worth: if you can get past tooling together a complicated Clojure project, you can get past tooling in any language.

It's also sort of funny / worth noting, that when CL was being 'defined' (collected together...) many people didn't think it was a 'true' lisp either 😐

I think that's true that a lot of Clojure's value isn't in it's relative level of Lispiness, but the data structures, the ecosystem it sits in, the pragmatism and care around interop, etc. It also makes it hard to disentangle all of those properties and see what everyone is bringing to the party if you haven't seen the concepts elsewhere. E.g. the LISP 1.5 manual spends like 6-7 fairly short pages explaining cons, car, cdr, eq, and atom and then basically says "ok, so that should be about all you need to build the world from first principles" and then goes about doing it, which is kind of eye-opening even if you never go on to use LISP 1.5.