Re: Russ olsen's Clojure Book
I am only really very new to clojure, I actually started with racket and htdp.org(how to design programs). The really unique thing I see with clojure is that super (clean to me) design and rather than shunning java and oop Rich openly advises to embrace it. That's the clincher for me rather than extremism its the recognition that OOP does some things well and Functional does some things well and using the best of both. Thank you for the design patterns book as well as stated I really enjoy the way you convey the ideas and ruby is an easy language to pickup so it doesn't impede the learning process. I have thought about doing a clojure book, but so far it is only in the back of the napkin stage. Always happy to supply more napkins. Sayth -- 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
Re: Please stand firm against Steve Yegge's yes language push
I agree, that clojure will not gain java-like popularity in a forseeable future. IMO clojure is much more a Language for SystemProgrammers (high demands, thinking in concurrency) than a Language for ApplicationProgrammers (midsize demands, thinking singlethread) it does not have to target general purpose use. But Very well could clojure become a mainstream-language for SystemProgrammers. other promising perspectives for clojure: - as a base for true innovation (core.logic) - for programming android (compile to dex) -- 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
Re: Please stand firm against Steve Yegge's yes language push
I find clojure suitable to pretty much every problem I've come across so far, since it allows me to write concise, low-ceremony code. The bottom-up approach helps raising the abstraction level, and soon the concepts of your domain will surface, so that the code starts reflecting the language you use in your problem domain. If you care to code that way of course... Las 2011/7/2 faenvie faen...@googlemail.com I agree, that clojure will not gain java-like popularity in a forseeable future. IMO clojure is much more a Language for SystemProgrammers (high demands, thinking in concurrency) than a Language for ApplicationProgrammers (midsize demands, thinking singlethread) it does not have to target general purpose use. But Very well could clojure become a mainstream-language for SystemProgrammers. other promising perspectives for clojure: - as a base for true innovation (core.logic) - for programming android (compile to dex) -- 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 -- László Török Skype: laczoka2000 Twitter: @laczoka -- 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
Re: about lazy-seq
... oops, of course the count realizes the seq, what a silly mistake thank you for your help On 2 juil, 06:45, Alan Malloy a...@malloys.org wrote: (count coll) needs to realize the whole sequence all at once in order to see how big it is. Depending on how much of this you want to do by hand, something like the following is how I would write it: (defn slice [low high coll] (lazy-seq (cond (pos? low) (slice (dec low) (dec high) (rest coll)) (zero? high) nil :else (cons (first coll) (slice 0 (dec high) (rest coll)) On Jul 1, 4:29 pm, kawas laurent.joi...@gmail.com wrote: Hi, As a clojure beginner I'm practicing my understanding of the language but at some point the use of lazy-seq get blurry. Imagine that I want to write a lazy function to extract a slice of a collection something like this : (defn slice [coll low high] (drop (dec low) (take high coll))) ... but hand-made using lazy-seq and with the constraint to check the boundaries (= 1 low high (count coll)) Of course I could write the check in lazy-seq but each call counts the collection. I could try to use arity to keep collection length, but I don't want to expose this to the user. I could use and outer helper function, but what if I want it all in one function ? (defn slice [coll low high] (when (= 1 low high (count coll)) (let [step (fn step [coll low high] (lazy-seq (cond ( low 1) (step (rest coll) (dec low) (dec high)) (and (= low 1) (= high 1)) (cons (first coll) (step (rest coll) low (dec high))) :else nil)))] (step coll low high Unexpectedly, this is not lazy, it seems like I'm hanging onto my head. Is lazy-seq creating some kind of closure with my collection in it ? How about lazy-seq, tail call and closure clearing ? regards, -- kawas -- 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
Discovering a function's closure
Hey, Does anyone know of a way, given a function, to discover it's closure programatically? I often find myself holding a pointer to such a function that only when knowing to what values it is bound to one can tell what it actually does. So it can be very helpful to be able to query the runtime (generally in the repl) what the function is bound to thanks Oded -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 4:05 AM, faenvie faen...@googlemail.com wrote: I agree, that clojure will not gain java-like popularity in a forseeable future. IMO clojure is much more a Language for SystemProgrammers (high demands, thinking in concurrency) than a Language for ApplicationProgrammers (midsize demands, thinking singlethread) it does not have to target general purpose use. But Very well could clojure become a mainstream-language for SystemProgrammers. other promising perspectives for clojure: - as a base for true innovation (core.logic) If true innovation means implementing good ideas found in academic papers, sure ;) I think your characterization of Clojure being best suited for systems programming to be inaccurate. Two of the most interesting large open source projects written in Clojure (for me) are Penumbra and Overtone. Both of these are for creative coding. David -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Jul 1, 10:50 pm, Gregg Reynolds d...@mobileink.com wrote: On Fri, Jul 1, 2011 at 2:59 PM, James Keats james.w.ke...@gmail.com wrote: ... Whereas when Steve Yegge writes: Who? Indeed. I'm not wishing this to be a personal attack on Steve Yegge, but a fair and justified re-examination; if people are going to use their heavyweight-sounding name to wield influence upon others, it's fair and justified to ask what's behind that name. I have been aware of Steve Yegge for many years; pseudo-literary and pseudo-humorous rants that might be of interest to a programmer's cabinet of curiosities, but that I've not had the luxury of time to indulge in reading, preferring to devote mine to meatier topics. I have not learned anything of note from Steve Yegge. His name seems to be associated lately with Javascript, but whereas I've learnt a lot from those folks, the likes of Stoyan Stefanov (perhaps my personal favourite of those folks), Doug Crockford and John Resig, the one time I felt compelled to read a Steve Yegge writing was when he was referenced in the Joy of Clojure regarding his so-called universal design pattern. What a poorly written piece of crap that was, there was nothing new in it (Javascript's literal syntax is well documented in much better writings, and in Steve Yegge's article it was burried in a bunch of mind-numbing nonsense). I believe it'd be better for the Clojure core notables, whom I have a deep respect for, to suggest Haskell and RDF/OWL as better resources for understanding Clojures types/protocols. -- 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
Re: Please stand firm against Steve Yegge's yes language push
Although I agree with the ideas here that have already been stated by Rich, I am concerned about this message. There is no reason to stand against somebody. Steve is welcome to his own opinions and is an incredibly smart guy. He should be respected as a peer. His opinions happen to be different from Clojure's core values, and that is ok. Steve will either choose to use Clojure or go another path, and that is alright. The way for Clojure to grow is by embracing it's core values and showing the world that careful choices do lead to the right outcome. Let's not turn this into us against Steve. There's nothing productive there. Focus your energy instead on writing great Clojure code and sharing it with everyone else. Get people excited about Clojure who want something more powerful, and show them what is truly possible. Cheers, Aaron Bedra -- Clojure/core http://clojure.com On 07/01/2011 03:59 PM, James Keats wrote: Hi all. I've been looking at Clojure for the past month, having had a previous look at it a couple of years ago and then moved on to other things only to return to it now. Over the past decade I have looked at many languages and many ways of doing things. People may say this language or that language is general purpose, but the fact remains that languages have their niches in which they excel and beyond which it'd be foolish to venture. Clojure should not attempt be a mass success language or worry about its Tiobe index ranking. Clojure, the way I see it, is most suitable for the advanced independent developer. It is a language in the image of its creator, Rich Hickey. It's not a language for the factory hen. It won't become the next Java. Java already fills that niche, and despite what some may say, I don't see it going away anytime soon. I don't feel Clojure needs to grow - in terms of size of language. In fact it would worry me enormously if Clojure's path is to grow in size. It is fundamentally unsuited for that. If anything I wish for it to shrink even further and further. A Rich Hickey's quote comes to mind: • (paraphrased) Most Clojure programmers go through an arc. First they think “eww, Java” and try to hide all the Java. Then they think “ooh, Java” and realize that Clojure is a powerful way to write Java code and As I've said in my talks, most Clojure users go from eww, Java libs to ooh, Java libs, leveraging the fact there there is already a lib for almost anything they need to do. And using the lib is completely transparent, idiomatic and wrapper free. - Google verbatim for sources. Whereas when Steve Yegge writes: which means that everyone (including me!) who is porting Java code to Clojure (which, by golly, is a good way to get a lot of people using Clojure) is stuck having to rework the code semantically rather than just doing the simplest possible straight port. The more they have to do this, the more you're going to shake users off the tree. all I could think on reading this is horror, horror, oh God, horror!!!; he really doesn't get it. First, he shouldn't be porting Java code to clojure, Second, Clojure IS fundamentally different from Java, and third, such said users who don't want to touch Java should not touch Clojure. Clojure shouldn't worry about growing; java already has innumerable libs. Clojure, imho, should continue its - what I would dub - middleware begone! path, in which it'd provide an end-to-end, down- to-the-metal comprehensible system that an individual developer can get his head round and know exactly what's happening with his code and its environment here and everywhere. I could write more, but I have to run. Regards. J. -- 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
Re: Please stand firm against Steve Yegge's yes language push
2011/7/2 Aaron Bedra aaron.be...@gmail.com Although I agree with the ideas here that have already been stated by Rich, I am concerned about this message. There is no reason to stand against somebody. Steve is welcome to his own opinions and is an incredibly smart guy. He should be respected as a peer. His opinions happen to be different from Clojure's core values, and that is ok. Steve will either choose to use Clojure or go another path, and that is alright. The way for Clojure to grow is by embracing it's core values and showing the world that careful choices do lead to the right outcome. Let's not turn this into us against Steve. There's nothing productive there. Focus your energy instead on writing great Clojure code and sharing it with everyone else. Get people excited about Clojure who want something more powerful, and show them what is truly possible. huge +1000 Cheers, Aaron Bedra -- Clojure/core http://clojure.com On 07/01/2011 03:59 PM, James Keats wrote: Hi all. I've been looking at Clojure for the past month, having had a previous look at it a couple of years ago and then moved on to other things only to return to it now. Over the past decade I have looked at many languages and many ways of doing things. People may say this language or that language is general purpose, but the fact remains that languages have their niches in which they excel and beyond which it'd be foolish to venture. Clojure should not attempt be a mass success language or worry about its Tiobe index ranking. Clojure, the way I see it, is most suitable for the advanced independent developer. It is a language in the image of its creator, Rich Hickey. It's not a language for the factory hen. It won't become the next Java. Java already fills that niche, and despite what some may say, I don't see it going away anytime soon. I don't feel Clojure needs to grow - in terms of size of language. In fact it would worry me enormously if Clojure's path is to grow in size. It is fundamentally unsuited for that. If anything I wish for it to shrink even further and further. A Rich Hickey's quote comes to mind: • (paraphrased) Most Clojure programmers go through an arc. First they think “eww, Java” and try to hide all the Java. Then they think “ooh, Java” and realize that Clojure is a powerful way to write Java code and As I've said in my talks, most Clojure users go from eww, Java libs to ooh, Java libs, leveraging the fact there there is already a lib for almost anything they need to do. And using the lib is completely transparent, idiomatic and wrapper free. - Google verbatim for sources. Whereas when Steve Yegge writes: which means that everyone (including me!) who is porting Java code to Clojure (which, by golly, is a good way to get a lot of people using Clojure) is stuck having to rework the code semantically rather than just doing the simplest possible straight port. The more they have to do this, the more you're going to shake users off the tree. all I could think on reading this is horror, horror, oh God, horror!!!; he really doesn't get it. First, he shouldn't be porting Java code to clojure, Second, Clojure IS fundamentally different from Java, and third, such said users who don't want to touch Java should not touch Clojure. Clojure shouldn't worry about growing; java already has innumerable libs. Clojure, imho, should continue its - what I would dub - middleware begone! path, in which it'd provide an end-to-end, down- to-the-metal comprehensible system that an individual developer can get his head round and know exactly what's happening with his code and its environment here and everywhere. I could write more, but I have to run. Regards. J. -- 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://groups.google.com/group/clojure?hl=en -- László Török Skype: laczoka2000 Twitter: @laczoka -- 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
Sample Vaadin application in Clojure
The blog http://dev.vaadin.com/wiki/Articles/ClojureScripting describes how to write a simple Vaadin app in Clojure, using lein-war, a web.xml with lots of init params, and a custom servlet written in Java. I realized that it must be possible to get rid of the Java servlet class that the blogger suggests, and sure enough, using gen- class it was possible to get a working Vaadin sample using only Clojure plus a small web.xml. It still uses lein-war, though. The code is available here: https://github.com/ulsa/cljvaadin The servlet is quite complex: http://grepcode.com/file/repo1.maven.org/maven2/com.vaadin/vaadin/6.6.0/com/vaadin/terminal/gwt/server/AbstractApplicationServlet.java/?v=source Is there any hope of getting rid of the servlet altogether, and somehow get a Ring handler to perform whatever Vaadin stuff that needs to be done on the server? Even if we're stuck with the servlet, is there a more agile way of developing such an app than running 'lein uberwar' and deploying the war to Tomcat? -- 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
Re: ordered map in Clojure?
Alan Malloy a...@malloys.org writes: Hi Alan, If I were using this for some performance-critical task and never disjoined, I'd use ninjudd's version. Otherwise I'd use mine, just because it's easier to build and tweak since it's in clojure. I tried your implementation, and I couldn't see any relevant slowdown compared to the java version. So I'll stick with that. Bye, Tassilo On Jun 28, 12:54 pm, Tassilo Horn tass...@member.fsf.org wrote: Alan Malloy a...@malloys.org writes: Hi Alan, ArrayMap isn't very performant for large collections. You might like https://github.com/flatland/ordered in my clojure app, I totally rely on ordered sets. Currently, I use https://github.com/ninjudd/ordered-set for which I've implemented transient support which is already incorporated and released. Looking at your code, it basically looks identical wrt features, except that your implementation is comletely in clojure (and includes maps) while ninjudd's implementation is mainly java. If you know ninjudd's lib, can you give advice in what use-cases you'd prefer your own lib? Basically, in my scenario I only conjoin using `into' but never disjoin, and performance for that is very important. That's why I've implemented the transient support. But as it turned out, that didn't improve performance significantly, cause the calculation of set members is far more expensive than aggregating them... Well, in any case, I think I'll simply try it out at the weekend. Hopefully, I'm able to get some totally non-empirical benchmark results from my test suite that I can poste here. Bye, Tassilo -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Jul 2, 4:16 pm, Aaron Bedra aaron.be...@gmail.com wrote: Although I agree with the ideas here that have already been stated by Rich, I am concerned about this message. There is no reason to stand against somebody. Steve is welcome to his own opinions and is an incredibly smart guy. He should be respected as a peer. His opinions happen to be different from Clojure's core values, and that is ok. Steve will either choose to use Clojure or go another path, and that is alright. The way for Clojure to grow is by embracing it's core values and showing the world that careful choices do lead to the right outcome. Let's not turn this into us against Steve. There's nothing productive there. Focus your energy instead on writing great Clojure code and sharing it with everyone else. Get people excited about Clojure who want something more powerful, and show them what is truly possible. Cheers, Aaron Bedra -- Clojure/corehttp://clojure.com On 07/01/2011 03:59 PM, James Keats wrote: To be absolutely clear, I am not against Steve Yegge as a person. The title of my post was Please stand firm against Steve Yegge's yes language push. I implore you as clojure core and clojure community to stand firm against his yes language push. I did not intend the message of my post to be personal/social issues, despite the unfortunate fact that the thrust of his posts in that thread revolved around his concept of social attitude of a language creator and community and the evident implication that such social considerations should take primacy over technical merits. -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Jul 2, 3:54 pm, David Nolen dnolen.li...@gmail.com wrote: On Sat, Jul 2, 2011 at 4:05 AM, faenvie faen...@googlemail.com wrote: I agree, that clojure will not gain java-like popularity in a forseeable future. IMO clojure is much more a Language for SystemProgrammers (high demands, thinking in concurrency) than a Language for ApplicationProgrammers (midsize demands, thinking singlethread) it does not have to target general purpose use. But Very well could clojure become a mainstream-language for SystemProgrammers. other promising perspectives for clojure: - as a base for true innovation (core.logic) If true innovation means implementing good ideas found in academic papers, sure ;) I think your characterization of Clojure being best suited for systems programming to be inaccurate. Two of the most interesting large open source projects written in Clojure (for me) are Penumbra and Overtone. Both of these are for creative coding. David I agree that it would be unsuitable for systems programming, if systems programming is of the C variety; in fact even Java wouldn't be suitable there. Actually I do believe Clojure to be an applications language, and I would not constrain it to any one application area, I believe it to be widely applicable. Where I would advocate caution that'd restrict its use though, it would not relate to the programming language itself, but to the programmer. Twofold: 1) Clojure requires an advanced programmer; there's no escaping that. Said programmer needs to know Java well, and also functional programming of the haskell/ml sort, as well as lisp 2) Clojure requires discipline and wisdom; those do not come about easily, they require wide and long experience. It allows the programmer much, not too much for the widely-read experienced programmer, but perhaps too much for a large team constituted of programmers of varied abilities. I therefore see it most suited, as I said, for the advanced independent programmer, or at most a small team of advanced enough programmers. -- 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
Re: Sample Vaadin application in Clojure
Is there any hope of getting rid of the servlet altogether, and somehow get a Ring handler to perform whatever Vaadin stuff that needs to be done on the server? Well, you could rewrite the servlet in Clojure... right? Aside from that, I don't think so. Ring works on a much lower level of abstraction. Even if we're stuck with the servlet, is there a more agile way of developing such an app than running 'lein uberwar' and deploying the war to Tomcat? Tomcat can deploy an exploded war directory. You'll need to add an appropriate Context entry to $CATALINA_HOME/ conf/server.xml and compile your servlet class. And, to take the example from ring.middleware.reload, you can add something like this: (require 'cljvaadin.core :reload) at the start of the init method. The rest of the method should then be extracted to another function or namespace, so that the changes could be picked up at runtime. I haven't tried this, but it should work. -- 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
Re: Sample Vaadin application in Clojure
you can try the following link https://github.com/hsenid-mobile/clj-vaadin it is a Clojure wrapper written for Vaadin. It's still in its initial stage :) You can check the implantation. -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 12:23 PM, James Keats james.w.ke...@gmail.comwrote: I therefore see it most suited, as I said, for the advanced independent programmer, or at most a small team of advanced enough programmers. I think Clojure is great for programmers with all kinds of experience - from beginner to advanced. In fact I think people haven't been brain washed by too much experience in object oriented and imperative languages will have a much easier time picking it up. David -- 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
Re: Please stand firm against Steve Yegge's yes language push
FWIW, I've been enjoying the Yegge posts for years. I definitely like his kind of humor and there are posts which made me laughing til the tears were running (*Settling the OS X focus-follows-mouse* debate comes to mind). Some posts deliver some insight, which at times may be well hidden. However, as Aaron pointed out, I'd rather a more tolerant, pleasant community. Kind regards, Stefan PS: And I don't think Steve Yegge would be porting Java code to Clojure without good reason and benefit. PPS: Regarding thin wrappers: take a look at the source code of e.g. dosync/sync, hash-map, to-array, find, keys ... There are situations where you just want to have a little less noise. -- 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
Re: Sample Vaadin application in Clojure
The clj-vaadin https://github.com/hsenid-mobile/clj-vaadin project is wonderful, it is very useful for me. It has an example of making a tree with vaadin with 2 levels. Do you know how I can add a third and fourth level? (defn level2 [tree n1 n2] (reduce (fn [tree n2] (doto tree (.addItem n2) (.setParent n2 n1) (.setChildrenAllowed n2 false))) tree n2)) (defn level1 [tree [n1 n2]] (.addItem tree n1) (if (empty? n2) (.setChildrenAllowed tree n1 false) (do (level2 tree n1 n2) (.expandItemsRecursively tree n1))) tree) (defn nomina-tree [] (let [tree (Tree. Index book)] (reduce level1 tree index))) -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Jul 2, 6:39 pm, David Nolen dnolen.li...@gmail.com wrote: On Sat, Jul 2, 2011 at 12:23 PM, James Keats james.w.ke...@gmail.comwrote: I therefore see it most suited, as I said, for the advanced independent programmer, or at most a small team of advanced enough programmers. I think Clojure is great for programmers with all kinds of experience - from beginner to advanced. In fact I think people haven't been brain washed by too much experience in object oriented and imperative languages will have a much easier time picking it up. David This above is the classic Sussman/Abelson/Harvey argument in favour of teaching lisp and functional programming as early as possible. I have nothing against it whatsoever other than to note that it is an educational argument, not an industrial one. In fact, it is exactly how I came to programming; lisp through the writings of those folks was my introduction to programming many years ago. Had it not been for their inspiration I wouldn't have bothered. However, once you're past the CS education stage then industrial concerns are an inescapable reality. And once you encounter the reality and frustration infamously characterized by likening the managing of lispers to the herding of cats then you begin to admire languages like python and java and see what they got right in imposing restrictions. A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. Kind regards, J -- 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
Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 12:21 PM, James Keats james.w.ke...@gmail.com wrote: A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. In your post, you talk about a certain naivete among Lispers about its practicality in industry, explain that python and java benefit from their added restrictions, and then offer up the above quote by Abelson. But you never really tie these observations back to Clojure. So I want to ask explicitly, do you think Clojure is suitable for these sorts of really large programs? Why or why not? -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 3:21 PM, James Keats james.w.ke...@gmail.com wrote: And once you encounter the reality and frustration infamously characterized by likening the managing of lispers to the herding of cats then you begin to admire languages like python and java and see what they got right in imposing restrictions. I've yet to see any evidence anecdotal or otherwise that managing a team of good Lisp programmers is any more difficult than managing good programmers in any other language. Links? A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. One of the most popular text editors to this day is Emacs. It's near 3 million lines of Lisp. David -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Jul 2, 6:41 pm, Stefan Kamphausen ska2...@googlemail.com wrote: FWIW, However, as Aaron pointed out, I'd rather a more tolerant, pleasant community. Kind regards, A month ago I asked a question here that barely a minute after clicking send realized was utterly dumb. It reminds of an anecdote about an (MIT?) professor who'd insist on whomever asks him a question to explain in some detail what they understand and what they don't understand, and oftentimes when people do so come to an Oh! moment of sudden understanding before he'd even answered just out of formulating the problem. That utterly dumb question got many tolerant, pleasant answers. :-) I would draw a thick line between the community's response to someone who'd ask an utterly dumb question - I don't me specifically, but any newcomer - and someone who'd insist upon the creator of a carefully considered and crafted solution and its community to change their culture outright. If I, and people like me who are willing to put their nose to the grindstone, read the books and watch the videos umpteen times over till they get it through and through, to become invested in clojure and its future, then we need a firm reassurance that ludicrous demands like those are firmly resisted, and believe it's imperative to implore clojure core to do so. Kind regards, :-) J -- 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
Re: Any ways to prevent protocol functions from being hardcoded in?
Hi On Jul 1, 8:09 am, Meikel Brandmeyer m...@kotka.de wrote: That's not what I understood. I know about the trade-offs between extend and inline methods. I blogged some time ago about it and voted for extend being the default until speed matters. However Stuart wrote protocols are a low-level implementation detail. In my understanding of the protocols, low-level is not the exact word. Protocols are designed with the implementer in mind, not the user. Sometimes user-facing API and implementer-facing API overlap but it's not a given. So, from the user point of view, protocols are an implementation detail, they are somewhat low-level -- lower than the user-level at least. NB: here I draw a distinction between the user which uses your API without providing his own implementation of your protocols, and the power user/implementer which does. Two groups with different trade- offs in API design If you have given them overlapping APIs you won't be able to change the user-facing API (eg adding fns or arities for convenience) without impacting the implementer. If you are the only implementer then your protocol is not pubic so you can get away with letting the user directly call protocol fns. And I don't think that this is reasonable. Take any of the collection functions: get, nth, peek, pop, seq, ... Each is a perfect candidate for a protocol function. Why (and how) would I hide this? I think this is a different question than using extend or inlining. conj, assoc, dissoc are counterexamples: their vararg forms can be implemented in terms of their shorter form. Let's forget that protocols fns can't be varargs. If you were specifying that conj as a protocol should accept a indefinite number of arguments, you would be putting the burden of providing this convenient signature onto the implementor, making your protocol harder to implement. That's exactly why Java frameworks are littered with abstract classes : interfaces are littered with helper methods that are tiresome to implement, so there's the abstract companion class which provide implementation of the helper methods, leaving only the core methods abstract. And as soon as you are creating a class which must implements two of such interfaces you are screwed because you won't be able to inherit implementations from two different abstract classes. Even nth and get are counterexamples too: given [coll index not-found] one can easily implement [coll index]. my 2 cents, Christophe -- 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
Re: Please stand firm against Steve Yegge's yes language push
As mundane as municipal billing sounds, there are actually some instances using 3rd party Windows based address verification (SmartSoft USA's Accumail) while bills are being loaded (before generating the print files) where a good multi-threaded language would help. Python does well as single thread and is a great go-to language. On Jul 2, 4:05 am, faenvie faen...@googlemail.com wrote: I agree, that clojure will not gain java-like popularity in a forseeable future. IMO clojure is much more a Language for SystemProgrammers (high demands, thinking in concurrency) than a Language for ApplicationProgrammers (midsize demands, thinking singlethread) it does not have to target general purpose use. But Very well could clojure become a mainstream-language for SystemProgrammers. other promising perspectives for clojure: - as a base for true innovation (core.logic) - for programming android (compile to dex) -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Jul 2, 8:33 pm, David Nolen dnolen.li...@gmail.com wrote: On Sat, Jul 2, 2011 at 3:21 PM, James Keats james.w.ke...@gmail.com wrote: And once you encounter the reality and frustration infamously characterized by likening the managing of lispers to the herding of cats then you begin to admire languages like python and java and see what they got right in imposing restrictions. I've yet to see any evidence anecdotal or otherwise that managing a team of good Lisp programmers is any more difficult than managing good programmers in any other language. Links? Sure, good lisp programmers, I have no argument against that, the key operative word here being *good*; where do you find those in large enough numbers to fill industry positions? I would also like to be specific about what good would entail: it has to entail some knowledge of what would actually work in the large and be maintainable, and a personal maturity that would prevent them from becoming too excited and overly adventurous. Unfortunately the industry is not made of good lisp programmers. A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. One of the most popular text editors to this day is Emacs. It's near 3 million lines of Lisp. David Versus the countless libraries and apps of Java and python? -- 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
Re: Discovering a function's closure
To get the source form of the function map?: (read-string (with-out-str (source map?))) This may not work only when the function has been AOT'ed already. Hope this helps. Regards, Shantanu On Jul 2, 11:34 am, Oded Badt odedb...@gmail.com wrote: Hey, Does anyone know of a way, given a function, to discover it's closure programatically? I often find myself holding a pointer to such a function that only when knowing to what values it is bound to one can tell what it actually does. So it can be very helpful to be able to query the runtime (generally in the repl) what the function is bound to thanks Oded -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 4:19 PM, James Keats james.w.ke...@gmail.com wrote: Sure, good lisp programmers, I have no argument against that, the key operative word here being *good*; where do you find those in large enough numbers to fill industry positions? I would also like to be specific about what good would entail: it has to entail some knowledge of what would actually work in the large and be maintainable, and a personal maturity that would prevent them from becoming too excited and overly adventurous. Unfortunately the industry is not made of good lisp programmers. good is more important than Lisp. I think a good programmer can easily pick up Lisp and run with it. Which is exactly what I think we're witnessing in the Clojure community. Most people here are not experienced Lispers. Versus the countless libraries and apps of Java and python? I was only talking about the scalability of Lisp with respect to code base size. David -- 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
Re: Please stand firm against Steve Yegge's yes language push
And we certainly will. And, as I stated in my previous email, we will do so with actions. My point is simply that I would rather not spend energy even talking about this, but rather demonstrating that we stand by our decisions by continuing on in the fashion Rich started, and many after have followed. I don't see how arguing about the merits of one person or another helps in any situation, or their technical influence or credibility. I would rather just put all that behind us. As you asked, Clojure/core will continue in the fashion that it always has. We welcome all ideas and opinions, though we will always think carefully about which ones are accepted into the Clojure language. You can rest easy knowing that the effort you put into building up your Clojure knowledge will not go to waste :) Cheers, Aaron Bedra -- Clojure/core http://clojure.com On 07/02/2011 03:59 PM, James Keats wrote: On Jul 2, 6:41 pm, Stefan Kamphausenska2...@googlemail.com wrote: FWIW, However, as Aaron pointed out, I'd rather a more tolerant, pleasant community. Kind regards, A month ago I asked a question here that barely a minute after clicking send realized was utterly dumb. It reminds of an anecdote about an (MIT?) professor who'd insist on whomever asks him a question to explain in some detail what they understand and what they don't understand, and oftentimes when people do so come to an Oh! moment of sudden understanding before he'd even answered just out of formulating the problem. That utterly dumb question got many tolerant, pleasant answers. :-) I would draw a thick line between the community's response to someone who'd ask an utterly dumb question - I don't me specifically, but any newcomer - and someone who'd insist upon the creator of a carefully considered and crafted solution and its community to change their culture outright. If I, and people like me who are willing to put their nose to the grindstone, read the books and watch the videos umpteen times over till they get it through and through, to become invested in clojure and its future, then we need a firm reassurance that ludicrous demands like those are firmly resisted, and believe it's imperative to implore clojure core to do so. Kind regards, :-) J -- 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
lein repl syntax highlighting?
Is there any way to highlight syntax in lein repl from a terminal? -- 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
Re: Please stand firm against Steve Yegge's yes language push
James, On Saturday, July 2, 2011 9:59:12 PM UTC+2, James Keats wrote: On Jul 2, 6:41 pm, Stefan Kamphausen ska...@googlemail.com wrote: I would draw a thick line between the community's response to someone who'd ask an utterly dumb question - I don't me specifically, but any newcomer - and someone who'd insist upon the creator of a carefully considered and crafted solution and its community to change their culture outright. obviously I don't live inside the head of Steve Yegge. However, I get the feeling, the fact that we are discussing things like we do on this thread may one of the things he tries to achieve. Yes, he seems to have a tendency to exaggeration. You probably have to exaggerate sometimes to drive a minor point home. If I, and people like me who are willing to put their nose to the grindstone, read the books Ah books. That's good. ;-) Cheers, Stefan -- 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
Re: Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
On Jul 2, 8:33 pm, Mark Engelberg mark.engelb...@gmail.com wrote: On Sat, Jul 2, 2011 at 12:21 PM, James Keats james.w.ke...@gmail.com wrote: A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. In your post, you talk about a certain naivete among Lispers about its practicality in industry, explain that python and java benefit from their added restrictions, and then offer up the above quote by Abelson. But you never really tie these observations back to Clojure. So I want to ask explicitly, do you think Clojure is suitable for these sorts of really large programs? Why or why not? If the community sticks to Rich Hickey's original vision, and in *competent and disciplined* hands, I believe clojure is suitable for almost any problems (barring the obvious of course, eg, those where the jvm wouldn't be suitable). Clojure is not just simply a lisp, it improves upon lisp through its immutable/persistent data structures, emphasis on pure functions and separation of pure code from side-effecting one, collections/sequence abstractions, embrace of java, concurrency, and recently datatypes/ protocols; clojure does impose restrictions; all those above are restrictions (use immutable/persistent data, use pure functions, use java directly, use generic data structures and generic sequence functions to manipulate them, use the appropriate concurrency feature.. etc, though it does somewhat enable the programmer to work around those when necessary) and also for example the disabling of user-defined reader macros. I'm actually thrilled about that, and look forward to see how it would actually work out as the community expands. I do though implore clojure core to stick or Rich Hickey's original vision, and not dilute it to appease ill-conceived social/ marketing claims and incalcitrant newcomers. Additionally, programs and teams for clojure don't have to be really large. The language is such that a small and competent team, or even an individual developer, could do a lot with so little. In any case, enterprise needs could be bolted on clojure; programming against services/interfaces/xml schemas/messaging/et cetera. Those could almost even be said to be orthogonal. Additionally, whatever clojure does, clojure is ultimately java. I could take clojure 1.0 and the innumerable java libs and be done with it (I remain to be convinced about datatypes/protocols and believe them to impose a managerial overhead, I believe for large teams they're a double edged-sword, the programming against interfaces is beneficial, but their ad hoc permissiveness could prove problematic). The same can't be said for other lisps, those weren't made with Java in mind as Rich Hickey made clojure. Regards, J -- 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
Re: lein repl syntax highlighting?
Some time ago I wrote a highlighter in clojure: https://github.com/Licenser/clj-highlight I guess it would be possible to integrate something like that in a REPL :) On Jul 2, 2011, at 10:51 PM, Antonio Recio wrote: Is there any way to highlight syntax in lein repl from a terminal? -- 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 smime.p7s Description: S/MIME cryptographic signature
Re: Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
As for whether Clojure would work in a large corporate environment (or for large software), I think that's more a function of the internal politics of the organization. Many managers, understandably, go with a technology with heavy library support and lots of developers. The common critique that Lisp isn't practical in industry, comes from that position. But Clojure, sitting atop the JVM, doesn't have that problem. Lisp was originally developed to build an AI system. So Clojure (a Lisp) is, in my opinion, a superior way to develop any size of program. I won't enumerate Clojure's many technical features and attributes. Just recall that computers are essentially heavy paper weights without software. And software is essentially functions and the manipulation of data. These companieshttp://clojure02.managed.contegix.com/display/community/Clojure+Success+Stories have all successfully used Clojure in medium to large projects. And Ray Kuzweil finds Lisp to be ideally suited to build a mindhttp://singularityhub.com/2010/12/21/ray-kurzweil-the-mind-and-how-to-build-one-video/ . OO, alternatively, is not at all practical. It was developed in the 60s, as a way to modularize (data abstraction, encapsulation, etc) large programs. The goal was maintainable and re-usable chunks of code. But we've seen the downsides of the OO paradigm, including: i) excessive overhead and ceremony, ii) software systems don't always fit into an Object world view, and iii) Rich Hickey's critique that OO is bad at representing time. Tim On Sat, Jul 2, 2011 at 3:33 PM, Mark Engelberg mark.engelb...@gmail.comwrote: On Sat, Jul 2, 2011 at 12:21 PM, James Keats james.w.ke...@gmail.com wrote: A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. In your post, you talk about a certain naivete among Lispers about its practicality in industry, explain that python and java benefit from their added restrictions, and then offer up the above quote by Abelson. But you never really tie these observations back to Clojure. So I want to ask explicitly, do you think Clojure is suitable for these sorts of really large programs? Why or why not? -- 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 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
Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 2:10 AM, László Török ltoro...@gmail.com wrote: I find clojure suitable to pretty much every problem I've come across so far, since it allows me to write concise, low-ceremony code. The bottom-up approach helps raising the abstraction level, and soon the concepts of your domain will surface, so that the code starts reflecting the language you use in your problem domain. I agree. I'm finding Clojure to be a very productive, concise way to solve problems in the Model of a large MVC web application originally built with other JVM-based technologies. We're finding a massive compression of code by switching core processing to Clojure - and as a nice side effect, we're taking the lessons of Clojure back to our other language(s) and finding massive simplifications there which were not obvious before. Just today we started on the process of analyzing Power MTA log files to deal with email bounces - an almost trivial process in Clojure, compared to other languages, with HOF and lazy sequences available to us. To me, Clojure is a very general purpose language. That said, I don't expect it to gain mainstream traction like Java (and I think that would be a bit of a disaster, to be honest) but I think it will gain a strong, productive community that will be large enough to be healthy and self-sufficient, and will compare favorably with other popular non-Java languages on the JVM. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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
Re: Clojure for large programs
Ideally, I was hoping to start a more in-depth discussion about the
pros and cons of programming in the large in Clojure than just
waxing poetic about Clojure/Lisp's capabilities in the abstract :)
Yes, much of the initial excitement around Clojure comes from the
feeling of Wow, I can do so much with so little code. But at some
point, all projects grow. I'm thinking that by now, there may be
enough people using Clojure in large projects and on large teams to
offer some good feedback about how well that works.
My Clojure codebase is somewhere around 2-3kloc and I already feel
like I'm bumping up against some frustration when it comes time to
refactor, maintain, and extend the code, all while keeping up with
ongoing changes to libraries, contrib structures, and Clojure
versions.
I want to hear war stories from those with even larger code bases than
mine. Has it proven to be a major hassle on large projects to avoid
circular dependencies in the modules? Are the lack of debugging
tools, documentation tools, and refactoring tools holding you back?
Anyone miss static typing?
One of my main gripes is that some of Clojure's built-ins return
nonsensical results (or nil), rather than errors, for certain classes
of invalid inputs. To me, one of the main benefits of functional
programming is that debugging is generally easier, in large part
because failures usually occur within close proximity of the flaw that
triggered the failure. Erlang, in particular, has really promoted the
idea of fail fast as a way to build robust systems. But Clojure's
lack of a fail-fast philosophy has burned me several times, with
hard-to-track-down bugs that were far-removed from the actual cause.
The larger my code grows, the more this annoys me, reminding me too
much of my days tracking down bugs in imperative programs.
One specific example of this is get, which returns nil whenever the
first input isn't something that supports get. For example, (get 2 2)
produces nil. This becomes especially problematic when you pass
something to get that seems like it should support get, but doesn't.
For example, (get (transient #{1}) 1) produces nil, when there's
absolutely no reason to think that (get (transient #{1} 1) would
behave any differently from ((transient #{1}) 1).
--
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
Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 10:39 AM, David Nolen dnolen.li...@gmail.com wrote: I think Clojure is great for programmers with all kinds of experience - from beginner to advanced. In fact I think people haven't been brain washed by too much experience in object oriented and imperative languages will have a much easier time picking it up. +1. I started out doing FP in the early/mid-80's and moved to OO in the 90's. Coming back to FP I've had to unlearn some bad habits and dust off some old habits that had laid dormant during my OO years. Of the people I've tried to expose to Clojure over the last six months, I've definitely found that those with less OO experience tend to pick it up much quicker. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Railo Technologies, Inc. -- http://www.getrailo.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
Agents not updating in lein swank or lein repl
This must be something really stupid I'm doing... If I run a vanilla clojure repl via java -jar clojure-xxx.jar, then agents do what I'd except. Ditto using Leiningen's generated standalone swank-clojure server. If I do a lein repl or connect to a lein swank in a simple project, then agents don't update with sent values. Even the simplest example like (def a (agent 0)) (send a (fn [_] 99)) doesn't cause any change. I guess something's up with the agent thread pool. Should I expect proper agent behaviour inside a lein session? Am I missing a project.clj configuration option? -- 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
Re: Please stand firm against Steve Yegge's yes language push
Ditto Aaron B. -Stuart Sierra clojure.com -- 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
Re: Clojure for large programs
On Jul 2, 2011, at 8:26 PM, Mark Engelberg wrote: My Clojure codebase is somewhere around 2-3kloc and I already feel like I'm bumping up against some frustration when it comes time to refactor, maintain, and extend the code, all while keeping up with ongoing changes to libraries, contrib structures, and Clojure versions. I have a codebase with 2.6kloc of production code and 4.8kloc of tests, and I feel your pain (even despite having been a Lisp programmer in the early 80's). I'm not sure yet how to navigate the transition to 1.3 while retaining backwards compatibility. And organizing things into namespaces is something I still haven't figured out. Russ Olsen said on this list: The community behind a language and the techniques that it develops are as much a part of the language as the syntax. I think we, the community, need to step up and figure out these techniques and *publicize* them. I hope the core team can provide the infrastructure/support to make that work. I was moderately heavily involved in the Ruby world starting in 2001 up until some time before Rails took the world by storm. There was a ton of inadvertent preparatory work done by people like Pragmatic Dave Thomas, Chad Fowler, Nathaniel Talbott, and Jim Weirich. We'd do well to learn from their oral histories of the early days of Ruby. - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Occasional consulting on Agile www.exampler.com, www.twitter.com/marick -- 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
Re: Clojure for large programs
On 3 July 2011 11:26, Mark Engelberg mark.engelb...@gmail.com wrote: But Clojure's lack of a fail-fast philosophy has burned me several times, with hard-to-track-down bugs that were far-removed from the actual cause. The larger my code grows, the more this annoys me, reminding me too much of my days tracking down bugs in imperative programs. I wonder if many people use the pre and post assertions when coding Clojure? Assertions ( pre/post-conditions) seem to have lost favour as a go-to tool for programmers. Most coders instead seem to go for unit testing exclusively. It seems to me that assertions could provide a lot benefit in dynamic programs as a way to fail-fast and as a way to document intention. In my limited experiments with them I've found them to be helpful. I do wish Clojure would give greater detail as to what went wrong when an assertion fails though. See Groovy's assert statement for an example of a very helpful error report [1]. [1] http://dontmindthelanguage.wordpress.com/2009/12/11/groovy-1-7-power-assert/ -- 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
Re: Clojure for large programs
On Jul 3, 2:26 am, Mark Engelberg mark.engelb...@gmail.com wrote:
Ideally, I was hoping to start a more in-depth discussion about the
pros and cons of programming in the large in Clojure than just
waxing poetic about Clojure/Lisp's capabilities in the abstract :)
Yes, much of the initial excitement around Clojure comes from the
feeling of Wow, I can do so much with so little code. But at some
point, all projects grow. I'm thinking that by now, there may be
enough people using Clojure in large projects and on large teams to
offer some good feedback about how well that works.
My Clojure codebase is somewhere around 2-3kloc and I already feel
like I'm bumping up against some frustration when it comes time to
refactor, maintain, and extend the code, all while keeping up with
ongoing changes to libraries, contrib structures, and Clojure
versions.
I want to hear war stories from those with even larger code bases than
mine. Has it proven to be a major hassle on large projects to avoid
circular dependencies in the modules? Are the lack of debugging
tools, documentation tools, and refactoring tools holding you back?
Anyone miss static typing?
One of my main gripes is that some of Clojure's built-ins return
nonsensical results (or nil), rather than errors, for certain classes
of invalid inputs. To me, one of the main benefits of functional
programming is that debugging is generally easier, in large part
because failures usually occur within close proximity of the flaw that
triggered the failure. Erlang, in particular, has really promoted the
idea of fail fast as a way to build robust systems. But Clojure's
lack of a fail-fast philosophy has burned me several times, with
hard-to-track-down bugs that were far-removed from the actual cause.
The larger my code grows, the more this annoys me, reminding me too
much of my days tracking down bugs in imperative programs.
One specific example of this is get, which returns nil whenever the
first input isn't something that supports get. For example, (get 2 2)
produces nil. This becomes especially problematic when you pass
something to get that seems like it should support get, but doesn't.
For example, (get (transient #{1}) 1) produces nil, when there's
absolutely no reason to think that (get (transient #{1} 1) would
behave any differently from ((transient #{1}) 1).
I have done 4 projects, one was with another person and ranked ~1k(a
lot of java calls). The others were done solo and ranged from ~300 to
~500 lines.
Now that I think about it, that (fail-slow/returns nil) also really
annoys me but, that normally only pops up when I have lots of side
effects chained (which make the code a lot harder to test, and it
generally leads to a lot more code being written before it's tested).
Otherwise, I iteratively build things on the repl, this coupled with
unit tests forces a bottom up approach and partially because of that
the code I write is generally a lot more maintainable than java code.
I would definitely like to hear from people with more experience to
understand if, how and why things change as the projects get larger
(in team size and code size).
--
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
Re: Clojure for large programs
On Sat, 2 Jul 2011 18:26:21 -0700
Mark Engelberg mark.engelb...@gmail.com wrote:
Ideally, I was hoping to start a more in-depth discussion about the
pros and cons of programming in the large in Clojure than just
waxing poetic about Clojure/Lisp's capabilities in the abstract :)
Yes, much of the initial excitement around Clojure comes from the
feeling of Wow, I can do so much with so little code. But at some
point, all projects grow. I'm thinking that by now, there may be
enough people using Clojure in large projects and on large teams to
offer some good feedback about how well that works.
My Clojure codebase is somewhere around 2-3kloc and I already feel
like I'm bumping up against some frustration when it comes time to
refactor, maintain, and extend the code, all while keeping up with
ongoing changes to libraries, contrib structures, and Clojure
versions.
We have above 6.5K lines of Clojure (src only) growing and it's all structured
with name spaces.
We still have a mixed code base here (Java + Clojure + JRuby) and we had already
name spaces to structure the code.
The code base is structured in 10 different projects.
We use Eclipse and CounterClockWise for dev. Dev coding/testing is done in
Eclipse
by specifying projects in dependencies.
We use leinigen to build these for Q/A and prod.
Moving from 1.0 to 1.2 was not painful. We did it methodically. With basic
tests in each
project, we spotted issues quite fast. We rolled this over a week roughly.
I want to hear war stories from those with even larger code bases than
mine. Has it proven to be a major hassle on large projects to avoid
circular dependencies in the modules? Are the lack of debugging
tools, documentation tools, and refactoring tools holding you back?
Anyone miss static typing?
Again using name spaces/individual projects here is the key to avoid circular
dependencies.
We do not miss static typing at all, in fact we are in the process of
getting rid of the Java code. The goal is to clear this by next fall.
For debugging when it's serious, we use the Eclipse JVM debugger
and look at the Clojure runtime context when needed.
As far as documentation tool we rely on (doc ...) and document our code
accordingly.
Since the code ratio versus Java is around one to 10, refactoring is not
a big deal even without the heavy assistance you may get in Java from
your IDE.
One of my main gripes is that some of Clojure's built-ins return
nonsensical results (or nil), rather than errors, for certain classes
of invalid inputs. To me, one of the main benefits of functional
programming is that debugging is generally easier, in large part
because failures usually occur within close proximity of the flaw that
triggered the failure. Erlang, in particular, has really promoted the
idea of fail fast as a way to build robust systems. But Clojure's
lack of a fail-fast philosophy has burned me several times, with
hard-to-track-down bugs that were far-removed from the actual cause.
The larger my code grows, the more this annoys me, reminding me too
much of my days tracking down bugs in imperative programs.
Were did you find the link between functional languages and close proximity of
errors ? That's a language design decision. You may want to use assertions
on your fns to validate inputs. That sould improve your ability to track errors
before they carry things too far from the spotwhere it failed.
I would not trade this for systematic exception reporting.
One specific example of this is get, which returns nil whenever the
first input isn't something that supports get. For example, (get 2 2)
produces nil. This becomes especially problematic when you pass
something to get that seems like it should support get, but doesn't.
For example, (get (transient #{1}) 1) produces nil, when there's
absolutely no reason to think that (get (transient #{1} 1) would
behave any differently from ((transient #{1}) 1).
The choice was made not to throw exceptions. Agree, it may feel frustrating
at the beginning. That's a choice that accommodate others while frustrating the
other half.
For your specific case, the first arg does not support the interface that get
expects,
however you may do this:
(get 1 1 WHATTHE...)
The third parm is the not found value. That may shed some light if your code
starts to carry this value
elsewhere. Or add assertions to your fns or create a wrapper fn.
As for transient sets, pretty sure this is a bug in 1.2.1:
user= (get (transient {:a 1}) :a)
1
user= ((transient {:a 1}) :a)
1
user= (get [1] 0)
1
user= (get (transient [1]) 0)
1
user= (get #{1} 1)
1
user= (get (transient #{1}) 1)
nil --- Oups...
user=
Dunno if it is fixed in 1.3, no time to play with it these times.
--
Luc P.
The rabid Muppet
--
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
Re: Integrating Clojure-CLR w/ VS
Sean, It looks like your not alone, see this https://github.com/jmis/vsClojure/issues/33 I was able to launch an exe outside of VS by adding the following environment variable - name: clojure.load.path value: %USERPROFILE%\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\jmis\vsClojure\1.1.0\Runtimes\1.2.0 Jeff -- 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
Re: Sample Vaadin application in Clojure
Hi Jason, How do you run the application? When I do lein run, I get the following exception: Exception in thread main java.lang.RuntimeException: java.lang.ClassNotFoundException: vaadin.Servlet, compiling:(vaadin/jetty.clj:20) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6357) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6338) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyze(Compiler.java:6118) at clojure.lang.Compiler$NewExpr$Parser.parse(Compiler.java:2396) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6350) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6338) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyze(Compiler.java:6118) at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:908) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6350) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6338) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyze(Compiler.java:6118) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5513) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5814) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6350) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6338) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyze(Compiler.java:6118) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5513) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:4949) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3570) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6348) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6338) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.access$100(Compiler.java:37) at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:492) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6350) at clojure.lang.Compiler.analyze(Compiler.java:6157) at clojure.lang.Compiler.analyze(Compiler.java:6118) at clojure.lang.Compiler.eval(Compiler.java:6410) at clojure.lang.Compiler.load(Compiler.java:6843) at clojure.lang.RT.loadResourceScript(RT.java:357) at clojure.lang.RT.loadResourceScript(RT.java:348) at clojure.lang.RT.load(RT.java:427) at clojure.lang.RT.load(RT.java:398) at clojure.core$load$fn__4636.invoke(core.clj:5377) at clojure.core$load.doInvoke(core.clj:5376) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5191) at clojure.core$load_lib.doInvoke(core.clj:5228) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:602) at clojure.core$load_libs.doInvoke(core.clj:5262) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:602) at clojure.core$require.doInvoke(core.clj:5343) at clojure.lang.RestFn.invoke(RestFn.java:408) at user$eval1.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:6406) at clojure.lang.Compiler.eval(Compiler.java:6395) at clojure.lang.Compiler.eval(Compiler.java:6372) at clojure.core$eval.invoke(core.clj:2745) at clojure.main$eval_opt.invoke(main.clj:296) at clojure.main$initialize.invoke(main.clj:315) at clojure.main$null_opt.invoke(main.clj:348) at clojure.main$main.doInvoke(main.clj:426) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:405) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:518) at clojure.main.main(main.java:37) Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: vaadin.Servlet at clojure.lang.Util.runtimeException(Util.java:153) at clojure.lang.RT.classForName(RT.java:2001) at clojure.lang.Compiler$HostExpr.maybeClass(Compiler.java:929) at clojure.lang.Compiler$HostExpr.access$400(Compiler.java:710) at clojure.lang.Compiler$NewExpr$Parser.parse(Compiler.java:2391) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6350) ... 67 more Caused by: java.lang.ClassNotFoundException: vaadin.Servlet at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:61) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.classForName(RT.java:1997) ... 71 more Thanks, Anton -- 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
Re: Clojure for large programs, was Re: Please stand firm against Steve Yegge's yes language push
Many managers, understandably, go with a technology with heavy library support and lots of developers. The common critique that Lisp isn't practical in industry, comes from that position. But Clojure, sitting atop the JVM, doesn't have that problem. The library part, ok, sure (but if I'm writing in Clojure, generally I'd prefer to work with a Clojure API, not wrestle with one built for Java). But not the lots of developers part. As much as I like Clojure, it has nowhere near the level of developers languages like Java or Python. And to be honest, that constraint is much more convincing for most software managers than the library one. Of course you can also make the argument there are fewer companies out there hiring Clojure programmers than Java programmers, so you have a better chance at nabbing an excellent developer with Clojure in the job description. But you also have a better chance at struggling to find someone at all, and it should be no surprise than in most corporate environments, most managers will go with the safe pick they know they can hire someone to work on. We can debate the wisdom of that choice and I will likely be sympathetic to your arguments, but then I'm not a manager so you would be preaching to the choir. OO may not be the ideal abstraction for many programs out there, but it is a very commonly used one (well, kinda, many Java programs are only superficially OO) so its still going to be the first choice for many managers who would prefer to go for the safe pick than take a risk with something relatively unknown. Think James Taggart in Atlas Shrugged resisting Rearden Metal because no one else uses it. On Jul 2, 7:02 pm, Timothy Washington twash...@gmail.com wrote: As for whether Clojure would work in a large corporate environment (or for large software), I think that's more a function of the internal politics of the organization. Many managers, understandably, go with a technology with heavy library support and lots of developers. The common critique that Lisp isn't practical in industry, comes from that position. But Clojure, sitting atop the JVM, doesn't have that problem. Lisp was originally developed to build an AI system. So Clojure (a Lisp) is, in my opinion, a superior way to develop any size of program. I won't enumerate Clojure's many technical features and attributes. Just recall that computers are essentially heavy paper weights without software. And software is essentially functions and the manipulation of data. These companieshttp://clojure02.managed.contegix.com/display/community/Clojure+Succe... have all successfully used Clojure in medium to large projects. And Ray Kuzweil finds Lisp to be ideally suited to build a mindhttp://singularityhub.com/2010/12/21/ray-kurzweil-the-mind-and-how-to... . OO, alternatively, is not at all practical. It was developed in the 60s, as a way to modularize (data abstraction, encapsulation, etc) large programs. The goal was maintainable and re-usable chunks of code. But we've seen the downsides of the OO paradigm, including: i) excessive overhead and ceremony, ii) software systems don't always fit into an Object world view, and iii) Rich Hickey's critique that OO is bad at representing time. Tim On Sat, Jul 2, 2011 at 3:33 PM, Mark Engelberg mark.engelb...@gmail.comwrote: On Sat, Jul 2, 2011 at 12:21 PM, James Keats james.w.ke...@gmail.com wrote: A very recent quote by Abelson is relevant: One of the things I’m learning here (Google) is the experience of working on these enormous programs. I just never experienced that before. Previously a large program to me was a hundred pages or something. Now that’s a tiny, little thing. In your post, you talk about a certain naivete among Lispers about its practicality in industry, explain that python and java benefit from their added restrictions, and then offer up the above quote by Abelson. But you never really tie these observations back to Clojure. So I want to ask explicitly, do you think Clojure is suitable for these sorts of really large programs? Why or why not? -- 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 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
Generated symbols
I'm need review of use of symbol and gensym functions in Clojure. Beside typical alpha-conversion of variables in macros, what are other typical or interesting uses of these in Clojure? Kazimir Majorinc http://kazimirmajorinc.blogspot.com -- 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
Re: Please stand firm against Steve Yegge's yes language push
On Sat, Jul 2, 2011 at 10:30 AM, James Keats james.w.ke...@gmail.com wrote: I'll re-quote it: • Most Clojure programmers go through an arc. First they think “eww, Java” and try to hide all the Java. Then they think “ooh, Java” and realize that Clojure is a powerful way to write Java code. Rich frowns upon “wrapper” functions in Clojure that do nothing but wrap a Java method. Calling the Java method directly is faster and easier to look up in JavaDoc. There's one obvious use case for such a wrapper function, though: if you'll want to pass the Java method to HOFs from time to time. You can't directly pass a Java method to a HOF, but you can pass such a wrapper function. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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
