59nadir on One Major Difference Between Clojure and Common Lisp

Comment on One Major Difference Between Clojure and Common Lisp parent

The result of that design is that Clojure shares literally zero lines of code with other Lisps: Autolisp, ISLisp, Emacs Lisp, Standard Lisp, Common Lisp. Many basic concepts are absent, renamed or redesigned ('Atom', 'Linked List', ...). Clojure is fully incompatible to any other language with Lisp in its name.

Programs have to be re-architectured, because the concepts are different:

"Re-architectured" can be read in a multitude of ways. Changing a few datatypes because Clojure prefers vectors instead of lists, etc., feels like it falls well below the bar for "re-architectured".

no TCO, but 'functional'

This would hold weight if CL mandated TCO, but it doesn't.

With this in mind, I'd like to examine a few of your points from a different angle:

Racket:

- Basic concepts are the same, (atom, linked lists, '...')

- Restructuring not really needed (up for debate, depends entirely on your prefered initial design choices in either language. Racket isn't that opinionated.)

- Tail call optimization required as per Scheme standard, so is present. Note that this is not actually something Lisp mandates.

- Doesn't 'care' about side effects, community is pragmatic and will generally advise you to do whatever is practical

- Has an object oriented sub-language with message passing and so on

There are a lot of points here that, according to you, makes Racket essentially a Lisp, even your non-point about TCO. I'm curious to know what you feel about people saying Scheme is a Lisp, considering the above.

The whole debate of "Is X (a) Lisp?" reminds me of nationality debates that essentially boil down to some people saying blood is more important than culture. You seem to be taking both sides, however; arguing culture and blood (source code). You cherry pick the cultural differences like most people standing on one side of the nationality debate would and argue that just those specific differences are the most important.

That's the thing, though; Swedish people could argue however much they want that they're very different from Norwegian people. To the rest of the world, though, they're essentially the same. Especially when you start comparing them to people from Peru, Venezuela, South Africa, and so on. When you're in the bubble the very small differences are much bigger to you, but if you zoom out to get some perspective these differences are much smaller than the commonalities.

lispm 10y

Shriram Krishnamurthi says about this topic:

Racket is Racket. It's its own language.

59nadir 10y

Yes. I was asking you, because you have ideas of what makes a Lisp a Lisp. I've given you several reasons that by your own admission were important for a Lisp being a Lisp and I'm wondering, considering what you've said was important, if you think Racket is a Lisp.

lispm 10y

In practical terms Racket is not a Lisp. There are large areas of overlap. The people behind Racket steer the language further away - which is nothing bad, just an observation... there are lots of new features in Racket, which are not in Lisp.

59nadir 10y

I find that interesting, considering that most of the points you raised about Clojure not being a Lisp would indicate that you think Racket is a Lisp.

You've also been nothing but vague in terms of what makes Racket not a Lisp, which is ironic considering your previous argument that we should have more clearly defined requirements for what makes a Lisp, but I'm beginning to think that this was mostly hot air.

I think you've mostly proven that the 'vague' definition serves a much more practical purpose than your seemingly arbitrary distinction between these languages, and it will continue to do so, as it implies far more than you've displayed in this thread.

lispm 10y

You've also been nothing but vague in terms of what makes Racket not a Lisp

True, and I have to apologize for that. But I don't have the time, nor the priority to go into full detail. The main points are: different community, different goals, almost zero code sharing, different technical solutions, different literature, ... The differences are technical and social. Each of the points would need more explanation, for which I don't have the time.

For me 'Lisp' is something practical. I have a bunch of non-trivial code -> can I compile/load it? Can I port it easily? Are there people who would be interested to share? What are they using? Can I work with them?

Example:

Macsyma is an old Lisp program. New Lisp dialects appeared. Macsyma was ported to them: Maclisp, Franz Lisp, NIL (New Implementation of Lisp), Lisp Machine Lisp, VaxLisp, Common Lisp...

This software can't be ported to Clojure or Racket, without fully re-architecting the software, and I'm only thinking about the basic Macsyma, without GUI or other system dependent parts.

that the 'vague' definition serves a much more practical purpose

which one? to confuse people? To raise expectations of collaboration in a community, which are then not fulfilled?

dragonwriter 10y

It's true that it is more difficult to port from Common Lisp or other Lisp-2 dialects to Scheme, Racket, or Clojure (which are Lisp-1 dialects) than it would be to port to other Lisp-2 dialects. But that certainly doesn't make Lisp-1 dialects "not Lisp" while Lisp-2 dialects are "Lisp".

lispm 10y

Porting code from Lisp-2 to Lisp-1 is not that difficult.

Example:

Lisp-2:

    (defun new-map (f l)
      (dolist (e l)
        (funcall f e)))

Lisp-1:

    (defun new-map (f l)
      (dolist (e l)
         (f e)))

Another example:

Lisp-2

    (defun foo (l)
      (flet ((new-map (f l)
               (dolist (e l)
                  (f e))))
        (new-map (function sin) l)))

Lisp-1

    (defun foo (l)
      (let ((new-map (lambda (f l)
                       (dolist (e l)
                         (f e)))))
        (new-map sin l)))

To make it easier, just define FUNCALL, FUNCTION and FLET in Lisp-1...

Comments