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.
