Re: Anyone spent time with Kawa Scheme?

2018-04-11 Thread 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.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Anyone spent time with Kawa Scheme?

2018-04-07 Thread 'somewhat-functional-programmer' via Clojure
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  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 
so 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/ 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, 

Re: Anyone spent time with Kawa Scheme?

2018-04-04 Thread 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. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Anyone spent time with Kawa Scheme?

2018-04-04 Thread 'somewhat-functional-programmer' via Clojure
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 ‐‐‐
On April 4, 2018 5:48 PM, Gary Johnson  wrote:

> 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
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Anyone spent time with Kawa Scheme?

2018-04-04 Thread 'somewhat-functional-programmer' via Clojure
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 
functionality -- peer into a running web app for instance and print out metrics 
for instance...

‐‐‐ Original Message ‐‐‐
On April 4, 2018 10:43 AM, Gary Trakhman  wrote:

> 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.
>
> On Wed, Apr 4, 2018 at 12:35 AM 'somewhat-functional-programmer' via Clojure 
>  wrote:
>
>> 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  socat STDIN TCP4:localhost:
>>
>> 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 ‐‐‐
>> On April 4, 2018 3:23 AM, 'André' via Clojure  
>> wrote:
>>
>>> They maybe relevant too:
>>>
>>> https://www.youtube.com/watch?v=2V1FtfBDsLU, around 1h4min
>>>
>>> On 04/03/2018 05:29 PM, 'André' via Clojure wrote:
>>>
 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

 On 04/02/2018 05:53 PM, 'somewhat-functional-programmer' via Clojure wrote:

> 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 

Re: Anyone spent time with Kawa Scheme?

2018-04-04 Thread 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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Anyone spent time with Kawa Scheme?

2018-04-04 Thread 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.

On Wed, Apr 4, 2018 at 12:35 AM 'somewhat-functional-programmer' via
Clojure  wrote:

> 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  socat STDIN TCP4:localhost:
>
> 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 ‐‐‐
> On April 4, 2018 3:23 AM, 'André' via Clojure 
> wrote:
>
> They maybe relevant too:
>
> https://www.youtube.com/watch?v=2V1FtfBDsLU, around 1h4min
>
> On 04/03/2018 05:29 PM, 'André' via Clojure wrote:
>
> 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
>
>
> On 04/02/2018 05:53 PM, 'somewhat-functional-programmer' via Clojure wrote:
>
> 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
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, 

Re: Anyone spent time with Kawa Scheme?

2018-04-03 Thread 'somewhat-functional-programmer' via Clojure
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  socat STDIN TCP4:localhost:

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 ‐‐‐
On April 4, 2018 3:23 AM, 'André' via Clojure  wrote:

> They maybe relevant too:
>
> https://www.youtube.com/watch?v=2V1FtfBDsLU, around 1h4min
>
> On 04/03/2018 05:29 PM, 'André' via Clojure wrote:
>
>> 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
>>
>> On 04/02/2018 05:53 PM, 'somewhat-functional-programmer' via Clojure wrote:
>>
>>> 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
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --

Re: Anyone spent time with Kawa Scheme?

2018-04-03 Thread 'André' via Clojure
They maybe relevant too:

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


On 04/03/2018 05:29 PM, 'André' via Clojure wrote:
>
> 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
>
>
> On 04/02/2018 05:53 PM, 'somewhat-functional-programmer' via Clojure
> wrote:
>> 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
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Anyone spent time with Kawa Scheme?

2018-04-03 Thread 'André' via Clojure
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


On 04/02/2018 05:53 PM, 'somewhat-functional-programmer' via Clojure wrote:
> 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
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.