Hi all, Firstly thanks for the kind comments, pizza, and those of you who bought me a drink! :-) I hope you all had as much as fun as I did.
On Jan 21, 5:28 pm, Peter Morris <[email protected]> wrote: > Thinking about the talk, I have several observations, perhaps this is the > right venue to air them. > > 1) Polymorphism appears to be handled by the ability to supply different > implementations of a keyword dependent on parameters. > This means your oo methods are broken up out of your class definitions and > sprinkled around your keyword definitions. This is approximately true. In Clojure functions aren't attached to types or classes. The language is dynamically (duck) typed so as in ruby you can pass a function any type as an argument, and so long as the right number of arguments are supplied it will be called. It depends on the function as to whether this will cause an error or not. Polymorphism is supported at a few points in Clojure. Firstly the core data types and structures are underneath java classes. They all implement all the right java interfaces, which not only makes interop a breeze, but it also means you can provide new implementations of the core language structures, and they will work with all Clojure APIs (and depending on the types you extend even Java ones). The abstractions Clojure provides here are significantly better than can be found in other JVM languages, like Scala. Secondly Clojure has multi-methods which I assume you're referring to. These can provide a powerful form of runtime polymorphism. Multi- methods in Clojure dispatch on the basis of a supplied function whos return value (the dispatch value) is used to specify which concrete method implementation is chosen. Note that the dispatch strategy here is under your control, and needn't be in terms of the type. For example you might choose to dispatch on the arguments metadata or values, or even a combination of metadata, value and type. If you need type based polymorphism (with near native java performance) you can also use protocols. Protocols (and the more powerful multi-methods) both allow you to extend existing types, and do so without using wrappers, adapters or monkey patching. Finally you can also extend java classes from within Clojure at either compile time with gen-class or runtime with proxy. > 2) Rock solid support for concurrency and integrity is really nice, but how > does it handle the persistence layer? Is all this integrity broken at the > point you need to push things into or out of the walled garden either to a > RDB or some other persistence mechanism. It doesn't. But firstly it's important to say that the Software Transactional Memory (STM) which I demonstrated (and I'm assuming you're referring to) is only one small part of Clojure's concurrency story, as there are also agents, atoms, transients, futures, promises, traditional locks, and one day maybe also pods. Regarding refs and the STM, as I mentioned briefly in the talk Clojure provides the ACI semantics of ACID. The 'D' being Durability is not provided. So yes, you're absolutely right that persisting these results to disk is your problem. Though there are strategies for handling this that depending on the guarantees you want may or may not be acceptable. For instance Clojure agents are co-ordinated with the STM and when inside an STM transaction operations sent to agents inside will be held back and sent on the final commit. These operations will then be placed in the agents work queue and serviced sequentially, asynchronously to the calling thread. You can then use this agent to flush the results to your database, though you'll probably want to use a database transaction too. And yes, depending on your requirements this might not be ideal as the database and in memory transactions were not co-ordinated. Though it'd be nice to have this, durability was not a design goal of the STM. This said there is a patch lurking around that purports to integrate Durability safely with the STM. For those interested in the STM, the best description of its semantics and implementation that I know of is here: http://java.ociweb.com/mark/stm/article.html > 3) It feels like Clojure has major winning capabilities for niche areas. > Process Intensive work that can make use of large numbers of cores. > Situations where realtime response may be important, the fact that the JVM > has all the code loaded and waiting for stimulae. This is certainly true. Clojure also has an excellent asynchronous (evented) web server called aleph, which has beaten node.js in benchmarks ( http://dosync.posterous.com/22397098 ). Couple this with Clojure's concurrency support and you have a lot of compelling reasons to give it a try. In addition Clojure has also found itself used in big-data (see cascalog/hadoop etc) stats and reporting (see incanter). There's also no reason why Clojure couldn't have a fullstack web framework every bit as good, if not better than rails. But it's still early days.... and Compojure, Ring, Clojureql and Enlive are already excellent. > I need to spend some time experimenting before I can have any meaningful > opinions so the above are just talking points. I am very happy to be wrong > (and told so) :-) On this note if you and others are interested the Clojure Dojo group can be found here: http://groups.google.com/group/clojure-dojo We also have some shoddy webpages here: http://manchester.clojuredojo.com/ Another link many of you might want to check out is this talk I mentioned on Clojure's philosophy: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey I really can't recommend this talk enough, especially to those who want to: - Better understand the limitations of OOP & mutable state - Better understand how to manage time (change) correctly in our programs It's an accessible (non technical) talk that many of you will find both interesting and profound. R. -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
