13 ms·

Clojure: It’s About the Libraries

• brlewis 17y ago
  The impedance mismatch between Scheme and the JVM is a lot less than what the writer thinks. Here's the comment I just added to the post: You don’t need primitive-static-method in Kawa as of several years ago. It’s just there for backward compatibility. Newer syntax for calling Java methods is much easier: http://www.gnu.org/software/kawa/Method-operations.html http://www.gnu.org/software/kawa/Method-operations.html
  • asciilifeform 17y ago
    > The impedance mismatch between Scheme and the JVM is a lot less than what the writer thinks Tail call optimization? Scheme is a cruel parody of itself without it.
    • brlewis 17y ago
      I can only remember two cases where I had to turn on the full-tail-call option to the Kawa compiler, and even then performance wasn't a problem. The SISC Scheme interpreter does reasonably well too, and it has full tail call optimization all the time.
• herdrick 17y ago
  ‘Cause if it’s ever been done, anywhere, by anyone, someone’s done it in Java. Twice. If only. If I could get something like Python's Numpy on the JVM, I'd be using Clojure on my current project(s).
  • icey 17y ago
    I don't know how useful this is to you, but here is a list of Java numerics libraries (and assorted other information): http://math.nist.gov/javanumerics/ http://math.nist.gov/javanumerics/
    • deleted 17y ago
      [deleted]
    • herdrick 17y ago
      I mean, "something as good".
      • arohner 17y ago
        I don't know enough about numpy or the Java attempts, but have you seen Incanter? (http://github.com/liebke/incanter/tree/6ef7e36c285e9c50c89fd0e21aee9622c092bc96 http://github.com/liebke/incanter/tree/6ef7e36c285e9c50c89fd...) rhickey has also expressed interest in integrating fast numerical processing into clojure.
        • jimbokun 17y ago
          Wow, that looks potentially awesome. Certainly looks like it has the potential to compete with NumPy and R. Nice use of Clojure to tie together unrelated Java libraries with a useful syntax and REPL style exploration.
      • swannodette 17y ago
        It's always good to do your research before making a statement on a topic you might not have a complete picture of: Colt: http://acs.lbl.gov/~hoschek/colt/ http://acs.lbl.gov/~hoschek/colt/ Parallel Colt: http://sites.google.com/site/piotrwendykier/software/parallelcolt http://sites.google.com/site/piotrwendykier/software/paralle... There's been talk about integrating this functionality into Clojure. Incanter is an example of a project by someone who wanted to get primitive support for matrix math and has had quite a bit of success.
        • herdrick 17y ago
          Wow, Incanter looks great. I've got to look into this more. How do you know I don't do my research by making provocative statements on public fora?
• benreesman 17y ago
  Using Java libraries from a non-Java language on the JVM is one of the happiest parts of my day, every day. However that being said, the real reason why Clojure is going to become the most important Lisp is the same reason why Java has been displacing the theoretically-faster C++: multicore.
  • 10ren 17y ago
    You're claiming that (a) Java is better at multicore than C++; and (b) Java has been displacing C++; and (c) that the former is due to the latter. I haven't heard this idea before. Can you elaborate please? Threading the locks have been integrated into Java from the beginning, with every object having a monitor and functions like wait() and notify(), and a synchronized keyword. These are nice, and do help, but they don't solve the problem. I've heard that Java fixed up some problems with these in version 1.5 or 1.6, but haven't looked at the details. My understanding is that none of the imperative languages are very good at multicore. Erlang is said to be effective at it (because of pure message passing); and some people claim FP will help because it overcomes the problem of shared state by making it immutable (while this is true, I'm not convinced it's particularly helpful in large projects, in practice). So I'm interested in your reasoning.
    • benreesman 17y ago
      As limited as the threading model of synchronization is, it can be used to fairly easily write programs that scale up to some reasonable number of threads (10-100). This is less to do with the convenience of having keywords like 'synchronized' and more to with the fact that modern Java has a proper memory model. The C++ people are trying to put together a memory model, but it's not here yet and there's some doubt about the ability to integrate it successfully with existing (pthreads etc.) code. Without a memory model you're going to be writing more code that is less correct at a substantially higher cost. If you're interested in this google for a Google Tech Talk by Josh Bloch on 'Java Memory Model'. This basically comes down to my ability to get at architecture specific stuff (CAS, fencing) in a platform independent way and have it work. Cliff Click has a really neat tech talk on writing a lock-free hash table in Java, don't bother trying to write it in C++. Ultimately we will need a better model for concurrency, which will be some combination of functional programming and lightweight processes (actors). Erlang/Scala/Clojure/Haskell are in the right neighborhood (maybe Gambit Scheme, don't know much about it), but Erlang and Haskell are really hard to teach to mere mortals like myself. I don't know enough category theory to understand 'hello world' in Haskell, but I can write Scala and Clojure programs that work (and leverage my existing investment in the JVM). edit: i left off something imporant. if anything saves imperative programming it will be transactional memory, which is exremely hard. hardware TM and code written for TM are in a chicken-and-egg situation. the answer is hybrid hardware/software TM and the sun guys are way ahead on this too.
