Re: Clojure analysis
Hello, 2009/12/17 Dmitry Kakurin > Judging by the article you've spent very little time "learning" > Clojure and have managed to get every key point wrong: > > > Clojure is a multi-paradigm language > > no it's not, and it's most certainty not an OOP language: > http://clojure.org/rationale > > > Functional programming finds its best implementation in the homoiconic > language family. > > very debatable statement > > > The attitude of the language [...] is to be a better Java > > Clojure's attitude is to be a great language for JVM platform (and > maybe CLR) _other_ than Java. With different set of goals. Granted > it's often _compared_ with Java for obvious reasons. > > > one will not appreciate Clojure for being a better LISP. Instead Clojure > tries to be a better Java with LISP syntax. > > Not sure who the 'one' is. I for one do appreciate Clojure as a better > Lisp :-). > > > Owing to the above attitude, many of the language constructs exist so > that one can do what Java cannot do > > Is Java some kind of "golden standard" in language design now? > > > For e.g. tail calls cannot be optimized in the Java > > Correction: in current version of JVM > As for tail calls, Clojure has to live with limitations of the target > platform. > > > In Clojure this identity is lost, because practical implementation > difficulties are put ahead of clean design. > > IMHO Clojure has a rather strong and unique identity. Here is my > elevator pitch for Clojure (not any kind of analysis, just what makes > Clojure attractive to ME): > - Lisp dialect designed for JVM with transparent interop > - Better Lisp than Lisp :-) Simpler/cleaner than Common Lisp, more > practical than Scheme. > - Rich immutable collections unified by a concept of sequence > I just learned (the hard way, by being humble and asking :-) ) on #clojure that one does not say "immutable" collections but "persistent" collections, since "persistent" conveys a lot more information about what Rich has achieved than just saying "immutable". :-p > - Unique and intriguing approach to state, identity and concurrency > - Very dedicated and talented author, great community > > In general I'd like to second Luc's "be humble" comment. And do your > home work before doing "analysis". > > - Dmitry > > On Dec 11, 1:04 pm, kusi wrote: > > http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-la... > > -- > 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: Clojure analysis
> I just learned (the hard way, by being humble and asking :-) ) on > #clojure that one does not say "immutable" collections but > "persistent" collections, since "persistent" conveys a lot more > information about what Rich has achieved than just saying "immutable". Good explanation: http://en.wikipedia.org/wiki/Persistent_data_structure Contrast to: http://en.wikipedia.org/wiki/Immutable_object -- 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: Semantic Versioning
Isn't this the ideal that clojure and libraries are almost more or less already following ? 2009/12/16 Nicolas Buduroi > Hi, on the CommonJS Google Group there was a discussion on semantic > versioning, a formalization of the concept of properly using a common > version number scheme (Major.Minor.Patch) for libraries. > > http://semver.org/ > > I think it would be especially easy to enforce a simple version of > this system in a Clojure project. A program could inspect code and > decide what version number to use during build time. The major version > could be changed automatically once a public function, multi-method or > macro arguments list change in a non-backward compatible way and also > when some of them are removed. The patch version number could be > incremented when code change (but not the API) and existing tests > don't change or new tests have been added. The minor version could be > incremented in other cases. This implementation have it's quirks, like > not being able to check for return types. Doing it for real would > certainly uncover a more lot subtle details. > > What do you thinking about this idea? How would you improve it? > > - budu > > -- > 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: Semantic Versioning
Dealing with version numbers at build time is quite easy with tool like Maven. The important thing is that everyone agrees on the same version semantics (great summary [1]). Putting some more tooling around this should be a good idea, yes. However, the problem in Java is dealing with versions at runtime, not at build time! Java's classloader design has not knowledge about versions, etc and makes it impossible to deal with versions without a new layer on top of it. The default system for dealing with this in Java is OSGi. Unfortunately, Clojure's classloader design seems to be completely incompatible with OSGi. If we could solve this, Clojure would instantly get multi version support. Cheers, Roman [1] http://www.osgi.org/blog/2009/12/versions.html 2009/12/16 Nicolas Buduroi : > Hi, on the CommonJS Google Group there was a discussion on semantic > versioning, a formalization of the concept of properly using a common > version number scheme (Major.Minor.Patch) for libraries. > > http://semver.org/ > > I think it would be especially easy to enforce a simple version of > this system in a Clojure project. A program could inspect code and > decide what version number to use during build time. The major version > could be changed automatically once a public function, multi-method or > macro arguments list change in a non-backward compatible way and also > when some of them are removed. The patch version number could be > incremented when code change (but not the API) and existing tests > don't change or new tests have been added. The minor version could be > incremented in other cases. This implementation have it's quirks, like > not being able to check for return types. Doing it for real would > certainly uncover a more lot subtle details. > > What do you thinking about this idea? How would you improve it? > > - budu > > -- > 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: Clojure analysis
Thanks Richard for the good link. So to be even more precise, we can say that clojure's data structures are "fully" persistent since any older version of the datastructure can still serve as the basis to create new versions. 2009/12/17 Richard Newman > > I just learned (the hard way, by being humble and asking :-) ) on > > #clojure that one does not say "immutable" collections but > > "persistent" collections, since "persistent" conveys a lot more > > information about what Rich has achieved than just saying "immutable". > > Good explanation: > > http://en.wikipedia.org/wiki/Persistent_data_structure > > Contrast to: > > http://en.wikipedia.org/wiki/Immutable_object > > -- > 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: Clojure analysis
Please keep in mind that it is almost literally the speech that I give to my friends/colleagues when they ask me why am I so excited about Clojure. I did it many times now and I have quickly learned that saying "persistent data structures" gets misinterpreted by every single person as "something you can save to file [as XML/binary]", i.e. serialization. So the funny thing is: by changing my tune and being imprecise, I communicate the basic idea much better now :-). I do understand and appreciate the difference (and I've watched all Rich's talks :-) but the term is so overloaded that it usually misleads "imperative" people. Only later I can introduce and use it by giving a formal definition first and letting it settle for a while. And only with people who wants to hear more and cares to learn the difference :). - Dmitry On Dec 17, 12:24 am, Laurent PETIT wrote: > Thanks Richard for the good link. > > So to be even more precise, we can say that clojure's data structures are > "fully" persistent since any older version of the datastructure can still > serve as the basis to create new versions. > > 2009/12/17 Richard Newman > > > > > > I just learned (the hard way, by being humble and asking :-) ) on > > > #clojure that one does not say "immutable" collections but > > > "persistent" collections, since "persistent" conveys a lot more > > > information about what Rich has achieved than just saying "immutable". > > > Good explanation: > > >http://en.wikipedia.org/wiki/Persistent_data_structure > > > Contrast to: > > >http://en.wikipedia.org/wiki/Immutable_object > > > -- > > 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: Clojure analysis
That's quite true ! 2009/12/17 Dmitry Kakurin > Please keep in mind that it is almost literally the speech that I give > to my friends/colleagues when they ask me why am I so excited about > Clojure. I did it many times now and I have quickly learned that > saying "persistent data structures" gets misinterpreted by every > single person as "something you can save to file [as XML/binary]", > i.e. serialization. > So the funny thing is: by changing my tune and being imprecise, I > communicate the basic idea much better now :-). > > I do understand and appreciate the difference (and I've watched all > Rich's talks :-) but the term is so overloaded that it usually > misleads "imperative" people. Only later I can introduce and use it by > giving a formal definition first and letting it settle for a while. > And only with people who wants to hear more and cares to learn the > difference :). > > - Dmitry > > On Dec 17, 12:24 am, Laurent PETIT wrote: > > Thanks Richard for the good link. > > > > So to be even more precise, we can say that clojure's data structures are > > "fully" persistent since any older version of the datastructure can still > > serve as the basis to create new versions. > > > > 2009/12/17 Richard Newman > > > > > > > > > > I just learned (the hard way, by being humble and asking :-) ) on > > > > #clojure that one does not say "immutable" collections but > > > > "persistent" collections, since "persistent" conveys a lot more > > > > information about what Rich has achieved than just saying > "immutable". > > > > > Good explanation: > > > > >http://en.wikipedia.org/wiki/Persistent_data_structure > > > > > Contrast to: > > > > >http://en.wikipedia.org/wiki/Immutable_object > > > > > -- > > > 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 > -- 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: How to fund open source Clojure development
> > > e. Find a business for whom Clojure is a critical piece of technology. > It is the easiest way to fund it. However AFAIK there is no big/profitable business depending on clojure solely...yet Everything else would eat into Rich's time and hence may not be such a good thing. -- 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: Funding Clojure 2010
I have looked at hundreds of languages and flavors more as a kind of hobby these days. I know these comments are getting a bit tedious by now, but what I think clojure needs is higher visibility. Right now only a handful of people know about it. The thought occurred to me while I was installing another open source language system today, I (but have only dabbled in clojure a bit so far), was that they had a visually appealing website. Visual signals send a strong message. This particular one has a lucious red strawberry (hint hint) motif, simple, clean, and appealing, and kind of lightens up a drab subject, makes it almost.. well I won't get into it. I'm coming at this as a bit of an outsider as have not been a programmer in a long time since I got involved with start-ups. So anyways, my point is, if you're looking for mass appeal, eveything is pretty web-based packaging these days. Forget even the CD idea, thats old, even for an old guy like me (I don't even have a CD drive on my computer anymore !). Also a windows installer, and no asking the user to compile things, make it as shrink wrapped as possible, with a good online tutorial, and chat help all bundled together in a quick install. Brian Rich Hickey wrote: > Funding Clojure 2010 > > Background > -- > > It is important when using open source software that you consider who > is paying for it, because someone is. There is no such thing as free > software. > > Sometimes open source software is developed under a license with > undesirable properties (e.g. the GPL), such that people are willing to > pay for a (proprietary) version of it that is not subject to that > license. Both Monty Widenius [1] and Richard Stallman [2] have argued > for the necessity of such a mechanism to fund open source software, > lest there be insufficient resources for its development. Clojure > doesn't use the GPL, thus conveying more freedom to its users, but > precluding me from funding it via dual licensing. > > Some companies develop technology as a component of a proprietary > product or service, absorbing it as a necessary expense, only to > decide that it is not a core, unique, or advantage-bearing business > function. They can reduce their costs in ongoing development by open > sourcing it, deriving benefit from community contributions and letting > them focus on their core business [3]. It is important to note that > the bulk of the costs are often in the original development, and are > paid for by the proprietary product or service. That is not the case > for Clojure. > > Some open source is the product of academic research, and is funded by > the academic institution and/or research grants [4]. That is not the > case for Clojure. > > Some open source software is (partially) funded by proprietary > support. It is important to note that often the support income does > not in fact make it to the people who create the software. Such income > models work best for support sold to conservative enterprises [5]. > That is not the case for Clojure. > > Some companies 'fund' open source software by dedicating some of their > employees' time, or making investments, in its development. There must > be some business value to the company for doing so (e.g. it helps them > sell hardware [6]), and thus is ultimately paid for by their > proprietary products/services. That is not the case for Clojure. > > There *are* companies that make software themselves, whose consumers > see a value in it and willingly pay to obtain that value. The money > produced by this process pays the salaries of the people who are > dedicated to making it, and some profit besides. It's called > "proprietary software". People pay for proprietary software because > they have to, but otherwise the scenario is very similar to open > source - people make software, consumers get value from it. In fact, > we often get a lot less with proprietary software - vendor lock-in, no > source etc. Most alarmingly, this is the only model that associates > value with software itself, and therefore with the people who make it. > > Why don't people pay for open source software? Primarily, because they > don't *have to*. I think also, partially, it is because open source > software often doesn't have a price tag. I think it should. I'd like > to pay for open source, and know the money is going to those who > create it. I'd like companies to *expect* to pay for it. I'd like to > see people make a living (and even profit!) directly making open > source, not as a side effect of some other proprietary process, to > dedicate themselves to it, and not have it be hobby/side work. > > Unfortunately, there seems to be no way to convey the full benefits of > open source software while *forcing* people to pay for it. Only in the > proprietary (including dual-license) model is there a direct > connection between the consumers of software and th
Re: How to modify the last few elements of a vector
Hi, On Dec 16, 10:36 pm, Graham Fawcett wrote: > Not sure it's better, but I find this more readable: > > (defn stack-apply [n f stack] > (if (zero? n) > stack > (conj (stack-apply (dec n) f (pop stack)) > (f (last stack) Unrelated note: (last stack) turns the vector into a seq and walks it linearly. (peek stack) returns the last element in O(1) (or maybe O (log32 N)?) time. 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: How to modify the last few elements of a vector
On Thu, Dec 17, 2009 at 2:04 AM, Meikel Brandmeyer wrote: > Hi, > > On Dec 16, 10:36 pm, Graham Fawcett wrote: > >> Not sure it's better, but I find this more readable: >> >> (defn stack-apply [n f stack] >> (if (zero? n) >> stack >> (conj (stack-apply (dec n) f (pop stack)) >> (f (last stack) > > Unrelated note: (last stack) turns the vector into a seq and walks it > linearly. (peek stack) returns the last element in O(1) (or maybe O > (log32 N)?) time. Definitely related! Thanks, Miekel, I have not yet internalized all of these seq operations. Best, Graham > > 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 -- 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
mapmap
I was just wondering how a #'map for maps could be done most
succinctly. Came up with this:
(defn mapmap
"Map values of map m using function f."
[f m]
(reduce (fn [m [k v]]
(assoc m k (f v))) {} m))
But there is probably a more straightforward way. What do you use?
Florian
--
Florian Ebeling
florian.ebel...@gmail.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: Any interest in a Nova Clug?
Interested? Yes. But it is improbable that I could attend anything regularly that was not metro accessible. -- 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: mapmap
1. I'd call it map-vals (as opposed to map-keys)
2. Slight change in the body
(defn map-vals [f coll]
(into {} (map (juxt key (comp f val)) coll))
There is talk of getting something like this into contrib. Stay
tuned :)
Sean
On Dec 17, 9:37 am, "C. Florian Ebeling"
wrote:
> I was just wondering how a #'map for maps could be done most
> succinctly. Came up with this:
>
> (defn mapmap
> "Map values of map m using function f."
> [f m]
> (reduce (fn [m [k v]]
> (assoc m k (f v))) {} m))
>
> But there is probably a more straightforward way. What do you use?
>
> Florian
>
> --
> Florian Ebeling
> florian.ebel...@gmail.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: mapmap
AFAIK, such a function is still not in clojure core because it's not clear
to Rich whether f should have one argument (the value), or 2 arguments (key
+ value).
Your version seems good, you can maybe improve it a little bit by using
transients (not tested):
(persistent!
(reduce (fn [m [k v]]
(assoc! m k (f v))) (transient {}) m))
HTH,
--
Laurent
2009/12/17 C. Florian Ebeling
> I was just wondering how a #'map for maps could be done most
> succinctly. Came up with this:
>
> (defn mapmap
> "Map values of map m using function f."
> [f m]
> (reduce (fn [m [k v]]
>(assoc m k (f v))) {} m))
>
> But there is probably a more straightforward way. What do you use?
>
> Florian
>
> --
> Florian Ebeling
> florian.ebel...@gmail.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
--
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 interest in a Nova Clug?
I'm interested, but may have a hard time making it consistently. I do have a coworker or two who might have both interest and availability. On Dec 16, 1:14 pm, Matt wrote: > I'm looking into setting up a Northern Virginia Clojure User Group and > would like to know who is interested. I know there is a DC clojure > study group, but it seems to not be as active recently. DC is also > hard for me to get to during the week. > > We have a couple of other user groups which meet once a month right > here in my office in Reston, VA. If there are enough people > interested, I can coordinate with the other user group organizers to > start a Clojure user group using the same meeting space. > > Questions? Comments? Hassletations? Aggravations? Contemplations? -- 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: Funding Clojure 2010
Speaking of websites, if you're talking about Matz creation, please bear in mind it has had a less appealing website for almost 10 years... ;) So maybe let give Clojure a bit time. Of course many things Ruby community achieved are cool. Both Ruby and Rails have very good introductory tutorials & docs which lowers a barrier to entry. OTOH Clojure documentation is awesome considering the fact how young project is it. The community here is expanding, smart people are writing smart tools, all that may seem to be a disorganized cloud of github projects, but in fact some order and standards are emerging. Evolution takes time. Referring to Ruby again, it earned gems & rake about 7 years after initial release IIRC. Now about Rich's manifesto: thanks for the honest and clear words. I'll donate and start persuading some organizations I work for to do so. On Thu, Dec 17, 2009 at 07:37, brian wrote: > I have looked at hundreds of languages and flavors more as a kind > of hobby these days. I know these comments are getting a bit > tedious by now, but what I think clojure needs is higher visibility. > Right now only a handful of people know about it. The thought > occurred to me while I was installing another open source language > system today, I (but have only dabbled in clojure a bit so far), was > that they had a visually appealing website. Visual signals send a > strong message. This particular one has a lucious red strawberry > (hint hint) motif, simple, clean, and appealing, and kind of > lightens up a drab subject, makes it almost.. well I won't get into > it. I'm coming at this as a bit of an outsider as have not been a > programmer in a long time since I got involved with start-ups. So > anyways, my point is, if you're looking for mass appeal, eveything > is pretty web-based packaging these days. Forget even the CD idea, > thats old, even for an old guy like me (I don't even have a CD drive > on my computer anymore !). Also a windows installer, and no asking > the user to compile things, make it as shrink wrapped as possible, > with a good online tutorial, and chat help all bundled together in > a quick install. > > Brian > > > > > Rich Hickey wrote: >> Funding Clojure 2010 >> >> Background >> -- >> >> It is important when using open source software that you consider who >> is paying for it, because someone is. There is no such thing as free >> software. >> >> Sometimes open source software is developed under a license with >> undesirable properties (e.g. the GPL), such that people are willing to >> pay for a (proprietary) version of it that is not subject to that >> license. Both Monty Widenius [1] and Richard Stallman [2] have argued >> for the necessity of such a mechanism to fund open source software, >> lest there be insufficient resources for its development. Clojure >> doesn't use the GPL, thus conveying more freedom to its users, but >> precluding me from funding it via dual licensing. >> >> Some companies develop technology as a component of a proprietary >> product or service, absorbing it as a necessary expense, only to >> decide that it is not a core, unique, or advantage-bearing business >> function. They can reduce their costs in ongoing development by open >> sourcing it, deriving benefit from community contributions and letting >> them focus on their core business [3]. It is important to note that >> the bulk of the costs are often in the original development, and are >> paid for by the proprietary product or service. That is not the case >> for Clojure. >> >> Some open source is the product of academic research, and is funded by >> the academic institution and/or research grants [4]. That is not the >> case for Clojure. >> >> Some open source software is (partially) funded by proprietary >> support. It is important to note that often the support income does >> not in fact make it to the people who create the software. Such income >> models work best for support sold to conservative enterprises [5]. >> That is not the case for Clojure. >> >> Some companies 'fund' open source software by dedicating some of their >> employees' time, or making investments, in its development. There must >> be some business value to the company for doing so (e.g. it helps them >> sell hardware [6]), and thus is ultimately paid for by their >> proprietary products/services. That is not the case for Clojure. >> >> There *are* companies that make software themselves, whose consumers >> see a value in it and willingly pay to obtain that value. The money >> produced by this process pays the salaries of the people who are >> dedicated to making it, and some profit besides. It's called >> "proprietary software". People pay for proprietary software because >> they have to, but otherwise the scenario is very similar to open >> source - people make software, consumers get value from it. In fact, >> we often get a lot less with proprietary software
Re: mapmap
> AFAIK, such a function is still not in clojure core because it's not clear
> to Rich whether f should have one argument (the value), or 2 arguments (key
> + value).
That is a good question. But I thought if the key makes a difference,
then one could use standard map and rely on map's collection nature,
using into {} afterwards.
My reasoning was that map does not care about the index of an element
of collection either. So the key should not count in. But there are
valid reasons for the opposite decision as well, I guess.
Florian
--
Florian Ebeling
florian.ebel...@gmail.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: mapmap
On Dec 17, 9:37 am, "C. Florian Ebeling"
wrote:
> (defn mapmap
> "Map values of map m using function f."
> [f m]
> (reduce (fn [m [k v]]
> (assoc m k (f v))) {} m))
>
> But there is probably a more straightforward way. What do you use?
I do that exactly, but I never felt the need to define a new function
for it. The advantage of "reduce" is that you can change the keys
too, and pick which keys end up in the final map.
-SS
--
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
Is this the expected behavior related to agent options in action function?
Hi,
I'm trying to access from within a action function, and with no
success, the metadata associated with agent.
My code:
user> (def agt (agent nil :meta {"some" "data"}))
user> (defn action [_] (:meta *agent*))
user> (await (send agt action))
Wich results in:
user> @agt
nil
Instead of:
user> @agt
{"some" "data"}
The same happens with a validation function. I'm wondering if this is
the expected behavior.
Thanks.
--
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 interest in a Nova Clug?
I'm in and Reston would be great. On Dec 17, 9:50 am, Mike Hogye wrote: > I'm interested, but may have a hard time making it consistently. I do > have a coworker or two who might have both interest and availability. > > On Dec 16, 1:14 pm, Matt wrote: > > > > > I'm looking into setting up a Northern Virginia Clojure User Group and > > would like to know who is interested. I know there is a DC clojure > > study group, but it seems to not be as active recently. DC is also > > hard for me to get to during the week. > > > We have a couple of other user groups which meet once a month right > > here in my office in Reston, VA. If there are enough people > > interested, I can coordinate with the other user group organizers to > > start a Clojure user group using the same meeting space. > > > Questions? Comments? Hassletations? Aggravations? Contemplations? -- 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: mapmap
Hi Laurent,
If you want to use transients, since the keyset is unchanged, it
should perform slightly better when using (transient m) instead of
(transient {}) as the seed to reduce.
Christophe
On Dec 17, 3:46 pm, Laurent PETIT wrote:
> AFAIK, such a function is still not in clojure core because it's not clear
> to Rich whether f should have one argument (the value), or 2 arguments (key
> + value).
>
> Your version seems good, you can maybe improve it a little bit by using
> transients (not tested):
>
> (persistent!
> (reduce (fn [m [k v]]
> (assoc! m k (f v))) (transient {}) m))
>
> HTH,
>
> --
> Laurent
>
> 2009/12/17 C. Florian Ebeling
>
> > I was just wondering how a #'map for maps could be done most
> > succinctly. Came up with this:
>
> > (defn mapmap
> > "Map values of map m using function f."
> > [f m]
> > (reduce (fn [m [k v]]
> > (assoc m k (f v))) {} m))
>
> > But there is probably a more straightforward way. What do you use?
>
> > Florian
>
> > --
> > Florian Ebeling
> > florian.ebel...@gmail.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
--
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: mapmap
On 17 Dec 2009, at 15:44, Sean Devlin wrote:
> 1. I'd call it map-vals (as opposed to map-keys)
>
> 2. Slight change in the body
>
> (defn map-vals [f coll]
> (into {} (map (juxt key (comp f val)) coll))
>
> There is talk of getting something like this into contrib. Stay
> tuned :)
There's already clojure.contrib.generic.functor/fmap, which is a
multimethod whose implementation for maps does just that. Here's the
code:
(defmethod fmap clojure.lang.IPersistentMap
[f m]
(into (empty m) (for [[k v] m] [k (f v)])))
Konrad.
--
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: mapmap
On Thu, Dec 17, 2009 at 12:16 PM, Konrad Hinsen
wrote:
>
> On 17 Dec 2009, at 15:44, Sean Devlin wrote:
> > (defn map-vals [f coll]
> > (into {} (map (juxt key (comp f val)) coll))
vs:
> (defmethod fmap clojure.lang.IPersistentMap
> [f m]
> (into (empty m) (for [[k v] m] [k (f v)])))
Are there any guidelines as to when it's appropriate to use the map
function vs a list comprehension?
e
--
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: Help recreating OS X Leiningen 1.0 +Swank bug
I came across this problem too, and David's patch helps, to a certain extent.
Additionally, without David's patch, the "src" and "test" directories of the
current project don't get added to the classpath one sees from inside swank.
(All the jars upon which leiningen depends *are* in the classpath, which is
probably also less than ideal.)
However, by forking the JVM, the console output is reformatted unpleasantly by
Ant, and any JAVA_OPTs etc. passed to lein's "master" JVM are not passed
through. The former is a nuisance, but the latter stops you from running Swank
with an increased max memory allowance, for example.
Given my immediate goal of processing a moderate pile of data within a swank
REPL session and charting it with Incanter, I have had to revert to
swank-clojure-project, when it would have been considerably cleaner to use
"lein swank".
I'm trying to get my head around what can be done here, and will report back if
I have any insights. It's been so nice to let leiningen take care of the
classpath for me, having abandoned Java years ago for less encumbered
languages. ("Ah, my old nemesis CLASSPATH, finally we meet again!")
-Steve
On 9 Dec 2009, at 19:13, David Nolen wrote:
> I found a solution to this problem and patched my own fork of Leiningen:
>
> http://github.com/swannodette/leiningen/commit/9d79d631a9faa870a9347992f50a4312170fdf97
>
> The important thing to do if you want this to work is to closely follow the
> instructions for hacking on Leiningen that's currently available on GitHub.
> Then you need a custom-build of lein-swank. This is easy enough to do, move
> into lein-swank in your Leiningen checkout and run:
>
> lein uberjar
>
> You might see some errors but none are deal breakers. Copy the new
> lein-swank-standalone.jar and replace the one in that is in your lib folder
> in your leiningen checkout.
>
> David
>
> On Tue, Dec 8, 2009 at 11:35 AM, David Nolen wrote:
> Just want to make sure other people are seeing this on OS X. When starting up
> "lein swank" from the project directory and attempting to connect from Emacs
> with slime-connect with this simple clojure project
> http://github.com/swannodette/lein-macosx-bug (just creates a JPanel and
> draws a small line) I get an exception:
>
> Cannot load apple.laf.AquaLookAndFeel
>
> I'm using lein 1.0, usual Emacs/Clojure/SLIME config on OS X 10.6, JDK 1.6
> 64bit.
>
> I note that if I use leiningen from git checkout I don't have this problem
> which seems odd since there aren't many changes between 1.0 and
> leiningen/master.
>
> Thanks,
> 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
--
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 analysis
> You warn that you learn languages "just for the fun of it". I would be > curious to know how much time you spent learning Clojure... I have been working with Scheme for the past 5 years. Yep, I don't have 20+ years in development; neither 12+ months in Clojure. My learning of Clojure has been for the past 2-3 months. As I have sent in my blog post "I am not a clojure developer. I am a programming language enthusiast". I don't think that disqualifies from expressing an opinion. > We have been working with Clojure for more than a 16 months with a > message bus software in production for 11 months. > Not a simple HelloWorld app To be honest, I have not written complicated software in Clojure. I am from the industry where dynamic languages/scripts are a no-no. I have been trying to sell Python and now Clojure, however there never are any takers. Even amongst the people who are enthusiastic, the fact that Clojure the community (not the language) expects some kind of java knowledge makes it a set back. I went through the same pains. > So either you are a genius and went through Clojure faster than we > could, learning all the features it offers, or you just skimmed the > surface. Neither a genius, nor did I skim through. By the way, isn't Clojure meant to be a minimalist language which one should be able to pick up quick!! Does't Clojure expect you to know more about functional/ declarative programming, than the syntax? So why would you need to be a genius to know the language. My analysis was on the language; not on the library. > Meanwhile be humble... I completely miss this. As I said "I am not a clojure developer. I am a programming language enthusiast and have learnt multiple languages with different programming paradigms; just for the fun of it. Programming languages which I know are Java, Python, Scheme, okie- dokie PERL, C# which for me is Java with a different library and idiom, C, C++ including the (in)famous STL, COBOL & FORTRAN purely because it was in my syllabus, Javascript both in its prototype and functional forms. I have tried to be unbiased; if it exists it might be due to my stronger background in Java, Python, Scheme." Is saying that I learn languages for the fun of it being haughty? Or saying that my bias exists because of my background in Java, Python, Scheme being "biased"!! For me being humble is to appreciate what should be appreciated, and criticize what should be criticized. > > Luc > > On Fri, 2009-12-11 at 13:04 -0800, kusi wrote: > >http://kusimari.blogspot.com/2009/12/analysing-clojure-programming-la... -- 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 analysis
> Judging by the article you've spent very little time "learning" > Clojure and have managed to get every key point wrong: > > Clojure is a multi-paradigm language > no it's not, and it's most certainty not an OOP > language:http://clojure.org/rationale I hear about this everywhere. Is Clojure not a multi-paradigm language because that is the rationale for the language? For me - It supports functional programming. It supports object orientation, though it does not support object oriented constructs. Yep, definitely it does not encourage multiple paradigms, but it allows you to do so! > > Functional programming finds its best implementation in the homoiconic > > language family. > very debatable statement Sorry, it should have been "one of the best implementation". In any case having seen different implementations, I definitely feel drawn towards homoiconic languages. > > one will not appreciate Clojure for being a better LISP. Instead Clojure > > tries to be a better Java with LISP syntax. > Not sure who the 'one' is. I for one do appreciate Clojure as a better > Lisp :-). I would disagree. Anyway in language preferences everything is debatable. :-) > > Owing to the above attitude, many of the language constructs exist so that > > one can do what Java cannot do > Is Java some kind of "golden standard" in language design now? If it was a golden standard then I and maybe you would never have tried to learn anything else. However, please note that Java is what opened the floodgates. Like Fyodor Dostoevsky's "we all came from Gogol's overcoat", many of us came from Java's overcoat. > In general I'd like to second Luc's "be humble" comment. And do your > home work before doing "analysis". Again the same statement about being humble :-( -- 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 analysis
Thanks Dmitry and Richard. In all the replies I found yours to be the most "humble". Even though my analysis says otherwise, I am doing the elevator pitch for Clojure wherever I work. Of course, in an enterprise (where I work), nobody is going to buy it; but in my own world I use Clojure more than Python just because I can get back to Scheme! On Dec 17, 5:04 am, Dmitry Kakurin wrote: > Please keep in mind that it is almost literally the speech that I give > to my friends/colleagues when they ask me why am I so excited about > Clojure. I did it many times now and I have quickly learned that > saying "persistent data structures" gets misinterpreted by every > single person as "something you can save to file [as XML/binary]", > i.e. serialization. > So the funny thing is: by changing my tune and being imprecise, I > communicate the basic idea much better now :-). > > I do understand and appreciate the difference (and I've watched all > Rich's talks :-) but the term is so overloaded that it usually > misleads "imperative" people. Only later I can introduce and use it by > giving a formal definition first and letting it settle for a while. > And only with people who wants to hear more and cares to learn the > difference :). > > - Dmitry > > On Dec 17, 12:24 am, Laurent PETIT wrote: > > > Thanks Richard for the good link. > > > So to be even more precise, we can say that clojure's data structures are > > "fully" persistent since any older version of the datastructure can still > > serve as the basis to create new versions. > > > 2009/12/17 Richard Newman > > > > > I just learned (the hard way, by being humble and asking :-) ) on > > > > #clojure that one does not say "immutable" collections but > > > > "persistent" collections, since "persistent" conveys a lot more > > > > information about what Rich has achieved than just saying "immutable". > > > > Good explanation: > > > >http://en.wikipedia.org/wiki/Persistent_data_structure > > > > Contrast to: > > > >http://en.wikipedia.org/wiki/Immutable_object > > > > -- > > > 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: mapmap
Konrad,
I am working on a different proposal on the dev list:
http://groups.google.com/group/clojure-dev/browse_thread/thread/9a518c853bfbba8b#
This is a more in depth version of these functions for maps. I'd love
to have you contribute to the discussion here.
Sean
On Dec 17, 12:16 pm, Konrad Hinsen wrote:
> On 17 Dec 2009, at 15:44, Sean Devlin wrote:
>
> > 1. I'd call it map-vals (as opposed to map-keys)
>
> > 2. Slight change in the body
>
> > (defn map-vals [f coll]
> > (into {} (map (juxt key (comp f val)) coll))
>
> > There is talk of getting something like this into contrib. Stay
> > tuned :)
>
> There's already clojure.contrib.generic.functor/fmap, which is a
> multimethod whose implementation for maps does just that. Here's the
> code:
>
> (defmethod fmap clojure.lang.IPersistentMap
> [f m]
> (into (empty m) (for [[k v] m] [k (f v)])))
>
> Konrad.
--
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: mapmap
Depends if you need a closure. There are times I do 2D mappings, and
I have to write something like
(map (partail map #(do-work %)) coll).
Or I have to compose my mapping operations.
for is awesome when you need some of the other built-ins, like :while
Sean
On Dec 17, 12:39 pm, Erik Price wrote:
> On Thu, Dec 17, 2009 at 12:16 PM, Konrad Hinsen
>
> wrote:
>
> > On 17 Dec 2009, at 15:44, Sean Devlin wrote:
> > > (defn map-vals [f coll]
> > > (into {} (map (juxt key (comp f val)) coll))
>
> vs:
>
> > (defmethod fmap clojure.lang.IPersistentMap
> > [f m]
> > (into (empty m) (for [[k v] m] [k (f v)])))
>
> Are there any guidelines as to when it's appropriate to use the map
> function vs a list comprehension?
>
> e
--
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: mapmap
Good to know, thank you !
2009/12/17 Christophe Grand
> Hi Laurent,
>
> If you want to use transients, since the keyset is unchanged, it
> should perform slightly better when using (transient m) instead of
> (transient {}) as the seed to reduce.
>
> Christophe
>
> On Dec 17, 3:46 pm, Laurent PETIT wrote:
> > AFAIK, such a function is still not in clojure core because it's not
> clear
> > to Rich whether f should have one argument (the value), or 2 arguments
> (key
> > + value).
> >
> > Your version seems good, you can maybe improve it a little bit by using
> > transients (not tested):
> >
> > (persistent!
> > (reduce (fn [m [k v]]
> >(assoc! m k (f v))) (transient {}) m))
> >
> > HTH,
> >
> > --
> > Laurent
> >
> > 2009/12/17 C. Florian Ebeling
> >
> > > I was just wondering how a #'map for maps could be done most
> > > succinctly. Came up with this:
> >
> > > (defn mapmap
> > > "Map values of map m using function f."
> > > [f m]
> > > (reduce (fn [m [k v]]
> > >(assoc m k (f v))) {} m))
> >
> > > But there is probably a more straightforward way. What do you use?
> >
> > > Florian
> >
> > > --
> > > Florian Ebeling
> > > florian.ebel...@gmail.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
>
> --
> 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: Clojure analysis
On 17 Dec 2009, at 10:04, Dmitry Kakurin wrote: > Please keep in mind that it is almost literally the speech that I give > to my friends/colleagues when they ask me why am I so excited about > Clojure. I did it many times now and I have quickly learned that > saying "persistent data structures" gets misinterpreted by every > single person as "something you can save to file [as XML/binary]", > i.e. serialization. > So the funny thing is: by changing my tune and being imprecise, I > communicate the basic idea much better now :-). I note that Haskellers don't refer to their data structures as "persistent", despite the fact that lazy evaluation means they get persistence of all data structures 'for free'. They seem to use the rather vague "purely functional data structure". Martin -- 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 1.1 release candidate 1
There is now a release candidate for Clojure 1.1: http://clojure.googlecode.com/files/clojure-1.1.0-rc1.zip and also a new "1.1.x" branch in git corresponding to the release. Please try these out ASAP and provide feedback here. Thanks much! 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: Any interest in a Nova Clug?
I'm interested. On Dec 16, 1:14 pm, Matt wrote: > I'm looking into setting up a Northern Virginia Clojure User Group and > would like to know who is interested. I know there is a DC clojure > study group, but it seems to not be as active recently. DC is also > hard for me to get to during the week. > > We have a couple of other user groups which meet once a month right > here in my office in Reston, VA. If there are enough people > interested, I can coordinate with the other user group organizers to > start a Clojure user group using the same meeting space. > > Questions? Comments? Hassletations? Aggravations? Contemplations? -- 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 analysis
On Dec 17, 2:16 pm, Martin Coxall wrote: > On 17 Dec 2009, at 10:04, Dmitry Kakurin wrote: > > > Please keep in mind that it is almost literally the speech that I give > > to my friends/colleagues when they ask me why am I so excited about > > Clojure. I did it many times now and I have quickly learned that > > saying "persistent data structures" gets misinterpreted by every > > single person as "something you can save to file [as XML/binary]", > > i.e. serialization. > > So the funny thing is: by changing my tune and being imprecise, I > > communicate the basic idea much better now :-). > > I note that Haskellers don't refer to their data structures as "persistent", > despite the fact that lazy evaluation means they get persistence of all data > structures 'for free'. > > They seem to use the rather vague "purely functional data structure". > There are differences in strictness in the interpretation of "persistent". At the most basic, it just means creating a "changed" version leaves the old version intact. But, if you use amortization in your analysis of the cost model for the data structure, then many such purely-functional data structures do not maintain their performance bounds when used in a non-ephemeral, i.e. persistent way. This latter characteristic does not come for free merely via immutability or laziness. The use of the term persistent for Clojure data structures is the stricter sense, both that old versions are unchanged and available *and* that performance guarantees are met when used persistently. See: Purely Functional Data Structures - Okasaki for details. 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 this the expected behavior related to agent options in action function?
Try removing the colon from your ":meta" call in the action, so you
don't invoke
a map fetch, but call the #'meta function.
user> (defn action2 [_] (meta *agent*)) ; call meta, not :meta
user> (await (send agt action2))
user> @agt
{"some" "data"}
On Dec 17, 10:35 am, Carlos Moscoso wrote:
> Hi,
>
> I'm trying to access from within a action function, and with no
> success, the metadata associated with agent.
>
> My code:
> user> (def agt (agent nil :meta {"some" "data"}))
> user> (defn action [_] (:meta *agent*))
> user> (await (send agt action))
>
> Wich results in:
> user> @agt
> nil
>
> Instead of:
> user> @agt
> {"some" "data"}
>
> The same happens with a validation function. I'm wondering if this is
> the expected behavior.
>
> Thanks.
--
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: Semantic Versioning
On Dec 17, 3:11 am, Laurent PETIT wrote: > Isn't this the ideal that clojure and libraries are almost more or less > already following ? Yes it is, but that's because the maintainers are very disciplined and professional people. Not everybody follow this scheme properly and even the best of us can err. If the build system enforce that system, it would help us follow it more closely. -- 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: Semantic Versioning
On Dec 17, 3:13 am, Roman Roelofsen wrote: > Dealing with version numbers at build time is quite easy with tool > like Maven. The important thing is that everyone agrees on the same > version semantics (great summary [1]). Putting some more tooling > around this should be a good idea, yes. Talking of semantics, do you think the one I enumerated would work? I'll certainly try to implement this concept, but I have many other projects on the table right now, so it might take a while before I start working on it. > However, the problem in Java is dealing with versions at runtime, not > at build time! It's sure would be a nice addition, but dealing with versioning at build time would at least give library users some assurance. > Java's classloader design has not knowledge about > versions, etc and makes it impossible to deal with versions without a > new layer on top of it. The default system for dealing with this in > Java is OSGi. Unfortunately, Clojure's classloader design seems to be > completely incompatible with OSGi. If we could solve this, Clojure > would instantly get multi version support. My knowledge of Java's classloader is pretty limited, I'll look at OSGi and Clojure's classloader to see what I can do, but don't expect miracles ;-) - budu -- 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 analysis
Santhosh G R writes: >> > Clojure is a multi-paradigm language >> no it's not, and it's most certainty not an OOP >> language:http://clojure.org/rationale > > I hear about this everywhere. Is Clojure not a multi-paradigm language > because that is the rationale for the language? For me - It supports > functional programming. It supports object orientation, though it does > not support object oriented constructs. Clojure's Wikipedia article calls it multi-paradigm, which may be partly where the confusion is coming from. Funnily enough Wikipedia also claims Java is multi-paradigm, having the four paradigms: generic, reflective, imperative and object-oriented. I wouldn't call this multi-paradigm as these four things are mostly orthogonal and don't really constitute different programming styles. > Yep, definitely it does not encourage multiple paradigms, but it > allows you to do so! You can do object-orientation in C (see GObject), does that make it an object-oriented language? If so than every language is "multi-paradigm" so the word is meaningless. ;-) In my mind the difference between a multi-paradigm language and one that is not is about what is idiomatic, rather than what is and is not possible, as the latter always reduces to a Turing-completeness style argument. Classic examples of multi-paradigm languages are Common Lisp, Scala and Perl. Clojure is certainly not multi-paradigm in the same sense that these languages are. Clojure has a very strong style of its own, which is definitely not imperative or object-oriented but neither is it purely functional, but just because it doesn't fit perfectly into one of the traditional categories doesn't make it's multi-paradigm. Of course that's just my interpretation. :-) -- 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
Deprecate replicate?
Hey everyone, I just noticed that replicate's functionality is now duplicated by repeat. Should this function be deprecated? Sean -- 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 analysis
I was about to point out this reference, but realized Rich has already already given a nice explanation. Good to know that this newbie (myself) is on the right track! On Thu, Dec 17, 2009 at 3:24 PM, Rich Hickey wrote: > > > On Dec 17, 2:16 pm, Martin Coxall wrote: > > On 17 Dec 2009, at 10:04, Dmitry Kakurin wrote: > > > > > Please keep in mind that it is almost literally the speech that I give > > > to my friends/colleagues when they ask me why am I so excited about > > > Clojure. I did it many times now and I have quickly learned that > > > saying "persistent data structures" gets misinterpreted by every > > > single person as "something you can save to file [as XML/binary]", > > > i.e. serialization. > > > So the funny thing is: by changing my tune and being imprecise, I > > > communicate the basic idea much better now :-). > > > > I note that Haskellers don't refer to their data structures as > "persistent", despite the fact that lazy evaluation means they get > persistence of all data structures 'for free'. > > > > They seem to use the rather vague "purely functional data structure". > > > > There are differences in strictness in the interpretation of > "persistent". At the most basic, it just means creating a "changed" > version leaves the old version intact. But, if you use amortization in > your analysis of the cost model for the data structure, then many such > purely-functional data structures do not maintain their performance > bounds when used in a non-ephemeral, i.e. persistent way. This latter > characteristic does not come for free merely via immutability or > laziness. > > The use of the term persistent for Clojure data structures is the > stricter sense, both that old versions are unchanged and available > *and* that performance guarantees are met when used persistently. > > See: > > Purely Functional Data Structures - Okasaki > > for details. > > 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 > -- 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 interest in a Nova Clug?
Seems like a wrong place to ask, but is there a Seattle Clojure Group too? Where can I find this info? Thanks, Ajay On Thu, Dec 17, 2009 at 3:22 PM, tcg wrote: > I'm interested. > > On Dec 16, 1:14 pm, Matt wrote: > > I'm looking into setting up a Northern Virginia Clojure User Group and > > would like to know who is interested. I know there is a DC clojure > > study group, but it seems to not be as active recently. DC is also > > hard for me to get to during the week. > > > > We have a couple of other user groups which meet once a month right > > here in my office in Reston, VA. If there are enough people > > interested, I can coordinate with the other user group organizers to > > start a Clojure user group using the same meeting space. > > > > Questions? Comments? Hassletations? Aggravations? Contemplations? > > -- > 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: mapmap
Erik,
My experience is that you should only use filter/map if you either have a
pre-existing function or you want to use a _very_ short closure (using #()).
For any other case the code becomes unmanageable and then I feel that using
for is the wiser choice.
I hope that they are just as efficient, but I haven't really tested it. I
feel like even if it isn't right now they can be brought up to the same
speed.
--
http://wave.theWE.net
http://twitter.com/theWE_
On Thu, Dec 17, 2009 at 7:39 PM, Erik Price wrote:
> On Thu, Dec 17, 2009 at 12:16 PM, Konrad Hinsen
> wrote:
> >
> > On 17 Dec 2009, at 15:44, Sean Devlin wrote:
>
> > > (defn map-vals [f coll]
> > > (into {} (map (juxt key (comp f val)) coll))
>
> vs:
>
> > (defmethod fmap clojure.lang.IPersistentMap
> > [f m]
> > (into (empty m) (for [[k v] m] [k (f v)])))
>
> Are there any guidelines as to when it's appropriate to use the map
> function vs a list comprehension?
>
> e
>
> --
> 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: Is this the expected behavior related to agent options in action function?
Just a follow up, Chris House pointed me out on twitter that the
correct would be to use (meta *agent*) instead of (:meta *agent*).
On Dec 17, 1:35 pm, Carlos Moscoso wrote:
> Hi,
>
> I'm trying to access from within a action function, and with no
> success, the metadata associated with agent.
>
> My code:
> user> (def agt (agent nil :meta {"some" "data"}))
> user> (defn action [_] (:meta *agent*))
> user> (await (send agt action))
>
> Wich results in:
> user> @agt
> nil
>
> Instead of:
> user> @agt
> {"some" "data"}
>
> The same happens with a validation function. I'm wondering if this is
> the expected behavior.
>
> Thanks.
--
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: Trying to rewrite a loop as map/reduce
Hi, Am 16.12.2009 um 17:26 schrieb Meikel Brandmeyer: > Well. It was claimed it is cleaner... Just asking... I wrote down my thoughts in a small blog post: http://tr.im/HW5P 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 analysis
On Thu, 17 Dec 2009 10:26:03 -0800 (PST) Santhosh G R wrote: > > You warn that you learn languages "just for the fun of it". I would be > > curious to know how much time you spent learning Clojure... > > I have been working with Scheme for the past 5 years. I think this is a critical element! > Yep, I don't have 20+ years in development; neither 12+ months in > Clojure. My learning of Clojure has been for the past 2-3 months. I expect that 5 years with Scheme is worth more than 20+ years with C/C++/Java when it comes to learning Clojure. Clojure is, after all, a LISP dialect. Once you've gotten your mind around the proper way to write programs in LISPy languages - which is a non-trivial thing - adopting to another one is fairly easy. I feel that mind-set coming back after my absence from the language as I read through the examples. The other unique features of Clojure should be relatively straightforward to deal with once you've gotten past this. > > So either you are a genius and went through Clojure faster than we > > could, learning all the features it offers, or you just skimmed the > > surface. > Neither a genius, nor did I skim through. Right. Just someone who was already familiar with programming in a LISPy environment. > I completely miss this. As I said "I am not a clojure developer. I am > a programming language enthusiast and have learnt multiple languages > with different programming paradigms; just for the fun of it. > Programming languages which I know are Java, Python, Scheme, okie- > dokie PERL, C# which for me is Java with a different library and > idiom, C, C++ including the (in)famous STL, COBOL & FORTRAN purely > because it was in my syllabus, Javascript both in its prototype and > functional forms. I have tried to be unbiased; if it exists it might > be due to my stronger background in Java, Python, Scheme." Given that list of languages, I'd suggest taking a look at Eiffel. It's imperative and statically typed, but it's a lot saner than the C++/C#/Java languages. It has a high mechanism for dealing with concurrency that make an interesting contrast to STM. It's the source of the function pre/post condition facilities that Clojure has. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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: Deprecate replicate?
On Thu, Dec 17, 2009 at 7:50 PM, Sean Devlin wrote: > Hey everyone, > I just noticed that replicate's functionality is now duplicated by > repeat. Should this function be deprecated? > > Sean > This was discussed before [1] as part of another issue [2], but I don't know what happened to the separate issue of removing replicate. 1 http://groups.google.com/group/clojure/browse_thread/thread/bb2bd6ad6986fedf/88894a8cc8dbbbd7?lnk=gst&q=replicate+repeat#88894a8cc8dbbbd7 2 http://code.google.com/p/clojure/issues/detail?id=55&can=1&q=replicate&colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary -- 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: mapmap
Avital Oliver writes: > My experience is that you should only use filter/map if you either have a > pre-existing function or you want to use a _very_ short closure (using #()). > For any other case the code becomes unmanageable and then I feel that using > for > is the wiser choice. I agree, but then again I've been criticized for writing "too bulky" functions so perhaps it's better to extract the conditions and the body as separate functions where possible. I guess the other advantage of map is that is more easily replaced with 'pmap'. > I hope that they are just as efficient, but I haven't really tested it. I feel > like even if it isn't right now they can be brought up to the same speed. In theory 'for' is slightly more efficient than a filter/map combo as it avoids one lazy sequence, but for almost all purposes the difference is negligible and not worth bothering over. -- 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: Trying to rewrite a loop as map/reduce
What are you using to generate the pretty rainbow perens on your website? --- Joseph Smith j...@uwcreations.com (402)601-5443 On Dec 17, 2009, at 5:25 PM, Meikel Brandmeyer wrote: > Hi, > > Am 16.12.2009 um 17:26 schrieb Meikel Brandmeyer: > >> Well. It was claimed it is cleaner... Just asking... > > I wrote down my thoughts in a small blog post: http://tr.im/HW5P > > 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 -- 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 analysis
> Given that list of languages, I'd suggest taking a look at Eiffel. > ... > It's the source of the function pre/post condition facilities that Clojure > has. I did not know that Clojure functions supported Eiffel-style pre/post conditions. Where can I read more about this? -- 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 analysis
It's new in 1.1. Go here: http://clojure.org/special_forms#toc7 And read the "Since 1.1" section. On Dec 17, 11:58 pm, Eric Lavigne wrote: > > Given that list of languages, I'd suggest taking a look at Eiffel. > > ... > > It's the source of the function pre/post condition facilities that Clojure > > has. > > I did not know that Clojure functions supported Eiffel-style pre/post > conditions. Where can I read more about this? -- 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 analysis
I was still using 1.0. This is a good incentive to upgrade :-) On Fri, Dec 18, 2009 at 12:22 AM, Sean Devlin wrote: > It's new in 1.1. Go here: > > http://clojure.org/special_forms#toc7 > > And read the "Since 1.1" section. > > On Dec 17, 11:58 pm, Eric Lavigne wrote: >> > Given that list of languages, I'd suggest taking a look at Eiffel. >> > ... >> > It's the source of the function pre/post condition facilities that Clojure >> > has. >> >> I did not know that Clojure functions supported Eiffel-style pre/post >> conditions. Where can I read more about this? > -- 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 analysis
Mike, I think that the whole issue about Lisp creates a big cloud about Clojure. Choosing a Lisp like syntax for a new language is a good choice because of the expressiveness, it requires less code lines, yields a better design, easier to test, ... That's a choice between a number of options. If it was the only sane one then we would all be coding using Lisp like syntax. That's not the case obviously. Talk to Ruby people, they made different choices... If you sum up Clojure as being a Lisp because of what it look likes and use only this to compare it to other languages then you are missing the forest and looking at a single tree. If you code in a Lisp like language using setq or set! or alike then you can get very far away from functional programming and end up writing procedural code with parenthesis. You will eventually face the issues that Clojure avoids. Clojure takes a brutal approach, forget the left-right assignment that almost every language eventually supports, forget variable mutations visible to everyone, forget procedural code... Oups these are the real show stoppers independently of the syntax used. There's no escapes in Clojure while in other languages you can still cheat (setq/set! and similar). What I found non-trivial in Clojure were these "restrictions", no the syntax. As soon as I understood the decisions behind these choices, my mental blockage vanished. Immutable data structures, transparent iterations over a variety of structures, lazy sequences, a workable STM implementation, parallel processing capabilities ridiculously simple to use, huge set of Java librairies available, easy to use, ... These are the real features that make Clojure distinct from other languages. All the choices made are sound and the sum of these decisions is coherent. Nothing looks like it's been added late to fill a gap like a nose in a face. Syntax by itself is nothing, it never made a good language implementation. I have a few years of Lisp behind me, I started to use Lisp in the 1980s.I used to prototype software in Lisp that I had to deliver in a more "classical" language. The main reason of this being the lack of basic librairies and incompatible Lisp implementations plus the maintenance issue. After my Clojure learning curve, I removed LispWorks from my desktop. I do not see the use for it anymore. My 25 years of experience is not the same as "5 years" of Scheme, I experimented more stuff in software in various environments than the majority of today's average developer. I adhere to justified critics when a rationale has been exposed otherwise I call it (repeat "blablabla"). To expose some rationale it implies that you understand the subject you are talking about. If you don't then you should be cautious about what you state or you state it conditionally. The above does not mean that I will not ever critic Rich's bad decisions in the future. I do not see this likely to happen however given its present score... Luc On Thu, 2009-12-17 at 19:02 -0500, Mike Meyer wrote: > On Thu, 17 Dec 2009 10:26:03 -0800 (PST) > Santhosh G R wrote: > > > > You warn that you learn languages "just for the fun of it". I would be > > > curious to know how much time you spent learning Clojure... > > > > I have been working with Scheme for the past 5 years. > > I think this is a critical element! > > > Yep, I don't have 20+ years in development; neither 12+ months in > > Clojure. My learning of Clojure has been for the past 2-3 months. > > I expect that 5 years with Scheme is worth more than 20+ years with > C/C++/Java when it comes to learning Clojure. Clojure is, after all, a > LISP dialect. Once you've gotten your mind around the proper way to > write programs in LISPy languages - which is a non-trivial thing - > adopting to another one is fairly easy. I feel that mind-set coming > back after my absence from the language as I read through the > examples. The other unique features of Clojure should be relatively > straightforward to deal with once you've gotten past this. > > > > So either you are a genius and went through Clojure faster than we > > > could, learning all the features it offers, or you just skimmed the > > > surface. > > Neither a genius, nor did I skim through. > > Right. Just someone who was already familiar with programming in a > LISPy environment. > > > I completely miss this. As I said "I am not a clojure developer. I am > > a programming language enthusiast and have learnt multiple languages > > with different programming paradigms; just for the fun of it. > > Programming languages which I know are Java, Python, Scheme, okie- > > dokie PERL, C# which for me is Java with a different library and > > idiom, C, C++ including the (in)famous STL, COBOL & FORTRAN purely > > because it was in my syllabus, Javascript both in its prototype and > > functional forms. I have tried to be unbiased; if it exists it might > > be due to my stronger background in Java, Python, Scheme." > > Giv
new fn: juxt - Theory & application
Hello everyone,
Today I'd like to shed some light on a new funciton in 1.1, juxt. In
order to understand juxt(apose), I'd like to first talk about comp
(ose). Comp can be defined in terms of reduce like so:
(defn my-comp [& fns]
(fn [args]
(reduce
(fn[accum f](f accum))
(conj (reverse (seq fns)) args
Granted, this isn't 100% equivalent to the Clojure comp function, but
it is very, very close. What it demonstrates is that comp applies a
list of functions in series using reduce. After writing Clojure for a
while, one usually finds frequent need to apply a list of functions in
parallel using map. juxt can be defined as follows
(defn juxt [& fns]
(fn[ & arg] (map #(apply % args) fns)))
Notice that juxt creates a closure. The most straightforward case is
to *predictably* access multiple values from a map.
user=>(def test-map {:a "1" :b "2" :c "3" :d "4"})
user=>((juxt :a :c) test-map)
("1" "3")
However, as one works with maps more and more, situations arise where
it is desired to perform many operations on a map at once. For
example
;assume parse-int turns a string to an int appropriately
user=>((juxt :a (comp parse-int :c)) test-map)
("1" 3)
Since juxt returns a closure, it is very useful in any place one would
use a map operation as well. For example, this can make turning a
list of maps into a list of lists very easy. Also, this made it very
easy to determine if a sub-selection of a hash-map is equal to another
hash- map
user=>(def test-juxt (juxt :a :c))
user=>(= (test-juxt {:a 1 :b 2 :c 3}) (test-juxt {:a 1 :b 34 :c 3}))
true
One thing that is very interesting is that this function allows one to
simulate the behavior of let in a point-free style.
;This is deliberate overkill for a small example
;Generate a list of squares
;Notice that the juxt fn uses the range twice
user=>((partial map (juxt identity #(* % %))) (range 1 6))
((1 1) (2 4) (3 9) (4 16) (5 25))
This also is useful when combined w/ clojure.contrib/group-by.
Suppose you have a sales database with a table in it. This table keep
tracks of each sale (:id), when it happened (:year, :quarter), who
sold it (:sold-by), and what category (:category) the product was
in.
It is obviously useful to group items by who sold it, or what category
it was sold under. However, it is also interesting to see which
employees are selling which items. This is a grouping by :sold-by
AND :category. In order to get at this information we'd do the
following.
;Assume our sales data is a list of maps, in the sales-coll variable
;returns a map with two element vectors as keys, a list of maps as the
vals.
user=>(group-by (juxt :sold-by :category) sales-coll)
Now, what happens when you need to change how you group the data?
Instead of :sold-by & :category, you need :year & :quarter? juxt
makes it easy.
user=>(group-by (juxt :year :category) sales-coll)
And finally, what happens when you need to break it down by all for
variables simultaneously?
user=>(group-by (juxt :year :category :sold-by :category) sales-coll)
There are tons of other uses for juxt, and I would encourage you to
experiment and find out some of these uses yourself. I hope these
examples help everyone understand how to use the new operator.
Happy Hacking,
Sean
--
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: Help recreating OS X Leiningen 1.0 +Swank bug
I've looked into it a little and this is probably a solvable problem.
Since my native code patch needs fork as well I will try an idea I
have later today.
/mac
On Dec 17, 7:02 pm, Steve Purcell wrote:
> I came across this problem too, and David's patch helps, to a certain extent.
>
> Additionally, without David's patch, the "src" and "test" directories of the
> current project don't get added to the classpath one sees from inside swank.
> (All the jars upon which leiningen depends *are* in the classpath, which is
> probably also less than ideal.)
>
> However, by forking the JVM, the console output is reformatted unpleasantly
> by Ant, and any JAVA_OPTs etc. passed to lein's "master" JVM are not passed
> through. The former is a nuisance, but the latter stops you from running
> Swank with an increased max memory allowance, for example.
>
> Given my immediate goal of processing a moderate pile of data within a swank
> REPL session and charting it with Incanter, I have had to revert to
> swank-clojure-project, when it would have been considerably cleaner to use
> "lein swank".
>
> I'm trying to get my head around what can be done here, and will report back
> if I have any insights. It's been so nice to let leiningen take care of the
> classpath for me, having abandoned Java years ago for less encumbered
> languages. ("Ah, my old nemesis CLASSPATH, finally we meet again!")
>
> -Steve
>
> On 9 Dec 2009, at 19:13, David Nolen wrote:
>
>
>
> > I found a solution to this problem and patched my own fork of Leiningen:
>
> >http://github.com/swannodette/leiningen/commit/9d79d631a9faa870a93479...
>
> > The important thing to do if you want this to work is to closely follow the
> > instructions for hacking on Leiningen that's currently available on GitHub.
> > Then you need a custom-build of lein-swank. This is easy enough to do, move
> > into lein-swank in your Leiningen checkout and run:
>
> > lein uberjar
>
> > You might see some errors but none are deal breakers. Copy the new
> > lein-swank-standalone.jar and replace the one in that is in your lib folder
> > in your leiningen checkout.
>
> > David
>
> > On Tue, Dec 8, 2009 at 11:35 AM, David Nolen wrote:
> > Just want to make sure other people are seeing this on OS X. When starting
> > up "lein swank" from the project directory and attempting to connect from
> > Emacs with slime-connect with this simple clojure
> > projecthttp://github.com/swannodette/lein-macosx-bug(just creates a JPanel
> > and draws a small line) I get an exception:
>
> > Cannot load apple.laf.AquaLookAndFeel
>
> > I'm using lein 1.0, usual Emacs/Clojure/SLIME config on OS X 10.6, JDK 1.6
> > 64bit.
>
> > I note that if I use leiningen from git checkout I don't have this problem
> > which seems odd since there aren't many changes between 1.0 and
> > leiningen/master.
>
> > Thanks,
> > 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
--
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 analysis
On Dec 17, 10:42 am, Santhosh G R wrote: > Again the same statement about being humble :-( The "humble" comment relates to the title of your article. Lookup (and contrast) words "analysis" and "opinion" in your favorite dictionary. Were your post named "My opinion about Clojure" I would not make the "humble" comment - everyone is entitled to their opinions. - Dmitry -- 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
