URI:
        _______               __                   _______
       |   |   |.---.-..----.|  |--..-----..----. |    |  |.-----..--.--.--..-----.
       |       ||  _  ||  __||    < |  -__||   _| |       ||  -__||  |  |  ||__ --|
       |___|___||___._||____||__|__||_____||__|   |__|____||_____||________||_____|
                                                             on Gopher (inofficial)
  HTML Visit Hacker News on the Web
       
       
       COMMENT PAGE FOR:
  HTML   Cl-kawa: Scheme on Java on Common Lisp
       
       
        Per_Bothner wrote 8 hours 19 min ago:
        What a blast from the past! I too remember with pleasure the days
        working with Anthony Green (and others) at Cygnus. I like to boast that
        (apart from Java) Kawa Scheme is the oldest compiler-based language
        implementation still available for the JVM.
       
        mark_l_watson wrote 23 hours 51 min ago:
        Github user atgreen has a large number of really interesting Common
        Lisp projects: [1] I am a fan.
        
  HTML  [1]: https://github.com/atgreen
       
          shawn_w wrote 20 hours 59 min ago:
          The newer ones are mostly vibecoded if that matters to you.
       
        stared wrote 1 day ago:
        I had to check if the creator is Polish, as "ciekawa" means
        "interesting". But apparently, just a coincidence.
       
          tmtvl wrote 22 hours 17 min ago:
          Well, GNU Kawa is named after the Polish word for coffee (going with
          a play on Java rather than a play on Scheme like Guile and Larceny
          EDIT: and Gambit went with).
       
          cloudbonsai wrote 23 hours 56 min ago:
          Coincidentally, Chi-kawa is a very popular anime character in Japan.
          [1] It's a portmanteau of "Chiisai" (small) and "Kawaii" (cute).
          
  HTML    [1]: https://en.wikipedia.org/wiki/Chiikawa
       
        varjag wrote 1 day ago:
        Perhaps someone could port Arc to Kawa! Then the whole contraption
        could run HN on SBCL in a roundabout way.
       
        atgreen wrote 1 day ago:
        Here's something I wrote about this work:
        
  HTML  [1]: https://atgreen.github.io/repl-yell/posts/cl-kawa/
       
        atgreen wrote 1 day ago:
        If you are interested in this, you might also be interested to learn
        that I also got clojure running on SBCL via OpenLDK.  See [1] .
        
        Regarding LLM-usage, the bulk of OpenLDK was written without the use of
        LLMs. But recently I let Claude loose on the code to fix a few
        remaining problems blocking kawa.  Claude also upleveled the Java
        support from Java 8 to Java 21.
        
        I wrote a couple of blog entries related to this work that might be of
        interest.  One was around how I had to use the MOP to optimize method
        dispatch in CLOS for clojure:
        
  HTML  [1]: https://github.com/atgreen/cl-clojure
  HTML  [2]: https://atgreen.github.io/repl-yell/posts/clos-mop-dispatch/
       
        anthk wrote 1 day ago:
        On OpenLDK, if it's able to run something like SweetHome3D at usable
        speeds I would consider it a success and an interesting exercise.
       
        rhkalth wrote 1 day ago:
        And? Do you want a medal for plagiarizing other people's work?
       
          klez wrote 21 hours 25 min ago:
          I'll bite. What have they plagiarized?
       
        nxobject wrote 1 day ago:
        The OpenLDK is very interesting - it looks like it “compiles” to
        the vintage procedural dialect within CL (eg TAGBODY etc.) I wonder if
        someone’s ever bypassed the “procedural Lisp” level and just used
        a CL implementation’s internal assembler interactively, though. (IIRC
        both SBCL and CCL expose theirs.)
       
          stassats wrote 23 hours 3 min ago:
          I did that to write simd routines for sbcl: [1] Probably the best way
          of writing assembly, can evaluate the function immediately, use
          macros and any other code to emit instructions, even can print
          register values (instruction-level stepping would be even better, but
          too much work).
          
  HTML    [1]: https://github.com/sbcl/sbcl/blob/master/src/code/arm64-simd...
       
          varjag wrote 1 day ago:
          TAGBODY/GO are broadly used in advanced Lisp macros. If you expand a
          non-trivial extended LOOP invocation you'd likely see some.
          
          If you compile to an implemenation's assembler (even where that
          possible) you don't really compile into Lisp anymore. And really the
          Lisp compiler is going to do a better job at generating machine code.
       
        zombot wrote 1 day ago:
        I haven't tried it, but the description sounds delightfully perverse.
        And an LLM (Claude) cannot be embarrassed by perverting Lisp/Scheme
        with Java.
       
          brazzy wrote 1 day ago:
          JVM, not Java. And there's Clojure already in that space.
       
            Per_Bothner wrote 3 hours 37 min ago:
            Kawa predates Clojure by a decade. (Kawa work started 1996;
            Clojure's initial release was 2007.) Also, Clojure isn't really
            focused on high performance, while that has always been a priority
            for Kawa, which generates bytecode similar to Java, especially if
            you include suitable type annotations. (It is likely Clojure have
            have improved in this respect - they have a lot more people working
            on it.)
       
            zombot wrote 4 hours 31 min ago:
            Agreed, "Java" was an oversimplification. It's actually JVM
            bytecode. It's still strange in my book to use an object soup
            runtime for something (Lisp/Scheme) that feels closer to functional
            languages to me.
            
            Clojure is a different case, because when you already are on the
            JVM anyway, then Clojure is still infinitely better than no Lisp at
            all. It's not the same as putting the JVM somewhere where it wasn't
            before and where it's not actually needed.
       
              brazzy wrote 2 hours 7 min ago:
              A serious Lisp/Scheme runtime needs a garbage collector. The JVM
              has probably the most advanced GC implementation around - for
              that reason alone it doesn't seem particularly strange to me.
       
              atgreen wrote 2 hours 9 min ago:
              It's like Dr Ian Malcolm says.. "Your developers were so
              preoccupied with whether or not they could, they didn't stop to
              think if they should" - Jurrasic Park (almost)
       
          anthk wrote 1 day ago:
          The Computer Abstractions book/course for Scheme had some kind of VM
          written in Java where you had to write an assembler in Scheme as the
          final 'biggie' project.
       
          pjmlp wrote 1 day ago:
          Why should it?
          
          "We were after the C++ programmers.  We managed to drag a lot of them
          about halfway to Lisp."  -- Guy Steele
       
            anthk wrote 1 day ago:
            RMS itself being a diehard Scheme and Elisp user said that he found
            Java elegant over C. This was OFC long before Go and when C++ was
            king in the 90's.
            
            On Java itself, when CLOS, a dog-ancient system for Common Lisp
            it's enough to support the Java class/method/object system by
            itself tells a lot on how great CL can be, even with SBCL which is
            the top tier free (as in freedom) interpreter/compiler out there.
            
            On performance, well, who knows; remember that PyPy itself back in
            the day was written in Python itself and it ran things much faster
            than the vanilla Python interpreter.
       
       
   DIR <- back to front page