Anyone spent time with Kawa Scheme?

[somewhat-functional-programmer]

I've recently come across Kawa Scheme and am very intrigued by it.  It's Java integration is superb like Clojure and it's very fast.  Has anyone here used it to build something?

So far I've only tried it with small toy programs.  Things I like about it:

  - Starts up very quickly

  - Java method notation lends itself to auto-complete

     (instance:method param1 param2)

  - Can pre-compile and use it on Android

  - Repl has line numbers so compilation errors on repl forms have source lines

Maybe Kawa fits into a niche that Clojure leaves open with its heavier runtime?  Maybe I'm just trying toy programs and those toy programs are fast? :-)

One thing that intrigues me here though since java integration is so easy with Kawa is the notion of using Clojure's immutable data structures from Kawa -- maybe even making a clojure "core" library for use from Kawa.

-lc

[André]

Rich has covered some of the motivation of why not extending existing Lisp->Java integrations, like Kawa and ABCL:

https://www.youtube.com/watch?v=cPNkH-7PRTk, around 3:25

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[André]

They maybe relevant too:

https://www.youtube.com/watch?v=2V1FtfBDsLU, around 1h4min

[somewhat-functional-programmer]

Thank you for posting these video links along with the time markers.  I thought I'd enjoyed all of Rich Hickey's presentations before but I actually hadn't seen his "Clojure for Lisp Programmers".  Clojure is the only lisp I "know" (still relatively a beginner) but have been fortunate enough to use full-time for the last few years -- given my Java background, I naturally had started with his "Clojure for Java Programmers".

I did not intend to suggest that Clojure should have been a library to a Scheme or Common Lisp.  I love the language as it is and not having a prior lisp background, absolutely appreciated watching the "Clojure for Lisp Programmers" (as now having some lisp experience, I could more fully appreciate some of Clojure's roots).  I've dabbled with toy programs in both ABCL/SBCL as well as Kawa mostly out of curiosity.

My reasons for asking my questions about other people's use of Kawa is that the performance characteristics of its runtime made me think maybe it may be applicable to some areas where Clojure may be a tougher choice (Android, CLI utilities).  I think Clojure startup time correlates with how many vars defined, and startup time of my projects increases with var counts.  I'm curious if any more thought has gone into this topic on the wiki: https://dev.clojure.org/pages/viewpage.action?pageId=950293.

I can't give up writing software in an immutable/functional style after using Clojure for a couple of years, and was starting to think about what a program using Kawa could look like using Clojure's immutable data structures and STM.

What I've settled into doing for using Clojure for CLI utilities thus far has been to just leave an instance running a socket repl on my machine always running and connect to it via rlwrap and socat (only using it interactively though):

rlwrap <rlwrap options> socat STDIN TCP4:localhost:<repl port>

Anyhow, thanks again for the video link, always a treat to watch a Rich Hickey Clojure talk that I hadn't seen before.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[Gary Trakhman]

If you're looking for fast CLI utilities, ocaml can be a good fit, or grenchman for loading clojure code, in this particular case (written in ocaml): https://github.com/technomancy/grenchman

You don't really need persistent data structures for those use-cases, do you?  But it does have seqs and async pipes (like channels) etc. My employer uses Jane St's core/async libs which bundle all that in a semi-coherent fashion.

Any of those options might be a tradeoff for mindshare and cases covered, but common lisp might also be a good choice.

[Gary Johnson]

If you haven't given it a try yet, Clojurescript is really the goto for a lot of Clojure programmers when it comes to cover the CLI and Android use cases.

Lumo and Planck are awesome Clojurescript runtimes that start up virtually instantaneously and make great choices for writing scripts.

Clojurescript + React Native can create apps for Android, iOS and Windows.

Have fun and happy hacking!
  Gary

[somewhat-functional-programmer]

Appreciate the response -- grench looks like a great way for me to continue to use my always-on repl in actual scripts and not just interactively.  I've lately ironically become more interested in Clojure startup time now than when I started developing with it because I'm starting to accumulate enough valuable snippets of code that I'd love to expose functions here and there from the command line.  What I'd started to move towards was interactively using the Clojure repl as more of a command shell than I'd ever had before (not just as a development support/workflow).  Grench looks perfect for driving things from bash/cron.  Also could be cool to deploy it with server side apps for O&M functionality -- peer into a running web app for instance and print out metrics for instance...

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[somewhat-functional-programmer]

Appreciate the pointer towards Lumo and Planck -- I've tried Lumo though not Planck.  I have used Clojurescript at work (not for scripting but for webapps) and it's been more challenging for me only because I am not as familiar with the Javascript ecosystem as I am the Java ecosystem.

What I've been hoping to do though is leverage a lot of the JVM Clojure code I've written in small CLI utilities.  I find that the library overlap between my Clojure and Clojurescript code in my usage is mainly of the plumbing/infrastructure variety (which is most useful) -- like EDN/transit/Sente/Timbre/Specter rather than the meat of what my apps are actually doing server-side.

As I write this it's dawning on me I could just expose my JVM Clojure code as services and figure out how to use Clojurescript from node.js...  it just sounds so much more complicated to me at the moment than something like the previously mentioned grench or even just interactive repl use (for simply exposing a function that say translates CSV data to something else) (and annoying if I'm trying to specify a local file reference etc). 

