good morning to #eggboy [cw ec]
good morning #wednesdaywisdom
@ashfurrow The language is simple enough. The ecosystem and API ("standard library") are pure insanity.
Every so often a new solution comes along that has everyone jump on a bandwagon and sing hallelujah! But it hides the fact that at its base language design level, java makes O.O.P. really, really hard and cumbersome.
@aeveltstra that's an interesting perspective. If I may ask, isn't that the goal of the JVM as a compile target? So that languages like Scala and Clojure can take advantage of Java's popularity without having to use the actual syntax?
(Not that Scala isn't a difficult language, too!)
@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!
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!