News for hackers. Stuff that matters.

zebraman

Re:Scripting in Common Lisp on Thursday January 31, 2019 @06:20AM (#19043992)
Using modern Clojure's clj is so much easier than the CL procedure.
Re:POLA Would Have Prevented the Event-Stream Incident on Tuesday December 04, 2018 @06:44AM (#18598526)
"This isn’t the case in a language like Java, where access to the outside world is mixed in with other functionality."

That's why there is a SecurityManager: https://docs.oracle.com/javase/tutorial/essential/environmen... that - if anything - is extremely granular.

Re:Perl 11 on Wednesday October 24, 2018 @01:38AM (#18289970)
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.
Re:Perl 11 on Wednesday October 24, 2018 @12:57AM (#18289823)
> 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.

Re:Native Clojure with GraalVM on Tuesday September 18, 2018 @05:44AM (#18013826)
Reflection is partially emulated, IIRC.
Re:Native Clojure with GraalVM on Tuesday September 18, 2018 @05:43AM (#18013821)
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.
Re:Native Clojure with GraalVM on Tuesday September 18, 2018 @05:40AM (#18013807)
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.

Re:Native Clojure with GraalVM on Tuesday September 18, 2018 @05:32AM (#18013765)
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.

Re:Native Clojure with GraalVM on Tuesday September 18, 2018 @05:08AM (#18013656)
For command-line applications, it opens up an interesting space. There was a post on HN a while ago: https://www.astrecipes.net/blog/2018/07/20/cmd-line-apps-wit... though the system requirements for compilation are at the moment very onerous.