Few people know that Clojure was not the first lisp worked on by Rich Hickey (I think Clojure was the 5th?). This was the last one he wrote before he started work on Clojure.
Both were (are? I can imagine people are still using them, Jfli in particular) interop libraries, not languages. FOIL is basically an RPC mechanism between a Common Lisp process and a JVM or CLR "host". JFli makes it reasonably easy to embed a JVM within a Common Lisp process, and thereby create Java objects from CL, call methods, and provide callbacks to Java methods written in CL.
(That's all IIRC, it's been a long time.)
I remember using JFli briefly during my later CL experimentation. Its model is very similar to jpype, which provides similar functionality for python, which was at the time my first committed step away from Java as my primary (production) language.
The prize was a sweet nylon set-up-anywhere hammock, BTW. I think Stuart was mildly irked that mine was the only hand that was up, but I thought the hammock looked neat. :-)
Genius is a little strong in my opinion. Still an intelligent and talent man I'm sure.
In my opinion he has made some questionable decisions with Clojure.
- Gratuitous use of [] in some forms; mainly defn and let. Why break the homonicity so often for no real benefit?
- Comment strings appearing before argument lists in functions. I would like to see the entire protocol, name and args, before reading the docstring which may refer to the args.
"- Comment strings appearing before argument lists in
functions. I would like to see the entire protocol,
name and args, before reading the docstring which may
refer to the args."
I think writing one doc string for a multivariate function is better than having to write one for many. Check out clojure core's min function:
(defn ^number min
"Returns the least of the nums."
([x] x)
([x y] (cljs.core/min x y))
([x y & more]
(reduce min (cljs.core/min x y) more)))
So there are occasions for this related to efficiency. Where would you prefer the docstring?
Clojure code is surprisingly hard to edit for a Lisp-like language. The gratuitous use of square brackets where a Lisp would just use parentheses is part of that.
Omitting the parentheses inside those square brackets, however, was an even worse decision wrt editability. When you can't edit a sequence of syntactically homogenous items by simple s-expression manipulations, your Lisp's design is defective.
I see your point, I think you may downvoted because you did not elaborate rather than just say "you're wrong".
Let me see if I can elaborate on what I think you mean. Homoiconic can be interpreted as meaning that the programs structure is similar to it's internal representation and so then it can be argued that an argument list is implemented as a vector and so should be represented as such.
But I would suggestion that this is an implementation detail and would hazard that many Lisp implementation might share this implementation strategy. I suppose I should have described it as something along the lines of needlessly breaking with Lisp syntax traditions.
As an aside the reader macros themselves are not the problem as lists are not a one size fits all data structure within current computing so there is a need for vectors and hash maps etc.
YMMV, but it's interesting to note that some of these decisions are interrelated: [] and {} are implemented at the reader level and the reader isn't (very) extensible. This makes implementing defn (and by extension a user macro like it) much easier. The same is true of putting the sparring first.
The other thing with the docstring, of course, is that Rich made the decision to only have one docstring on an overloaded function. The docstring/arg order falls straight out of that. OTOH if you've read the docs for "map" recently you may be wondering if that was such a smart decision. For better or for worse, muti-arity overloading that doesn't just do partial application is a big part of modern Clojure.
> It is substantially more sophisticated than DotLisp and I strongly recommend it, unless you must target .Net.
> The idea behind DotLisp was to build a Lisp for .Net that yielded to the CLR those things provided by the CLR that languages normally have to provide themselves:
I'm curious how DotLisp improves on the situation provided by clojureclr, especially since "It is substantially more sophisticated than DotLisp".
It might be "sharing type system, GC and other runtime services etc., with transparent access to .Net w/o a FFI or wrappers", I am note sure if clojureclr requires wrappers whereas DotLisp doesn't, but I imagine it would be similar to how Clojure proper integrates with the JVM.
> ClojureCLR development closely tracks progress in the ClojureJVM project. We index many of our commits directly to commits in the Clojure repo, so it should be easy to track our progress. We try to be within a week or so of development milestones on the main Clojure project. https://github.com/clojure/clojure-clr/wiki
I thought ClojureCLR had been abandoned after Rich Hickey started working on ClojureJVM.
