> In case you haven't had time to see the talk, the feature of > most interest, at least to me, was that Kay managed to create > a mathematical foundation for the 2.5D screen geometry. > From that mathematical basis, they derived a correct, small, > fast, and clean program. In 20,000 lines of code they seem to > have built a system from hardware to graphics, a project of > comparable size to Clojure. Would formalizing aspects of > Clojure make it reliably correct? Smaller? More portable?
After seeing the talk I looked for the source code for this, and couldn't find it. I have a fairly in-depth background in graphics rendering and am interested to see how this all is implemented. In the past few days I've been reading up on OMeta, but have yet to see anything besides compiler-esque software written in it. Writing a calculator program is one thing, I'd love to see a "ant-simulator", or a web app written with these new ideas. Overall I can't find many examples at all on this. > If Clojure is to support parallel programming work, does it > need to provide Go-like channels? Does it need a reliable > message queuing primitive (or do we just wrap things in an > STM? But what about retrys?). Everyone has to solve this > problem which implies that language features become critical. > Rich made it possible to hide locking and improved life for all. > A similar set of support for common distributed and parallel > pain points is needed. I tend to agree with Joe Armstrong (co-designer of Erlang) on this. STM is great for single workstations with a low number of cores. But, as the number of cores increase, so with the problems with shared state. STM is based on CAS (compare-and-swap). In general this is a fairly cheap operation, but it doesn't scale. If you have 1024 cores, and each has a L1 cache, you have to keep some running table of memory locations that can be swapped with CAS, and flush the caches of the effected processors. This is why the documentation for CUDA programming basically says "yes we support CAS...don't ever use it...." I've been putting a lot of thought into all this recently as it relates to Clojure-Py. STM in Clojure-Py is possible, it's just rather useless (due to the GIL). That forces us to re-think concurrency in the context of distributed programming. Something Joe mentioned in his talks is that there are three things that are tightly intertwined: 1) Fault Tolerance 2) Concurrency 3) Distributed Programming If you correctly implement #1 you get the rest for free. I highly recommend this talk by Joe Armstrong http://www.infoq.com/presentations/Building-Highly-Available-Systems-in-Erlang Here he goes into the details about how Erlang has limitless scalability and infinite reliability. At any rate, these are the ideas I'm attempting to implement in Clojure-Py, we'll see where it goes. Timothy Baldridge -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
