Well, will disagree about some things, but agree very much about others--probably all practical matters. Some of your remarks seem valuable. Some don't seem relevant to me. Ah well, we're just talking here. Not everything needs to matter.
Your point about thriving, competing libraries is important. What's the difference between this situation and the Curse of Lisp? I'm not sure. There is one each of all of the Clojure contrib libraries <http://clojure.org/api/api>. There's a reason that that's a good thing, imo. It's the same reason that there's usually only one of each core function in Clojure, and that similar functions usually have similar syntax (can't assume this in Common Lisp), although other people can define alternative functions, or build Scheme syntax into Clojure, or whatever one wants. That there's a standard set of contrib libraries doesn't mean that there can't be competing libraries or competition for core functions, and there are in some cases. (I would never use clojure.core/rand except for little experiments.) If it works for people to have multiple React wrappers, etc., yeah, why not? These competing tools have different costs and benefits--not just in efficiency in different contexts, but in how one goes about structuring one's code. Given that, there would be no sense to having a single-line switch between competing libraries. Matrix operations seem different, though. Every matrix library will share a lot of functionality with any other, because they're intended to implement the same standard mathematical abstractions. They will have different functionality in some places, of course, but on the shared functionality, the difference will only be in which library is more efficient for which kinds of operations with what kind of data, what systems they'll run on, etc.) There are not that many different fundamental operations that one can want with matrices. I don't care whether adding a constant to a matrix is written as '(add m c)` or '(add c m)' or '(sum m c)', etc. I want an API that's sensible and not foolish, and I prefer an API that's more sensible and more flexible without being more difficult to understand. Beyond that I don't care much about what API I use, except that I don't want to have to learn multiple APIs and port my code from one to the other. My guess is that in an alternate universe in which core.matrix had the API that Neanderthal has in this universe, I would be equally happy with core.matrix. (Too bad that the Google Summer of Code deadline is past. Providing a core.matrix interface to Neanderthal would be a great project for someone, I bet.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
