Not sure if it is me, but for a long time I have kept away from anything perl of moderate complexity. Package management used to be atrocious - it would be slow, pull a ton of modules, compile them with the C toolchain, break for missing dependencies and leave you wondering where the log was. Maybe it's better now. But I wonder why on earth interpreted languages need mandatory C bindings.
> I hope that some derivative of perl can rise from the ashes, because I'm too stupid to write actual lisp programs, but perl allows me to emulate what I imagine lisp programmers must feel.
Well, there is Clojure. You can script it with `clj` and https://github.com/l3nz/cli-matic, and/or one of the ClojureScript interpreters. It has sane library management, so there is no PITA installing anything. You have JVM libraries, so you have all you need. We find it pretty handy.
What I'm saying is that it breaks when you do a Class.forName(...), while if such class is known to exist at compile time, it is the same as a switch statement on the class name that returns a new object of the same type; and that second form would be a valid operation.
Personally, I wonder why class-loading is not possible. In the end either a class exists in the closed-world that existed when the project was compiled, or it does not. Of course you cannot change the JDBC connector after it was compiled!
Maybe they could add a whitelist of "known" entry-points for class loading, as to avoid going through a list of 10,000 inner classes that existed at compile time but nobody will ever instance by name.
We are starting to do that, and for very simple operations, it works (like scripts for maintenance that we deploy remotely, and run as cron jobs). So far no big surprises, but we were very careful.
The big minefield is that you do not really know which libraries will go boom and where, as any place could make use of class loading.