[mrottenkolber]

> And what about using persistent data structures by default

You can do that in CL if you like to.

> and having JavaScript as a compilation target?

See ParenScript.

> I also haven't heard much about how easy CL's host language inter-op is to work with...

CL doesn't have a host language. And look at ABCL please.

> Another big thing of course is that the community is much more vibrant and welcoming than Common Lisp's.

The community is more skiddish and therefore newbie friendly. CL's community may feel arrogant at first, but with time you will notice it was justified because you were wrong and ignorant about it.

[mtrimpe]

> > And what about using persistent data structures by default

> You can do that in CL if you like to.

When you do this by default you do get a completely different ecosystem of libraries though, which is one of Clojure's key advantages over CL.

> CL doesn't have a host language.

Another one of Clojure's key features is that it's designed to be easy to implement on a host language.

That choice has some disadvantages such as forgoing the elegant condition system of CL in favor of plain old exceptions, but it also enables the practical use of Clojure and it's persistent data structures on a varied collection of host languages.

> CL's community may feel arrogant at first, but with time you will notice it was justified

We all know the Smug Lisp Weeny stereotype. I had the pleasure of talking with the original smug lisp weeny (smuglispweeny.blogspot.com) a couple of years ago about his OpenCells library which I still love as one of the most elegant solutions in computing.

OpenCells never went anywhere serious though but the Clojure ecosystem is starting to develop it's own version of the concept which runs on the browser right away and is already driving demo iOS and Android apps.

So yes, Clojure might not have the history of CL behind it and has less of a history of drawing bright minds into an ivory tower which contains infinite beauty but which rarely, if ever, makes down to earth.

You could say that makes it a toy, but if I had to place a bet on which language will have the biggest impact from now on then I'm pretty sure which language I would put my money on.

[mrottenkolber]

> When you do this by default you do get a completely different ecosystem of libraries though, which is one of Clojure's key advantages over CL.

This isn't even an argument. "Because its new."

> Another one of Clojure's key features is that it's designed to be easy to implement on a host language.

You just made that up. Clojure was designed to be able to run on the JVM. When implementing Clojure from scratch you will have to emulate the JVM. So the guys who will maybe (I don't think anybody will remeber Clojure in 10 years) do that in ten years will curse rich hickey.

I am not comment on the rest, because it has no content.

[weavejester]

> This isn't even an argument. "Because its new."

I think you're mistaking the parent poster's argument. Immutability is at its most useful when it's the norm, rather than the exception. For this to work, the core language needs to very strongly encourage immutability, to the point where in-place mutability is considered something only useful for low-level performance tweaks.

It's not that Clojure is new - there are plenty of older languages that have a strong core of immutability. The point is that it needs to be at the core of the language in order to be pervasive.

> You just made that up. Clojure was designed to be able to run on the JVM.

No he didn't. The Clojure rationale page talks about separating languages from platforms, and this subject has come up often in talks and on the mailing list. Clojure has already been ported to Javascript, and there are various projects to implement Clojure in Python, Ruby, C and Lua - that I know of.

There's also a lot of current work going on in abstracting out the Clojure analyser and compiler, both to bootstrap the language, and to make it easier to derive ports.

[mrottenkolber]

> I think you're mistaking the parent poster's argument. Immutability is at its most useful when it's the norm, rather than the exception. For this to work, the core language needs to very strongly encourage immutability, to the point where in-place mutability is considered something only useful for low-level performance tweaks.

I don't think so. What you are saying is you can only program in way X if your language forces you to, which is obviously wrong? I think people just are not used to using a language that doesn't force you to do anything at all (e.g. lisp).

You can only program in way X if your language _allows_ you to. What language allows you to program in any way and even lets you easily modifiy the language to do whatever you want? Lisp.

> The Clojure rationale page talks about separating languages from platforms, and this subject has come up often in talks and on the mailing list.

Then they made that up. ClojureScript is not the same as Clojure. They did a pretty horrible job at seperating their language from their platform. I know because I get Java stack traces all day. I also have to use inferior language primitives dues to Clojure's Java-centrism every day.

[weavejester]

> I don't think so. What you are saying is you can only program in way X if your language forces you to, which is obviously wrong?

If you have a library that expects mutable data structures, that's going to be incompatible with a library that uses immutable data structures. The type signatures of the functions are going to be fundamentally different.

It's certainly possible to have a language without a consistent set of core data structures, but I'd argue that's considerably less useful. Enforcing a particular paradigm means you can interface between libraries without worrying about compatibility of data structures.

> Then they made that up. ClojureScript is not the same as Clojure. They did a pretty horrible job at seperating their language from their platform.

That's not quite what I meant. A particular implementation of Clojure is typically tied closely to the platform its hosted on. That's why Clojure and ClojureScript have marked differences, especially around concurrency.

What Clojure lacks, and deliberately so, is a platform of its own. There isn't an equivalent of the JVM in Clojure; there's no intermediate layer that sits between Clojure and the JVM, or ClojureScript and Javascript. The idea is that the language should adapt to its host, instead of trying to shoehorn everything through a universal interface that can't cope with every situation.

[Mikera]

There's a pretty good argument that taking away features is what makes programming paradigms effective. You create restrictions (invariants, if you like) that enable the paradigm. Consider:

- Structured programming takes away GOTO - OOP takes away manual function pointer tables - FP takes away unrestricted mutation - Logic programming takes away explicit specification of execution order - etc.

None of this is about "forcing" you to do anything. It just appears that humans aren't very good at coding with unrestricted power over their machines, and it helps to simplify paradigms in a way that enables them to be effective at reading and writing higher level code.

If this wasn't the case we'd all still be programming in assembly.

Slightly tongue-in-cheek talk by Uncle Bob on the topic: - https://skillsmatter.com/skillscasts/2323-bobs-last-language

[gtrak]

Better stacktraces would be better, sure, but there are good arguments on both sides whether it's better to separate the language from the platform or not.

I prefer a thin, readable compiler and core library over such abstractions. I don't mind the stacktraces, but I could see how some people might.

The fact that clojure is host-centric makes clojure and clojurescript compelling to java or javascript programmers at the expense of some aesthetics, and it also has performance implications.