248 karma · joined November 9, 2012
My views and posts are my own.
Are there any plans for exposing a Clojure API? Given that it's implemented in Clojure, seems like it would be a natural fit. Interop with Java is nice but can be cumbersome compared to the more natural calling conventions and idioms (threading macros instead of `..` builder patterns, etc).
You disagree that they enjoyed the article?
In Racket, you write `(define (foo arg1 arg2) (+ arg1 arg2))`. Why isn’t `(foo arg1 arg2)` evaluated as a function? It’s a list and it isn’t quoted, so it should be evaluated. However, `define` is a macro (I think, might be a special form), so that list isn’t evaluated and doesn’t have to be quoted. That violates the basic tenant of “unquoted forms wrapped in a list are evaluated as fiction calls.”
In Clojure, you write `(defn foo [arg1 arg1] (+ arg1 arg2))`. The [] is a reader macro, a vector literal. It communicates that it’s not a function call but simply data (in this case, a vector containing two symbols).
Maybe I’m just used to it but I find this stuff really helpful.
This is an interesting design decision. Why don’t you want to combine them?
Thank you for the effort, you gave me quite a few cherished memories.
Not to denigrate the efforts of folks who study and practice “the act of language acquisition”, I’ve just been surprised and delighted to watch my now 2 year old daughter learn to speak, which has made me think about how different her experience of “learning a language” is from all of my poor attempts at learning foreign languages.
I browsed the titles of a bunch of the articles published by the journal after the name change, and most of the were language agnostic but still lisp-adjacent and potentially lisp-relevant. (For example, Volume 12 Issue 1, the second year with the new name, has multiple articles about call/cc using demonstration languages.)
I will say, however, that this paragraph felt like sour grapes:
> As examples, the scientific journal Guy Steele and I founded called Lisp and Symbolic Computation (LASC) had been renamed Higher-Order and Symbolic Computation (HOSC), and my primary scientific conference called Lisp and Functional Programming (L&FP) had been renamed the International Conference on Functional Programming (ICFP). I was discouraged for two reasons. One was that during the 1980s when functional programming researchers had few outlets, many of us Lispers kept the lights on at L&FP for them, and later when Lisp was on the decline, they shut the door. And the other is that this seemed to signal that my field of inquiry had been deleted by the academy.
All that’s changed is that Lisp isn’t primary anymore; they are both titled to allow other languages and other media to contribute to their respective focuses. Common Lisp is a good language but it’s not the final language nor even the final “programming medium”, so acting like it is artificially limits both Common Lisp users and future language designers who could all benefit from that cross-pollination.
Now maybe the change of names is shorthand for lisp actually being excluded from the journal and conference, which nullifies the above, but without doing any research at all lol, I doubt it.
It can be slightly inconvenient but doesn’t feel moronic to me. It means that except for the built-in functions, everything can be traced to either a definition or an import. Makes tracking code much easier.
The alternative is what exactly? Have the entire standard library exposed at once? Make all modules create non-conflicting names for exported objects, so that the json parse function has to be called json_parse and the csv parse function has to be called csv_parse?
Seems less than ideal to me.
Additionally, it is cathartic (and occasionally even productive) to complain about the warts and sharp edges of a popular tool, especially when the tool is the overwhelming the tool of choice in its domain.
I also found a small bug, that you'll want to use `(elt s (+ x 7))`, not `(+ x 8)`. `elt` is 0-indexed, so first and last of an 8 element list will be 0 and 7.