@ashfurrow Yes, it is. And then these other JVM-targeting languages have to build their own API, via which they show, that they hadn't planned for that, and just wind up making a big mess.
It's like how creating a new language is fun. But the ecosystem around it, to male that language practical to use? That's hard work.
@aeveltstra gotcha, that makes sense. Do you think this is why we (I) hear more success stories with languages compiling to the .Net CLR than compiling to the JVM? Because it was designed to be agnostic to languages from the start? (Not that it doesn't have to be hacky about adding support for new constructs, too.)
@ashfurrow I have on-hands experience with several .Net languages. Yes: the CLR does not appear to suffer the exact same issues. It suffers whole other ones.
Inside Powershell for instance, we can mix paradigms in the same script: functional, o.o., procedural, and maybe event-driven too (legacy VB was event-driven and moved from procedural to o.o. over time) - 1/2
But depending of the version of your script engine and the source version of an invoked library, Powershell may force us to employ a different, unwanted paradigm. And apart from finding a different library to invoke, there's literally nothing we can do.
That is not Powershell's fault, as far as I could determine, but the CLR. - 2/2
@aeveltstra interesting – I hadn't realized the different paradigms targeting the same runtime would add such complexity!
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!