3 ms·

> Other JVMs So I need to switch to exotic JVMs to get better performance? > I think Clojurists (which probably outnumber all other professional Lispers combi

by lispm 8y ago

> Other JVMs So I need to switch to exotic JVMs to get better performance? > I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree Does the number matter, since most of them have a) never used Lisp nor b) do they know anything about Lisp implementation? Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. There are many reasons to use the JVM, but good support in the JVM for Lisp implementations is not one of the strong points. > Delimited continuations and eventually tail calls are coming as part of Project Loom Which means, after reading the linked doc, that neither resumeable exceptions nor TCO are in JVM, neither currently nor in the near future. Now the usual arguments about TCO are: a) one does not need TCO b) it makes tracing difficult c) it's a security problem d) we can do recursive self-calls e) a future version of the JVM will provide annotatations for tail calls f) using TCO would provide interop problems with JVM code... etc etc. The fact remains: TCO is not supported by the JVM, while this capability is a part of many other runtimes. > probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). That's all great, but I don't develop huge backbones all the time. > I'm not saying that HotSpot is always the best tool for the job Your original claim was this: 'if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well.' We are now talking about capabilities like full TCO and the JVM simply does not provide it. It currently provides no TCO at all. > You don't need to use a Java IDE It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities.

deleted 8y ago
[deleted]
pron 8y ago
> So I need to switch to exotic JVMs to get better performance? Depends what you mean by "better". HotSpot is optimized for peak performance (which is higher than that of other Lisp runtimes), and to suit the needs of server-side development. Other VMs target other uses -- fast startup, embedded etc. > If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. It's already a better match, because that's what most Lispers prefer. If you mean it could be even better than it is, then I agree. I also agree that it's not the best match for, say, Racket. Now, it's perfectly fine if you prefer Racket over Clojure, but most people prefer Clojure to Racket, partly because overall the runtime gives them more of what's most important to them. Would it be cool if the JVM had more features that would allow it to be a better match for Racket? Sure. > Does the number matter Yes, because Clojure is the most popular Lisp, the features it has are probably the ones most important to Lispers. > Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. Yes, but how much not having TCO matters can be answered by popularity. That people use Clojure much more than they use Lisps on runtimes with TCO suggests that other things matter to them more. > neither currently nor in the near future Currently, no. Near future -- probably. I'm the technical lead for that project, and it's very likely that delimited continuations would arrive soon (in fact, you can already build the prototype today, and early access builds will be available in a couple of months). > Now the usual arguments about TCO are ... Well, as it's being addressed only now rather than, say, 10 years ago means that it's not a top priority, but judged to justify some reasonable effort at this point in time. > TCO is not supported by the JVM, while this capability is a part of many other runtimes. True, but the fact remains that the totality of capabilities of the JVM is considered more attractive by more people than that of most other runtimes. > That's all great, but I don't develop huge backbones all the time. I am not saying that you, personally, should definitely use the JVM, only that it seems that the JVM is a great platform for many languages, including Lisps, and that the use cases it targets are very desired. > Your original claim was this ... I believe I also said that I mean capabilities for the domain HotSpot targets. Obviously, other things may be more attractive for, say, embedded software. > It currently provides no TCO at all. There are other things it doesn't provide. But by comparing capabilities I did not mean one by one, but the totality of those of one runtime vs. those of the others. > It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities. No, that capability is definitely there. I'm guessing the IDE authors just didn't think it's worthwhile to use. NetBeans, for example, doesn't require a restart after downloading plugins (or, rather, rarely does).
- lispm 8y ago
  > I'm the technical lead for that project, and we're very likely to have continuations soon. What relationship have continuations to making Java exceptions resumeable? > But by comparing capabilities I did not mean one by one, but the totality of those of one runtime vs. those of the others. Not sure how you compare a totality, other than actually having a list and compare them one by one. My feeling: you make a claim, but you have never used one of the Lisp runtimes like Allegro CL and you simply don't know what they provide and when it comes to specific capabilities, they are not important to YOU, because JVM users don't use them - given that they have no choice. The JVM isn't the predominant enterprise platform because it is the best Lisp platform. Very few people in companies care whether it runs Lisp well or not. People have chosen it as their platform for their niche language, because of its domination in the specific enterprise market - not because it is technically or capability-wise a good platform for their niche language. Actually even though the JVM now exists for a long time, none of the dynamic languages have their best / most performant / dominant implementations on the JVM. Not Smalltalk, not Lisp, not Scheme, not Python, not Ruby, ...
  - pron 8y ago
    > What relationship have continuations to making Java exceptions resumeable? We don't want resumable exceptions for Java. But if you want to implement a Lisp that has them on the JVM, you'll be able to use continuations for that. > but you have never used one of the Lisp runtimes like Allegro CL and you simply don't know what they provide and when it comes to specific capabilities, they are not important to YOU, because JVM users don't use them - given that they have no choice. I have never used Allegro, and, as I said, some capabilities that are important to some people may be missing on the JVM. But it seems that most Lispers prefer what the JVM has to offer, which is high performance, low-latency GC, low-overhead monitoring, and a huge ecosystem. > not because it is technically or capability-wise a good platform for their niche language. True, but most people don't care about what's good for their language, they care about what's good for their program (and users). It seems like more people prefer Lisp on the JVM, even if they have to give up some features (and they'll need to give up fewer features with Loom). > Not Smalltalk, not Lisp, not Scheme, not Python, not Ruby, ... Python and Ruby are actually most performant on the JVM nowadays. Look up TruffleRuby and GraalPython. They're just very new. Even TruffleJS is almost as good as V8.

