Hacker News Reader

Comment by gleenn | Hacker News Reader

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?

View on HN

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.

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.

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.

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++.

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/

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-us...

Clojure data Sturucture links: Persistent Vectors http://hypirion.com/musings/understanding-persistent-vector-...

Video with Rick hick on them https://youtu.be/wASCH_gPnDw?t=1742

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.

I always laugh when I see this complaints, given that Lisp was already running on IBM 7090, Univac M-460, IBM 360 and many other mainframes.

Any of those tiny environments run circles around the hardware constraints of 60's and 70's mainframes.

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

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.

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.

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.

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.

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.

Reply on news.ycombinator.com