3 ms·

Why? I have no particular feelings for or against the JVM. It always surprises me when people get so passionate about runtimes - how much do you interact with

Why? I have no particular feelings for or against the JVM. It always surprises me when people get so passionate about runtimes - how much do you interact with them? They're just in the background doing their thing. I can see reasons for not wanting to use the JVM in specific cases. For example, it may not have the performance you want for the application you're developing. I'm just confounded by general statements such as "JVM = no go", "I want to use C# but I'm more of a JVM guy than dotnet" (or vice versa). Is this some bizarre nu-console war that's going on in the programming community that I have missed?

dgan 4y ago
Why => because JVM is poor no fit for CLI, and is a poor fit for games. Those two fields in which I see myself using common-lisp. Unsure what's so wierd about it, everyone (most) knows about slow cold startup times, and inability to control memory layout in JVM. Also, horrible C bindings
- crapaud23 4y ago
  For me it's microcontrollers, however I've heard in spite of the unmaintained status, clojure-scheme[1] is very usable. It uses gambit to produce C-code you can compile anywhere. https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme
- yoyohello13 4y ago
  I'm with you on stock JVM. The slow startup time is often a deal breaker for me. But there are projects that address this. Like https://github.com/babashka/babashka https://github.com/babashka/babashka for Clojure. Or GraalVM for general JVM use.
- richard_todd 4y ago
  How do you control memory layout in Common Lisp?
- iainctduncan 4y ago
  you might be interested in embedded Schemes. I use s7, which shares a lot of features with both CL and Clojure (for a Scheme) and is very easy to embed in C or C++ apps. I use it for music coding, but others (e.g. Naughty Dog) have done it for games. It's a super fun way to develop. My high level code is mostly Scheme, interfacing with low level C.
- itsautomatisch 4y ago
  I don't see how the JVM is a "poor fit for games" when it's entirely contextual towards the goals of the game itself. Garbage collection also does not automatically disqualify an environment from games development, and there are plenty of games made in garbage-collected languages out there by both hobbyists and professionals using frameworks like LibGDX and Monogame/FNA/XNA. Depending on the kind of game, sure, the JVM might not be the right choice (or a choice at all), but for most people they likely will be too busy trying to actually finish the game instead of tuning for performance.
JonChesterfield 4y ago
> Why? I have no particular feelings for or against the JVM. It always surprises me when people get so passionate about runtimes - how much do you interact with them? They're just in the background doing their thing. I spent a day writing Clojure after watching a bunch of talks about it. Very keen on persistent data structures. Every time I put a foot wrong it printed a Java stack trace for me, which was very large but told me nothing. I then went looking for the optimiser and discovered there wasn't one, it just falls through into the JVM JIT and hopes for the best. And finally it turned out a bunch of Clojure libraries were reskinned Java, and therefore likely to have the stereotypical properties of Java code. So that all seems directly attributable to the runtime. Clojure the language is totally my sort of thing but that was such a horrendous experience that I haven't picked it up again in... what turns out to be seven years (found my stack overflow question about it).

dgan 4y ago

Why => because JVM is poor no fit for CLI, and is a poor fit for games. Those two fields in which I see myself using common-lisp. Unsure what's so wierd about it, everyone (most) knows about slow cold startup times, and inability to control memory layout in JVM. Also, horrible C bindings

crapaud23 4y ago
For me it's microcontrollers, however I've heard in spite of the unmaintained status, clojure-scheme[1] is very usable. It uses gambit to produce C-code you can compile anywhere. https://github.com/takeoutweight/clojure-scheme https://github.com/takeoutweight/clojure-scheme
yoyohello13 4y ago
I'm with you on stock JVM. The slow startup time is often a deal breaker for me. But there are projects that address this. Like https://github.com/babashka/babashka https://github.com/babashka/babashka for Clojure. Or GraalVM for general JVM use.
richard_todd 4y ago
How do you control memory layout in Common Lisp?
iainctduncan 4y ago
you might be interested in embedded Schemes. I use s7, which shares a lot of features with both CL and Clojure (for a Scheme) and is very easy to embed in C or C++ apps. I use it for music coding, but others (e.g. Naughty Dog) have done it for games. It's a super fun way to develop. My high level code is mostly Scheme, interfacing with low level C.
itsautomatisch 4y ago
I don't see how the JVM is a "poor fit for games" when it's entirely contextual towards the goals of the game itself. Garbage collection also does not automatically disqualify an environment from games development, and there are plenty of games made in garbage-collected languages out there by both hobbyists and professionals using frameworks like LibGDX and Monogame/FNA/XNA. Depending on the kind of game, sure, the JVM might not be the right choice (or a choice at all), but for most people they likely will be too busy trying to actually finish the game instead of tuning for performance.

JonChesterfield 4y ago

> Why? I have no particular feelings for or against the JVM. It always surprises me when people get so passionate about runtimes - how much do you interact with them? They're just in the background doing their thing. I spent a day writing Clojure after watching a bunch of talks about it. Very keen on persistent data structures. Every time I put a foot wrong it printed a Java stack trace for me, which was very large but told me nothing. I then went looking for the optimiser and discovered there wasn't one, it just falls through into the JVM JIT and hopes for the best. And finally it turned out a bunch of Clojure libraries were reskinned Java, and therefore likely to have the stereotypical properties of Java code. So that all seems directly attributable to the runtime. Clojure the language is totally my sort of thing but that was such a horrendous experience that I haven't picked it up again in... what turns out to be seven years (found my stack overflow question about it).