6 ms·

Seems like a cool project if you already know Clojure and hate the start up time, but also seems like it sidesteps one of the main benefits of Clojure which is

by gleenn 9y ago

Seems like a cool project if you already know Clojure and hate the start up time, but also seems like it sidesteps one of the main benefits of Clojure which is Java interop obviously... Which Clojure has to do a fair number of handsprings to accomplish. Begs the question, why pick Clojure as the lisp to compile to C++? Why not Racket or Common Lisp etc?

christophilus 9y ago
I like Clojure for its encouragement of functional, immutable-first programming. That, and I find its syntax for function parameters, data-structure literals, etc to be preferable.
- kbp 9y ago
  Why not Racket? It has a similar emphasis on immutable, functional programming, it's also a Lisp-1 (I assume that's what you mean by "syntax for function parameters"), and the different syntax for data-structure literals I have to imagine is a pretty minor point.
  - mclehman 9y ago
    I think they meant that function parameters are vectors when defining a function: (defn foo [arg1 arg2 & rest] ...) As for data-structure literals, it's nice to be able to write [1 2 3] vs (vec '(1 2 3)) {:key1 "val1", :key2 "val2"} vs (hash-map :key1 "val1" :key2 "val2") Agreed, all pretty minor points, but all nice to have. Function arguments are easily distinguishable and creating maps/vectors is simplified.
    - deleted 9y ago
      [deleted]
ohyes 9y ago
I think clojure has very well designed concurrency and data structures. If this compiles to c++ presumably one could leverage the c++ universe.
nerdponx 9y ago
Why not? It's great to have another Lisp for me to try out. I was avoiding learning Clojure specifically because of the JVM dependency.
dbattaglia 9y ago
I kind of saw it as being intended for someone that loves Clojure but needs to run in a constrained environment that usually requires C or C++.
- jzelinskie 9y ago
  Aren't most of these environments low on memory and thus it doesn't really make sense for them to use Clojure's persistent data structures? Kinda related is this awesome paper: https://blog.acolyer.org/2015/11/27/hamt/ https://blog.acolyer.org/2015/11/27/hamt/
  - deleted 9y ago
    [deleted]
  - chipset 9y ago
    I'm not sure how it's implemented in Ferret but Clojure's data structures are implemented as trees so there's structural sharing that happens when a vector or hash map is updated or when a new version is produced. So the whole data structure isn't copied but only the relevant parts are added / updated in the tree and the rest is shared with the "new" data structure. Mutable data structures are still more memory effective but I'm assuming its fine since the author has a blog post on using ferret on an Arduino Uno which has 32k of ram. https://nakkaya.com/2017/02/15/bare-metal-lisp-rc-control-using-ferret/ https://nakkaya.com/2017/02/15/bare-metal-lisp-rc-control-us... Clojure data Sturucture links: Persistent Vectors http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-... Video with Rick hick on them https://youtu.be/wASCH_gPnDw?t=1742 https://youtu.be/wASCH_gPnDw?t=1742
    - gizmo385 9y ago
      It's so interesting watching Rich talk. He has such a breadth and depth of knowledge and you can tell that he really took his time when designing the language.
  - pjmlp 9y ago
kazinator 9y ago
The relationship with Java is both a benefit and a disadvantage of Clojure. > Why not Racket or Common Lisp etc? These already have solutions in the compilation space. Kyoto Common Lisp (KCL), a fairly old implementation tracing back to the 1980's, and its descendant GNU Common Lisp (GCL) compile to C. Embeddable Common Lisp (ECL) also contains a Lisp to C compiler. Of course, numerous CL implementations compile to native code without the C route.
- lispm 9y ago
  Btw: ECL is also a descendant of KCL. Like AKCL, MKCL, Delphi CL, Ibuki CL, GCL. Other Lisp-to-C compilers like CLICC, mocl, Thinlisp, and a few others are not descendants of KCL.
  - kazinator 9y ago
    I'm looking at CLICC now a bit. Boy, the implementors made a significant mistake in this one. Though CLICC is not intended to be a complete Lisp system, but a Lisp application, they insisted that CLICC has to itself be a CLICC-compiled application. And so what that means is that, then, programs being compiled with this bootstrapped CLICC are severely limited as to what they can do at compile time (in macros), simply because of the crippled run-time environment of the CLICC-compiled CLICC compiler which has to run without the benefit of an actual CL runtime. Whereas if CLICC had been kept as a Lisp-compiled program, only the run-time parts of user code would be restricted to the "CL1" language; macros could be written in full CL.