I've been fairly content with my own interactive repl use for these things (convert this CSV file etc), but I don't think it translates to non-clojure developers and when I hand over instructions/procedures to folks I work with I'd like to give them something simple they can run from bash etc.  That's really where a lot of the startup costs are killer, you give something with a 10-20 second startup time over to other teams and it only justifies their hatred of the JVM (I'd never tell them it was Clojure then the cat would be out of the bag :-)).

Anyhow I appreciate the response -- thanks!

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[Didier]

I'd recommend you try some of the startup optimizations for the JVM that zprint does: https://github.com/kkinnear/zprint/blob/master/doc/filter.md#we-all-know-that-clojure-startup-is-so-slow-that-this-will-not-work

With it, they've managed to get the Clojure zprint filter to start faster then the equivalent ClojureScript one.

[somewhat-functional-programmer]

Thanks -- I had seen some Clojure startup benchmarks in relation to Java 9: https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html. I did try these on one of my projects that uses a lot of Clojure library deps and I went from ~11 second startup to ~5 (both were AOT/direct linking compiled).

I appreciate the discussion. I think it's helped me think a little more clearly about what my goals/requirements are. I started thinking about why I've chosen to use any JVM language over just plain Java. After all, no JVM language is going to execute faster or have more support behind it than Java itself. I won't enumerate all the reasons writing Java code is more painful than <other language here> code as the reasons are mostly personal per developer, and I'm guessing that most people here in this particular forum have already come to the same conclusion.

I'd love to know why people here have chosen Clojure. Everyone chooses it for persistent data structures and functional programming, as Clojure essentially forces you to use them. I've found structuring my code that way seems less prone to bugs and more reusable and compose-able. However, with Java now having lambda functions it's possible to get *some* of the same advantages there.

For me the selling point of Clojure was the learning a lisp. My motivation for wanting to learn a lisp, and the fact that Clojure was so perfectly practical I could potentially use it professionally (JVM!) started me down the path. Where I hoped I would end up is leveraging macros. I've always done a lot of code generation in my Java projects... from things like using templating languages to generate java source files to using annotations to generate additional java code at compile time. What I've found with Clojure and macros is -- it's sooooo much easier to do those same things. I know there's a huge emphasis in the Clojure community (and maybe all lisps) of not over-using macros... and I'm not disagreeing with that. But to me that's the heart of why I would ever use a lisp.

So finally full circle (back to Kawa)... *my* primary benefit of Clojure could be summarized as "JVM + Macros" (which to me is orthogonal to the immutable/functional benefit - as it is possible to program this way in other languages, and I'd argue writing in Clojure/<another JVM language> usually limits projects to small teams of experts and on those types of teams it would be possible to be disciplined enough to do so in a language that doesn't force it). Kawa has "JVM + Macros" (though at the moment I find scheme macros much less approachable than CL or Clojure macros). It also has different development trade-offs, but the things I like:
- Little to no overhead over plain Java
- I think this would make it sell-able in the enterprise world for *libraries* or *part* of a project. Could a couple of experts using Kawa replace a lot of the code I used to generate in far more awful ways than macros (templates or annotation processors)? If Kawa easily compiles to Java and has good code completion (i.e., not IFn passing Objects but actual static method definitions with types)... I bet "regular" Java-based software projects wouldn't mind consuming libraries written in Kawa. And if there wasn't a 10-20 second startup penalty for using the library... (even though I know, in "situated" programs this really doesn't matter at all -- but it does from a language adoption standpoint. I think I couldn't convince a project to let me write a library in Clojure if it took 20 seconds to load the library).
- Still has macros and sexps
- I prefer Clojure's syntax to scheme (maybe just because I'm used to it). But it's really the same argument people have against using Clojure (parenthesis :-)). Other low overhead JVM languages like Scala don't have macros.
- I could still use Clojure's data structures and even STM from Kawa
- Clojure's runtime is very approachable and a beautiful piece of software (I don't even mind the Java source formatting -- reminds of C# actually -- why indent *everything* when the language says you must have a top level "form" (namespace in C# / class in Java? :-)). Using its data structures and even STM would be very straightforward.

My motivations in writing here is to get people's feedback about using Kawa / other lisps when their main motivation is to stay in the JVM ecosystem. I'd love to see both Kawa and Clojure be so easy to intertwine into a larger Java project that they could be used even within large enterprise-y Java projects (for some portion of the project). My interest in that is mostly personal :-). I think using them in this manner would be a real benefit to both those projects and to developers on them. That's what gets me excited about Kawa -- I think I maybe I could sell it's use as a library in a large corporate project simply because there's no runtime overhead.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On April 5, 2018 4:00 AM, Didier <did...@gmail.com> wrote:

> I'd recommend you try some of the startup optimizations for the JVM that zprint does: https://github.com/kkinnear/zprint/blob/master/doc/filter.md#we-all-know-that-clojure-startup-is-so-slow-that-this-will-not-work
>
> With it, they've managed to get the Clojure zprint filter to start faster then the equivalent ClojureScript one.
>
>

> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

>
> You received this message because you are subscribed to the Google
>
> Groups "Clojure" group.
>
> To post to this group, send email to clo...@googlegroups.com
>
> Note that posts from new members are moderated - please be patient with your first post.
>
> To unsubscribe from this group, send email to
>
> clojure+u...@googlegroups.com
>
> For more options, visit this group at
>
> http://groups.google.com/group/clojure?hl=en
>
>

> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[Didier]

Haven't tried Kawa, and my only other Lisp experience is Emacs Lisp.

That said, I think Clojure as a Lisp differentiate itself from other Lisps in that all its data-structures are built on abstractions. They default to be immutable in a performant and low memory profile way. Its got great added concurrency constructs like STM, CSP, Atom, Futures, Promises, Delays, etc. Its syntax includes very convenient default data-literals that has contributed to it having a culture of data-driven logic. EDN is great for serialization of code and data. It has powerful support for lazy evaluation, as well as strict. Finally, its interop with Java is excellent.

So, I don't know much about scheme and Kawa, but I suspect you'd have to build a lot to get all this back.