JWM VS Petalisp

sigh

Yeah. I am very bullish on Kotlin. Think it's probably the most exciting language evolving right now.

I went on a few-tweet minirant here about why:

https://twitter.com/GavinRayDev/status/1443279425311805440

But the tl;dr is that:

- There is Jetpack Compose currently, for Desktop, Web, and Android

- And Kotlin Native putting a large portion of resources into Skia bindings (JetBrains calls the lib "Skiko" for Kotlin Native https://github.com/JetBrains/skiko and "Skija")

It's very clear (and there are some employees which have confirmed this IIRC) that they are working on "Jetpack Compose Everywhere" that runs on iOS as well, from a single codebase.

There's the big Kotlin event going on right now, where they just announced the new WASM backend and changes in their compiler + IR commonizing/restructuring ("K2").

- https://blog.jetbrains.com/kotlin/2021/10/the-road-to-the-k2...

- https://www.youtube.com/watch?v=-pqz9sKXatw

The net result is that you wind up with a single language that you can use to write your backend API, your UI code (Jetpack Compose app deployed across Web/Android/iOS/Mac/Win/Linux, or transpile to JS/TS if you just want a web app, etc) and with Kotlin Native even your native, low-level code to integrate with existing C/C++ etc ecosystem.

KN already does automatic bindgen for C and Swift headers, they have direct C++ interop (like Swift does) on their future roadmap as a potential "todo".

All of this is mostly possible already -- I can do the same thing using IE Java, GraalVM, and a transpiler like Google's j2cl or bck2brwser (which is what Gluon uses for JavaFX on the web). Including the "native" part.

IE, here's a contribution I made to get GraalVM producing native binaries using Skia from the JVM + JNI Jetbrains Skia library:

https://github.com/HumbleUI/JWM/issues/158

But Kotlin is pushing the hardest to make this whole platform/stack from native <-> desktop <-> mobile <-> browser a seamless, unified experience. And you can feel it, when you try to do the "whole stack, every platform, one language" thing.

Sorry for the rant and wall of text!

While not "as fast as C" (C is not the absolute pinnacle of performance), Common Lisp is incredibly fast compared to the majority of programming languages around today. There is even a huge amount of ongoing work being done to make it faster still. We are seeing many interesting projects that make better use of the hardware in your computer (e.g. https://github.com/marcoheisig/Petalisp).

i think lisp-stat library is actually being developed. however one numerical cl library that doesnt get enough mention and is being constantly developed is petalisp for HPC

https://github.com/marcoheisig/Petalisp

However, if you have a lisp library that puts those semantics to use, then you could get it to employ magicl/ext-blas and cl-bmas to speed it up. (petalisp looks relevant, but I lack the background to compare it with APL.)

> his means cl pagckages can be "done".

this is true if there is nothing functional that can be added to a package. however its very much not true for ml frameworks right now. new things are being added all the time in the field. however even in the package i linked you have the necessary ingredients for any deep learning model: cuda and back propagation. the other person mentioned convolution which i think is pretty trivial to implement but still, if you expect everything for you to be ready made then you should probably stick to tf and pytorch. if you want to explore the cutting edge and push the boundaries then i think common lisp is a good tool. as an aside it might also be interesting to note that a common lisp package (Petalisp) is being used for high performance computing by a german university

https://github.com/marcoheisig/Petalisp

One trick is that Common Lisp can generate and compile code at runtime, whereas static languages typically do not have a compiler available at runtime. This lets you make your own lazy person's JIT/staged compiler, which is useful if some part of the problem is not known at compile-time. Such an approach has been used at least for array munging, type munging and regular expression munging.