pg: I'm a big fan, but I think you're a bit off on this one. Costs, risks, and benefits.
Costs: with Java/.Net, you get free garbage collectors, machine code compilers, debuggers maybe, vast numbers of libraries from thousands of sources, a huge installed technology base and ecosystem. Versus almost none of that with start-from-scratch.
Risks: by staying on a known platform risk is minimized. If an organization is looking to replace/supplement language X with a new language Y, it helps that X and Y are both calling the same libraries. Developers get knowledge re-usability and the organization gets a way to easily recode new programs in X that were recently written in Y before everyone decided that Y was a mistake.
Benefits: much reuse of platform knowledge, libraries, etc., most of which have typically been heavily used and debugged (again reducing risk.)
You once pointed out that moving away from the herd's choice of languages can bestow some major competitive advantages. I agree, but think that this will work only if one doesn't acquire so many disadvantages in the switch that the advantages are obviated. Clojure on the JVM gives the best of Lisp, FP, and the JVM/Java ecosystem while minimizing the problems of each.
The languages don't "have to be built on top of existing popular VMs", but why, given all these advantages, do it any other way?
It seems to me you're saying it's the latter case: that new Lisps will get an advantage from being built on existing VMs that new "mainstream" languages don't need. Maybe. But in that case, let's follow the thread further: what is it about Lisp dialects that makes them need this extra crutch?
Not the semantics, surely. I'm sure if you gave ordinary schmoes a language that looked familiar, they wouldn't balk at it because it happened to have clean semantics. Is it merely the name "Lisp?" You could solve that problem by refusing to call it a Lisp. So all that's left is syntax. You're saying, in effect, that a language with s-expression syntax needs the extra boost of being on a popular VM to make it.
I don't know if that's true or not. It might be. But it is interesting to know that this is what the argument reduces to.
>> You're saying, in effect, that a language with s-expression syntax needs the extra boost of being on a popular VM to make it.
Actually, my guess is that all future non-DSL languages are going to need to be built on a popular VM/framework in order to succeed, because of the advantages I listed in my earlier post. A DSL can get by without a popular platform because, by definition, it doesn't extend beyond its narrow scope and thus doesn't need access to a broad range of libraries. Also, DSLs don't tend to be performance sensitive and therefore don't need the compiler optimizations.
What I was really responding to was the fact that you are the co-author of Arc, and I was (wrongly) seeing your post in that context. My apologies for confusing the issue, although I do think that the point I'm driving at is an important one.
Once that's taken as a given, why reinvent the wheel? It seems like there's numerous advantages to using established VMs like the JVM or the CLR. In order to justify the engineering effort of building and maintaining a new VM, you'd have to have a compelling reason and I'm not sure that the reason is always there.
unless your programming language requires a new VM for some good reason, build it on top of an existing one.
when would a new VM be required? well, Erlang for example just could not have been implemented on top of JVM (forget for the moment that it predates the JVM by a few years). BEAM, the Erlang VM, has an overhead of ~500 bytes per process -- try that with JVM. Factor, IIRC, outgrew the JVM very quickly too – though i forget how exactly.
most of Lisp's power lies in uniform syntax which manifests itself in Lisp macros. that's not a good reason to write a whole new VM.
the reason i talk about "future of Lisp" rather than all programming languages is that at the time i was thinking about Lisp & why it remains unpopular despite being an awesome language.
And if it's not the case that this principle applies to all new languages, what's special about dialects of Lisp that makes it only apply to them? Why can you build a new language with infix syntax and Greenspun's-tenth-law semantics up from scratch, but not a new Lisp?