3 ms·
I'd argue it still could be true. The CLR has variants of a lot of those too, but they are much less popular. All those alternative languages for the JVM probab
by jdc0589 9y ago
I'd argue it still could be true. The CLR has variants of a lot of those too, but they are much less popular. All those alternative languages for the JVM probably still would have been born at some point even if Java adapted faster, but they are as popular as they are due to Java's slow adaptation.
This isn't a very good argument, but name recognition is on totally different level with alternative JVM languages too. Most people have heard of Groovy even if they don't use it. Boo on the other hand...?
- vorg 9y agoBeanshell came before Apache Groovy and had many dynamic features useful in scripting for the JVM. Groovy essential copied many of those Beanshell features, then added closures, which was Groovy's real contribution to the JVM ecosystem. Soon after there was some disagreement among its leaders over the syntax when closures are used as Kotlin-style builders.
- jdc0589 9y agoHuh, I did't know there was lineage there. Coincidentally, I've actually used Beanshell; integrating it in to a project was a SUPER pleasant experience. It was some weird find/replace thing I contrived in college to let you do weird crap like define a bunch named regexes and use them to match and transform stuff. Contrived example that chops the "L" off long literals in files with the (optional) beanshell integration: integer { -?[0-9]+ } really_bad_long_chopper { <integer>L } -> { String original = match.group(0); return original.substring(0, original.length() -1); }