• asciilifeform 17y ago
  Clojure revolts me. It is the most explicit to date abandonment of the age-old Lispers' Dream, which was "Lisp All The Way Down." Clojure is the antithesis of the Lisp Machine. Rather than a crystalline pyramid of comprehensible mutually-interlocking concepts, behind every Clojure primitive there lurks Black Magic. The Clojure user who is missing some routine or other will run crying to Java for help, rather than implementing the feature himself correctly - that is, as a natural part of the entire language, built on the same concepts. Clojure pisses on everything I've ever loved about Lisp. It rejects even what little consistency and intellectual rigor there is to be found in an abomination like Common Lisp. Clojure is the False Lisp, which Reeketh of the Cube Farm. I don't care if everybody really is more productive in Clojure than in Common Lisp. The latter is not my standard of comparison (Symbolics Genera, the state of the art, is. Or, if you want something that is distinctly inferior but is currently available on the market: Mathematica.) Clojure is the gutted corpse of a dream. I am tired of this abomination being hailed as the future of Lisp. Users of real Lisps, such as myself, will keep hoping, dreaming, and working on systems which do not betray the original virtues of the language.
  • polos 17y ago
    I fully understand you -- and I don't understand you at all. If you got all of the revolutionary Lisp ideas, you don't have to worry about the rest -- currently I'm more or less forced to use C++ instead of CL (which is still my favorite language) -- but this doesn't prevent my mind to still 'think' in Lisp. If you have some really revolutionary idea, and you want to break it through the history grown walls, you always need to introduce it in homeopathic manner -- but since your new idea is really, really much more ingenious than all of the previous ones, it will finally and actually replace the more limited ones. But this takes time. If you limit yourself to think either black or white, you will never win...
  • anc2020 17y ago
    As a genuine interest, please could you clear up what is meant by "Lisp All The Way Down."? I've implemented my own Lisp interpreter in Scheme before, and I looked at the interpreter from McCarthy's original paper, but in both of these, the interpreter still required some language (albeit one with list-processing procedures) to begin with. My experience would be that there's nothing special with Lisp in this regard, just that its _really_ easy to parse, but I still hear this claim often enough - am I missing something here? And to answer your post, I'd say that Clojure does give you what you need - it gives you the axioms, it gives you defmacro - the rest is history. All those other library functions you can think of in a more abstract sense ("George's problem"), and in the end these should be machine code no matter which HLL they were originally written in. The Lisp way has always been very dynamic - you can change things, even when they're orbiting Mars, but Clojure is functional, you generally don't change things. So in that sense, Clojure is not a true Lisp, but only because it chooses a different set of trade-offs, and if you don't like that then its fine, but it doesn't make Clojure evil, just different.
• radu_floricica 17y ago
  It's also that AFAIK, it's the first major lisp in a while to be completely redesigned without regard to compatibility with CL. There's a ton of stuff that was just waiting to be done, but couldn't because people kept using car and cdr instead of first and rest.
  • gruseom 17y ago
    but couldn't because people kept using car and cdr instead of first and rest Huh? What do names have to do with it? If I recall correctly, first and rest were introduced 6 months after car and cdr were. The difference between 50 years and 49.5 years is hardly great enough to have affected the subsequent evolution of Lisp.
  • mahmud 17y ago
    No, Common Lisp has both sets of operators; it has car, cdr and all the combinations of c(a|d)+r you can handle, it also has the ordinal number words, first, second .. tenth, and rest. The difference is that first, rest et al. are used when the data being handled are proper lists. A list of items terminated by nil. Car, cdr and others can be used with lists as well, but they're more primitive operations that mean cons cells; a pair data structure that has two parts. You can view a proper list as "a primitive pair data structure that has the first item of the list as its first cell, and has its second items a pointer to rest of the list" .. and construct the rest inductively. You can't use first and rest to operate on associative lists, graph structures cyclical or otherwise and a host of other data structures. Some programmers decide to make their intent clear when operating on proper lists, while others prefer to stick to car and cdr out of habit, nostalgia, not-knowing better, street cred, or as a cheap way to advance pointers with one compact operation. CAR and CDR are less relevant now that people use CLOS, CL's Object System, and to a lesser extent structures. Defstruct gives you the accessor FREE, it constructs the accessor functions as classname-slotname for the reader and (setf classname-slotname) for the update/write function. With CLOS you can choose the name for it with an initialization argument (:initarg :accessor, :reader, or :writer) Please update your Common Lisp prejudice check-list.