I just found a very interesting #CommonLisp project which shows how to extend the LOOP macro: https://github.com/Gleefre/loop-continue

It was added to Ultralisp.org recently.

This code should work on #SBCL, #CLASP, #ALLEGRO, #ABCL and #ECL implementations.

@Elizafox Alternatively, one can use #ABCL for #CommonLisp or #Kawa for #Scheme when performance is critical (at the cost of CL's niceties).

#KawaScheme

@scdollins Java #Processing works well inside #abcl #CommonLisp if you're into that. Cool generative art.

@maegul Interop being desirable wouldn't be much of a good reason, there's #ABCL and several other FFI libraries for JVM interaction.

An abstraction library dynamically papering over the differences based on what's available at runtime would've been perfectly feasible.

I honestly think the main reason was NIH.

@rq I'd say, consider #CommonLisp?

There are serialization libraries for object persistence and you can use #FFI to other language runtimes like #CLR or #JVM (if you don't feel like just using #ABCL directly).

@Reiddragon @ezio It's part of why I'd say #ABCL or #Kawa should be the canonical #JVM language.

So much of the boilerplate problem that people complain about in #Java would literally be 5 minutes of writing macros if the language wasn't so ill-designed (and pretty much purposely inextensible).

#CommonLisp #Lisp #Scheme

@natty That list comprises a large part of why I dislike #Java as a language.

Basically all of those features can be trivially added in #JVM #Lisp languages like #KawaScheme and #ABCL.

Having to wait years for the devs to do something useful and so basic is just silly.

@starshine
Pretty much always did. And even for #CSP (the main #Golang attraction), there were a few libraries in Java proper for it too (nevermind #Clojure).

#Scheme