Re: Namespaces [was Re: Is Clojure right for me?]
I read through the docs on jig and component. Basically, the answer proposed by that workflow is: You have to thread your shared state through all the functions (what I described as Solution 2), and if you don't want the difficulty of refactoring to that way of doing things, you better just do it that way from the beginning. OK, not the answer I was hoping for, but I appreciate the pointer. I found it interesting that at the component link, under Disadvantages of the Component Model, Stuart mostly reiterates the points I've been making here, so I guess the issue is understood, it's just that other people are happy with the idea of writing all code this way from the beginning and don't mind being restricted to libraries that use the same methodology. Of course, Clojure itself doesn't follow this component model. Part of that may be because the component model is too new. But I think part of it is that the component model is not always the right choice. Consider decimal precision. Right now, the main mechanism for controlling precision is `with-precision`. This feels natural because precision doesn't make sense as being part of a single component -- its relevance potentially spans your entire code base. Furthermore, it would be absurd to have to thread some precision variable as the first input to every single arithmetic operation. Can you imagine how annoying Clojure would be if it made you do that? `with-precision` has the same limitations as bindings -- if you want to produce, for example, a lazy sequence involving decimal arithmetic, you're going to get burned. Maybe in some projects you can get away with just setting a default precision for the entire project. But if you end up needing to deal with a mixture of sequences generated with different precisions, you're going to have major problems. So we have a dilemma -- it's awkward to thread decimal precision through all operations, and binding isn't good enough. This is exactly the kind of thing I'm talking about. To put it bluntly, binding vars is an imperfect solution but we use it because it's the best tool we have in Clojure. Can we do better? -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
On 28 December 2013 08:21, Mark Engelberg mark.engelb...@gmail.com wrote: `with-precision` has the same limitations as bindings -- if you want to produce, for example, a lazy sequence involving decimal arithmetic, you're going to get burned. Maybe in some projects you can get away with just setting a default precision for the entire project. But if you end up needing to deal with a mixture of sequences generated with different precisions, you're going to have major problems. So we have a dilemma -- it's awkward to thread decimal precision through all operations, and binding isn't good enough. This is exactly the kind of thing I'm talking about. To put it bluntly, binding vars is an imperfect solution but we use it because it's the best tool we have in Clojure. Well, there's the bound-fn macro, but you need to know ahead of time to use that. It sounds as if you want something that combines the advantages of dynamic and lexical scoping - i.e. dynamic scope that can be passed through closures. I'm not yet decided on whether this is a good idea or not - in my view, implicit arguments are generally bad news - but I'd suggest taking a look at Riddley https://github.com/ztellman/riddley and Sleighthttps://github.com/ztellman/sleight if you're interesting in pursuing the idea. As far as I'm aware, the only top-level Clojure forms that produce closures are fn* and deftype*. You could transform them in much the same way bound-fn works, by using lexical scope to deliver the values to an inner binding. - James -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
On Sat 28 Dec 2013 at 12:21:22AM -0800, Mark Engelberg wrote: You have to thread your shared state through all the functions (what I described as Solution 2), and if you don't want the difficulty of refactoring to that way of doing things, you better just do it that way from the beginning. I agree that the approach outlined by Component is essentially your Solution 2 + stop complaining and just do it this way. You stated earlier: Solution 2 is irritating because if you use a map for shared-info, you end up having to repeat the destructuring in every single function. Also, you need to thread this information through all the functions, not only the functions that directly use, but also the functions that call other functions that use it. This is where one could argue that passing the entire local context to every function to approximate the convenience of OO is sloppy design. I have found that carefully writing functions in terms of very specific input has resulted in very modular, reusable, and testable code. Of course, this is no surprise; these are the rewards of FP. Writing programs in this fashion often feels difficult because it demands more design up front, whereas writing closures/methods in the environmental soup of the namespace/global configuration/instance is really quite easy because all the necessary data is at hand. Furthermore, it would be absurd to have to thread some precision variable as the first input to every single arithmetic operation. Can you imagine how annoying Clojure would be if it made you do that? … So we have a dilemma -- it's awkward to thread decimal precision through all operations, and binding isn't good enough. It would be annoying if it were mandatory, but it is easy to make it optional. Alternately, you could create versions that take an explicit precision argument, then write a macro that takes a precision and rebinds the these arithmetic fn symbols with partially applied versions within the body: (defn +. [precision xs] …) (defn *. [precision xs] …) … (defmacro with-precision [precision body] `(let [~'+ ~(partial +. precision) …] ~@body)) The amount of magic in this macro can be adjusted to taste, but it will work with lazy-seq, and is also pretty convenient. Can we do better? Overall, it seems to me that you are looking for a better way to manage implicit parameters¹. However, I imagine a sizable part of this community is here precisely because of negative experiences with systems with large amounts of implicit data. To the extent this is true, you're likely to get the same don't do that as a response. guns ¹ Perhaps with something akin to an instantiable namespace? :) pgpoYxal8Gnkm.pgp Description: PGP signature
Re: Namespaces [was Re: Is Clojure right for me?]
On Sat 28 Dec 2013 at 05:12:24AM -0600, guns wrote: (defn +. [precision xs] …) (defn *. [precision xs] …) … (defmacro with-precision [precision body] `(let [~'+ ~(partial +. precision) …] ~@body)) I just realized that this does not help with functions already defined in terms of the existing arithmetic functions, which is the problem that you posed. So I guess the answer is still to explicitly pass your precision to every function that requires it. This seems onerous, but we gain the important advantage of transparency. guns pgprpWXAVEfE8.pgp Description: PGP signature
Re: Is Clojure right for me?
Mark, Your comment Clojure's namespaces are quite limited in ways that frequently cause me pain brings to mind Daniel Spiewak's talk on modularity in functional languages: http://2013.flatmap.no/spiewak.html. It might be interesting to Massimiliano as well. Spiewak is actually criticizing Haskell's approach to modules and not Clojure's but similar criticisms could apply to both. The gist of what he says is that there are expressive advantages to Scala's decision to treat modules as first class things. He then goes on to cite Clojure's protocols as another example of an OO abstraction improving modularity in an FP language, but that's not news here. Rob On Thu, Dec 26, 2013 at 7:26 PM, Mark Engelberg mark.engelb...@gmail.comwrote: One reason it might not be clear what I'm driving it is that in trying to create a minimalist example, I used grid dimensions, and in reality, you'd probably know right away to put something like that in a data structure, and pass it around to all your functions. Try to imagine that at the beginning of your project, you really do believe that you're only going to ever be working with 3x4 grids, and then later, you realize that's not the case. In the early phase, it's very easy to construct a bunch of functions that all refer to those shared vars (in my example `rows` and `cols`). Later, when you realize rows and cols can change, making those names parameters is a major overhaul to the codebase. I believe that most Clojurians try to delay the refactoring by using `binding` to alter those vars. But that's a fragile strategy, and eventually the code typically needs to be rewritten. On Thu, Dec 26, 2013 at 7:04 PM, Mark Engelberg mark.engelb...@gmail.comwrote: Does this OO pseudocode help clarify at all? https://gist.github.com/Engelberg/8142000 On Thu, Dec 26, 2013 at 6:27 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Hi Mark, I am not following your example. Can you post (pseudocode fine) what a good OO impl would look like, and why Clojure's defrecords can't do something similar? Stu -- -- 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. -- -- 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.
Re: Is Clojure right for me?
Yes! This is very much what I'm talking about. When we talk about why we don't need classes in Clojure, we're usually talking about how we have better tools for inheritance, polymorphism, encpasulation, mutable state, etc. But classes are also powerful namespaces, and Clojure's namespaces aren't rich enough to make me stop missing those sorts of useful aspects of classes. Spiewak gives some really great examples in his talk. Thanks for the link. On Fri, Dec 27, 2013 at 2:10 AM, Robert Levy r.p.l...@gmail.com wrote: Mark, Your comment Clojure's namespaces are quite limited in ways that frequently cause me pain brings to mind Daniel Spiewak's talk on modularity in functional languages: http://2013.flatmap.no/spiewak.html. It might be interesting to Massimiliano as well. -- -- 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.
Re: Is Clojure right for me?
First, regarding OO. When programming Clojure I never think about adding objects to the application, I think how can I extend the language so it is better tailored to my application domain?. And for a lot of domains good libraries are already available. So, for the example that you gave I would first look at core.matrix https://github.com/mikera/core.matrix. It does something which objects can't do; it adds matrices to the language in a very natural way. Second, regarding cyclic dependencies. When programming Clojure I think about how data (EDN) flows through my application. Because of this my namespaces usually depend on the structure of the data. My namespaces rarely depend on namespaces other that those that provide the additional language elements that I need (like e.g. core.matrix, core.async, ...). This does raise a new problem how do I check the validity of the data flowing in and out of namespaces?. There were several presentations at Clojure/conj that addressed this problem. But overall I find this approach to work very well, even for large applications, because namespaces are highly decoupled and easy to test. Those are the tricks that I use. But I must admit that it has taken me many iterations to slowly improve my code. Old habits die hard. On Friday, December 27, 2013 3:08:04 AM UTC+1, puzzler wrote: I do like the way Clojure steers you away from all sorts of unnecessary OO-nonsense, and provides most of the raw capabilities of OO in other forms. However, even if you avoid mutable state, inheritance, and polymorphism, Classes/objects make great namespaces, and Clojure's namespaces can't do everything classes can do, for example, cyclic dependencies. This was the subject of my blog post yesterday. Take a look at the following gist code for one of the scenarios that frequently drives me up a wall: https://gist.github.com/Engelberg/8141352 I'd love to hear any tricks you guys use to deal with situations like this in your own code. -- -- 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.
Re: Is Clojure right for me?
The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs. On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the time. Learning is never inefficient... when you want to learn. Luc P On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- 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.
Re: Is Clojure right for me?
Words play a very important role in expressing ideas. For me, I think clojure is mostly about ideas. A way of doing things. For me clojure was intuitive from day one. The notion of programming with functions applied to data. So in clojure data structures are emphasized as a way of representing data as opposed to classes which Rich Hickey has argued as using mechanical things(classes) for the wrong purpose. Because of this we have words like: pure functions, higher order functions, which many OOP language has just started adopting; closures, which are analogous to objects in OOP but are sanely done with the help of immutability; data structures as opposed to using classes to track numerous variables in the name of data; composition rather than inheritance because the *complect* control. And a number of other ideas. You just have to take a deep breadth and accept you are about to look at things a bit more mathematically using functions as the major tool for designing machines. Don't resort to familiarity as that will prevent you from learning new things and trust me you have a whole lot to unlearn. But if you stick with the community you can learn fast seeing you already a programmer. With regard to frameworks I agree it's about composition of libraries that's where you get the most power and less problem because of all this immutability thing. Dive in and start applying it on something real and before long you will be glad you did and ready to bring others on board. On Wednesday, December 25, 2013 10:06:20 PM UTC+1, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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.
Re: Is Clojure right for me?
Then we have more in common than you may think :) I learned Ruby first, went through Scala which appeared in the same time frame, all this to pick up the language of choice to replace Java and Ruby which we used to prototype our product. All this took around 9 months including the time to get the prototype working. Choose carefully... :) Luc P. The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs. On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the time. Learning is never inefficient... when you want to learn. Luc P On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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.
Re: Is Clojure right for me?
Yes, thanks Mark. It seems to me that you are saying namespaces make poor maps. Stipulated. So why not use records or maps? I think that where my experience differs from yours is summarized in your comment In Clojure, a project often begins with a bunch of functions sharing some immutable state or magic constants stored in vars. I *never* do that. If there are a group of related things, I put them in an associative container (maybe just a map) on day one. The analogy with OO is misleading here. If you started an OO project putting everything in static/singleton members, you would have the same pain you attribute to Clojure's namespaces. I find this to be a my car doesn't have wings argument, and the kind of thing that leads into casually complecting everything with everything else. Stu On Thu, Dec 26, 2013 at 10:04 PM, Mark Engelberg mark.engelb...@gmail.comwrote: Does this OO pseudocode help clarify at all? https://gist.github.com/Engelberg/8142000 On Thu, Dec 26, 2013 at 6:27 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Hi Mark, I am not following your example. Can you post (pseudocode fine) what a good OO impl would look like, and why Clojure's defrecords can't do something similar? Stu -- -- 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. -- -- 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.
Re: Is Clojure right for me?
I would add that you *need* to write some code to get a feeling about a new language. Feature comparisons may help you up to a certain degree. However deciding about how efficient you may become using a new language requires you to dive at least a bit into it. Not all brains are wired the same. Luc P. Then we have more in common than you may think :) I learned Ruby first, went through Scala which appeared in the same time frame, all this to pick up the language of choice to replace Java and Ruby which we used to prototype our product. All this took around 9 months including the time to get the prototype working. Choose carefully... :) Luc P. The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs. On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the time. Learning is never inefficient... when you want to learn. Luc P On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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
Re: Is Clojure right for me?
On Friday, December 27, 2013 7:29:22 AM UTC+1, Sean Corfield wrote: On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli How do you decompose large systems in Clojure? I'm curious as to why you think only OOP allows you to decompose large systems? Between namespaces, protocols, multimethods, ad hoc hierarchies, and higher order functions, Clojure has a lot of tools for organizing code... I've never claimed that OOP is the only way to decompose large systems, but since Clojure doesn't support OOP and many languages are multi-paradigm nowadays, I was wondering how you modularize systems in a language which is purely functional. -- -- 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.
Re: Is Clojure right for me?
I've seen Clojure in action and I know it's extremely concise and expressive. What I wanted to know is how it copes with complexity when you develop complex systems. You can't get an idea of that just by writing some code and getting a feeling about the language, IMHO. When I studied OOP at University my professors taught me that OOP was extremely successful in reducing the complexity of big systems. I was given many examples of that in the many courses of software engineering I took. FP was relegated to some theoretical courses about paradigms. With such a background it's not easy to accept some of the things the Clojure community claim. The fact that I'm here asking questions should mean that I'm more open minded than most :) But please understand where I'm coming from. On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote: I would add that you *need* to write some code to get a feeling about a new language. Feature comparisons may help you up to a certain degree. However deciding about how efficient you may become using a new language requires you to dive at least a bit into it. Not all brains are wired the same. Luc P. Then we have more in common than you may think :) I learned Ruby first, went through Scala which appeared in the same time frame, all this to pick up the language of choice to replace Java and Ruby which we used to prototype our product. All this took around 9 months including the time to get the prototype working. Choose carefully... :) Luc P. The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs. On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the time. Learning is never inefficient... when you want to learn. Luc P On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Luc Prefontainelprefo...@softaddicts.ca javascript: sent by ibisMail! -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this
Re: Is Clojure right for me?
I modularize my Clojure systems using Jig: https://github.com/juxt/jig - it's one of many possible approaches. On 27 December 2013 15:23, Massimiliano Tomassoli kiuhn...@gmail.comwrote: On Friday, December 27, 2013 7:29:22 AM UTC+1, Sean Corfield wrote: On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli How do you decompose large systems in Clojure? I'm curious as to why you think only OOP allows you to decompose large systems? Between namespaces, protocols, multimethods, ad hoc hierarchies, and higher order functions, Clojure has a lot of tools for organizing code... I've never claimed that OOP is the only way to decompose large systems, but since Clojure doesn't support OOP and many languages are multi-paradigm nowadays, I was wondering how you modularize systems in a language which is purely functional. -- -- 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/zwhpqptqV1A/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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.
Re: Is Clojure right for me?
It took us some time to structure the code at the time and now with protocols we went under a other restructuring a year ago. I agree this part can be hard (structuring the code) but at the time we started protocols were not yet there hence some of the restructuring. Best practices also evolved for a couple of years. It's much more stable these days. When I say write some code, well you need to choose a domain aside from simple things like hello world. Which makes it harder to write some code :) but forces you to question yourself about how to do this right the first time. This is the list of my favorite items that I keep an eye on: a) abstractions, choose them according to your business domain, do not try to re-invent the wheel or create alien terminology. This is a starting point to get your name space structure right. b) In your APIs try to stay generic by not assuming implementation details. This step can be hard to achieve. Keep doors opened. c) You may want to redefine the implementations of your abstractions or provide different flavors or some flexibility in your APIs. Protocols/multimethods become handy at some point here. This is the part that may feel a bit like OO but this is the one you have to think last. (remember point a and b) d) Do not hesitate to refactor. There's less code than in most other languages that get some support for refactoring from their IDE so you should not wait until it becomes a mess. If a name space is not rightly named anymore, chane it. If more separation of concerns is required, add/change name spaces accordingly and reorg the code. e) A good indicator of the stability of your APIs is how much your test code gets messed up when you do change something. It could be related to implementation details leaking out, bad choice in name space design, I am not an advocate of TDD but at some point when the code of a name space is stable enough, a few test cases can be used as health signs. f) Search for existing librairies, there are enough of them out there, either Java libs with/wo Clojure wrappers or Clojure centric ones to speed you up not having to rewrite the universe. g) Read the code of the libs you are pulling in as you go along. This will probably light a bulb in your brain about tricks you should apply to your code. The above should sound familiar :) It's not that different in Clojure to me than in many other languages. If you have some specific concerns, send them to me off line. I may share some code privately to answer some of your questions. Sorry for the other folks on this thread but there are copyright issues here :) Luc P. I've seen Clojure in action and I know it's extremely concise and expressive. What I wanted to know is how it copes with complexity when you develop complex systems. You can't get an idea of that just by writing some code and getting a feeling about the language, IMHO. When I studied OOP at University my professors taught me that OOP was extremely successful in reducing the complexity of big systems. I was given many examples of that in the many courses of software engineering I took. FP was relegated to some theoretical courses about paradigms. With such a background it's not easy to accept some of the things the Clojure community claim. The fact that I'm here asking questions should mean that I'm more open minded than most :) But please understand where I'm coming from. On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote: I would add that you *need* to write some code to get a feeling about a new language. Feature comparisons may help you up to a certain degree. However deciding about how efficient you may become using a new language requires you to dive at least a bit into it. Not all brains are wired the same. Luc P. Then we have more in common than you may think :) I learned Ruby first, went through Scala which appeared in the same time frame, all this to pick up the language of choice to replace Java and Ruby which we used to prototype our product. All this took around 9 months including the time to get the prototype working. Choose carefully... :) Luc P. The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs. On Friday, December 27, 2013 3:04:18 AM UTC+1, Luc wrote: This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the
Re: Is Clojure right for me?
On Friday, December 27, 2013 10:02:46 AM UTC-6, Massimiliano Tomassoli wrote: I've seen Clojure in action and I know it's extremely concise and expressive. What I wanted to know is how it copes with complexity when you develop complex systems. My intuition is that getting rid of or reducing mutable state by itself reduces some of the problems of complexity. I'm not against mutability--some things are a lot easier with it--but it's also one of the motivations for modularizing code. One of the purposes of OO is to reduce and constrain dependence on state elsewhere. This is not a full answer because there's still a need for making code modular even with immutability, and because although I've programmed in an FP spirit for a long time, it's only recently, when I started learning Clojure, that I've tried to be more pure about FP. So others will have more insight into what I suggest above. -- -- 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.
Namespaces [was Re: Is Clojure right for me?]
I ended up accidentally injecting a completely different thread of
discussion into the Is Clojure right for me? thread. I'm breaking it
into a separate thread here.
Here's where we left off:
On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway
stuart.hallo...@gmail.comwrote:
Yes, thanks Mark. It seems to me that you are saying namespaces make poor
maps. Stipulated. So why not use records or maps?
This is close, but not exactly what I'm saying. It's not so much about
wanting namespaces to be maps. It's about wanting a robust mechanism for
functions to share information other than threading that information
through the functions.
In Structure and Interpretation of Computer Programming, a large chunk of
the programs are written in a pseudo-object-oriented style, a style which
simulates objects by having functions' closures share the same local
context.
Sure, you could do that with maps:
For example:
(defn create-functions [init-info]
(let [shared-info init-info]
{:foo (fn foo [x] ... body uses shared-info in some way ...),
:bar (fn bar [x] ... body uses shared-info in some way ..)}))
Then, to access these functions, you'd do something like this:
(def instance (create-functions default-info))
((:foo instance) 2) ; the equivalent of instance.foo(2) in OO
((:bar instance) 3) ; the equivalent of instance.bar(3) in OO
Of course, SICP's main point is that even bare-bones Scheme is rich enough
to simulate objects, but the other point is that it is important for
functions to be able to share stat*e* which can be initialized for a group
of functions,
*even if that state is immutable.*
The above pattern is important enough that most languages provide some kind
of mechanism for doing that. Classes are one such pattern.
In Clojure, the above code would be horribly un-idiomatic of course.
Actually, depending on the functions and definitions, it might not even be
possible to structure the code that way (because Clojure's local definition
capabilities are not as rich as what is possible at the global level, for
example, regarding mutual references -- in some contexts, letfn might help,
but not all contexts).
The above example uses associative containers for the shared-info, and
associative containers to hold the group of related functions that are
outputted, but that doesn't make this solution any more attractive --
again, emphasizing that this is not about associative containers.
I claim that Clojure only provides two idiomatic solutions to the above
problem of functions sharing the same immutable information, which might
need to be set prior to using those functions:
Solution 1:
(def ^:dynamic shared-info default-info)
(defn foo [x] ... body uses shared-info)
(defn bar [x] ... body uses shared-info)
Call these functions via:
(foo 2) and (bar 3) if you're happy with the defaults or
(binding [shared-info info] (foo 2)) and
(binding [shared-info info] (bar 3)) otherwise.
This is awkward for several reasons, and sometimes this solution isn't
really an option since functions that return lazy structures won't work
with the above mechanism.
Solution 2:
(defn foo [shared-info x] ... body uses shared-info)
(defn bar [shared-info x] ... body uses shared-info)
Call these functions via:
(foo info 2)
(bar info 3)
My argument is that both these solutions are unsatisfying. Solution 2 is
irritating because if you use a map for shared-info, you end up having to
repeat the destructuring in every single function. Also, you need to
thread this information through all the functions, not only the functions
that directly use, but also the functions that call other functions that
use it. It makes all the functions bulky and awkward, and at the end of
that, you still don't have something that reflects the notion of getting
back a group of functions that share the *same* info -- instead, you have
to remember to always pass in that same info with every function call.
Also, with the threading-the-state version, you don't have a convenient
notion of default state, unless you are willing to take cases on the
number of arguments for every single one of your functions.
My other claim is that Solution 2 feels too heavy-handed for small
projects, or scenarios where it isn't clear you'll ever want to initialize
the shared-info to something other than the defaults, but the path of
transition from Solution 1 to Solution 2 is a painful one.
I think that where my experience differs from yours is summarized in your
comment In Clojure, a project often begins with a bunch of functions
sharing some immutable state or magic constants stored in vars. I
*never* do that. If there are a group of related things, I put them in an
associative container (maybe just a map) on day one.
Even if you share all those constants in an immutable container, I maintain
that the threading of that information through all the functions can be
awkward.
The analogy with OO is misleading here. If you started an OO project
Re: Namespaces [was Re: Is Clojure right for me?]
I posted this in response to the original gist, but it probably wasn't
seen. Does this demonstrate the behavior you want?
https://gist.github.com/johnwalker/8142143
On Friday, December 27, 2013 1:08:49 PM UTC-5, puzzler wrote:
I ended up accidentally injecting a completely different thread of
discussion into the Is Clojure right for me? thread. I'm breaking it
into a separate thread here.
Here's where we left off:
On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway
stuart@gmail.comjavascript:
wrote:
Yes, thanks Mark. It seems to me that you are saying namespaces make
poor maps. Stipulated. So why not use records or maps?
This is close, but not exactly what I'm saying. It's not so much about
wanting namespaces to be maps. It's about wanting a robust mechanism for
functions to share information other than threading that information
through the functions.
In Structure and Interpretation of Computer Programming, a large chunk of
the programs are written in a pseudo-object-oriented style, a style which
simulates objects by having functions' closures share the same local
context.
Sure, you could do that with maps:
For example:
(defn create-functions [init-info]
(let [shared-info init-info]
{:foo (fn foo [x] ... body uses shared-info in some way ...),
:bar (fn bar [x] ... body uses shared-info in some way ..)}))
Then, to access these functions, you'd do something like this:
(def instance (create-functions default-info))
((:foo instance) 2) ; the equivalent of instance.foo(2) in OO
((:bar instance) 3) ; the equivalent of instance.bar(3) in OO
Of course, SICP's main point is that even bare-bones Scheme is rich enough
to simulate objects, but the other point is that it is important for
functions to be able to share stat*e* which can be initialized for a
group of functions,
*even if that state is immutable. *
The above pattern is important enough that most languages provide some
kind of mechanism for doing that. Classes are one such pattern.
In Clojure, the above code would be horribly un-idiomatic of course.
Actually, depending on the functions and definitions, it might not even be
possible to structure the code that way (because Clojure's local definition
capabilities are not as rich as what is possible at the global level, for
example, regarding mutual references -- in some contexts, letfn might help,
but not all contexts).
The above example uses associative containers for the shared-info, and
associative containers to hold the group of related functions that are
outputted, but that doesn't make this solution any more attractive --
again, emphasizing that this is not about associative containers.
I claim that Clojure only provides two idiomatic solutions to the above
problem of functions sharing the same immutable information, which might
need to be set prior to using those functions:
Solution 1:
(def ^:dynamic shared-info default-info)
(defn foo [x] ... body uses shared-info)
(defn bar [x] ... body uses shared-info)
Call these functions via:
(foo 2) and (bar 3) if you're happy with the defaults or
(binding [shared-info info] (foo 2)) and
(binding [shared-info info] (bar 3)) otherwise.
This is awkward for several reasons, and sometimes this solution isn't
really an option since functions that return lazy structures won't work
with the above mechanism.
Solution 2:
(defn foo [shared-info x] ... body uses shared-info)
(defn bar [shared-info x] ... body uses shared-info)
Call these functions via:
(foo info 2)
(bar info 3)
My argument is that both these solutions are unsatisfying. Solution 2 is
irritating because if you use a map for shared-info, you end up having to
repeat the destructuring in every single function. Also, you need to
thread this information through all the functions, not only the functions
that directly use, but also the functions that call other functions that
use it. It makes all the functions bulky and awkward, and at the end of
that, you still don't have something that reflects the notion of getting
back a group of functions that share the *same* info -- instead, you have
to remember to always pass in that same info with every function call.
Also, with the threading-the-state version, you don't have a convenient
notion of default state, unless you are willing to take cases on the
number of arguments for every single one of your functions.
My other claim is that Solution 2 feels too heavy-handed for small
projects, or scenarios where it isn't clear you'll ever want to initialize
the shared-info to something other than the defaults, but the path of
transition from Solution 1 to Solution 2 is a painful one.
I think that where my experience differs from yours is summarized in your
comment In Clojure, a project often begins with a bunch of functions
sharing some immutable state or magic constants stored
Re: Namespaces [was Re: Is Clojure right for me?]
On Fri, Dec 27, 2013 at 1:08 PM, Mark Engelberg mark.engelb...@gmail.comwrote: Solution 2: (defn foo [shared-info x] ... body uses shared-info) (defn bar [shared-info x] ... body uses shared-info) Call these functions via: (foo info 2) (bar info 3) In what way is this any worse than info.foo(2); info.bar(3); which is how OO would do this with methods foo and bar of a common class with an instance info having private data? Only the punctuation and VSO vs. SVO word order differ here. -- -- 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.
Re: Is Clojure right for me?
On Fri, Dec 27, 2013 at 8:02 AM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: When I studied OOP at University my professors taught me that OOP was extremely successful in reducing the complexity of big systems. That's always been the claim about OOP but big systems have an inherent complexity and you can never reduce that - you can just push it around in the system and give the illusion of hiding it. But it's still there. Having done decades of OOP as well as quite a bit of FP both before and after, I don't find OOP to be any more successful at _reducing_ complexity in the real world. I was given many examples of that in the many courses of software engineering I took. Hmm, I've never known any courses that deal with big systems although many of them discussion the _theory_ of dealing with big systems. FP was relegated to some theoretical courses about paradigms. That's unfortunate. I think the shift in education from FP to OOP was actually a bad thing. With such a background it's not easy to accept some of the things the Clojure community claim. With my background I find it hard to accept some of the things the educational OOP community claim :) The reality is that big systems are just plain hard to work with - in any paradigm - and FP provides tools to manage it just like OOP does. They're just _different_ tools. I'm glad you're open minded. For now you'll just have to trust those people who tell you that Clojure lets you deal with big system complexity very well. I'm not sure why you are less trusting of their real world experiences than what your professors told you about (theoretical) OOP... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
We use a lot of configuration information in our product and I mean lot :)
Immutable in regard to the application cycle.
We chose to remove this from each name spaces and instead use a name
space to act as an intermediate to acces it.
It's not as pure as it should be (it's contextually outside of any fn referring
to it)
but since it does not appear to change in the life cycle of the app it's
bearable.
It also useful because we can decide were it's stored. In prod it's in
zookeeper. When running tests, it comes from a memory based implementation
and can be stubbed at will within the tests.
It's also versionned, a change clones the current config and creates a new
one with whatever delta needs to be applied to it.
Passing this stuff around using one of the two methods you have shown
would have been cumbersome and unmaintainable. Most of the time
our configuration information comes from top level fns so the lower
layers remain even more insensitive to how this info is pulled in.
I would not however share state this way using this outside of Clojure
constructs (atom, refs, ...) to handle mutation explicitly.
When the configuration changes it's because the app ends its life cycle and
restarts anyway.
My 2 cents :)
Luc P.
I ended up accidentally injecting a completely different thread of
discussion into the Is Clojure right for me? thread. I'm breaking it
into a separate thread here.
Here's where we left off:
On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway
stuart.hallo...@gmail.comwrote:
Yes, thanks Mark. It seems to me that you are saying namespaces make poor
maps. Stipulated. So why not use records or maps?
This is close, but not exactly what I'm saying. It's not so much about
wanting namespaces to be maps. It's about wanting a robust mechanism for
functions to share information other than threading that information
through the functions.
In Structure and Interpretation of Computer Programming, a large chunk of
the programs are written in a pseudo-object-oriented style, a style which
simulates objects by having functions' closures share the same local
context.
Sure, you could do that with maps:
For example:
(defn create-functions [init-info]
(let [shared-info init-info]
{:foo (fn foo [x] ... body uses shared-info in some way ...),
:bar (fn bar [x] ... body uses shared-info in some way ..)}))
Then, to access these functions, you'd do something like this:
(def instance (create-functions default-info))
((:foo instance) 2) ; the equivalent of instance.foo(2) in OO
((:bar instance) 3) ; the equivalent of instance.bar(3) in OO
Of course, SICP's main point is that even bare-bones Scheme is rich enough
to simulate objects, but the other point is that it is important for
functions to be able to share stat*e* which can be initialized for a group
of functions,
*even if that state is immutable.*
The above pattern is important enough that most languages provide some kind
of mechanism for doing that. Classes are one such pattern.
In Clojure, the above code would be horribly un-idiomatic of course.
Actually, depending on the functions and definitions, it might not even be
possible to structure the code that way (because Clojure's local definition
capabilities are not as rich as what is possible at the global level, for
example, regarding mutual references -- in some contexts, letfn might help,
but not all contexts).
The above example uses associative containers for the shared-info, and
associative containers to hold the group of related functions that are
outputted, but that doesn't make this solution any more attractive --
again, emphasizing that this is not about associative containers.
I claim that Clojure only provides two idiomatic solutions to the above
problem of functions sharing the same immutable information, which might
need to be set prior to using those functions:
Solution 1:
(def ^:dynamic shared-info default-info)
(defn foo [x] ... body uses shared-info)
(defn bar [x] ... body uses shared-info)
Call these functions via:
(foo 2) and (bar 3) if you're happy with the defaults or
(binding [shared-info info] (foo 2)) and
(binding [shared-info info] (bar 3)) otherwise.
This is awkward for several reasons, and sometimes this solution isn't
really an option since functions that return lazy structures won't work
with the above mechanism.
Solution 2:
(defn foo [shared-info x] ... body uses shared-info)
(defn bar [shared-info x] ... body uses shared-info)
Call these functions via:
(foo info 2)
(bar info 3)
My argument is that both these solutions are unsatisfying. Solution 2 is
irritating because if you use a map for shared-info, you end up having to
repeat the destructuring in every single function. Also, you need to
thread this information through all the functions, not only the functions
that directly use, but also the functions that call other functions
Re: Namespaces [was Re: Is Clojure right for me?]
I can think of a couple more alternatives to consider:
;; Turns out you don't need vars for everything.
(let [state {:some :data}]
(defn do-stuff [] (func-of state)))
;; Shifts some burden to the client code
(defn do-stuff-fn [state]
(fn [] (func-of state))
The issue as I see it is a complection of namespaces (DAG of bags of
functions) and individual object lifecycles. The grid size stuff impl is a
function of that particular object (which starts out with a global
lifecycle), whether that's exposed in their signatures or not. If I have
to make it explicit later, I'm willing to accept that work as stemming from
an incorrect initial design. It doesn't bother me to refactor the old in
terms of the new, explicit, versions when I identify something like that,
deleting the old eventually (or not).
Why should functions share information? Parameters and return values give
you inputs and outputs, and if it weren't a little cumbersome to add new
ones we'd be abusing it to bits. Vars are easy, but wrong at times, thus
the tension. Is there something in between the purity and the ease?
I guess I'm willing to accept the immediate costs because of a perceived
larger benefit, namely decoupled designs.
But, I think if we had more functions to dynamically modify scopes as data,
that would get us closer, like 'environment-as-a-value'. Right now, it's
all bound up in private or complicated implementation details.
On Fri, Dec 27, 2013 at 6:35 AM, Softaddicts lprefonta...@softaddicts.cawrote:
We use a lot of configuration information in our product and I mean lot :)
Immutable in regard to the application cycle.
We chose to remove this from each name spaces and instead use a name
space to act as an intermediate to acces it.
It's not as pure as it should be (it's contextually outside of any fn
referring to it)
but since it does not appear to change in the life cycle of the app it's
bearable.
It also useful because we can decide were it's stored. In prod it's in
zookeeper. When running tests, it comes from a memory based implementation
and can be stubbed at will within the tests.
It's also versionned, a change clones the current config and creates a new
one with whatever delta needs to be applied to it.
Passing this stuff around using one of the two methods you have shown
would have been cumbersome and unmaintainable. Most of the time
our configuration information comes from top level fns so the lower
layers remain even more insensitive to how this info is pulled in.
I would not however share state this way using this outside of Clojure
constructs (atom, refs, ...) to handle mutation explicitly.
When the configuration changes it's because the app ends its life cycle and
restarts anyway.
My 2 cents :)
Luc P.
I ended up accidentally injecting a completely different thread of
discussion into the Is Clojure right for me? thread. I'm breaking it
into a separate thread here.
Here's where we left off:
On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway
stuart.hallo...@gmail.comwrote:
Yes, thanks Mark. It seems to me that you are saying namespaces make
poor
maps. Stipulated. So why not use records or maps?
This is close, but not exactly what I'm saying. It's not so much about
wanting namespaces to be maps. It's about wanting a robust mechanism for
functions to share information other than threading that information
through the functions.
In Structure and Interpretation of Computer Programming, a large chunk of
the programs are written in a pseudo-object-oriented style, a style which
simulates objects by having functions' closures share the same local
context.
Sure, you could do that with maps:
For example:
(defn create-functions [init-info]
(let [shared-info init-info]
{:foo (fn foo [x] ... body uses shared-info in some way ...),
:bar (fn bar [x] ... body uses shared-info in some way ..)}))
Then, to access these functions, you'd do something like this:
(def instance (create-functions default-info))
((:foo instance) 2) ; the equivalent of instance.foo(2) in OO
((:bar instance) 3) ; the equivalent of instance.bar(3) in OO
Of course, SICP's main point is that even bare-bones Scheme is rich
enough
to simulate objects, but the other point is that it is important for
functions to be able to share stat*e* which can be initialized for a
group
of functions,
*even if that state is immutable.*
The above pattern is important enough that most languages provide some
kind
of mechanism for doing that. Classes are one such pattern.
In Clojure, the above code would be horribly un-idiomatic of course.
Actually, depending on the functions and definitions, it might not even
be
possible to structure the code that way (because Clojure's local
definition
capabilities are not as rich as what is possible at the global level, for
example, regarding mutual references -- in some
Re: Namespaces [was Re: Is Clojure right for me?]
The thing I like about your record/protocol example version is that all the protocol function implementations can see the components of the record and use those names in the implementation without explicit destructuring. That adds significantly to the ease of working with multiple functions sharing common information. I generally haven't been able to do this kind of thing because: 1. The implementations of the functions are too long to implement inline in the record definition. 2. Protocols are significantly more restricted than regular functions (e.g., aren't they restricted to 4 parameters, no indefinite arities, and no destructuring in the arguments?) On Fri, Dec 27, 2013 at 10:19 AM, john walker john.lou.wal...@gmail.comwrote: I posted this in response to the original gist, but it probably wasn't seen. Does this demonstrate the behavior you want? https://gist.github.com/johnwalker/8142143 -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
On Fri, Dec 27, 2013 at 10:35 AM, Softaddicts lprefonta...@softaddicts.cawrote: Passing this stuff around using one of the two methods you have shown would have been cumbersome and unmaintainable. Most of the time our configuration information comes from top level fns so the lower layers remain even more insensitive to how this info is pulled in. Agreed. Now imagine that one day you realize that you have a problem that can't be solved with one single configuration for the entire lifecycle of the program, but somehow, you have to process and compare results from two configurations simultaneously. What would you do? How painful would that change be? Is there something we can do to make this more feasible in Clojure? -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
On Fri, Dec 27, 2013 at 10:27 AM, Cedric Greevey cgree...@gmail.com wrote: On Fri, Dec 27, 2013 at 1:08 PM, Mark Engelberg mark.engelb...@gmail.comwrote: Solution 2: (defn foo [shared-info x] ... body uses shared-info) (defn bar [shared-info x] ... body uses shared-info) Call these functions via: (foo info 2) (bar info 3) In what way is this any worse than info.foo(2); info.bar(3); In an OO implementation, the definitions of foo and bar could be dramatically more concise because from within the object, references to the other components of the object don't need to be prefixed with info. This is a big deal. In Clojure, the closest comparison is namespaces, which let you use other names from within the same namespace without explicit prefixing. But in Clojure there's no way to combine a namespace's capability for things referring to one another without a prefix with a problem where some of that data can be initialized/configured to different initial values. Contrast that with classes-as-namespaces and you see that there is a mechanism both for things in a class to refer to one another without prefixes, and to easily turn it into something where a constructor sets up some initial values. -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
On Fri, Dec 27, 2013 at 11:03 AM, Gary Trakhman gary.trakh...@gmail.comwrote:
Why should functions share information?
Maybe I'm the odd one out, but every project I've done has at least a few
bits of info shared by many functions. It might be something like
BUFFERSIZE or NUM-THREADS or DATABASE_URL. Basically, they are things I
expect to be unchanged. I separate it out as a var so that I don't have to
repeat the number 30268 everywhere, and I can easily change it for the
whole project if necessary. In the initial design, nothing suggests to me
that {:buffer-size, :number-threads, :database-url} is some data structure
that I should be explicitly passing around and destructuring in all my
functions, just in case some day I decide I want to configurations to exist
simulatenously.
Can we create a path that makes it easier to get from the version where we
expect things to be unchanged to the version where we need to support
multiple configurations?
Vars are easy, but wrong at times, thus the tension. Is there something
in between the purity and the ease?
Exactly.
--
--
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.
Re: Is Clojure right for me?
That makes me think that maybe there's a need for more books about Clojure. There are many introductory books but nothing more advanced such as best practices, patterns, etc... That's maybe a problem for someone like me who wants to do things right from the start. Should I read books about Common LISP and functional programming in general? On Friday, December 27, 2013 5:55:57 PM UTC+1, Luc wrote: It took us some time to structure the code at the time and now with protocols we went under a other restructuring a year ago. I agree this part can be hard (structuring the code) but at the time we started protocols were not yet there hence some of the restructuring. Best practices also evolved for a couple of years. It's much more stable these days. When I say write some code, well you need to choose a domain aside from simple things like hello world. Which makes it harder to write some code :) but forces you to question yourself about how to do this right the first time. This is the list of my favorite items that I keep an eye on: a) abstractions, choose them according to your business domain, do not try to re-invent the wheel or create alien terminology. This is a starting point to get your name space structure right. b) In your APIs try to stay generic by not assuming implementation details. This step can be hard to achieve. Keep doors opened. c) You may want to redefine the implementations of your abstractions or provide different flavors or some flexibility in your APIs. Protocols/multimethods become handy at some point here. This is the part that may feel a bit like OO but this is the one you have to think last. (remember point a and b) d) Do not hesitate to refactor. There's less code than in most other languages that get some support for refactoring from their IDE so you should not wait until it becomes a mess. If a name space is not rightly named anymore, chane it. If more separation of concerns is required, add/change name spaces accordingly and reorg the code. e) A good indicator of the stability of your APIs is how much your test code gets messed up when you do change something. It could be related to implementation details leaking out, bad choice in name space design, I am not an advocate of TDD but at some point when the code of a name space is stable enough, a few test cases can be used as health signs. f) Search for existing librairies, there are enough of them out there, either Java libs with/wo Clojure wrappers or Clojure centric ones to speed you up not having to rewrite the universe. g) Read the code of the libs you are pulling in as you go along. This will probably light a bulb in your brain about tricks you should apply to your code. The above should sound familiar :) It's not that different in Clojure to me than in many other languages. If you have some specific concerns, send them to me off line. I may share some code privately to answer some of your questions. Sorry for the other folks on this thread but there are copyright issues here :) Luc P. I've seen Clojure in action and I know it's extremely concise and expressive. What I wanted to know is how it copes with complexity when you develop complex systems. You can't get an idea of that just by writing some code and getting a feeling about the language, IMHO. When I studied OOP at University my professors taught me that OOP was extremely successful in reducing the complexity of big systems. I was given many examples of that in the many courses of software engineering I took. FP was relegated to some theoretical courses about paradigms. With such a background it's not easy to accept some of the things the Clojure community claim. The fact that I'm here asking questions should mean that I'm more open minded than most :) But please understand where I'm coming from. On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote: I would add that you *need* to write some code to get a feeling about a new language. Feature comparisons may help you up to a certain degree. However deciding about how efficient you may become using a new language requires you to dive at least a bit into it. Not all brains are wired the same. Luc P. Then we have more in common than you may think :) I learned Ruby first, went through Scala which appeared in the same time frame, all this to pick up the language of choice to replace Java and Ruby which we used to prototype our product. All this took around 9 months including the time to get the prototype working. Choose carefully... :) Luc P. The point is that Clojure is not the only modern language out
Re: Namespaces [was Re: Is Clojure right for me?]
I investigated a few of these. Variable arity functions don't some to work, but destructuring and parameter number seem unaffected. https://gist.github.com/johnwalker/8151474 I suspect that what I wrote below is possible with multimethods. (defrecord foobarrecord foobarprotocol :declare foo) (defn :foobarrecord foo [...] ...) This is an excellent issue you've brought up. On Friday, December 27, 2013 2:14:54 PM UTC-5, puzzler wrote: The thing I like about your record/protocol example version is that all the protocol function implementations can see the components of the record and use those names in the implementation without explicit destructuring. That adds significantly to the ease of working with multiple functions sharing common information. I generally haven't been able to do this kind of thing because: 1. The implementations of the functions are too long to implement inline in the record definition. 2. Protocols are significantly more restricted than regular functions (e.g., aren't they restricted to 4 parameters, no indefinite arities, and no destructuring in the arguments?) On Fri, Dec 27, 2013 at 10:19 AM, john walker john.lo...@gmail.comjavascript: wrote: I posted this in response to the original gist, but it probably wasn't seen. Does this demonstrate the behavior you want? https://gist.github.com/johnwalker/8142143 -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
We have a good basis with versioning. 99% of the time, workers are the ones accessing the configuration. They are at the top level. It happens that they do access configuration through the workers service name space. In fact through a single fn ... Passing a version number when pulling out a resource is feasible. This could override the default (the current config established at startup). I want to make it clear, we never intended to do this BUT it happens that we need a way to compare configs. It's not implemented yet. It maybe more or less an unconscious design decision that makes it easy to implement. Versioning is mainly a way for us to revert back to previous configs but it's also a way to fake an immutable config state. It's an operational requirement more than a code or design issue. Luc P. On Fri, Dec 27, 2013 at 10:35 AM, Softaddicts lprefonta...@softaddicts.cawrote: Passing this stuff around using one of the two methods you have shown would have been cumbersome and unmaintainable. Most of the time our configuration information comes from top level fns so the lower layers remain even more insensitive to how this info is pulled in. Agreed. Now imagine that one day you realize that you have a problem that can't be solved with one single configuration for the entire lifecycle of the program, but somehow, you have to process and compare results from two configurations simultaneously. What would you do? How painful would that change be? Is there something we can do to make this more feasible in Clojure? -- -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
On Fri, Dec 27, 2013 at 2:03 PM, Gary Trakhman gary.trakh...@gmail.com wrote: The issue as I see it is a complection of namespaces (DAG of bags of functions) and individual object lifecycles. The grid size stuff impl is a This is a very fair point, and something people have worked on Check out https://github.com/juxt/jig https://github.com/stuartsierra/component and http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
On Fri 27 Dec 2013 at 11:40:45AM -0800, Mark Engelberg wrote: On Fri, Dec 27, 2013 at 11:03 AM, Gary Trakhman gary.trakh...@gmail.comwrote: Why should functions share information? Maybe I'm the odd one out, but every project I've done has at least a few bits of info shared by many functions. It might be something like BUFFERSIZE or NUM-THREADS or DATABASE_URL. In OO systems we typically have an Application class with a constructor that receives a map of configuration values. This allows more flexibility than defining static constants as the methods of our Application class close over the instance values. We can achieve the same thing in Clojure, but creating closures over dynamic configuration values is difficult to reconcile with REPL driven development. Typically then, the Clojurist chooses to store these instance values in vars, which creates the tension described in this thread. Stuart Sierra has been thinking quite a bit about this issue, and I think he's developed a great solution: https://github.com/stuartsierra/component/ Designing a system as outlined above results in a modular application with the benefits of an instance constructor, while still allowing easy access from the REPL via a single var bound to the current running instance of the application. I encourage everyone to look into it; I have had great success with it so far. (Thanks Stuart!) guns pgp8B_Qd2JTzv.pgp Description: PGP signature
Re: Namespaces [was Re: Is Clojure right for me?]
On Fri, Dec 27, 2013 at 2:32 PM, Mark Engelberg mark.engelb...@gmail.comwrote:
On Fri, Dec 27, 2013 at 10:27 AM, Cedric Greevey cgree...@gmail.comwrote:
On Fri, Dec 27, 2013 at 1:08 PM, Mark Engelberg mark.engelb...@gmail.com
wrote:
Solution 2:
(defn foo [shared-info x] ... body uses shared-info)
(defn bar [shared-info x] ... body uses shared-info)
Call these functions via:
(foo info 2)
(bar info 3)
In what way is this any worse than
info.foo(2);
info.bar(3);
In an OO implementation, the definitions of foo and bar could be
dramatically more concise because from within the object, references to the
other components of the object don't need to be prefixed with info. This
is a big deal.
Erm,
(defn foo [{:keys [thingy mumble fiddly]} x]
(...thingy ... mumble ... fiddly ... mumble ... mumble ... x ... thingy
...))
After from one brief incantation in the parameter list you can just go
ahead and refer to the fields like in an OO method body.
There's also protocol + defrecord and record fields referenced in the
function bodies in the defrecord.
--
--
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.
Re: Namespaces [was Re: Is Clojure right for me?]
This works (clever hack!), but you would have to reduplicate the keys in
(defn bar [..]...), (defn baz [...] ...) etc.
On Friday, December 27, 2013 3:05:24 PM UTC-5, Cedric Greevey wrote:
On Fri, Dec 27, 2013 at 2:32 PM, Mark Engelberg
mark.en...@gmail.comjavascript:
wrote:
On Fri, Dec 27, 2013 at 10:27 AM, Cedric Greevey
cgre...@gmail.comjavascript:
wrote:
On Fri, Dec 27, 2013 at 1:08 PM, Mark Engelberg
mark.en...@gmail.comjavascript:
wrote:
Solution 2:
(defn foo [shared-info x] ... body uses shared-info)
(defn bar [shared-info x] ... body uses shared-info)
Call these functions via:
(foo info 2)
(bar info 3)
In what way is this any worse than
info.foo(2);
info.bar(3);
In an OO implementation, the definitions of foo and bar could be
dramatically more concise because from within the object, references to the
other components of the object don't need to be prefixed with info. This
is a big deal.
Erm,
(defn foo [{:keys [thingy mumble fiddly]} x]
(...thingy ... mumble ... fiddly ... mumble ... mumble ... x ... thingy
...))
After from one brief incantation in the parameter list you can just go
ahead and refer to the fields like in an OO method body.
There's also protocol + defrecord and record fields referenced in the
function bodies in the defrecord.
--
--
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.
Re: Is Clojure right for me?
On Friday, December 27, 2013 7:31:25 PM UTC+1, Sean Corfield wrote: I'm not sure why you are less trusting of their real world experiences than what your professors told you about (theoretical) OOP... First, someone said that OOP doesn't alleviate the problems that it's supposed to solve and this I don't believe. Then, someone else claimed that OOP is useless in presence of immutability. I don't agree with that. It would also imply that Scala's developers are just plain stupid. So I was under the impression that you were criticizing something you didn't fully understand. Also, it's difficult to trust someone who claim that LISP is the best language there is and everybody else is just stupid for not realizing that. I only tend to trust people who realize that their language is not perfect and is just one of the many languages available. -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
On Fri, Dec 27, 2013 at 3:13 PM, john walker john.lou.wal...@gmail.comwrote:
This works (clever hack!), but you would have to reduplicate the keys in
(defn bar [..]...), (defn baz [...] ...) etc.
(defmacro defthingyfn [name arglist body]
`(defn name ~(vec (cons '{:keys [thingy mumble fiddly]} arglist)) ~@body))
(defthingyfn foo [x]
(...thingy ... mumble ... fiddly ... mumble ... mumble ... x ... thingy
...))
(defthingyfn bar [x]
(...mumble ... thingy ... mumble ... mumble ... x ... thingy ... fiddly
... thingy ...))
...
(Extending that to cope with docstrings and multiple arities is left as an
exercise for the reader. :))
--
--
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.
Re: Is Clojure right for me?
On Fri, Dec 27, 2013 at 12:24 PM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: First, someone said that OOP doesn't alleviate the problems that it's supposed to solve and this I don't believe. There is no silver bullet: OOP helps with some problems in some ways but it's not perfect. The folks who pioneered OOP didn't imagine it would turn into C++ or Java... Then, someone else claimed that OOP is useless in presence of immutability. I don't think anyone claimed that. There was a comment that encapsulation is less important in the presence of immutability. Encapsulation is only one aspect of OOP - and Clojure provides several ways to encapsulate data if you want to do that. So I was under the impression that you were criticizing something you didn't fully understand. Perhaps you've been convinced otherwise now? I feel that I understand OOP pretty well after two decades of using several OOP languages to deliver production systems - and helping to design parts of C++, and building a C++ compiler :) Also, it's difficult to trust someone who claim that LISP is the best language there is and everybody else is just stupid for not realizing that. Well, that's the Smug Lisp Weenie and part of the Lisp Curse [1]. I think there's an OOP equivalent but it doesn't get written about very much because OOP is so mainstream, despite its flaws. [1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Re: Is Clojure right for me?
I am kind of old school. To me these things come through practice... Which I understand maybe of little help to you in the immediate future :) When I was young we had many books that had little to do with the ones mostly available today. (Learn xxx in nnn days) Looks to me that this is the missing piece in the puzzle. Not sure that this kind of book would be popular these days. Luc P. That makes me think that maybe there's a need for more books about Clojure. There are many introductory books but nothing more advanced such as best practices, patterns, etc... That's maybe a problem for someone like me who wants to do things right from the start. Should I read books about Common LISP and functional programming in general? On Friday, December 27, 2013 5:55:57 PM UTC+1, Luc wrote: It took us some time to structure the code at the time and now with protocols we went under a other restructuring a year ago. I agree this part can be hard (structuring the code) but at the time we started protocols were not yet there hence some of the restructuring. Best practices also evolved for a couple of years. It's much more stable these days. When I say write some code, well you need to choose a domain aside from simple things like hello world. Which makes it harder to write some code :) but forces you to question yourself about how to do this right the first time. This is the list of my favorite items that I keep an eye on: a) abstractions, choose them according to your business domain, do not try to re-invent the wheel or create alien terminology. This is a starting point to get your name space structure right. b) In your APIs try to stay generic by not assuming implementation details. This step can be hard to achieve. Keep doors opened. c) You may want to redefine the implementations of your abstractions or provide different flavors or some flexibility in your APIs. Protocols/multimethods become handy at some point here. This is the part that may feel a bit like OO but this is the one you have to think last. (remember point a and b) d) Do not hesitate to refactor. There's less code than in most other languages that get some support for refactoring from their IDE so you should not wait until it becomes a mess. If a name space is not rightly named anymore, chane it. If more separation of concerns is required, add/change name spaces accordingly and reorg the code. e) A good indicator of the stability of your APIs is how much your test code gets messed up when you do change something. It could be related to implementation details leaking out, bad choice in name space design, I am not an advocate of TDD but at some point when the code of a name space is stable enough, a few test cases can be used as health signs. f) Search for existing librairies, there are enough of them out there, either Java libs with/wo Clojure wrappers or Clojure centric ones to speed you up not having to rewrite the universe. g) Read the code of the libs you are pulling in as you go along. This will probably light a bulb in your brain about tricks you should apply to your code. The above should sound familiar :) It's not that different in Clojure to me than in many other languages. If you have some specific concerns, send them to me off line. I may share some code privately to answer some of your questions. Sorry for the other folks on this thread but there are copyright issues here :) Luc P. I've seen Clojure in action and I know it's extremely concise and expressive. What I wanted to know is how it copes with complexity when you develop complex systems. You can't get an idea of that just by writing some code and getting a feeling about the language, IMHO. When I studied OOP at University my professors taught me that OOP was extremely successful in reducing the complexity of big systems. I was given many examples of that in the many courses of software engineering I took. FP was relegated to some theoretical courses about paradigms. With such a background it's not easy to accept some of the things the Clojure community claim. The fact that I'm here asking questions should mean that I'm more open minded than most :) But please understand where I'm coming from. On Friday, December 27, 2013 3:50:23 PM UTC+1, Luc wrote: I would add that you *need* to write some code to get a feeling about a new language. Feature comparisons may help you up to a certain degree. However deciding about how efficient you may become using a new language requires you to dive at least a bit into it. Not all brains are wired the same. Luc P. Then
Re: Is Clojure right for me?
With a little searching, you can find several papers like this one that research the question of whether OO has lived up to the hype: http://scholarworks.gvsu.edu/cgi/viewcontent.cgi?article=1129context=cistechlib Feel free to jump straight to the conclusion, i.e., object-oriented technology has only partly kept its promises. If you want to use OO in its traditional form, there are many languages that will support you in doing that. Clojure is not one of them. If you want to join a community of people who are dissatisfied with OO, and feel they are working towards a better way, with better tools for reuse and managing complexity, give Clojure a try. It's entirely your choice. No one's making you do anything. -- -- 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.
Re: Is Clojure right for me?
Err, a lot of these questions are quite open in nature. I don't think anyone in software engineering has great answers - see Everything is an Object for Javaland and then some of the proposals in Doug Hoyte's Let Over Lambda (an excellent read if you're after Common Lisp books and recognize the high-mindedness). These topics should then probably be reframed with additional context. I probably sound like a broken record, but I strongly feel that you should ask for examples of large projects and look for yourself to see how they're engineered. Umm, I hope that no one actually said that Lisp is the perfect language and everyone else is stupid or that OOP is useless with immutability. What are some flaws that you think Clojure has? : ) On Friday, December 27, 2013 3:24:56 PM UTC-5, Massimiliano Tomassoli wrote: On Friday, December 27, 2013 7:31:25 PM UTC+1, Sean Corfield wrote: I'm not sure why you are less trusting of their real world experiences than what your professors told you about (theoretical) OOP... First, someone said that OOP doesn't alleviate the problems that it's supposed to solve and this I don't believe. Then, someone else claimed that OOP is useless in presence of immutability. I don't agree with that. It would also imply that Scala's developers are just plain stupid. So I was under the impression that you were criticizing something you didn't fully understand. Also, it's difficult to trust someone who claim that LISP is the best language there is and everybody else is just stupid for not realizing that. I only tend to trust people who realize that their language is not perfect and is just one of the many languages available. -- -- 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.
Re: Is Clojure right for me?
Luc, I've just got to say, your tiny margin widths always make me think your message is some kind of haiku :) On Fri, Dec 27, 2013 at 1:08 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: I am kind of old school. To me these things come through practice... Which I understand maybe of little help to you in the immediate future :) -- -- 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.
Re: Is Clojure right for me?
brain-dump TLDR: I like clojure's costs-to-benefits.. and it's successful because it's what the industry needs. I wouldn't say lisp family langs are the 'best' languages, but I would say its tradeoffs maximize the power of the individual, which interests me since I am one :-). Talking about tradeoffs can get very verbose, but I find it helpful to make an analogy for things like mutability/immutability as a number line. Let's think of some tradeoffs and virtues, it's not always black/white or bad/good: regularity/expressiveness type-safety/dynamicity mutability/immutability speed code size (language implementation or generated) 'weight of an abstraction' (ie how hard/big is it to jump a level of expressiveness) orthogonality of feature-set (pay for what you use) popularity blub-ability (do you need to be an expert to program in it?) team-suitability Then we can start to think of it as quantities, a vector. We can subjectively normalize these for orthogonality, eg.. for some languages, some tradeoffs will interact more with others in practice, and we can come up with a cost-model according to our usage. Then programming in this language can be thought of as a projection (dot-product) of our minds along this vector space over time. These tradeoffs affect 'costs', ie time/money/effort. There is a fixed cost to learning clojure well enough (IME the time it takes to grok Joy of Clojure, implementation details like core.clj and Compiler.java, learning enough emacs to get by), and little recurring costs along the way (like how hard it is to refactor something). In my opinion, I love clojure because of the orthogonality of its feature-set (design by decoupling) and because of the expressivity of lisp itself, that outweighs everything else. Its code has a high SNR because of it. I think s-expressions are the closest thing to how brains actually work, ie it's an efficient way to 'project' at any level of abstraction, and the cost of traversing abstractions up and down is low due to the regularity of the syntax. Scheme makes a good teaching language because there are benefits to seeing the structure directly. We know from experience that restricting abstraction is bad (java). So, I'm pretty satisfied with it, I might learn other languages for specific use-cases, but I think time spent in lisp isn't wasted, since it's easy to pull an abstraction out of anything repetitive, and we as users can steal ideas from other languages more effectively without involvement from compiler writers. A new language becomes necessary when we have to revisit core primitives, which we will be compelled to do once we identify certain costs are too high for too many people. People might have different ideals, use-cases or costs based on their experience or situation.' I think the curation approach of 'design by decoupling' turned out to be a great idea simply because of the huge amount of stuff that's been written by many people in isolation over the last decades. If we took it to an extreme, then it would also cease to be a good idea. I think C++/Java-style OO has already been taken as far as it needs to go. We've reached the point where the costs-to-benefits are well-understood and felt to be lacking for many current and future use-cases. On Fri, Dec 27, 2013 at 8:24 AM, Massimiliano Tomassoli kiuhn...@gmail.comwrote: On Friday, December 27, 2013 7:31:25 PM UTC+1, Sean Corfield wrote: I'm not sure why you are less trusting of their real world experiences than what your professors told you about (theoretical) OOP... First, someone said that OOP doesn't alleviate the problems that it's supposed to solve and this I don't believe. Then, someone else claimed that OOP is useless in presence of immutability. I don't agree with that. It would also imply that Scala's developers are just plain stupid. So I was under the impression that you were criticizing something you didn't fully understand. Also, it's difficult to trust someone who claim that LISP is the best language there is and everybody else is just stupid for not realizing that. I only tend to trust people who realize that their language is not perfect and is just one of the many languages available. -- -- 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. -- -- You received this message because you
Re: Is Clojure right for me?
Maybe it would be helpful to define what exactly you mean by OOP. Use this list: http://www.paulgraham.com/reesoo.html Clojure supports some of the constructs that people typically relate to OOP. Decomposing large systems: How do you decompose large systems with OOP? By using classes and objects? I don't believe that classes and objects tell you much about how to structure systems (comprised of multiple subsystems). It tells you more about how to view the software you are writing at a small scale, and it tells you how to build a mental image of your programs. In any case, you can use established principles in Clojure programming that transcends language paradigms, e.g., hiding implementation details, creating well-defined interfaces and data structures, separating concerns (making things simple, as they say in the Clojure community). If you are hoping to find a feature set in Clojure that matches what you are already familiar with, you may end up disappointed. Is Clojure the right language for you? It probably depends mostly on personal taste and willingness to change perspective. Best regards, Patrick -- -- 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.
Re: Is Clojure right for me?
Given your goals of evaluating the language quickly, not having a lot of free time to devote to it, and having to get productive fast in a web environment, I think a better avenue to explore would be Groovyhttp://groovy.codehaus.org/alongside Spring Boothttp://spring.io/blog/2013/08/06/spring-boot-simplifying-spring-for-everyoneor Ratpack http://www.infoq.com/presentations/Ratpack. It's concise, close to Java OO, and yet have functional programming features and metaprogramming facilities. On Friday, December 27, 2013 7:54:44 AM UTC-5, Massimiliano Tomassoli wrote: The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs. -- -- 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.
Re: Is Clojure right for me?
Been writing these on my iPhone most of the day and if I do not cut lines myself, it looks pretty ugly on my side :) I am pretty bad at writing poetry, glad to see I could fake at it :) Luc P. Luc, I've just got to say, your tiny margin widths always make me think your message is some kind of haiku :) On Fri, Dec 27, 2013 at 1:08 PM, Luc Prefontaine lprefonta...@softaddicts.ca wrote: I am kind of old school. To me these things come through practice... Which I understand maybe of little help to you in the immediate future :) -- -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
+1 for Stuart's component lib. I've been using it a lot in my day job and
it works quite well. It also serves as a reminder not to throw global
config values into vars. Building code that works well with the library
makes it less natural to put random state values in globals.
Timothy
On Fri, Dec 27, 2013 at 1:25 PM, Cedric Greevey cgree...@gmail.com wrote:
On Fri, Dec 27, 2013 at 3:13 PM, john walker john.lou.wal...@gmail.comwrote:
This works (clever hack!), but you would have to reduplicate the keys in
(defn bar [..]...), (defn baz [...] ...) etc.
(defmacro defthingyfn [name arglist body]
`(defn name ~(vec (cons '{:keys [thingy mumble fiddly]} arglist))
~@body))
(defthingyfn foo [x]
(...thingy ... mumble ... fiddly ... mumble ... mumble ... x ... thingy
...))
(defthingyfn bar [x]
(...mumble ... thingy ... mumble ... mumble ... x ... thingy ... fiddly
... thingy ...))
...
(Extending that to cope with docstrings and multiple arities is left as an
exercise for the reader. :))
--
--
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.
Re: Namespaces [was Re: Is Clojure right for me?]
On 27 December 2013 18:08, Mark Engelberg mark.engelb...@gmail.com wrote: On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway stuart.hallo...@gmail.com wrote: Yes, thanks Mark. It seems to me that you are saying namespaces make poor maps. Stipulated. So why not use records or maps? This is close, but not exactly what I'm saying. It's not so much about wanting namespaces to be maps. It's about wanting a robust mechanism for functions to share information other than threading that information through the functions. In Structure and Interpretation of Computer Programming, a large chunk of the programs are written in a pseudo-object-oriented style, a style which simulates objects by having functions' closures share the same local context. What sort of local context did you imagine sharing? I can't think of any instance where I've needed to share the *same* context between functions. I find that internal functions will typically end up with a small subset of the configuration passed to a top-level component. It's also fairly rare that I find any configuration placed in var, as generally the configuration I deal with are specific to a particular deployment, such as database URLs, API keys and the like. - James -- -- 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.
Re: Is Clojure right for me?
On Friday, December 27, 2013 10:07:14 PM UTC+1, Sean Corfield wrote: On Fri, Dec 27, 2013 at 12:24 PM, Massimiliano Tomassoli So I was under the impression that you were criticizing something you didn't fully understand. Perhaps you've been convinced otherwise now? I feel that I understand OOP pretty well after two decades of using several OOP languages to deliver production systems - and helping to design parts of C++, and building a C++ compiler :) Yes. I wasn't speaking of you in particular and mine was just a first impression. Now I'm ready to start learning Clojure and find out if it is really as powerful as you say. I must admit I don't like its syntax (or absence of it), but I hope to get used to it. -- -- 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.
Re: Is Clojure right for me?
On Friday, December 27, 2013 10:12:06 PM UTC+1, john walker wrote: What are some flaws that you think Clojure has? : ) I don't even know the language yet! :) -- -- 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.
Re: Is Clojure right for me?
On Friday, December 27, 2013 10:47:35 PM UTC+1, Jeff Heon wrote: Given your goals of evaluating the language quickly, not having a lot of free time to devote to it, and having to get productive fast in a web environment, I think a better avenue to explore would be Groovyhttp://groovy.codehaus.org/alongside Spring Boothttp://www.google.com/url?q=http%3A%2F%2Fspring.io%2Fblog%2F2013%2F08%2F06%2Fspring-boot-simplifying-spring-for-everyonesa=Dsntz=1usg=AFQjCNEO8WjhSuoe4am7HR-H9tI3nvzAVAor Ratpack http://www.infoq.com/presentations/Ratpack. It's concise, close to Java OO, and yet have functional programming features and metaprogramming facilities. I already know Python. As my next language I want to try something radically different like F#, Scala or Clojure, but thanks for the suggestion. -- -- 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.
Re: Is Clojure right for me?
On Friday, December 27, 2013 6:27:34 PM UTC-6, Massimiliano Tomassoli wrote: I must admit I don't like its syntax (or absence of it), but I hope to get used to it. This is understandable. I think that the things that are most important for becoming comfortable with the syntax, other than experience, are using an editor that matches parentheses, and learning (Clojure-style) Lisp pretty-printing. If you can use an editor that has a plugin that will do the pretty-printing for you, that's even better. -- -- 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.
Re: Is Clojure right for me?
On Saturday, December 28, 2013 2:26:17 AM UTC+1, Mars0i wrote: On Friday, December 27, 2013 6:27:34 PM UTC-6, Massimiliano Tomassoli wrote: I must admit I don't like its syntax (or absence of it), but I hope to get used to it. This is understandable. I think that the things that are most important for becoming comfortable with the syntax, other than experience, are using an editor that matches parentheses, and learning (Clojure-style) Lisp pretty-printing. If you can use an editor that has a plugin that will do the pretty-printing for you, that's even better. I'm using eclipse + counterclockwise. -- -- 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.
Re: Is Clojure right for me?
Hi Massimiliano, Perhaps I'm a bit late to this thread but let me offer an opinion going in the opposite direction. Basically, if the web development you have in mind fits squarely within the use case addressed by RoR or Django or something like that, then I expect you will find one of those frameworks is more productive than the Clojure web stack. The reason has nothing to do with FP vs OOP, or anything so grand. It's just that the Clojure web dev ecosystem doesn't offer the same depth of mature, ready-to-go components. I'm thinking of meat and potatoes things like administrative interfaces, user account management, user authentication systems, forgot-my-password workflows, etc.. Yes you can build what you need yourself. And, quite possibly, maybe you can build it from scratch in Clojure faster than in another language. But building it from scratch in Clojure will still be slower than downloading a widely-used framework in another language. I expect this difference will be especially strong if you're working on relatively small projects with conventional requirements, since those are most likely to be handled by frameworks in other languages. As projects become larger and more customized, then Clojure becomes a better choice because of the strength of the language fundamentals. All of this is not because Clojure is immature. It's just because it's not what most people are using the language for. I have the impression (I could be wrong) that more people use Clojure to build API endpoints, or to perform some kind of compute service behind an endpoint. If you do want to go ahead with Clojure for web development, then there are a number of great projects that give good examples of the current state of things: luminusweb, caribou, pedestal, etc.. I also found that the books Clojure Programming and Web Development in Clojure both had good discussions of how to do it. Anyway, this is the opinion I came to over the last couple months, diving into Clojure web development on a real project for the first time, after already being familiar with the language but new to its web stack. But I could be wrong. For instance, I've never used RoR seriously, so it may be I'm overestimating the quality of what you get out of the box doing it that way. A On Wednesday, December 25, 2013 1:06:20 PM UTC-8, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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.
Re: Namespaces [was Re: Is Clojure right for me?]
James Reeves has got it. It's same for me. All this boils down to really
knowing the language. Knowing how to make music with the instruments
provided. For me Clojure's namespaces has been one of the most wonderful
things that has happened to me in programming. It has facilitated all kinds
of evaluation environments. I've never had such issues as yours.
Configuration management is one of the easiest things to do in Clojure. I
think what I would offer in this case is the word, Refactor. One thing I
noticed about your examples is that your functions lack composition. Think
that way and maybe you'll stop having the problems you're having because if
you're not careful it won't be long before you start thinking of
inheritance as well.
On Friday, December 27, 2013 7:08:49 PM UTC+1, puzzler wrote:
I ended up accidentally injecting a completely different thread of
discussion into the Is Clojure right for me? thread. I'm breaking it
into a separate thread here.
Here's where we left off:
On Fri, Dec 27, 2013 at 6:34 AM, Stuart Halloway
stuart@gmail.comjavascript:
wrote:
Yes, thanks Mark. It seems to me that you are saying namespaces make
poor maps. Stipulated. So why not use records or maps?
This is close, but not exactly what I'm saying. It's not so much about
wanting namespaces to be maps. It's about wanting a robust mechanism for
functions to share information other than threading that information
through the functions.
In Structure and Interpretation of Computer Programming, a large chunk of
the programs are written in a pseudo-object-oriented style, a style which
simulates objects by having functions' closures share the same local
context.
Sure, you could do that with maps:
For example:
(defn create-functions [init-info]
(let [shared-info init-info]
{:foo (fn foo [x] ... body uses shared-info in some way ...),
:bar (fn bar [x] ... body uses shared-info in some way ..)}))
Then, to access these functions, you'd do something like this:
(def instance (create-functions default-info))
((:foo instance) 2) ; the equivalent of instance.foo(2) in OO
((:bar instance) 3) ; the equivalent of instance.bar(3) in OO
Of course, SICP's main point is that even bare-bones Scheme is rich enough
to simulate objects, but the other point is that it is important for
functions to be able to share stat*e* which can be initialized for a
group of functions,
*even if that state is immutable. *
The above pattern is important enough that most languages provide some
kind of mechanism for doing that. Classes are one such pattern.
In Clojure, the above code would be horribly un-idiomatic of course.
Actually, depending on the functions and definitions, it might not even be
possible to structure the code that way (because Clojure's local definition
capabilities are not as rich as what is possible at the global level, for
example, regarding mutual references -- in some contexts, letfn might help,
but not all contexts).
The above example uses associative containers for the shared-info, and
associative containers to hold the group of related functions that are
outputted, but that doesn't make this solution any more attractive --
again, emphasizing that this is not about associative containers.
I claim that Clojure only provides two idiomatic solutions to the above
problem of functions sharing the same immutable information, which might
need to be set prior to using those functions:
Solution 1:
(def ^:dynamic shared-info default-info)
(defn foo [x] ... body uses shared-info)
(defn bar [x] ... body uses shared-info)
Call these functions via:
(foo 2) and (bar 3) if you're happy with the defaults or
(binding [shared-info info] (foo 2)) and
(binding [shared-info info] (bar 3)) otherwise.
This is awkward for several reasons, and sometimes this solution isn't
really an option since functions that return lazy structures won't work
with the above mechanism.
Solution 2:
(defn foo [shared-info x] ... body uses shared-info)
(defn bar [shared-info x] ... body uses shared-info)
Call these functions via:
(foo info 2)
(bar info 3)
My argument is that both these solutions are unsatisfying. Solution 2 is
irritating because if you use a map for shared-info, you end up having to
repeat the destructuring in every single function. Also, you need to
thread this information through all the functions, not only the functions
that directly use, but also the functions that call other functions that
use it. It makes all the functions bulky and awkward, and at the end of
that, you still don't have something that reflects the notion of getting
back a group of functions that share the *same* info -- instead, you have
to remember to always pass in that same info with every function call.
Also, with the threading-the-state version, you don't have a convenient
notion of default state, unless you
Re: Is Clojure right for me?
What sort of web development were you planning to do? - James On 25 December 2013 21:06, Massimiliano Tomassoli kiuhn...@gmail.comwrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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. -- -- 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.
Re: Is Clojure right for me?
I'm still partial to Ring. On Thu, Dec 26, 2013 at 2:16 AM, James Reeves ja...@booleanknot.com wrote: What sort of web development were you planning to do? - James On 25 December 2013 21:06, Massimiliano Tomassoli kiuhn...@gmail.comwrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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. -- -- 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. -- -- 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.
Re: Is Clojure right for me?
On 26 December 2013 12:24, Massimiliano Tomassoli kiuhn...@gmail.comwrote: On Thursday, December 26, 2013 11:16:07 AM UTC+1, James Reeves wrote: What sort of web development were you planning to do? I'd like to build websites. What kind depends on what my clients need. My recent Clojure web development has revolved around web services, either internally as part of a larger system, or as an external-facing API. Clojure is well-equipped in this area. I can offer less advice around the classic RoR use-case of a form-based website with a SQL back end. Most of the things I work on doesn't overlap much with that architecture. - James -- -- 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.
Re: Is Clojure right for me?
Hi Massimiliano. The absence of a well-established framework for web development in Clojure is not a sign of its immaturity (rather the opposite). Web frameworks can give you some increased productivity to begin with, but as soon as you need to do something that isn't naturally supported by your chosen web framework you're in trouble, and that's when productivity drops off a cliff as you struggle to bend the web framework to your requirements. For example, you choose a web framework with good REST support, then find out later you need to add web sockets. I've written and deployed about a dozen serious web applications using Clojure. My opinion is the best strategy that guarantees long-term productivity is to build your system from a set of smaller components that you choose 'a la carte'. That way, if your requirements change you can swap in and out other components as you need to. I would guess that the vast majority of Clojure web applications are written this way, which is why you don't see widescale adoption of a particular web 'framework' by the Clojure community. Instead, Clojure developers pick from a set of constituent parts: Jetty, http-kit, Ring, Compojure, Hiccup, Enlive, Stencil, Liberator, domina, dommy, C2, Om, shameless-plugbidi/shameless-plug, and so on and so on. The fact that these components all fit together so well is one of the truly outstanding features of the Clojure platform. Few languages come close to this level of integration, which is why they actively curate frameworks. Investing time in Clojure is both pleasurable and productive. It's a question of whether you want 'short-term' productivity to meet a particular project goal (choose a web framework), or sustainable productivity to deliver value to your users over the longer term (choose to learn, understand and utilize a set of components from the wide pool that the Clojure community has created). Regards, Malcolm On Wednesday, December 25, 2013 9:06:20 PM UTC, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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.
Re: Is Clojure right for me?
Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure? On Thursday, December 26, 2013 2:52:26 PM UTC+1, Malcolm Sparks wrote: Hi Massimiliano. The absence of a well-established framework for web development in Clojure is not a sign of its immaturity (rather the opposite). Web frameworks can give you some increased productivity to begin with, but as soon as you need to do something that isn't naturally supported by your chosen web framework you're in trouble, and that's when productivity drops off a cliff as you struggle to bend the web framework to your requirements. For example, you choose a web framework with good REST support, then find out later you need to add web sockets. I've written and deployed about a dozen serious web applications using Clojure. My opinion is the best strategy that guarantees long-term productivity is to build your system from a set of smaller components that you choose 'a la carte'. That way, if your requirements change you can swap in and out other components as you need to. I would guess that the vast majority of Clojure web applications are written this way, which is why you don't see widescale adoption of a particular web 'framework' by the Clojure community. Instead, Clojure developers pick from a set of constituent parts: Jetty, http-kit, Ring, Compojure, Hiccup, Enlive, Stencil, Liberator, domina, dommy, C2, Om, shameless-plugbidi/shameless-plug, and so on and so on. The fact that these components all fit together so well is one of the truly outstanding features of the Clojure platform. Few languages come close to this level of integration, which is why they actively curate frameworks. Investing time in Clojure is both pleasurable and productive. It's a question of whether you want 'short-term' productivity to meet a particular project goal (choose a web framework), or sustainable productivity to deliver value to your users over the longer term (choose to learn, understand and utilize a set of components from the wide pool that the Clojure community has created). Regards, Malcolm On Wednesday, December 25, 2013 9:06:20 PM UTC, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 11:16:07 AM UTC+1, James Reeves wrote: What sort of web development were you planning to do? I'd like to build websites. What kind depends on what my clients need. -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 7:55:05 AM UTC+1, Devin Walters (devn) wrote: http://hoplon.io/#/home/ http://caribou.github.io/caribou/docs/outline.html On Thursday, December 26, 2013 at 12:26 AM, tao wrote: http://pedestal.io/ http://www.luminusweb.net/ Why so many frameworks? It's difficult to decide which one to use and you'll find fewer people that use the same framework and can answer your questions. -- -- 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.
Re: Is Clojure right for me?
Yes, I feel framework is a patch to a language. Use framework can do some thing productively, but also limit you do some thing poorly. Prefer Libraries to Frameworks http://blog.getprismatic.com/blog/2012/4/5/software-engineering-at-prismatic.html -- tao Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, December 26, 2013 at 9:52 PM, Malcolm Sparks wrote: Hi Massimiliano. The absence of a well-established framework for web development in Clojure is not a sign of its immaturity (rather the opposite). Web frameworks can give you some increased productivity to begin with, but as soon as you need to do something that isn't naturally supported by your chosen web framework you're in trouble, and that's when productivity drops off a cliff as you struggle to bend the web framework to your requirements. For example, you choose a web framework with good REST support, then find out later you need to add web sockets. I've written and deployed about a dozen serious web applications using Clojure. My opinion is the best strategy that guarantees long-term productivity is to build your system from a set of smaller components that you choose 'a la carte'. That way, if your requirements change you can swap in and out other components as you need to. I would guess that the vast majority of Clojure web applications are written this way, which is why you don't see widescale adoption of a particular web 'framework' by the Clojure community. Instead, Clojure developers pick from a set of constituent parts: Jetty, http-kit, Ring, Compojure, Hiccup, Enlive, Stencil, Liberator, domina, dommy, C2, Om, shameless-plugbidi/shameless-plug, and so on and so on. The fact that these components all fit together so well is one of the truly outstanding features of the Clojure platform. Few languages come close to this level of integration, which is why they actively curate frameworks. Investing time in Clojure is both pleasurable and productive. It's a question of whether you want 'short-term' productivity to meet a particular project goal (choose a web framework), or sustainable productivity to deliver value to your users over the longer term (choose to learn, understand and utilize a set of components from the wide pool that the Clojure community has created). Regards, Malcolm On Wednesday, December 25, 2013 9:06:20 PM UTC, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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 (mailto: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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com). For more options, visit https://groups.google.com/groups/opt_out. -- -- 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.
Re: Is Clojure right for me?
On 26 December 2013 16:32, Massimiliano Tomassoli kiuhn...@gmail.comwrote: Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure? You write functions. To quote Alan J. Perlis: It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures. IMO, OOP just makes it harder to build modular systems, because OOP involves a lot of implicit connections between components. Clojure, and other functional languages, tend to emphasise isolation more. - James -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 7:51:39 PM UTC+1, James Reeves wrote: On 26 December 2013 16:32, Massimiliano Tomassoli kiuh...@gmail.comjavascript: wrote: Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure? You write functions. To quote Alan J. Perlis: It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures. Classes or objects are not simple data structures. IMO, OOP just makes it harder to build modular systems, because OOP involves a lot of implicit connections between components. Clojure, and other functional languages, tend to emphasise isolation more. Why implicit? Objects communicate through well-defined channels. OOP can certainly be misused but it served me well for over 20 years (C++/C#). And Scala proves that FP and OOP are orthogonal paradigms. I can't see how the lack of OOP is a good thing for Clojure, honestly. I'm willing to give up mutability because I never programmed that way and I believe it can be a good thing (after I get used to it), but giving up OOP means going back to something I already know and I don't like. -- -- 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.
Re: Is Clojure right for me?
exactly which part of OOP is missing in clojure that you would like to use? if you took my java code and ported it to clojure, the main difference would be (a b) instead of b.a , but the main design would be similar 2013/12/26 Massimiliano Tomassoli kiuhn...@gmail.com On Thursday, December 26, 2013 7:51:39 PM UTC+1, James Reeves wrote: On 26 December 2013 16:32, Massimiliano Tomassoli kiuh...@gmail.comwrote: Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure? You write functions. To quote Alan J. Perlis: It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures. Classes or objects are not simple data structures. IMO, OOP just makes it harder to build modular systems, because OOP involves a lot of implicit connections between components. Clojure, and other functional languages, tend to emphasise isolation more. Why implicit? Objects communicate through well-defined channels. OOP can certainly be misused but it served me well for over 20 years (C++/C#). And Scala proves that FP and OOP are orthogonal paradigms. I can't see how the lack of OOP is a good thing for Clojure, honestly. I'm willing to give up mutability because I never programmed that way and I believe it can be a good thing (after I get used to it), but giving up OOP means going back to something I already know and I don't like. -- -- 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. -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 11:32:51 AM UTC-5, Massimiliano Tomassoli wrote: Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure? This presentation has been really helpful in that regard for me: Clojure in the Largehttp://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques Even though Clojure is not OOP in the way Java is, you can go a long way with Protocols and namespaces, imho. -- -- 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.
Re: Is Clojure right for me?
Agree, classes are not simple structures, they carry internal mutable state and hidden behaviours. Compounding mutable objects creates a huge brittled context were system state at any given point in time is untraceable by a normal human brain except in simplistic systems. Now you could create un mutable objects but then why bother creating classes with hidden behaviours if there is no hidden state ? Please explain then the advantage of using classes in this context versus name spaces to delimit concerns with high order functions ? How can you stick to both things at the same time ? Luc P. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 9:01:56 PM UTC+1, HamsterofDeath wrote: exactly which part of OOP is missing in clojure that you would like to use? if you took my java code and ported it to clojure, the main difference would be (a b) instead of b.a , but the main design would be similar How can that be? What about encapsulation, inheritance and polymorphism? OOP is not just syntactic sugar. If I were to implement something (complex enough) in C and C++ the differences between my implementations would be far from superficial. -- -- 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.
Re: Is Clojure right for me?
Encapsulation: a) I don't miss it. b) Functions/private-namespaces/maps/deftypes can serve this purpose. Inheritance: Clojure provides ad-hoc hierarchies, which give you the desired tree structure of a type-hierarchy, but it is decoupled from implementation details. You can inherit implementations in lots of ways in clojure. The simplest conceptually in my mind is simply a hash-map of keys to functions. Once you start doing it, the question shifts to do you need a 'this' pointer? 'this' makes a first argument to a pure function implicit. In most cases, you don't need it. If you do need it, deftypes or records can fill in the gap. Records and deftypes also participate in protocols, which provides... Polymorphism: Single-dispatch is a degenerate case of more generalized multiple dispatch, which we have via multi-methods. It turns out that JVMs are pretty good at it, but conceptually I think of 'dispatching on the type' as an implementation detail or optimization, not something to build a language around (java, C++, ...). Protocols give this kind of fast-implementation polymorphism back to you in a decoupled form. Reify/proxy are just so darned convenient, both with JVM interfaces and clojure protocols. There's nothing missing here, it's just disassembled and presented back to you in pieces as part of a practical and philosophical argument. This is the 'design by decoupling' thought. What _is_ missing here is an actually helpful static type-system (there's WIP), but immutable data is the best glue for a dynamic one, in my opinion, as it provides easy isolation of components. I don't miss java's, that's for sure. Some things that didn't look like syntactic sugar will start to look like syntactic sugar once you get deep into compiler internals and macros :-). Lisp broke me in this way, but I like it. On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli kiuhn...@gmail.comwrote: On Thursday, December 26, 2013 9:01:56 PM UTC+1, HamsterofDeath wrote: exactly which part of OOP is missing in clojure that you would like to use? if you took my java code and ported it to clojure, the main difference would be (a b) instead of b.a , but the main design would be similar How can that be? What about encapsulation, inheritance and polymorphism? OOP is not just syntactic sugar. If I were to implement something (complex enough) in C and C++ the differences between my implementations would be far from superficial. -- -- 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. -- -- 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.
Re: Is Clojure right for me?
On 26 December 2013 19:53, Massimiliano Tomassoli kiuhn...@gmail.comwrote: Why implicit? Objects communicate through well-defined channels. OOP can certainly be misused but it served me well for over 20 years (C++/C#). And Scala proves that FP and OOP are orthogonal paradigms. I can't see how the lack of OOP is a good thing for Clojure, honestly. I'm willing to give up mutability because I never programmed that way and I believe it can be a good thing (after I get used to it), but giving up OOP means going back to something I already know and I don't like. Clojure provides all the functionality of OOP, but separated into specialised tools. For grouping functions, we have namespaces. For polymorphism, we have multimethods and protocols. For encapsulation there are closures, and for inheritance we have the derive and isa? functions. I've worked with OOP systems for over a decade, but it wasn't until I started using Clojure that really started to understand the separate pieces of functionality that OOP bundles together. I found that there were some pieces I used regularly (such as namespaces), some pieces I used occasionally (polymorphism), and some pieces I didn't use at all (encapsulation and inheritance). Clojure emphasises simplicity, which in this case means should aim for tools that perform specific tasks, rather than tools that attempt to tackle everything at once. This is why Clojure doesn't have OOP, because Clojure prefers having a diverse toolbox of individual tools, rather than a single generic tool that acts as a swiss army knife. Clojure also rejects the idea that we should hide data structures behind an API (i.e. encapsulation). This is the opposite of OOP doctrine, which suggests that data structures need to be hidden to prevent constant refactoring. In practise, I find I need to refactor *less* with Clojure, while at the same time avoiding the need to hide information, and the repetition that comes with having to re-implement part of the functionality of a map, every time I build an object. When I started using Clojure, I almost started on an OOP system for it. Within a few weeks, I began to understand that wasn't necessary. After 5 years, I'm very much sold on Clojure's methodology. I suspect I'm not alone in this, otherwise there would be at least a dozen OO systems for Clojure. To my knowledge, there are zero so far. - James -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 9:18:06 PM UTC+1, Luc wrote: Now you could create un mutable objects but then why bother creating classes with hidden behaviours if there is no hidden state ? The state is still hidden. Even if the state is immutable: 1) other code could access it and, thus, changing the inner working of your class would break that code; 2) other code could create a new instance of your class with inconsistent internal state. As you can see, immutability is totally orthogonal to object orientation. Encapsulation is still useful, as are inheritance and polymorphism. -- -- 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.
Re: Is Clojure right for me?
a) encapsulation of unmutable state ? What for ? b) inheritance ? see a) c) polymorphism ? Multimethods (which are more flexible) or protocols Nice words but not much else. Comparing C versus C++ is fair but this comparison does not relate at all to Clojure, it's like answering blue to the question which even number sits between 1 and 3 ? I am still waiting for an answer to my previous post btwy... Luc P. On Thursday, December 26, 2013 9:01:56 PM UTC+1, HamsterofDeath wrote: exactly which part of OOP is missing in clojure that you would like to use? if you took my java code and ported it to clojure, the main difference would be (a b) instead of b.a , but the main design would be similar How can that be? What about encapsulation, inheritance and polymorphism? OOP is not just syntactic sugar. If I were to implement something (complex enough) in C and C++ the differences between my implementations would be far from superficial. -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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.
Re: Is Clojure right for me?
On 26 Dec 2013 21:04, Softaddicts lprefonta...@softaddicts.ca wrote: a) encapsulation of unmutable state ? What for ? b) inheritance ? see a) c) polymorphism ? Multimethods (which are more flexible) or protocols Nice words but not much else. Comparing C versus C++ is fair but this comparison does not relate at all to Clojure, it's like answering blue to the question which even number sits between 1 and 3 ? I am still waiting for an answer to my previous post btwy... Let's be nice. We're supposed to have a welcoming community, not a combative one :) - James -- -- 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.
Re: Is Clojure right for me?
If I were to implement something (complex enough) in C and C++ the differences between my implementations would be far from superficial. Those are both inexpressive in different ways. In my opinion java is closer to lisp than C++, given garbage collection, closures (even faked by objects), reflection (code-as-data), classloading (eval). On Thu, Dec 26, 2013 at 9:15 AM, James Reeves ja...@booleanknot.com wrote: On 26 Dec 2013 21:04, Softaddicts lprefonta...@softaddicts.ca wrote: a) encapsulation of unmutable state ? What for ? b) inheritance ? see a) c) polymorphism ? Multimethods (which are more flexible) or protocols Nice words but not much else. Comparing C versus C++ is fair but this comparison does not relate at all to Clojure, it's like answering blue to the question which even number sits between 1 and 3 ? I am still waiting for an answer to my previous post btwy... Let's be nice. We're supposed to have a welcoming community, not a combative one :) - James -- -- 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. -- -- 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.
Re: Is Clojure right for me?
Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. I was just teasing a bit :) If I were to be combative, it would be much worse :) Luc P. On 26 Dec 2013 21:04, Softaddicts lprefonta...@softaddicts.ca wrote: a) encapsulation of unmutable state ? What for ? b) inheritance ? see a) c) polymorphism ? Multimethods (which are more flexible) or protocols Nice words but not much else. Comparing C versus C++ is fair but this comparison does not relate at all to Clojure, it's like answering blue to the question which even number sits between 1 and 3 ? I am still waiting for an answer to my previous post btwy... Let's be nice. We're supposed to have a welcoming community, not a combative one :) - James -- -- 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. -- Softaddictslprefonta...@softaddicts.ca sent by ibisMail from my ipad! -- -- 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.
Re: Is Clojure right for me?
clojurekoans.com uses Joodo. https://github.com/slagyr/joodo What are some other cool sites powered by Clojure? On Wednesday, December 25, 2013 4:06:20 PM UTC-5, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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.
Re: Is Clojure right for me?
http://preview.getprismatic.com/news/home On Thu, Dec 26, 2013 at 2:42 PM, john walker john.lou.wal...@gmail.comwrote: clojurekoans.com uses Joodo. https://github.com/slagyr/joodo What are some other cool sites powered by Clojure? On Wednesday, December 25, 2013 4:06:20 PM UTC-5, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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. -- -- 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.
Re: Is Clojure right for me?
You can define vars to be private to a namespace in clojure, thus preventing (1). In practice, I've found that (2) never comes up. Ultimately, you won't truly appreciate what is being said in this conversation without giving it a chance and trying it out. On Thursday, December 26, 2013 4:02:49 PM UTC-5, Massimiliano Tomassoli wrote: On Thursday, December 26, 2013 9:18:06 PM UTC+1, Luc wrote: Now you could create un mutable objects but then why bother creating classes with hidden behaviours if there is no hidden state ? The state is still hidden. Even if the state is immutable: 1) other code could access it and, thus, changing the inner working of your class would break that code; 2) other code could create a new instance of your class with inconsistent internal state. As you can see, immutability is totally orthogonal to object orientation. Encapsulation is still useful, as are inheritance and polymorphism. -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 10:26:11 PM UTC+1, Gary Trakhman wrote: If I were to implement something (complex enough) in C and C++ the differences between my implementations would be far from superficial. Those are both inexpressive in different ways. In my opinion java is closer to lisp than C++, given garbage collection, closures (even faked by objects), reflection (code-as-data), classloading (eval). You can do metaprogramming in C++ (with templates, which are Turing-complete) and now it supports closures and many other things. Unfortunately, it's become too complex. D would be a better choice if only it was more popular. -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 10:04:21 PM UTC+1, Luc wrote: a) encapsulation of unmutable state ? What for ? b) inheritance ? see a) c) polymorphism ? Multimethods (which are more flexible) or protocols Nice words but not much else. Comparing C versus C++ is fair but this comparison does not relate at all to Clojure, it's like answering blue to the question which even number sits between 1 and 3 ? I am still waiting for an answer to my previous post btwy... I did answer to your post. -- -- 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.
Re: Is Clojure right for me?
On 27 December 2013 00:16, Massimiliano Tomassoli kiuhn...@gmail.comwrote: On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. There are a lot of programming languages, but you can get a good overview from just few. If I had to pick just four to provide a reasonable spread of ideas, I'd suggest Scheme, C, Smalltalk and Haskell. In my very subjective estimation, Clojure sits somewhere between Scheme and Haskell. However, assuming you don't want to spend several months researching interesting programming languages, let me see if I can make an argument against OOP that requires a little less background reading :) Clojure has been around for over six years now, and has all the components necessary to construct an object system. It would take maybe a few hours to build a library for Clojure that provide support for OOP. To the best of my knowledge, however, no-one has. If OOP was a particularly useful paradigm, why the lack of interest in reproducing it in Clojure? Perhaps it's worth investigating how Clojure manages without it? - James -- -- 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.
Re: Is Clojure right for me?
On Thursday, December 26, 2013 10:00:46 PM UTC+1, James Reeves wrote: On 26 December 2013 19:53, Massimiliano Tomassoli kiuh...@gmail.comjavascript: wrote: Why implicit? Objects communicate through well-defined channels. OOP can certainly be misused but it served me well for over 20 years (C++/C#). And Scala proves that FP and OOP are orthogonal paradigms. I can't see how the lack of OOP is a good thing for Clojure, honestly. I'm willing to give up mutability because I never programmed that way and I believe it can be a good thing (after I get used to it), but giving up OOP means going back to something I already know and I don't like. Clojure provides all the functionality of OOP, but separated into specialised tools. For grouping functions, we have namespaces. For polymorphism, we have multimethods and protocols. For encapsulation there are closures, and for inheritance we have the derive and isa? functions. I've worked with OOP systems for over a decade, but it wasn't until I started using Clojure that really started to understand the separate pieces of functionality that OOP bundles together. I found that there were some pieces I used regularly (such as namespaces), some pieces I used occasionally (polymorphism), and some pieces I didn't use at all (encapsulation and inheritance). Clojure emphasises simplicity, which in this case means should aim for tools that perform specific tasks, rather than tools that attempt to tackle everything at once. This is why Clojure doesn't have OOP, because Clojure prefers having a diverse toolbox of individual tools, rather than a single generic tool that acts as a swiss army knife. Clojure also rejects the idea that we should hide data structures behind an API (i.e. encapsulation). This is the opposite of OOP doctrine, which suggests that data structures need to be hidden to prevent constant refactoring. In practise, I find I need to refactor *less* with Clojure, while at the same time avoiding the need to hide information, and the repetition that comes with having to re-implement part of the functionality of a map, every time I build an object. When I started using Clojure, I almost started on an OOP system for it. Within a few weeks, I began to understand that wasn't necessary. After 5 years, I'm very much sold on Clojure's methodology. I suspect I'm not alone in this, otherwise there would be at least a dozen OO systems for Clojure. To my knowledge, there are zero so far. OK, I'll give Clojure a try. Thanks for your time. -- -- 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.
Re: Is Clojure right for me?
This depends strictly on your learning speed which I will not comment here :) It took me three months full time to start to feel at ease with Clojure writing production code and I was around 45 years old at the time. Learning is never inefficient... when you want to learn. Luc P On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote: Ok I'll drop the subject. Still cannot understand why people cannot try something new w/o sticking to the stuff they know already until they are totally immersed in the new thing. And by that I mean use the new thing as it was intended. Then you can generate useful conclusions and get some benefits from this learning process. Learning every single language just to find the right one is not very time-efficient. -- -- 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. -- Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail! -- -- 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.
Re: Is Clojure right for me?
I do like the way Clojure steers you away from all sorts of unnecessary OO-nonsense, and provides most of the raw capabilities of OO in other forms. However, even if you avoid mutable state, inheritance, and polymorphism, Classes/objects make great namespaces, and Clojure's namespaces can't do everything classes can do, for example, cyclic dependencies. This was the subject of my blog post yesterday. Take a look at the following gist code for one of the scenarios that frequently drives me up a wall: https://gist.github.com/Engelberg/8141352 I'd love to hear any tricks you guys use to deal with situations like this in your own code. -- -- 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.
Re: Is Clojure right for me?
Hi Mark, I am not following your example. Can you post (pseudocode fine) what a good OO impl would look like, and why Clojure's defrecords can't do something similar? Stu On Thu, Dec 26, 2013 at 9:08 PM, Mark Engelberg mark.engelb...@gmail.comwrote: I do like the way Clojure steers you away from all sorts of unnecessary OO-nonsense, and provides most of the raw capabilities of OO in other forms. However, even if you avoid mutable state, inheritance, and polymorphism, Classes/objects make great namespaces, and Clojure's namespaces can't do everything classes can do, for example, cyclic dependencies. This was the subject of my blog post yesterday. Take a look at the following gist code for one of the scenarios that frequently drives me up a wall: https://gist.github.com/Engelberg/8141352 I'd love to hear any tricks you guys use to deal with situations like this in your own code. -- -- 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. -- -- 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.
Re: Is Clojure right for me?
Does this OO pseudocode help clarify at all? https://gist.github.com/Engelberg/8142000 On Thu, Dec 26, 2013 at 6:27 PM, Stuart Halloway stuart.hallo...@gmail.comwrote: Hi Mark, I am not following your example. Can you post (pseudocode fine) what a good OO impl would look like, and why Clojure's defrecords can't do something similar? Stu -- -- 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.
Re: Is Clojure right for me?
One reason it might not be clear what I'm driving it is that in trying to create a minimalist example, I used grid dimensions, and in reality, you'd probably know right away to put something like that in a data structure, and pass it around to all your functions. Try to imagine that at the beginning of your project, you really do believe that you're only going to ever be working with 3x4 grids, and then later, you realize that's not the case. In the early phase, it's very easy to construct a bunch of functions that all refer to those shared vars (in my example `rows` and `cols`). Later, when you realize rows and cols can change, making those names parameters is a major overhaul to the codebase. I believe that most Clojurians try to delay the refactoring by using `binding` to alter those vars. But that's a fragile strategy, and eventually the code typically needs to be rewritten. On Thu, Dec 26, 2013 at 7:04 PM, Mark Engelberg mark.engelb...@gmail.comwrote: Does this OO pseudocode help clarify at all? https://gist.github.com/Engelberg/8142000 On Thu, Dec 26, 2013 at 6:27 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: Hi Mark, I am not following your example. Can you post (pseudocode fine) what a good OO impl would look like, and why Clojure's defrecords can't do something similar? Stu -- -- 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.
Re: Is Clojure right for me?
On Dec 26, 2013, at 9:32 AM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure? That seems like a very intelligent question. I didn't see that anyone in the thread mentioned Brian Marick's book, Functional Programming for the Object-Oriented Programmer. In the book, Marick emulates object-oriented programming in Clojure, which not only helps you see the greater flexibility you get with Clojure, but also helps you be a better OOP programmer when dealing with OOP languages. I'd definitely recommend the book. Another book worth checking out is Dmitri Sotnikov's Web Development with Clojure, which is a good survey of Clojure web development using Ring and Compojure. It illustrates well the idea of selecting the components you need for your web application and pulling them together, as opposed to the idea of a single overarching framework. I am a professional Rails developer and I like Rails. But I think the criticisms leveled against the single-framework model are very legitimate. If you want to do something the framework is not built for, you can spend a lot of time trying to work around the framework instead of using it. The easy things are really magically easy, but the hard things are pretty hard. Having said all that, here's what I really love about Clojure. Like Ruby and Rails, you can start off with an amorphous, ill-defined idea that you are prototyping. You can put it together, realize you had a lot of misconceptions (about the problem, the product, what people want, etc), and easily shift your assumptions. But Clojure shifts from Ruby and Rails when your idea matures and the invariants of your application settle. Clojure's tools give you more assurance of correctness when your app increasingly takes shape. Functional programming and immutability save you from whole classes of really fun state problems. Pure functions give you testability and transparency that are rarely seen in Rails apps. You can gradually add types to your arguments and return values (https://github.com/clojure/core.typed), thereby gaining much of the safety of statically-typed languages. You can use contracts (https://github.com/clojure/core.contracts) to ensure that your assumptions are always met, both regarding parameters and results of your functions. You can elegantly address all the possible cases of a set of parameters using matching (e.g. matchjure, https://github.com/dcolthorp/matchure/). Argument pattern-matching and destructuring is a fabulous tool and you really have to use it a little to realize how handy it is. In short, Clojure gives you all you need for prototyping, and when your idea jells out, you can tighten it down tremendously and expect fewer late-night phone calls where the app is breaking. Your software is simply more stable and correct, with less effort. Yet, you didn't have to pay the static-typing toll up front, when you needed the freedom and flexibility to try different things. I don't know if Clojure is ultimately right for you. But I can say with no doubt that learning Clojure will grow you as a software developer, and you won't be sorry you spent the time to get to know the language and the Clojure way of thinking. Good luck, steven -- -- 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.
Re: Is Clojure right for me?
On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli kiuhn...@gmail.com wrote: Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. I'm a little late to this thread (it's been one of those days!) but having read over your posts, I didn't get a good sense of why you are worried about the absence of support for OOP in Clojure? Like you, I have 20+ years of OOP experience - including eight years where I worked on the ANSI C++ Standards Committee - and I've worked with C++, Java, Groovy, Scala and a few other OOP languages during that time. I've developed and worked with static analysis tools and been able to look at millions of lines of code (mostly C++), and seen all sorts of horrors committed in the name of OOP :) Before that I worked on C and COBOL compilers, and various C and assembler projects. And before that I did FP, albeit in an academic context. For the last three years I've worked increasingly in Clojure. My team is slowly migrating from an OOP language and a 90Kloc system to Clojure (where we already have 16Kloc). Adjusting to FP from OOP can be hard - I've seen a number of Java developers really struggle with the transition. You might find Prof. Grossman's Programming Languages course (on Coursera) to be illuminating: it starts with Standard ML, then moves on to Racket, and then finishes with Ruby. Part of the course looks closely at what both FP and OOP bring to the table and how they can be viewed as complementary, orthogonal, and in some ways simply equivalent. How do you decompose large systems in Clojure? I'm curious as to why you think only OOP allows you to decompose large systems? Between namespaces, protocols, multimethods, ad hoc hierarchies, and higher order functions, Clojure has a lot of tools for organizing code... -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- -- 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.
Is Clojure right for me?
Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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.
Re: Is Clojure right for me?
http://pedestal.io/ http://www.luminusweb.net/ -- tao Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, December 26, 2013 at 5:06 AM, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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 (mailto: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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com). For more options, visit https://groups.google.com/groups/opt_out. -- -- 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.
Re: Is Clojure right for me?
http://hoplon.io/#/home/ http://caribou.github.io/caribou/docs/outline.html -- Devin Walters On Thursday, December 26, 2013 at 12:26 AM, tao wrote: http://pedestal.io/ http://www.luminusweb.net/ -- tao Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, December 26, 2013 at 5:06 AM, Massimiliano Tomassoli wrote: Hi, I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure. -- -- 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 (mailto: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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com). For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 (mailto: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 (mailto: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 (mailto:clojure+unsubscr...@googlegroups.com). For more options, visit https://groups.google.com/groups/opt_out. -- -- 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.
