Hi all! I've been playing around with Clojure in the last couple of days. Very interesting! However, I have never used a non-OO, lispy, pure functional language before and several questions popped up while digging deeper into the Clojure world. I hope you don't mind if I post them together in one mail. Even though I will use some scala snippets for comparison, this mail is not meant to be a scala vs. clojure flamewar ;-) I think clojure is a great language and I simply want to improve my adoption path with your help ;-)
* Syntax * I never used a LISP-like language before and I can't read the clojure code as fluent as code from different languages. Take for example this scala snippet: (0 until 100) map (_ * 2) filter (_ % 3 == 0) I can easily read this line from left to right (just like english) and instantly see whats going on. By contrast, I have to read the clojure version a couple of times to understand it: (filter #(= 0 (rem % 3)) (map #(* 2 %) (range 100))) Is this just a matter of pratice? Do you find it easy to read the clojure version? Also, would it make sense to have a function like this: (apply-chain (range 100) (map #(* 2 %)) (filter #(= 0 (rem % 3)))) apply-chain could evaluate each parameter and pass the results from left to right. Each parameter (except the first one) would be a partially applied function (if this works in clojure). I know that I could write a macro and adopt clojure to how I would like it to be. But this seems to be more a design question and I don't think that different clojure apps should use different approaches on this level. * Parametrization of "function groups" * Lets say I have a bunch of functions that provide database operations (read, write, delete, ...). They all share information about the database the operate on. In an OO language, I would define these methods in the same class and an instance variable would define the database. The advantage is, that the caller side does not need to be aware of the database name. I can create an instance somewhere and pass around the object. I can also create several objects with different database configurations. Currently I can think of 2 approaches to implement this in clojure: a) Each function also defines a database parameter The downside is that the caller needs to fill in the value every time. b) The function invocation needs be part of something else, e.g. (do- with-db "mydbname" (db-write) (db-read) ... ). Here, the caller still needs to be aware of this setting. What is the clojure way of dealing with this? Do I overvalue this problem because of my OO background? I am not asking for OO features like inheritance. My goal is simply to avoid repetition and scattering. * Dynamic typing * How would you compare the dynamic typing of clojure to e.g. Python or Ruby? I am wondering if it may be easier in clojure since the logic is not based so much on types (less structures to deal with?). I could imagine that macros help as well to minimize the typical errors people make in dynamic languages. What's your opinion? * Real-world macros * Correct me if I am wrong, but it seems that people often use macros for lazy evaluation of parameters. In Scala, it is quite easy to accomplish the same via by-name parameters. E.g. def maybe(lazyarg: => Unit) = if (...) lazyarg lazyarg will be evaluated in the if clause, not when the method 'maybe' gets invoked. I know that macros in clojure are much more powerful. But what are selling points in pratice? What is a unique feature of clojure's macro that you don't want to miss? Sorry for the long posting and thanks a lot for reading it ;-) Cheers, Roman --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