spacemanmatt 9y ago
Clojure on JVM certainly benefits from Java interop, but ClojureScript compiles to JavaScript, and benefits from JavaScript interop. For me, I like being able to take EDN and immutable data to the various platforms I need. My portability hurdle is little more than writing alternative functions where Java/JS interop doesn't port.

by gleenn 9y ago

christophilus 9y ago

I like Clojure for its encouragement of functional, immutable-first programming. That, and I find its syntax for function parameters, data-structure literals, etc to be preferable.

kbp 9y ago
Why not Racket? It has a similar emphasis on immutable, functional programming, it's also a Lisp-1 (I assume that's what you mean by "syntax for function parameters"), and the different syntax for data-structure literals I have to imagine is a pretty minor point.
- mclehman 9y ago
  I think they meant that function parameters are vectors when defining a function: (defn foo [arg1 arg2 & rest] ...) As for data-structure literals, it's nice to be able to write [1 2 3] vs (vec '(1 2 3)) {:key1 "val1", :key2 "val2"} vs (hash-map :key1 "val1" :key2 "val2") Agreed, all pretty minor points, but all nice to have. Function arguments are easily distinguishable and creating maps/vectors is simplified.
  - deleted 9y ago
    [deleted]

ohyes 9y ago

I think clojure has very well designed concurrency and data structures. If this compiles to c++ presumably one could leverage the c++ universe.

nerdponx 9y ago

Why not? It's great to have another Lisp for me to try out. I was avoiding learning Clojure specifically because of the JVM dependency.

dbattaglia 9y ago

I kind of saw it as being intended for someone that loves Clojure but needs to run in a constrained environment that usually requires C or C++.

jzelinskie 9y ago
Aren't most of these environments low on memory and thus it doesn't really make sense for them to use Clojure's persistent data structures? Kinda related is this awesome paper: https://blog.acolyer.org/2015/11/27/hamt/ https://blog.acolyer.org/2015/11/27/hamt/
- deleted 9y ago
  [deleted]
- chipset 9y ago
  I'm not sure how it's implemented in Ferret but Clojure's data structures are implemented as trees so there's structural sharing that happens when a vector or hash map is updated or when a new version is produced. So the whole data structure isn't copied but only the relevant parts are added / updated in the tree and the rest is shared with the "new" data structure. Mutable data structures are still more memory effective but I'm assuming its fine since the author has a blog post on using ferret on an Arduino Uno which has 32k of ram. https://nakkaya.com/2017/02/15/bare-metal-lisp-rc-control-using-ferret/ https://nakkaya.com/2017/02/15/bare-metal-lisp-rc-control-us... Clojure data Sturucture links: Persistent Vectors http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-... Video with Rick hick on them https://youtu.be/wASCH_gPnDw?t=1742 https://youtu.be/wASCH_gPnDw?t=1742
  - gizmo385 9y ago
    It's so interesting watching Rich talk. He has such a breadth and depth of knowledge and you can tell that he really took his time when designing the language.
- pjmlp 9y ago

kazinator 9y ago

The relationship with Java is both a benefit and a disadvantage of Clojure. > Why not Racket or Common Lisp etc? These already have solutions in the compilation space. Kyoto Common Lisp (KCL), a fairly old implementation tracing back to the 1980's, and its descendant GNU Common Lisp (GCL) compile to C. Embeddable Common Lisp (ECL) also contains a Lisp to C compiler. Of course, numerous CL implementations compile to native code without the C route.

lispm 9y ago
Btw: ECL is also a descendant of KCL. Like AKCL, MKCL, Delphi CL, Ibuki CL, GCL. Other Lisp-to-C compilers like CLICC, mocl, Thinlisp, and a few others are not descendants of KCL.
- kazinator 9y ago
  I'm looking at CLICC now a bit. Boy, the implementors made a significant mistake in this one. Though CLICC is not intended to be a complete Lisp system, but a Lisp application, they insisted that CLICC has to itself be a CLICC-compiled application. And so what that means is that, then, programs being compiled with this bootstrapped CLICC are severely limited as to what they can do at compile time (in macros), simply because of the crippled run-time environment of the CLICC-compiled CLICC compiler which has to run without the benefit of an actual CL runtime. Whereas if CLICC had been kept as a Lisp-compiled program, only the run-time parts of user code would be restricted to the "CL1" language; macros could be written in full CL.

spacemanmatt 9y ago

Clojure on JVM certainly benefits from Java interop, but ClojureScript compiles to JavaScript, and benefits from JavaScript interop. For me, I like being able to take EDN and immutable data to the various platforms I need. My portability hurdle is little more than writing alternative functions where Java/JS interop doesn't port.