by lispm 8y ago

deleted 8y ago

[deleted]

pron 8y ago

> So I need to switch to exotic JVMs to get better performance? Depends what you mean by "better". HotSpot is optimized for peak performance (which is higher than that of other Lisp runtimes), and to suit the needs of server-side development. Other VMs target other uses -- fast startup, embedded etc. > If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. It's already a better match, because that's what most Lispers prefer. If you mean it could be even better than it is, then I agree. I also agree that it's not the best match for, say, Racket. Now, it's perfectly fine if you prefer Racket over Clojure, but most people prefer Clojure to Racket, partly because overall the runtime gives them more of what's most important to them. Would it be cool if the JVM had more features that would allow it to be a better match for Racket? Sure. > Does the number matter Yes, because Clojure is the most popular Lisp, the features it has are probably the ones most important to Lispers. > Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. Yes, but how much not having TCO matters can be answered by popularity. That people use Clojure much more than they use Lisps on runtimes with TCO suggests that other things matter to them more. > neither currently nor in the near future Currently, no. Near future -- probably. I'm the technical lead for that project, and it's very likely that delimited continuations would arrive soon (in fact, you can already build the prototype today, and early access builds will be available in a couple of months). > Now the usual arguments about TCO are ... Well, as it's being addressed only now rather than, say, 10 years ago means that it's not a top priority, but judged to justify some reasonable effort at this point in time. > TCO is not supported by the JVM, while this capability is a part of many other runtimes. True, but the fact remains that the totality of capabilities of the JVM is considered more attractive by more people than that of most other runtimes. > That's all great, but I don't develop huge backbones all the time. I am not saying that you, personally, should definitely use the JVM, only that it seems that the JVM is a great platform for many languages, including Lisps, and that the use cases it targets are very desired. > Your original claim was this ... I believe I also said that I mean capabilities for the domain HotSpot targets. Obviously, other things may be more attractive for, say, embedded software. > It currently provides no TCO at all. There are other things it doesn't provide. But by comparing capabilities I did not mean one by one, but the totality of those of one runtime vs. those of the others. > It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities. No, that capability is definitely there. I'm guessing the IDE authors just didn't think it's worthwhile to use. NetBeans, for example, doesn't require a restart after downloading plugins (or, rather, rarely does).

lispm 8y ago
> I'm the technical lead for that project, and we're very likely to have continuations soon. What relationship have continuations to making Java exceptions resumeable? > But by comparing capabilities I did not mean one by one, but the totality of those of one runtime vs. those of the others. Not sure how you compare a totality, other than actually having a list and compare them one by one. My feeling: you make a claim, but you have never used one of the Lisp runtimes like Allegro CL and you simply don't know what they provide and when it comes to specific capabilities, they are not important to YOU, because JVM users don't use them - given that they have no choice. The JVM isn't the predominant enterprise platform because it is the best Lisp platform. Very few people in companies care whether it runs Lisp well or not. People have chosen it as their platform for their niche language, because of its domination in the specific enterprise market - not because it is technically or capability-wise a good platform for their niche language. Actually even though the JVM now exists for a long time, none of the dynamic languages have their best / most performant / dominant implementations on the JVM. Not Smalltalk, not Lisp, not Scheme, not Python, not Ruby, ...
- pron 8y ago
  > What relationship have continuations to making Java exceptions resumeable? We don't want resumable exceptions for Java. But if you want to implement a Lisp that has them on the JVM, you'll be able to use continuations for that. > but you have never used one of the Lisp runtimes like Allegro CL and you simply don't know what they provide and when it comes to specific capabilities, they are not important to YOU, because JVM users don't use them - given that they have no choice. I have never used Allegro, and, as I said, some capabilities that are important to some people may be missing on the JVM. But it seems that most Lispers prefer what the JVM has to offer, which is high performance, low-latency GC, low-overhead monitoring, and a huge ecosystem. > not because it is technically or capability-wise a good platform for their niche language. True, but most people don't care about what's good for their language, they care about what's good for their program (and users). It seems like more people prefer Lisp on the JVM, even if they have to give up some features (and they'll need to give up fewer features with Loom). > Not Smalltalk, not Lisp, not Scheme, not Python, not Ruby, ... Python and Ruby are actually most performant on the JVM nowadays. Look up TruffleRuby and GraalPython. They're just very new. Even TruffleJS is almost as good as V8.