Re: REQUEST: Add apply-map to contrib.def (or core)
On Fri, Jul 31, 2009 at 2:34 PM, Sean Devlin wrote:
>
> I've been using Meikel's defnk macro a fair bit in some of my code. I
> have several functions that have sensible defaults that only need to
> be overridden occasionally, so keyword arguments fit the bill nicely.
>
> Let's consider two (contrived) keyword fns.
>
> (use 'clojure.contrib.def)
>
> (defnk add
> [x :y 10 :z 20]
> (+ x y z))
>
> (defnk nil-free?
> [a :b 1 :c 2]
> (every? (comp not nil?) [a b c]))
>
> There are several occasions I would like to use apply, and supply a
> map for the keyword arguments. For those of you with a Python
> background, it would work just like the ** operator. Let's call this
> function apply-map (a definition can be found here:
> http://gist.github.com/159324
> ). You can use apply-map just like you would apply.
>
> (def useful-vec [:y 0])
> (def useful-map {:y 0})
>
> user=> (apply add 1 usefull-vec)
> 21
>
> ;This could be used to apply setting from a user...
> user=>(apply-map add 1 useful-map)
> 21
>
> Some more use cases:
>
> user=> (def test-map {:a "A" :b "B" :c "C"})
> #'user/test-map
> user=> (vector test-map)
> [{:a "A", :b "B", :c "C"}]
> user=> (apply vector test-map)
> [[:a "A"] [:b "B"] [:c "C"]]
> user=> (apply-map vector test-map)
> [:a "A" :b "B" :c "C"]
>
> This helps with higher order functions
>
> ;This worked before, because Meikel is just awesome.
> user=>(map add [1 2 3])
> (31 32 33)
>
> ;Slightly ugly, but it works...
> user=>(map
> #(apply-map add (first %) (second %))
> [[1 {:z 0}] [2 {:y 0}] [3]])
> (11 22 33)
>
> Similarly, this works for filter/remove
>
> ;Again, somewhat ugly...
> user=>(filter
> #(apply-map nil-free? (first %) (second %))
> [[nil {}] [1 {:b nil}] [2]])
> ([2])
>
> This does NOT attempt to solve the problem of mixing keyword and
> variable length arguments. However, I think it is a step forward in
> making keyword arguments more useful in Clojure.
>
> Feedback?
I think your 'uglies' are a hint - perhaps better to make a function
that takes a keyword fn and returns a fn that works the way you want:
(fixfnk keywordfn) -> mapargfn
((fixfnk add) 4 {:y 101}) -> 125
Then you can map, filter etc.
But the whole thing is somewhat an exercise in the non-composability
of keyword fns.
Rich
--~--~-~--~~~---~--~~
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: Bug in parallel.clj (and fix)
On Fri, Jul 31, 2009 at 10:40 AM, Eric wrote: > > I tried to import clojure.parallel today and it didn't work. It > couldn't find forkjoin.ParallelArray > > So I went hunting for it and it doesn't exist. There is a > extra166y.ParallelArray. In fact, all of the names imported were in > extra166y. So I changed the line in parallel to reflect that. > > (import '(jsr166y.forkjoin ParallelArray ParallelArrayWithBounds > ParallelArrayWithFilter > ParallelArrayWithMapping > Ops$Op Ops$BinaryOp Ops$Reducer Ops > $Predicate Ops$BinaryPredicate > Ops$IntAndObjectPredicate Ops > $IntAndObjectToObject)) > > changed to > > (import '(extra166y ParallelArray ParallelArrayWithBounds > ParallelArrayWithFilter > ParallelArrayWithMapping > Ops$Op Ops$BinaryOp Ops$Reducer Ops > $Predicate Ops$BinaryPredicate > Ops$IntAndObjectPredicate Ops > $IntAndObjectToObject)) > > > This seems to fix it. You are right, ParallelArray has moved, but more important, isn't going to make it into Java 7. Due to that, and some prodding to look at the latest ForkJoin, I've started work on implementing parallel algorithms right on the Clojure persistent data structures using the lower-lever ForkJoin primitives. The work is in the 'par' branch on GitHub: http://github.com/richhickey/clojure/tree/par You'll need the jsr166y.jar I have built, placed in the same directory as build.xml: http://cloud.github.com/downloads/richhickey/clojure/jsr166y.jar And be building and running with Java 6. Right now there is just pvmap and pvreduce, both in the clojure.par namespace. Both take (Clojure) vectors, and, unlike pmap, are quite fast even for relatively small operations, i.e. (pvmap inc v) should be faster than (map inc v) for large vectors on multicore machines. The nice thing is pvmap returns a Clojure vector, so no need for the special data structures as with the older parallel library. The results are quite promising, and I look forward to implementing many parallel operations on Clojure's vectors and maps, and providing the tools for you to write your own. Feedback welcome, Rich --~--~-~--~~~---~--~~ 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: Is it possible to swap in a new classloader?
2009/7/31 Garth Sheldon-Coulson : > Dear Clojurians, > > Is it possible to dynamically swap in a new classloader or give Clojure's > classloader a new parent classloader? > > I'm embedding Clojure in a parent app, and the parent app has its own > classloader that keeps track of its own classpath. It gives my embedded > Clojure a pretty meager classpath such that I can't import anything without > add-classpath'ing first. > > One option is to shuttle the parent classpath over to Clojure iteratively > using add-classpath. It would be better and more elegant, though, if I could > just link into the parent classloader directly. Not exactly sure what you're referring to, or what exactly the layout of your classloaders are, but classloaders are _in general_ hierarchical, with the parent having precedence. Meaning that if it's on the parents classpath, then the parent classloader will load an provide the class (that scheme is part of the security architecture around the JVM to prevent unwanted code injection/manipulation). If you're running in a container (appserver/servlet container/osgi container/etc.), which is doing classloading tricks, then the answer is going to be dependent on which container it is and how your app fits in. Cheers, Daniel --~--~-~--~~~---~--~~ 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: Bug in parallel.clj (and fix)
Brilliant. Can't wait to see this in action. On 8/1/09, Rich Hickey wrote: > > On Fri, Jul 31, 2009 at 10:40 AM, Eric wrote: >> >> I tried to import clojure.parallel today and it didn't work. It >> couldn't find forkjoin.ParallelArray >> >> So I went hunting for it and it doesn't exist. There is a >> extra166y.ParallelArray. In fact, all of the names imported were in >> extra166y. So I changed the line in parallel to reflect that. >> >> (import '(jsr166y.forkjoin ParallelArray ParallelArrayWithBounds >> ParallelArrayWithFilter >> ParallelArrayWithMapping >> Ops$Op Ops$BinaryOp Ops$Reducer Ops >> $Predicate Ops$BinaryPredicate >> Ops$IntAndObjectPredicate Ops >> $IntAndObjectToObject)) >> >> changed to >> >> (import '(extra166y ParallelArray ParallelArrayWithBounds >> ParallelArrayWithFilter >> ParallelArrayWithMapping >> Ops$Op Ops$BinaryOp Ops$Reducer Ops >> $Predicate Ops$BinaryPredicate >> Ops$IntAndObjectPredicate Ops >> $IntAndObjectToObject)) >> >> >> This seems to fix it. > > You are right, ParallelArray has moved, but more important, isn't > going to make it into Java 7. Due to that, and some prodding to look > at the latest ForkJoin, I've started work on implementing parallel > algorithms right on the Clojure persistent data structures using the > lower-lever ForkJoin primitives. > > The work is in the 'par' branch on GitHub: > > http://github.com/richhickey/clojure/tree/par > > You'll need the jsr166y.jar I have built, placed in the same directory > as build.xml: > > http://cloud.github.com/downloads/richhickey/clojure/jsr166y.jar > > And be building and running with Java 6. > > Right now there is just pvmap and pvreduce, both in the clojure.par > namespace. Both take (Clojure) vectors, and, unlike pmap, are quite > fast even for relatively small operations, i.e. (pvmap inc v) should > be faster than (map inc v) for large vectors on multicore machines. > The nice thing is pvmap returns a Clojure vector, so no need for the > special data structures as with the older parallel library. > > The results are quite promising, and I look forward to implementing > many parallel operations on Clojure's vectors and maps, and providing > the tools for you to write your own. > > Feedback welcome, > > Rich > > > > -- Sent from my mobile device --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Converting seqs to vectors & caching lazyseqs
Hi there, I have a program that produces multidimensional LazySeqs, i.e. seqs of seqs of seqs of... I would like to write a function to convert these multidimensional LazySeqs to vectors. This is in case a user needs constant lookup time. The following function will do it: (defn vectorize [obj] (if-not (seq? obj) obj (vec (map vectorize obj (def foo (list 1 2 3 (list 1 2 4 (list 1 4)) 2)) (vectorize foo) >> [1 2 3 [1 2 4 [1 4]] 2] However, since there is no recur there, the function is liable to blow the stack on a very deep data structure (or so I gather from reading about Clojure's lack of TCO). I cannot figure out how to write the function using recur. Any ideas? More broadly, this would not be necessary if I could tell my LazySeqs to cache accesses and they cached them using a constant-lookup-time data structure. I've seen mention that LazySeqs cache access, but they don't seem to for me: user=> (def foo (lazy-seq (range 1000))) user=> (time (nth foo 999)) "Elapsed time: 655.924286 msecs" 999 user=> (time (nth foo 999)) "Elapsed time: 675.42013 msecs" 999 Maybe I'm misunderstanding what is meant by caching. Any thoughts on the vectorize function or caching? Thanks. Garth --~--~-~--~~~---~--~~ 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: Converting seqs to vectors & caching lazyseqs
On Aug 1, 9:37 am, Garth Sheldon-Coulson wrote: > Hi there, > > I have a program that produces multidimensional LazySeqs, i.e. seqs of seqs > of seqs of... > > I would like to write a function to convert these multidimensional LazySeqs > to vectors. This is in case a user needs constant lookup time. > > The following function will do it: > > (defn vectorize [obj] > (if-not (seq? obj) > obj > (vec (map vectorize obj > > (def foo (list 1 2 3 (list 1 2 4 (list 1 4)) 2)) > > (vectorize foo) > > >> [1 2 3 [1 2 4 [1 4]] 2] > > However, since there is no recur there, the function is liable to blow the > stack on a very deep data structure (or so I gather from reading about > Clojure's lack of TCO). > > I cannot figure out how to write the function using recur. Any ideas? > > More broadly, this would not be necessary if I could tell my LazySeqs to > cache accesses and they cached them using a constant-lookup-time data > structure. I've seen mention that LazySeqs cache access, but they don't seem > to for me: > > user=> (def foo (lazy-seq (range 1000))) > user=> (time (nth foo 999)) > "Elapsed time: 655.924286 msecs" > 999 > user=> (time (nth foo 999)) > "Elapsed time: 675.42013 msecs" > 999 > > Maybe I'm misunderstanding what is meant by caching. The results of realizing the seq are cached, but its still a list, so the lookup is done in linear time. I would guess that the times are similar because the dominant factor is nth's traversal of the seq, not range's generation of incremental ints; that or the hotspot hasn't kicked in. > > Any thoughts on the vectorize function or caching? > Thanks. > > Garth --~--~-~--~~~---~--~~ 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: Converting seqs to vectors & caching lazyseqs
Hi, Am 01.08.2009 um 18:37 schrieb Garth Sheldon-Coulson: I have a program that produces multidimensional LazySeqs, i.e. seqs of seqs of seqs of... I would like to write a function to convert these multidimensional LazySeqs to vectors. This is in case a user needs constant lookup time. The following function will do it: (defn vectorize [obj] (if-not (seq? obj) obj (vec (map vectorize obj (def foo (list 1 2 3 (list 1 2 4 (list 1 4)) 2)) (vectorize foo) >> [1 2 3 [1 2 4 [1 4]] 2] However, since there is no recur there, the function is liable to blow the stack on a very deep data structure (or so I gather from reading about Clojure's lack of TCO). I cannot figure out how to write the function using recur. Any ideas? This function can obviously be not tail-recursive, because you need it's return value to do further computations. What you could maybe use is different "stack". (defn vectorize [s] (loop [s s v [] stack nil] (if-let [s (seq s)] (let [fst (first s)] (if (seq? fst) (recur fst [] (conj stack [(next s) v])) (recur (next s) (conj v fst) stack))) (if (seq stack) (let [[s v-s] (peek stack)] (recur s (conj v-s v) (pop stack))) v This function runs in constant stack space. It uses a separate list to store the state needed for the function to continue. This is just what happens in the call frame on the stack. I'm not sure that this is better, but it will never cause a stack overflow. user=> (vectorize '(1 2 (3 4 5) ((6) 7 8) () 9 10)) [1 2 [3 4 5] [[6] 7 8] [] 9 10] More broadly, this would not be necessary if I could tell my LazySeqs to cache accesses and they cached them using a constant- lookup-time data structure. I've seen mention that LazySeqs cache access, but they don't seem to for me: This is what's meant with "caching": user=> (def x (lazy-seq (cons (do (Thread/sleep 1) :x) nil))) #'user/x user=> (time (first x)) "Elapsed time: 1.646 msecs" :x user=> (time (first x)) "Elapsed time: 0.085 msecs" :x They calculate the value of an element only once and then cache the result. Hope this helps. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Clojure without Rich Hickey
Today i saw the announcement http://groups.google.com/group/Qilang/browse_thread/thread/592773c562017d87 that the creator and maintainer of another modern lisp dialect Qi closed the shop and went to India. The effect on Qi was so drastic that the Qi community are discussing right now which languages to port it over, clojure being one of the options. Since i'm using clojure in my business i got worried at a sudden thought what would happen to clojure if Ruch calls it a day. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Possible addition to swing-utils?
Hello Stephen, maybe this is worth another addition to c.c.swing-utils? (import 'javax.swing.JFileChooser) (use [clojure.contrib.def :only (defvar-)]) (defvar- file-chooser-last-directory (atom nil)) (defn with-chosen-file* "Creates a file chooser with the given Ok button label. If a directory is supplied the chooser starts showing the directory. If no directory is provided the chooser shows the last directory which was opened in the last call to the chooser." ([thunk label] (with-chosen-file* (fn [f] (reset! file-chooser-last-directory (.getParentFile f)) (thunk f)) @file-chooser-last-directory label)) ([thunk directory label] (let [chooser (JFileChooser. directory)] (when (= (.showDialog chooser nil label) JFileChooser/APPROVE_OPTION) (thunk (.getSelectedFile chooser)) (defmacro with-chosen-file "Opens a file chooser, binds the result the user chose to the given variable name and executes the body. In front of the body there might be two options given: :directory is the initial directory shown in the chooser :label is the label shown on the Ok button of the dialog If no directory is given, the dialog will show the parent directory of the last chosen file. If no label is given Choose will be used. If given, directory must be specified first." [file & body] (let [directory (when (= (first body) :directory) (second body)) body (if directory (nnext body) body) label (if (= (first body) :label) (second body) "Choose") body (if (= (first body) :label) (nnext body) body)] (if directory `(with-chosen-file* (fn [~file] ~...@body) ~directory ~label) `(with-chosen-file* (fn [~file] ~...@body) ~label Any thoughts? I'm not totally happy with the current form, so discussion appreciated. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Converting seqs to vectors & caching lazyseqs
Wow, that's really good. That's what I was trying to come up with all afternoon. I knew I needed some way to keep track of the function's state, but I couldn't figure it out. I came up with my own version using Rich's zipper library, traversing the data structure like a tree, but yours is much faster. Thank you. On Sat, Aug 1, 2009 at 5:53 PM, Meikel Brandmeyer wrote: > Hi, > > Am 01.08.2009 um 18:37 schrieb Garth Sheldon-Coulson: > > I have a program that produces multidimensional LazySeqs, i.e. seqs of >> seqs of seqs of... >> >> I would like to write a function to convert these multidimensional >> LazySeqs to vectors. This is in case a user needs constant lookup time. >> >> The following function will do it: >> >> (defn vectorize [obj] >> (if-not (seq? obj) >>obj >>(vec (map vectorize obj >> >> (def foo (list 1 2 3 (list 1 2 4 (list 1 4)) 2)) >> >> (vectorize foo) >> >> [1 2 3 [1 2 4 [1 4]] 2] >> >> However, since there is no recur there, the function is liable to blow the >> stack on a very deep data structure (or so I gather from reading about >> Clojure's lack of TCO). >> >> I cannot figure out how to write the function using recur. Any ideas? >> > > This function can obviously be not tail-recursive, because you need it's > return value to do further computations. What you could maybe use is > different "stack". > > (defn vectorize > [s] > (loop [s s > v [] > stack nil] >(if-let [s (seq s)] > (let [fst (first s)] >(if (seq? fst) > (recur fst [] (conj stack [(next s) v])) > (recur (next s) (conj v fst) stack))) > (if (seq stack) >(let [[s v-s] (peek stack)] > (recur s (conj v-s v) (pop stack))) >v > > This function runs in constant stack space. It uses a separate list to > store the state needed for the function to continue. This is just what > happens in the call frame on the stack. I'm not sure that this is better, > but it will never cause a stack overflow. > > user=> (vectorize '(1 2 (3 4 5) ((6) 7 8) () 9 10)) > [1 2 [3 4 5] [[6] 7 8] [] 9 10] > > More broadly, this would not be necessary if I could tell my LazySeqs to >> cache accesses and they cached them using a constant-lookup-time data >> structure. I've seen mention that LazySeqs cache access, but they don't seem >> to for me: >> > > This is what's meant with "caching": > > user=> (def x (lazy-seq (cons (do (Thread/sleep 1) :x) nil))) > #'user/x > user=> (time (first x)) > "Elapsed time: 1.646 msecs" > :x > user=> (time (first x)) > "Elapsed time: 0.085 msecs" > :x > > They calculate the value of an element only once and then cache the result. > > Hope this helps. > > Sincerely > Meikel > > --~--~-~--~~~---~--~~ 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 without Rich Hickey
I think the short answer is to build up clojure community so strong that in the very unlikely event this happens, clojure can survive it. On Aug 1, 2009, at 6:22 PM, Vagif Verdi wrote: > > Today i saw the announcement > http://groups.google.com/group/Qilang/browse_thread/thread/592773c562017d87 > that the creator and maintainer of another modern lisp dialect Qi > closed the shop and went to India. > The effect on Qi was so drastic that the Qi community are discussing > right now which languages to port it over, clojure being one of the > options. > > Since i'm using clojure in my business i got worried at a sudden > thought what would happen to clojure if Ruch calls it a day. > > > > > --~--~-~--~~~---~--~~ 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 without Rich Hickey
> Today i saw the announcement > http://groups.google.com/group/Qilang/browse_thread/thread/592773c562017d87 > that the creator and maintainer of another modern lisp dialect Qi > closed the shop and went to India. > The effect on Qi was so drastic that the Qi community are discussing > right now which languages to port it over, clojure being one of the > options. I find this somewhat amusing: it targets Common Lisp, a language which isn't likely to change soon. Mark Tarver's departure shouldn't be a motivation for retargeting Qi! > Since i'm using clojure in my business i got worried at a sudden > thought what would happen to clojure if Ruch calls it a day. It's worth noting that Clojure and Qi are in very different situations. Qi is built on Common Lisp, and (my personal perspective) somewhat driven by the author's view of the limitations of CL. As such its primary audience is a sophisticated subset of Common Lisp users — already a small group. Clojure has a much larger pool from which to draw: dissatisfied Lispers, Java people, concurrency enthusiasts… I suspect that Clojure already has enough "community experts" that development would continue should Rich depart; hundreds of people have heard Rich speak, read the documentation and code for various features and paradigms, and so on. Some have even gone so far as to take up the CLR port, which is a good sign. I'm quite confident in it continuing to meet my needs for the foreseeable future. Sidenote 1: Given its focus on solving the practical problems that plague professional developers, rather than on software research, I'd be inclined to think that Clojure is already a much better choice for commercial software than Qi, with a larger pool of experts/ consultants, simpler deployment, yadda yadda. Sidenote 2: Qi isn't free for commercial use unless you buy the book. Odd. --~--~-~--~~~---~--~~ 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 without Rich Hickey
On Sat, Aug 1, 2009 at 6:22 PM, Vagif Verdi wrote: > > Since i'm using clojure in my business i got worried at a sudden > thought what would happen to clojure if Ruch calls it a day. If Rich quit working on Clojure for whatever reason, it would be a huge blow to the potential future of Clojure. That is, Clojure is not yet done, and I don't know of anyone with the focus, drive, and design sensibility needed to take it to where it could be, other than Rich. However, I do think the community already has sufficient knowledge and experience to fix Clojure bugs as they turn up and perhaps even make modest incremental improvements. The code (the complete history even) is widely distributed, so there's essentially no risk of losing anything important there. The docs, name, and website might have some stewardship issues, but nothing that can't be solved with transparency and goodwill, I would expect. The thought of everyone trying to get all this organized is quite daunting, but people would manage. So I think you shouldn't let it trouble you too much. In other words: Don't worry. Be happy now. Doo doo doo... --Chouser --~--~-~--~~~---~--~~ 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 without Rich Hickey
On Aug 1, 3:22 pm, Vagif Verdi wrote: > Today i saw the > announcementhttp://groups.google.com/group/Qilang/browse_thread/thread/592773c562... > that the creator and maintainer of another modern lisp dialect Qi > closed the shop and went to India. The guy certainly has some self-image: """ Anyhow, I was thinking of Mitchell and his beautiful creation, the Spitfire. The guy barely lived to see it fly and he certainly didn't expect to fight in it. Yet a whole generation of men, Stanford Tuck, Sailor Malan etc. flew and fought in his magnificent machine. And another generation of scabby-kneed schoolboys, of which I was one, built Airfix models of the machine. It was just so beautiful to draw - the elliptical wings were just an exquisite line. I've been luckier, just, than Mitchell. He died of cancer shortly after his prototype took wing. The reason I think of him is because I think Qi has something in common with that beautiful piece of design engineering; and I also think that like Mitchell, it will be others and not myself who pilot it and exploit its amazing acrobatics to their fullest extent. --~--~-~--~~~---~--~~ 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 without Rich Hickey
On Aug 1, 7:24 pm, Chouser wrote: > On Sat, Aug 1, 2009 at 6:22 PM, Vagif Verdi wrote: > > > Since i'm using clojure in my business i got worried at a sudden > > thought what would happen to clojure if Ruch calls it a day. > > If Rich quit working on Clojure for whatever reason, it > would be a huge blow to the potential future of Clojure. > That is, Clojure is not yet done, and I don't know of anyone > with the focus, drive, and design sensibility needed to take > it to where it could be, other than Rich. I think there is a huge difference between Clojure and Qi. Clojure was created by the author "for himself". Tarver created Qi so that others could go forth and program in it (application programming is something he claimed to have no interest in). For the record, I don't see the point of Qi whatsoever, but that's another (off-topic) story. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
