>> 1) Clojure is said to be "data-oriented". Well it is, it's just that your definition of "data" is radically different from the normal business use case. In the line of work I'm in, "big data" is millions of hash maps filled with heterogeneous data types. In these cases, Clojure really shines.
>> 2) Clojure is said to make simple things easy. That's a tad debatable. I would say that Clojure simplifies your code, therefore allowing for easier reasoning about that code. One of the ways it accomplishes this by being a dynamic language. And that right there hits on the main reason you're experiencing problems. This simplicity doesn't come without a cost. There are many trade-offs Clojure makes. Immutable data-structures are fast, but not as fast as mutable structures. Clojure allows for REPL based development at the cost of requiring that every function must go through a var deref. This cost is low (very low thanks to the JVM), but it still exists. And we see this cost when it comes to primitives. In languages like Scala and Java you know exactly what functions every function will call, and so you can link it to the exact overload needed for the primitives in use. However, in Clojure, at any moment a def (var) could be changed at the REPL, and we have to pick that up without problems. In return you have the ability to program without having to re-compile at every step. The same thing applies with type hinting in general. No other dynamic language offers the performance of Clojure. Python is used heavily by the scientific community, and yet it boxes everything. It doesn't support floats, let alone unboxing. So Clojure really should be viewed as a super fast dynamic language, not as a slow Scala/Java clone. I think this is clearly exemplified by Fressian ( https://github.com/Datomic/fressian), this is the serialization library used by Datomic (also written by Rich Hickey). Notice something interesting about this codebase. It almost 100% java (except for the tests, those are in Clojure). Why? Because serialization libraries need to be lean, fast, and are mostly side-effecting, this is a use case Java excels at. Now I've never seen the inner workings of Datomic, but I've heard it said the database is written in Clojure. So that's interesting...it's a set of Java libraries (for performance) glued together and controlled by Clojure (for simplicity). When Clojure people talk about simplicity what we're really railing against is the complexity of orchestrating large projects using a OOP language like Java. Write your data processing routines as static java members that take float arrays and emit float arrays and you're going to do quite well. One other thing you touched on is the idea that no one has given you a straight answer on this yet. And I think this comes down to several things: a) No one wants to speak for Rich. When it comes down to it, Clojure is his baby, so no one but him has the authority to say "this is a focus for version X". He doesn't hang out on the mailing lists a whole lot, so perhaps an email to him might do well, or even to clojure-dev. b) No one has a clue on how to implement this without changing Clojure semantics. And changing the semantics of a language just to support a single use case is one of the best ways to get your patch rejected by Rich. :-) c) I want to make this point as carefully as possible...there's little incentive for anyone (including Rich) to implement this. If you came to me an said "Tim...we want to pay double your current salary for the next year and have you re-write the Clojure compiler from scratch to support these features", I might actually do that. But sadly, I have a day job, and making massive changes to the Clojure compiler is not something I plan on spending my time on this year. Perhaps at some point a corporation will offer paid support for Clojure and then things like this can be possible. As the saying goes, money talks. Offer enough money and people will get more motivated to help. I know this point isn't very nice to hear from the OSS world, but the sad fact of it is, you seem to have a unique use case, and until the people with the knowledge of the system have the need of that same use case, nothing is going to happen. That being said, if someone hired me to write a video editor (as I've done some work in that area in the past), I'd probably write it in either C (for SSE support), CUDA/OpenCL, or perhaps bare Java, and once again, I'd glue my library together with Clojure code. Writing the image processing code for 4K video at 48fps in a dynamic language is a joke. Unless you're the people who write PyPy, but then again, I'm convinced that those people are mostly insane :-). So there it is, it's not going to change soon (if ever), and you probably won't get much feedback from others unless you start offering money. But once again I want to come back to something I've said a lot in this conversation: I work with Clojure a lot. If someone came to me and said "how do I do this in Clojure?". I'd say the following: put your math in static java methods, and call them from Clojure. This is really the way it should be done. Low level stuff in Java, high level stuff in Clojure. The nice thing is, lein has very nice features for just this use case: http://stackoverflow.com/questions/7511789/clojure-lein-how-do-i-include-a-java-file-in-my-project So you can write your java code, stick it in a folder, and then it'll be compiled by lien on startup. That's my professional opinion. Timothy Baldridge On Sat, Sep 14, 2013 at 8:08 AM, Alex Fowler <alex.murat...@gmail.com>wrote: > Excuse me, when I said "Vertex3f" I meant "Vector3f". > > суббота, 14 сентября 2013 г., 15:14:01 UTC+4 пользователь Alex Fowler > написал: > >> Timothy, thanks,for giving a thorough answer to my questions, I >> appreciate this! As far as I understood, you did some work for Clojure >> team, and you have the necessary knowledge to express a knowing opinion on >> what are the implications of the matter. That was one of the things I >> wanted to know - the cause of the present situation. However, still I don't >> understand (although you mentioned a reason) why no one from the core team >> gives a definite, cut-off answer, like the one, Mikera is also asking for - >> what is for the future? Probably, as somebody mentioned here (sorry, I look >> and can't find the message, deleted?), the question would probably be >> better addressed to clojure-dev. But I have no good knowledge of Clojure >> internals and would be easily suppressed by an answer of a person, showing >> a technical knowledge, like yours. Yes, I understand what you're saying, >> but I do not have knowledge of Clojure or JVM to answer you on par. Simply >> I do not know what to say, although I feel there is a break between JVM and >> Clojure that should not be. And I feel, that you have a right in what >> you're saying - you know the language, you know the people here, more than >> me. But not to let a discussion on such a topic to die, here I am glad that >> Mikera, someone who has that knowledge, can sympathise me and say what I >> cannot say. >> >> James, for some numbers on OpenGL penalties, please refer to message #6 >> in thread (my initial answer for Timothy). You can also google on it, I am >> sure, you will find more information, or, why not, simply call NVIDIA or >> ATI support lines, and ask them. A perfectly valid question for them to >> consult you on :) As for more Java-friendly answers, you might also be >> interested in asking on LWJGL or JOGL forums. Personally I work with OpenGL >> for quite a long time already. Even when we were on C/C++ we never used >> doubles. Then we went Java, and there too, doubles are nowhere. One of the >> cornerstone computational workhorses of LWJGL, for example, the class >> Vertex3f, has no double version. And that is for a reason, not because Java >> bindings are bad and we must go C-plus-plusing now. Probably, after 10 >> years we will have only doubles and longs on GPUs... do you believe in it? >> Why we need them there at all? >> >> I still strongly believe that primitives support should be made one of >> the highest priorities to support. >> >> Lets look from a perspective of someone who researches the language, >> considering if to adhere to it. Here is a couple of frustrations that hit >> me so much that I think could even diverse somone from using the language. >> Warning: the following three points may cause rage in some individuals >> (they do cause a rage in me at least, because I really like Clojure) : >> >> 1) Clojure is said to be "data-oriented". Rich Hickey says that in the >> videos. Cool! I have a stream of millions floats and ints to be processed >> on the fly! Now we find that it is not data-oriented. It is double, long >> and Object oriented. Data does not just come as "information" it comes with >> its data-type. Bending data-sources and data-consumers to your will usually >> does not sign a good data-processing. >> 2) Clojure is said to make simple things easy. Alright, that's a PC in >> front of me? With a JVM? Alright, I want to add,multiply, divide and >> subtract some billion floats. What could be simpler?... Uh... typehints.. >> alright, sure JVM is typed, we have types in Java and Scala, that's ok! Oh, >> only local... oh, still always returns doubles... err.. boxed? Cast? Oh... >> 3) As Mikera pointed out, some libraries, like "fast arrays on Clojure" >> is just.. a little bit too much. Are they faster than Java arrays? A >> library that implements fast arrays for a language that runs on a VM that >> has fast arrays? For a language, claimed to be perfect for data-processing? >> There is nothing wrong with the library, I think it is a masterpiece, but >> something scares me here. >> >> Surely, preserving semantics while letting full primitives support for >> Clojure, as it is right now, is a challenge. I really like the symantics as >> it is now, but the cost is too great. The examples that Timothy and Mikera >> are discussing right now is a problem. Some my ideas, although I am not as >> professional with them and some of them might not make sense at all (sorry): >> 1) In computations you do not often use functions that compute floats to >> compute ints instead. Usually you know what are you computing. I wouldn't >> switch, say spatial vector calculations from floats to ints under any >> circumstances. Remember Java - when you write signatures of your >> computational functions - how often do you change types? float<->double or >> int<->long maybe, but still not likely. Even on a lisp. >> 2) That leads to the other question - what if you *still* somehow want >> to reuse a computational function for other types? Well, maybe you could >> make functions named (+f) or (+i)? Or have a macros that builds them for >> you and calls them for you? >> 3) To simplify furhter: can a primitive typization of a function be >> specified by some clever tag in metadata? >> 4) Can functions working with primitives and the other functions be >> separated? I.e. functions working with primitives only take in primitives. >> 5) If working with primitives would introduce more burden to the user, >> could macros help? >> 6) To avoid the aforementioned explosion, can a functional interface, as >> proposed, be synthesized, with some static field hint for Java to not lose >> the interop? >> >> -- > -- > 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/groups/opt_out. > -- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth) -- -- 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/groups/opt_out.
