Re: Kawa experience [was: the right way to compile and load modules]

[mikel evins <mevins at me dot com>]

On May 14, 2014, at 1:59 PM, Per Bothner <per@bothner.com> wrote:

> On 05/13/2014 11:51 PM, mikel evins wrote:
>> Have I mentioned lately how great Kawa is?
> 
> No - but we're always happy to hear it!
> 
> Please tell your friends and co-workers and on blogs.
> Kawa's biggest problem is lack of word-of-mouth and mind-share.
> 
>> I've used it before  though it's been some years.
>> I picked it again for this project  after a short period of trying
>> it alongside ABCL and Clojure. I like  Common Lisp just fine, and
>> I like Clojure too, but Kawa was just easier
>> to work with and faster. I'm particularly impressed by its quick launch
>> times compared to other JVM tools.
> 
> Interesting.  I'm aware that Kawa generally runs quite a bit faster than
> other "scripting" languages (especially with suitable type specifiers),
> but I haven't really thought about it having faster startup. Can you share
> a bit about which tools are (or seem) fast or slow in your experience?

Cold start to kawa prompt is something like a quarter of a second on my machine. For a Clojure prompt it's eight to twelve times longer. For ABCL it's around twice the Clojure startup time.

Those startup times carry over to my built app. Cold start to first window on the screen is under a second for Kawa, and longer in rough proportion to the above numbers for Clojure and ABCL.

Kawa's launch is so fast that it's a kind of camouflage. Everyone knows that Java apps start up slowly, so our app, built with Kawa, appears superficially to be a non-Java app.

That doesn't mean Kawa is faster overall than Clojure and ABCL. I didn't do benchmarks and I don't plan to. All I can say is that it seems noticeably faster executing many tasks in our app (an immersive 3D multiplayer networked game). 

> Also, what makes Kawa "easier to work with"?
> 
> I'll be writing an "intro to Kawa" article for LWN soon,
> so it is useful to know what to emphasize.

It's simpler and easier to get started using Kawa. Kawa is one jar plus whatever JVM-related tools you want to use. You just run it and write Scheme code. You can add Jave-related features incrementally as you reach the point where you need them.

Using ABCL with Java libraries most likely means organizing your project as a regular Java project that happens to include ABCL as a JSR-223 scripting component. You don't *have* to do that, but if you're going to be using Java libraries, that's probably the easiest way to do it. If those Java libraries want you to write Java classes in order to integrate them, as libraries often do, then you're pretty much going to have to do things that way, because ABCL doesn't know how to implement novel Java classes, so you're going to have to drop into Java to do it.

That's not my preferred solution. I want to use some Java libraries in my Lisp program. I don't want to use Lisp scripting in a Java program.

Clojure isn't just a jar, it's a whole tools ecosystem. It's *possible* to use the main clojure jar alone, but that's masochism. You really want to start with Leiningen and its config files and all the various tools and libraries it will download and set up, and its idea of what a Clojure project looks like, because that's the de facto standard Clojure project. The tools are good and helpful, and they do a lot for you, especially if you're working on enterprise software, which is where Clojure's bread and butter is. But it's a lot of stuff to learn about, download, and configure before you ever reach the Clojure prompt.

The hole in ABCL's java interop means it's not as easy to work with Java libraries. Its interop is fine, if slightly more verbose than Kawa's, but besides the lack of class definition, it's also complicated a little in that there are actually two different Java interop layers. One is more verbose, but more mature and better integrated. The other is more terse and more convenient, but also less mature and less well-integrated, so that you end up deciding on a case-by-case basis whether to use one interop layer or the other. That's not a deal killer; it's just a little gratuitous complexity, especially since the interop between the two different interops is not perfectly transparent.

Clojure's Java interop is comprehensive and mature and it works very very well. It is intrinsically a little more complicated than Kawa's simply because Clojure is a primarily functional language that disdains side effects without completely forbidding them. Java, of course, is not like that, so you have to take some extra care whenever the two languages talk to each other that one isn't violating invariants assumed by the other. 

Also, Clojure's been evolving a novel type system lately, and there are pieces and scaffolding of that type system lying around in the language. Since those pieces and scaffolding more often than not involve some sort of interaction with the JVM and Java types, they constitute something of a distraction. You have to learn which features are actually meant to be used for Java interop and which are artifacts of the evolving type system. You have to learn where you really want to use the new types and where you really want to use Java interop.

If I sound like I dislike Clojure or ABCL, that's unintentional. In fact I like them both and would use either of them with pleasure in any case where they seem to be the best option. Clojure is broadly successful and a nice piece of work. ABCL has reached a remarkable level of compliance with the ANSI Common Lisp standard, and steadily keeps getting better.

But for my uses, Kawa is clearly the best choice. It's smaller, faster to launch, easier to integrate with our app, and it imposes fewer arbitrary requirements on us in using it.

What's not to like?