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 brw...@gmail.com 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 - vendor lock-in, no source etc. Most alarmingly, this is the only model that associates value with software
Re: Generalizing - -
On Thu, Dec 3, 2009 at 17:02, Meikel Brandmeyer m...@kotka.de wrote: Are there any plans to add -$ to core or contrib? The rules on contrib are that the work must be original to the author. Even with Andrew's disclaimer that it be considered public domain, he would still need a contributor agreement in place to get this incorporated into contrib. I haven't tried using -$ yet, but based on its description it seems like it would be a useful addition to contrib. There is also an old discussion about this: pipe, let-, pipe-as, and what not http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/c3d4a6dae45d4852?q=pipe+group:clojure#c3d4a6dae45d4852 +1 for pipe-as in contrib. But frankly I'd be glad seeing *any* of these macros in contrib.macros (this one seems quite abandoned with 3 macros only, huh?) or wherever in contrib. Let the contributors decide go with it, that will push it to use, for good. I wrote a bunch of similar stuff but not so general; it arises from a need to control order of passed forms while sticking to 'threading' style, as this style helps in grasping how data is transformed (btw it's a thought raised a couple of times, see eg. recent blog of Tim Bray cited here). It'd be very cool to see these threading augmentations standarized a bit. cheers Wojtek -- 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: Deep deref
On Mon, Nov 23, 2009 at 22:46, Sergey Didenko sergey.dide...@gmail.com wrote: BTW I'm also coding the simple persistence for Clojure data structures. Though I took Prevayler approach (http://prevayler.org), so I journal function calls that change my root object. This approach is better than simple snapshotting when your data grows big, so you can't do the snapshots very often but do not want to lose a lot of the latest changes. Making snapshots are easy to implement after this, if data objects reference each other only one time or through ids. I guess it would be a simple traversal of the root object. I plan to make this persistence code public if anyone is interested. Though I'm not moving very fast, I'm learning Clojure at the same time. Yeah it would be cool to look at it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: roll call of production use?
On Tue, Nov 24, 2009 at 00:00, Raoul Duke rao...@gmail.com wrote: hi, i'd be interested to hear who has successfully used clojure in production. i know of some, as some folks have been vocal; any other interesting-but-so-far-silent uses people'd be willing to fess up about? many thanks. I use Clojure for web crawling / scraping of certain services with storing extracted data in a custom database. I could marry existing Java libs with an excellent xml/html walking via zippers; and could test it in REPL which is a pleasure to use. After finishing a prototype it became a valid production version which Just Works in a near-zero time. Ah, and I eradicated many bugs early by having set *warn-of-reflection* - esp. for the code heavily calling Java. Nothing revolutionary, it was just use of typical web-related techniques, which are unfortunately still a major pain in the ass on many programming platforms (and they don't have macros!! ;) More uses incoming. It will be bulk data load of QDBM and TokyoCabinet storages, for example. -- 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: Hiring full-time work-at-home clojure/emacs dev
On Tue, Oct 13, 2009 at 18:58, Robert Stehwien rstehw...@gmail.com wrote: If you have to work Remote, why limit yourself to us only? There are developers outside the states you know... Yes, but if you're pair programming (which they are), it sure helps to if all involved are awake at the same time. So maybe Canadians would be OK. ;-) How well does remote pair programming work? I telecommute 100% so I'm curious. Must be working for you guys, I just haven't tried Rudel. Since I almost live in emacs I should give it a try sometime... if I can find any of my co-workers that use emacs. It's so cool to learn sth new. We used just screen -x for a serious remote pair work; I haven't heard of Rudel yet, thanks for pointing at it. Yeah as you said it's crucial to be in the same or similar timezone. Being in central Europe I can just wish you luck guys :]] --~--~-~--~~~---~--~~ 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: Can anyone here give a comparison between Clojure and Erlang on concurrent programming?
On Fri, Sep 18, 2009 at 17:41, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Sep 17, 6:54 pm, dongbo dongb.w...@gmail.com wrote:
Can any one give a comparison between Clojure and Erlang on concurrent
programming?
Hi! I'd add 2cents here as I did some hacking in Erlang and now i'm
transforming lots of habits to try coding in Clojure efficiently.
Erlang supports one concurrency model, Actors. Clojure supports
several -- Agents, which are similar to Actors; Refs, which have ACI
(not D) transactional semantics; and Atoms, which have atomic updates.
Erlang is designed for distributed operation across many machines;
Clojure is designed for a single machine with many cores.
Yeah, Erlang makes distribution easy and gives you a nice way to send
any term (a nested data structure, including closures inside) across
the network and read it on the other node, even if the nodes have
different OS architecture underneath. It also means such data is
serializable for free - you can write it to a file or just keep it as
a binary blob for a while in your program - and you don't have to
write any serializing implementation for your specific data
structures, it just works by calling term_to_binary and
binary_to_term. I found it a killer feature for some code I wrote.
OTOH Erlang's data structures are not unified as in Closure in that
they all are immutable. Most of the OTP modules you'd use for your
data - sets, trees, dicts - operate on purely functional data. But
then some other (say, digraphs) are implemented over ETS, which is
really a server encapsulating some state. So you can't serialize such
stuff as I described above, you have to export it first to some 'pure'
structure and import on the other side. So, you should carefully read
the docs to see what are you dealing with. As you work with such
different stuff, it becomes obvious these implementations were added
as language evolved to cover the needs of various users, incl.
commercial ones. I mean, the high-level data structures weren't
designed from the ground up as in Clojure, rather they were
implemented in different ways using low-level structures: atoms, lists
and tuples, and made their way to Erlang's standard lib.
So, if you are into FP and like the idea of all the data being
immutable, Closuje is a breeze - data structures behave predictably
and they pretty-print nice, which is important if you live in a REPL.
Compare a standard way of creating and printing some nested data, Erlangs:
sets:from_list([1,2,[{foo,3},4,5]]).
{set,3,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
{{[[{foo,3},4,5]],
[],[],[],[],[],
[2],
[],[],[],[],
[1],
[],[],[],[]}}}
with Closure's:
#{1 2 '([foo 3] 4 5)}
#{1 2 ([foo 3] 4 5)}
Sucintness is power, isn't it?
In Erlang you probably would want to roll your own pretty-printer for
such simple thing as a set, or just run sets:to_list() every time you
print it human-readably, but still there's no easy way to convince the
REPL to do it for you.
Erlang is designed to hot-swap entire modules in a running production
system; Clojure is not.
Erlang has its own light-weight thread model; Clojure threads are JVM
threads, which are usually operating system threads.
You can't really say that one approach is more efficient than another
without reference to a specific problem.
Very well put.
I'd say: if your system must be concurrent *and* distributed, go for
Erlang and you will get used to it. Even if Erlang has only an Actor
model, it's a very powerful model and they did it right. If you only
need concurrency on one node, it's worth to try both Erlang and
Clojure and make a decision based on early symptoms ;]
If you like Lisp you can also try LFE which is a Lisp over Erlang, but
that's another story.
cheers,
Wojtek
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
A welcome
Hi folks! I just subscribed to this list and hope we gain some hacking experience together. I walked a long way since I decided to go beyond OO: rediscovered CL, then went to ML family for a couple of years, then Haskell, and back to dynamic setting via Erlang to Lisps of today. I consider myself an early adopter of LFE, which is a Lisp-2 over Erlang, and wrote a bunch of code in it -- hope will be able to publish something or at least blog about it. I still have some heart for, say, Ruby -- but I tend to code FP way even if it's non-idiomatic for a given setting. That's how mind can be transformed by exercises ;) Now I'm checking the Clojure, which was on my radar since published but awaited in a mental queue, and I must say most of experience with it is a pure pleasure :] I'm going through a transcript of excellent Rich's talk; when I digest it I'd have some questions, mostly comparing features with other Lisps -- just don't take them as X is better comments, it will be rather a complement of grasping what can be easily done in Clojure. cheers, Wojtek --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
