Common Lisp stack traces tend to be no better, anyway, at least with SBCL and CCL. Up to 90% of a trace you see in the inspector can be compiler/runtime infrastructure. Given that macros don't show up, only their expansions, the backtrace can be full of stuff like SB-KERNEL:%FUNCTION-THAT-I-DONT-RECOGNIZE-BUT-MACROEXPANDED-FROM-SOMETHING-I-KNOW.
Like in Java, most of the time the top few lines are the ones related to your code, but just like in Java, there are exceptions, in which the source of the problem ends up in the middle of the backtrace, surrounded by infrastructure frames.
The SecurityManager is an example of ambient authority, exactly the kind of design that the article is criticizing.
There's at most one SecurityManager per application, meaning you can't in general use it for fine-grained confinement. It's only "granular" in the sense that requested permissions can be arbitrarily finely subdivided. There's no notion of intra-application invocation contexts, making it vulnerable to "confused deputy" problems, including things like the event-stream incident.
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.
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.
> Of course you cannot change the JDBC connector after it was compiled!
no, but you can add, dynamically at run time (such as from a user supplied file) a new implementation of the interface. And because as part of the JDBC interface, a connector is able to register itself too (via classloading magic).
JDBC is just an example of a common plugin architecture for extensible software. But perhaps one way to make this work with AOT is to bring along the AOT compiler, and AOT the connector jar when it is being loaded, and treat that binary same as any dynamically linked library!
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.
> What I'm saying is that it breaks when you do a Class.forName(...),
but you don't do this. you register the classes according to what is on your file system and you load one that matches your criterions or you ask your user to choose one in a UI of some kind.
What people are talking about is different. It's when the app genuinely loads plugins that weren't available at compile time, or generates bytecode on the fly.
> So you have no excuses not to build your CLI tools in Clojure now.
Well I do disagree with this part, see other sibling comments (not by me). I'm not even sure GraalVM is really production-ready, notwithstanding the potential licensing and long-term issues.
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.
What licensing issues do you have in mind. Graal and SubstrateVM are all GPL-with-classpath-exception licensed, same as Java itself. It's an open source license.
