4 ms·

>> Why can you build a new language with infix syntax and Greenspun's-tenth-law semantics up from scratch, but not a new Lisp? pg: I'm a big fan, but I think

by miked 18y ago

>> Why can you build a new language with infix syntax and Greenspun's-tenth-law semantics up from scratch, but not a new Lisp? 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?

pg 18y ago
How can I be off? I didn't draw any conclusions; I merely explained that the author's statement translates into one of two possibilities, and asked which they meant. 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.
- miked 18y ago
  Sorry, my bad. Upon carefuly re-reading your original post I can see the point you were actually making, rather than the one I thought you were making. I completely agree that there is nothing special about Lisp-class languages rather than those of other classes. In fact, I would go further. Having implemented a small Scheme on .Net and also having read thru most of the Clojure code on the JVM, I'd guess that the OO/statically typed nature of both platforms gets in the way of Lisp-like languages more than those of other paradigms. So, in effect, I may "more than" agree with you. >> 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.

by miked 18y ago

pg 18y ago

How can I be off? I didn't draw any conclusions; I merely explained that the author's statement translates into one of two possibilities, and asked which they meant. 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.

miked 18y ago
Sorry, my bad. Upon carefuly re-reading your original post I can see the point you were actually making, rather than the one I thought you were making. I completely agree that there is nothing special about Lisp-class languages rather than those of other classes. In fact, I would go further. Having implemented a small Scheme on .Net and also having read thru most of the Clojure code on the JVM, I'd guess that the OO/statically typed nature of both platforms gets in the way of Lisp-like languages more than those of other paradigms. So, in effect, I may "more than" agree with you. >> 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.