Emacs and clojure for newbies
I disagree. This is a subject of religious debates that I don't want to get into in detail, but FWIW this educator thinks that Lisp is a perfectly defensible first language and that Clojure can serve the purpose quite well as long as installation and tooling doesn't make it unnecessarily difficult to write and run code. +1 for all your points here, Lee. Scheme has often used as a first language, and it works great. It's better to teach people the right way first, and the right way is Lisp. I'm really happy to hear you're teaching Clojure. I hope everyone teaches Clojure soon. And (not to sound like a broken record...) people learn programming by programmingnot by reading books while they try to configure their environments. As for an OS-Native Emacs, on Mac at least you have Aquamacs. All the copy/paste/save/tab stuff works exactly as you would expect (and the control-k control-a are OS-native anyway). I don't see much of a learning curve there, although unfortunately the menu options are still more Stallmanesque than Jobsian. However, Aquamacs is difficult to get working with Clojure, Slime, Swank, etc. I've managed to do it exactly once. (Some people have no problemsthey must be lucky.) I've finally concluded (taking Phil Hagelberg's advice) that it's not really worth the trouble. But Aquamacs might make a nice base for a packaged Mac Clojure distribution. If someone could convince Aquamacs to put .emacs.d in some non-home directory (beyond my emacs-fu at the moment) where it doesn't interfere with any other Emacs and bundle it up with Lein and all the good stuff, it might make a perfectly good Clojure IDE. As for Windows and Linux, that's a whole other ball of wax It might be too heavyweight, but you could always also have people create a Clojure user accountMac makes switching those pretty easy. There you would at least get a complete clean slate. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Please stand firm against Steve Yegge's yes language push
Read my blog post (written a year ago; updated several times to ensure it works with newer versions of Clojure and Leiningen): http://corfield.org/blog/post.cfm/getting-started-with-clojure Now replace clojure.org/getting_started with something like that and I think most of the complaints would go away. 1. That's really all there is to it. The starting path needs to be Lein and lein repl. If that one section on the Clojure.org website were changed (it's been there for whattwo years?) it would look so much better to newcomers. Lein can at least get people up and running, and give them time to play with Clojure while they figure out IDEs. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Please stand firm against Steve Yegge's yes language push
Mailing my contributor agreement today so I can helpreally excited! May I just add that at the same level of prominence after the no decisions beginner path, we might also put a tutorial on Web (via Noir, perhaps?) and Incanter development? Those are two amazing applications of Clojurelet's not be coy to beginners about them! On Jul 8, 11:50 am, Stuart Halloway stuart.hallo...@gmail.com wrote: Read my blog post (written a year ago; updated several times to ensure it works with newer versions of Clojure and Leiningen): http://corfield.org/blog/post.cfm/getting-started-with-clojure Now replace clojure.org/getting_started with something like that and I think most of the complaints would go away. 1. That's really all there is to it. The starting path needs to be Lein and lein repl. If that one section on the Clojure.org website were changed (it's been there for whattwo years?) it would look so much better to newcomers. Lein can at least get people up and running, and give them time to play with Clojure while they figure out IDEs. Here's a possible plan: 1. Core will produce a smaller, up-to-date page for clojure.org/getting_started. This page will do less, and will link out prominently to the contributor wiki. Turnaround time on this: probably not before the announcement [1] on July 20. We're quite busy atm. 2. Between now and then, please help make the contributor wiki (http://dev.clojure.org/display/doc/Getting+Started) better! Some obvious things: 2a. Create a no decisions needed path for beginners. I share the opinion that this should not be IDE-based. 2b. Link out to the various other resources that are particularly useful for beginners. Stu Stuart Halloway Clojure/corehttp://clojure.com [1]http://www.meetup.com/Clojure-NYC/events/16166953/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Please stand firm against Steve Yegge's yes language push
I think we need to nail the intro / setup experience and I'm nailing my colors to Leiningen. I think that needs to be adopted as the default, standard way to get up and running on Clojure and all the official tutorials need to be updated to reflect that. I think getting an experienced Clojurian to agree with that is worth any (hopefully fixed) logorrhea! If people can agree to that one point, I'm really not going to worry about \any of the others (hence I put it first). I think it's an important time to be making it (so let's forget about the other stuff for now). Clojure was \just put on Herokuand for the first time in a while, it showed up under Google news. Steve Yegge is also (threatening? promising?) to blog about it (after writing an intro to the Joy of Clojure), and he happens to be one of the 2 or 3 most-read language bloggers. That means that a lot of attention is going to be coming Clojure's way soon. It would be very much a travesty if large portions of these people were put off by out- of-date stuff on the website. Once they are put off once, it is going to be much harder to get them in a second time. Speaking to people who I think would not mind being paid to program Clojurewe all have a stake in making the language popular and useful. (As for Steve Yeggeis he reading all this?if he's totally wrong, then of course people should feel free to disagree with him, and forget about the consequences. But if he happens to be \right, and I do think he mostly is, then making basically dismissive firm stands against him is not going to do anybody any good. This isn't a political party, thank God.) It may be that I am really talking about the website (clojure.org, not any of the auxiliary ones, which are a bit of a mess in themselves) more than the language itself. If people receive the \right instructions, setting up Emacs/Leiningen/Web servers etc. is actually not so hard. The trouble is that all of this information is currently scattered to the four winds (I include things like the Paredit cheat sheet, Slime commands, which Emacs to use, etc.), and I don't think we should rely on users to pull this information together themselves and at any rate, why should they? Mainstream languages (Java, Python) provide good resources drawn together onto their websites, painless documentation systems for contributed packages (where is the Contrib documentation these days?), and they have a pretty standard option for getting started. I think Clojure should fully aspire to that, and provide ways for users to help with developing it. That is a long-term project, but in the meantime, there seem to be some really simple things that can be done now. That's not my whole point by any means, but it's more than enough. I wish that someone of the stature of Phil Hagelberg would have brought it up on this thread; but as I have made (enough of) my point, I'll get off my hobby-horse now. See (some of) you at the Bay Area meetup tomorrow! Nick. On Jul 6, 11:37 pm, Sean Corfield seancorfi...@gmail.com wrote: Much better. Now I can read it and see your points... and respond... On Wed, Jul 6, 2011 at 10:42 PM, nchubrich nchubr...@gmail.com wrote: * Clojure still ends up turning off new users more than it needs to. I think we need to nail the intro / setup experience and I'm nailing my colors to Leiningen. I think that needs to be adopted as the default, standard way to get up and running on Clojure and all the official tutorials need to be updated to reflect that. It's the biggest, single roadblock IMO and all that nonsense about downloading ZIP files and running some specific Java command is a huge barrier to entry. So far everyone I've introduced to Clojure has struggled with the Java infrastructure stuff but has got Leiningen instantly. * It also can do a better job of attracting and retaining core contributors. I cited an example of someone who posted a patch to make refs persistent. She ended up being ignored, and left for Erlang. But Clojure needs people like her. Unfortunate but all open source projects have a bar to entry and lots of potential contributors get left by the wayside. I think Clojure actually has a pretty good ecosystem around contribution. Could it be better? Maybe. Could it maintain the high level of quality and still be more inclusive? Hard to say... * Putting up barriers to entry is \not a good thing. I think most people agree with that but the disagreement is on whether Clojure really is putting up such barriers. I think that's debatable. * Since Lisp is highly extensible, in the long run being 'prescriptive' is a losing battle. Again, I think this is a debatable point. I don't believe there is any direct correlation between the prescriptiveness of a language / framework and its success. * Clojure is already enough of a new way of thinking, and it may be simply too much at once for many people. Aye, maybe
Re: Please stand firm against Steve Yegge's yes language push
Thank you, Logan, you put it very well. You're absolutely right there can be an inherent instinct against user-friendliness in open-source software, as well as a kind of hierarchyand you've identified the source and nature of it, I think. The response to this is not to try to become commercial. The response is to realize that it's a piece of sociology and human nature that we all have to make an extra effort to rise above. It's not such a different issue from table manners good food tends to make people act like pigs unless they are careful, so people actually have to explicitly learn to eat politely. It doesn't happen by instinct, it requires leadership and guidance. For the present circumstance, I think it means that open source projects have to make user-friendliness (both on the forums, in the software, and in the documentation) a core value whether they have any deep animalistic drive to do so or not. It needs to become ingrained in the culture, and examples need to be set. I think Clojure is not too far behind the head of the pack on some of these matters. As Sean Corfield pointed out, Lein is a big part of making Clojure user- friendly; unfortunately, its central role isn't really reflected on Clojure.org. The documentation meanwhile could stand to be improved (many people seem to agree on that point), and that I think will go a long way towards shaping the culture in the right direction. I need to reply to Stu's post on that. (And yes, I intend to help. But I do want to say that talking about things is \also useful. I admit the wrongth of my prolixity in the first post, but I \don't think it's wrong to talk about cultures and processes. Every group of people has to do this at some point, and it may not always fit under the 140 character limit. And not all problems in a programming language community can be solved by programming.) Logan's economic explanation makes sense, but there is still an irony in the way programmers spend their day jobs making life easier for users, but don't always bring the same ethic to bear on their own environment. If I may make yet another homely analogy, it's like a family that keeps one room in pristine condition for guests, but lets the rest of their house accumulate cruft. It's a common but odd situation. And (as anyone who has dealt with Makefiles would know) it can be amazingly durable. We're already vastly better off than Makefiles, but this is no reason for complacency. On Jul 7, 12:03 pm, logan duskli...@gmail.com wrote: I think Yegge clarified in a follow-up post that what he really meant to say was say yes to USERS, not say yes to FEATURES, but in his typical off-the-cuff ranty writing style, he had accidentally conflated the two. As far as saying yes to every feature, I think that is obviously not a great idea. It is easy to make the argument that one of the reasons Java became successful are the features that it said no to: No to pointers, no to multiple inheritance, no to operator overloading. As far as saying yes to USERS. I think Yegge brings up a really important point about a critical problem that plagues not just clojure but all open source communities in general. Basically the blowhard who thinks he is smarter than the average person and who enjoys letting other people know it. We all have some element of self-interest in our hearts. When you get paid to write software the reward is obvious. When you are contributing to open source what is the motivation? If you have the soul of an artist maybe you just want to create something beautiful. But there are a lot of others for whom contributing to open source is an ego trip. They haven't gotten the recognition that they feel they deserve in other parts of their life, so they decided that by writing something cool and putting it on the internet then they will be cool too. When you are getting paid for software you have a direct incentive to make your software as user friendly as possible. If it just works for the users and they like it and they can happily use it without ever looking at a manual, then you get more users and more money. People in open source want more users too but they don't necessarily want it to be user friendly. In fact often I feel there is this huge incentive to NOT be user friendly. It is like hazing. You get to say things like That is not the functional way, I know the right way but you don't, I am better than you. or Why would anyone want to do that? The problem you are stumped on has such an obvious solution to me that I can't even understand why you have a problem, I am better than you. There is this attitude of I figured how to write my own .emacs all by myself, from reading the forums and the documentation, because I was too socially maladjusted to ask anyone for help. Why can't you? This poisonous attitude is perfectly exemplified in this thread by James Keats. I think it's important to recognize that we
Re: Please stand firm against Steve Yegge's yes language push
Stu--- Thanks for the links. I took a look at clojure dev and signed up. I don't see any way to editdoes that happen after I mail in the Contributor agreement? It does seem a little medieval to have to mail it in. Clojure dev though doesn't seem like such a direct way of improving clojure.org, which is what people see and try to use. (Steve, ClojureDocs.org is also another outside site.) The fact that people are posting tutorials in blog posts that need to be corrected as the language changes strikes me as an indication that there isn't enough of a way for them to write these things under Clojure's aegis. Why not eventually make a beta version of Clojure.org (with the exact same formatting), that can then be migrated piece-by-piece to the main site as things get approvedand let anyone edit this, wiki- style? What's there on clojure.org is already quite good (with the exception of Getting Started, which still tells people to do java - cp ). There could also be someone responsible overall for each section, so it doesn't get too messy a la the Emacs Wiki. I'm happy to put some time into organizing the API a little better, but I don't see any way of doing this at the moment. (I see no API section on Clojure dev.) I'd love to see the API reference not only organized into good groupings with cross-references from a given function (one area where OOP actually \is a good thingthe only one, so far as I can tell), but have these groupings include references to related Contribs and even Java functions with their Clojure call syntax. So long as there is a way for users to add these sorts of things, it can grow over time. There is probably a way of automatically snarfing things from JavaDocs as well. Again, I'm happy to undertake this sort of project, but I need to see if it's a good idea, and I obviously need guidance. Why not have clojure.org also include tutorials (the equivalent of Java trails, perhaps) to get a given thing done: shell scripting; web server; system programming; Swing; etc. The best of what people put on blogs could go straight on the main site, and then be kept up to date right there. Once this is done, you might actually get people up to speed on Clojure fairly quickly. Best, Nick. On Jul 7, 6:12 am, Stuart Halloway stuart.hallo...@gmail.com wrote: It may be that I am really talking about the website (clojure.org, not any of the auxiliary ones, which are a bit of a mess in themselves) more than the language itself. If people receive the \right instructions, setting up Emacs/Leiningen/Web servers etc. is actually not so hard. The trouble is that all of this information is currently scattered to the four winds (I include things like the Paredit cheat sheet, Slime commands, which Emacs to use, etc.), and I don't think we should rely on users to pull this information together themselves and at any rate, why should they? Getting Started documentation is bound to be a high churn area. Here are things you can do to help: (1) Edit and improve the official docs:http://dev.clojure.org/display/doc/Getting+Started (2) Link to the official docs, and help us do the same. clojure.org has a slower update process than the dev site (by design!) but if there is something wrong, or a place where it needs to link out, please let us know! (3) Encourage people who wrote a blog post 18 months ago that is now filled with misinformation (as things have moved on) to go back and add a link to the official docs. There are now almost 300 signatories to the contributor agreement, and any of them can update dev.clojure.org without any review process. This should be plenty of horizontal scaling to keep documentation (even high-churn documentation) accurate. Thanks to everyone who is helping out! Stu Stuart Halloway Clojure/corehttp://clojure.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Please stand firm against Steve Yegge's yes language push
I'm always bewildered by this argument. What has a newbie to choose here? Of course he uses what he's used to. Many Java devs probably want one of the IDEs they already know. Old-time Lispers use emacs. I think it's a question of style and how to present the information (which is why it would help to have a single person in charge of each section). For one thing, the information is really in the wrong placeit should be on Clojure.org. Even where it is, there's something aesthetically wrong about having to wade through all of those choices right at the outset. (I say this even as an admitted long-poster) Having text describing emacs and lein setup, followed by links to all the other options for those who know about them, seems like a good compromise. The information is still there, and people who need it will know to click on it. Everyone else can have setup instructions that are simple and concise (and Emacs and Lein really do seem to be emerging standards). On Jul 7, 2:37 pm, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 07.07.2011 um 21:54 schrieb Sean Corfield: I think one sticking point here is that there are (so far) seven IDEs/editors listed and five build tools. For a n00b, that's too much choice. I'm always bewildered by this argument. What has a newbie to choose here? Of course he uses what he's used to. Many Java devs probably want one of the IDEs they already know. Old-time Lispers use emacs. I don't read this information as “Look, newbie, there is emacs, or eclipse, or vim, which you can use to edit Clojure code. And you can build clojure stuff with leiningen, or with gradle, or with maven.” I see this list as: “I'm used to maven and eclipse, let's see how I get this running with the tools I know already.” Isn't that the most natural thing someone would try to do? 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: Please stand firm against Steve Yegge's yes language push
I've been using Clojure on and off for a whilecurrently off, though not because of the language itself. The thread now seems to have moved in a different direction, but I have to say (looking at the Seajure and Y Combinator threads) that Steve Yegge has some good points. And ending up here with a thread titled stand firm against... seems to be exactly the sort of community problem that he is worried about. I wish that we did not have to deal with a fundamental disagreement about what a language is \for. If a programming language is something like Hermann Hesse's Glass Bead Gamean intellectual diversion for superior intellectsthen spending time contemning Joe Developer and deploring people who want to suggest different directions for the language is a worthwhile activity. But ultimately programming languages are about getting things \done, just as cars are about \going places. It is still possible (though increasingly difficult) to tinker with your own car before driving it. In the beginning, it was obligatory. You had to choose a third-party auto-body manufacturer. You had to crank the engine yourself. You even had to manually set the ignition timing while you were driving. There was a lot of cruft you had to deal with that had nothing to do with getting from point A to point B. The first users of cars had to be willing to work with them as a kind of \hobbyyou had to give over a certain amount of time out of your day just to just keeping the things running. At some point, a transition happened. They became mass-market devices. The tinkerers never went away, but their increased numbers, and the increased numbers of people simply \using cars, led to an increase in simplicity and reliability. Every time there was an issue to deal with, there were that many more people with a stake in fixing it. Some people may miss the old hobbyist culture around cars, but I don't think anyone really wants to go back to Model T days. The remarkable thing nowadays is that a \huge number of people become good drivers (although admittedly there are quite a few that shouldn't be on the roads)and driving is a fairly demanding and crucial activity. Sadly, we cannot say the same thing for computer users. Clojure is still in the Model T days (though it is continuously improving). Getting a non-broken Emacs setup is not always easy (I attended a Clojure class a few weeks ago where we spent the first couple of hours just trying to get Clojure and Emacs working). There is no built-in command-line REPL or interpreter. Debugging is cryptic and not particularly helpful, and occasionally outright misleading (see what someone posted to the Seajure and Y Combinator threads on his roundabout way of discovering that Clojure needed advance declarations). The documentation is not quite as consolidated and organized as the Java or Python documentation (though it has also gotten better), and people really wanting to get things done must deal with two independent sets of documentation, Java and Clojure, the latter of which is simply organized alphabetically. Supposing that they do get over this hump and now wish to develop a practical project, they are immediately faced with more choices. There is no standard, immediate path for developing web apps, GUIs, or even shell scriptsyou have to use your sixth sense of what libraries may or may not actually work (which on the Internet can be quite difficult, as something that doesn't really work rarely \tells you so itself). You can jump into Python as a complete noob in the morning, and have a useful program by the afternoon. This is much less likely to happen with Clojure. There are plenty of smart people who lack both the time and the system administration chops to deal with getting into Clojure. This is very sad, because once you get into it, Clojure is very easy and very sensible. There are surely many great programs that are not being writtensome of them would be programs that help smoothe the way for everyone else. Many people who would help spread the functional programming gospel are getting their brains fried in Python and Javaand teaching them will be that much harder when they eventually come around (as people have pointed out here). Now all of the rough edges are perfectly understandable for a new language, and they continue to get betterand the more you are willing to Google around and read blogs and so forth, the more solutions you find. But what bothers Steve Yegge and many other people, I suspect, is that fixing this fragmented user experience and the gaps in the language doesn't really seem to be a prioritywhen in fact it should be a prime mission. People actually make the argument that these difficulties are good weed outs for the joe developers who would (presumably) get in here and muck everything up. I have actually heard people say here that people who don't have the wherewithal to configure emacs and
Re: Please stand firm against Steve Yegge's yes language push
amount of work and a lot of trial and error to go from zero to easy for everyone. Python has had 15+ years to get to that point, Clojure is at 3+. Needs are seeming to be addressed at a reasonable rate, in my view. Not to be rude, only practical: if there are itches you are having that are not being scratched, it would be far more productive to do something about it than complain that others are not pulling their weight. On Wed, Jul 6, 2011 at 7:30 PM, nchubrich nchubr...@gmail.com wrote: I've been using Clojure on and off for a whilecurrently off, though not because of the language itself. The thread now seems to have moved in a different direction, but I have to say (looking at the Seajure and Y Combinator threads) that Steve Yegge has some good points. And ending up here with a thread titled stand firm against... seems to be exactly the sort of community problem that he is worried about. I wish that we did not have to deal with a fundamental disagreement about what a language is \for. If a programming language is something like Hermann Hesse's Glass Bead Gamean intellectual diversion for superior intellectsthen spending time contemning Joe Developer and deploring people who want to suggest different directions for the language is a worthwhile activity. But ultimately programming languages are about getting things \done, just as cars are about \going places. It is still possible (though increasingly difficult) to tinker with your own car before driving it. In the beginning, it was obligatory. You had to choose a third-party auto-body manufacturer. You had to crank the engine yourself. You even had to manually set the ignition timing while you were driving. There was a lot of cruft you had to deal with that had nothing to do with getting from point A to point B. The first users of cars had to be willing to work with them as a kind of \hobbyyou had to give over a certain amount of time out of your day just to just keeping the things running. At some point, a transition happened. They became mass-market devices. The tinkerers never went away, but their increased numbers, and the increased numbers of people simply \using cars, led to an increase in simplicity and reliability. Every time there was an issue to deal with, there were that many more people with a stake in fixing it. Some people may miss the old hobbyist culture around cars, but I don't think anyone really wants to go back to Model T days. The remarkable thing nowadays is that a \huge number of people become good drivers (although admittedly there are quite a few that shouldn't be on the roads)and driving is a fairly demanding and crucial activity. Sadly, we cannot say the same thing for computer users. Clojure is still in the Model T days (though it is continuously improving). Getting a non-broken Emacs setup is not always easy (I attended a Clojure class a few weeks ago where we spent the first couple of hours just trying to get Clojure and Emacs working). There is no built-in command-line REPL or interpreter. Debugging is cryptic and not particularly helpful, and occasionally outright misleading (see what someone posted to the Seajure and Y Combinator threads on his roundabout way of discovering that Clojure needed advance declarations). The documentation is not quite as consolidated and organized as the Java or Python documentation (though it has also gotten better), and people really wanting to get things done must deal with two independent sets of documentation, Java and Clojure, the latter of which is simply organized alphabetically. Supposing that they do get over this hump and now wish to develop a practical project, they are immediately faced with more choices. There is no standard, immediate path for developing web apps, GUIs, or even shell scriptsyou have to use your sixth sense of what libraries may or may not actually work (which on the Internet can be quite difficult, as something that doesn't really work rarely \tells you so itself). You can jump into Python as a complete noob in the morning, and have a useful program by the afternoon. This is much less likely to happen with Clojure. There are plenty of smart people who lack both the time and the system administration chops to deal with getting into Clojure. This is very sad, because once you get into it, Clojure is very easy and very sensible. There are surely many great programs that are not being writtensome of them would be programs that help smoothe the way for everyone else. Many people who would help spread the functional programming gospel are getting their brains fried in Python and Javaand teaching them will be that much harder when they eventually come around (as people have pointed out here). Now all of the rough edges are perfectly understandable for a new language
Re: Please stand firm against Steve Yegge's yes language push
It did go on too long. I hope when someone \does read it, they will see I am not being wholly unreasonable. On Jul 6, 7:21 pm, Ken Wesson kwess...@gmail.com wrote: On Wed, Jul 6, 2011 at 10:06 PM, nchubrich nchubr...@gmail.com wrote: As to making contributions, I just pointed out an example of someone who made a contribution and was ignored. Does the term tl;dr mean anything to you? I doubt very many people got that far in the wall of text you posted earlier, especially in just the few hours it's been since you posted it. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Please stand firm against Steve Yegge's yes language push
I'll try :) It was really a polemical post for a polemical thread, but my main points can be extracted here. Feel free to read as many or as few of them as you are inclined: * Clojure still ends up turning off new users more than it needs to. This may be partly an issue of priorities (see the Getting Started section on clojure.org). Many good efforts are going into libraries, but this doesn't necessarily lead to a smoothe starting path. That would require choices from the top. * It also can do a better job of attracting and retaining core contributors. I cited an example of someone who posted a patch to make refs persistent. She ended up being ignored, and left for Erlang. But Clojure needs people like her. * Putting up barriers to entry is \not a good thing. The benefits of getting new users outweigh the drawbacks, because they will bring more functionality and maturity with them. It only takes a small effort to filter out 'noise' in the group (even mine!). * Since Lisp is highly extensible, in the long run being 'prescriptive' is a losing battle. It is better to eventually add standard 'bad' features to the language than to tempt third parties to do it in even worse and incompatible ways. * Clojure is already enough of a new way of thinking, and it may be simply too much at once for many people. If a gentle path gets more people into the ecosystem, it's worth itonce they are in Clojure they can be steered towards better, more functional ways of doing things. In any case, experienced users are always free to ignore extra features. * It's meant to be a pragmatic language. This means that a prime goal should be to get people writing useful (web, GUI, shell) code in it right away. Having choices is good, but being forced to make all these choices your first day of writing Clojure, when you don't have a sixth sense about the community and What Really Works, is needlessly discouraging. * The attitude that Smart People are precisely the ones who will want to deal with Clojure's existing drawbacks ends up excluding many great future Clojurians. (A lot of smart people are busy.) The attitude itself is off-putting and self-defeating. Moreover, dealing with these issues takes \everyone's time. * Final (added) point: while it might have made sense to be 'prescriptive' initially in order to establish the identity, core, and soul of the language, this has been done sufficiently. Newcomers are not going to be confused about what the main points of Clojure are now. There is therefore less risk in making it broadly useful to different paradigms. If you want to read the arguments behind all that, you can wade into the postor add your own. On Jul 6, 9:37 pm, Sean Corfield seancorfi...@gmail.com wrote: On Wed, Jul 6, 2011 at 7:21 PM, Ken Wesson kwess...@gmail.com wrote: Does the term tl;dr mean anything to you? I'll remember this date - I find myself really liking / agreeing with one of Ken's posts :) Sorry nchubrich but that really was far too long - I started reading but couldn't find any meat in the first few paragraphs and just tuned out... I may try again later but if you can _summarize_ more ppl will read what you're trying to say. -- Sean A Corfield -- (904) 302-SEAN An Architect's View --http://corfield.org/ World Singles, LLC. --http://worldsingles.com/ Railo Technologies, Inc. --http://www.getrailo.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: SQLRat - A Clojure 1.2 library to access Relational Databases using DataTypes
So, the question is -- is SQLRat doing more or less the same thing as ClojureQL? Partly yes, but mostly no. Thanks Shantanu! So I suppose one way you could use them both is simply use the SQL compilation feature of ClojureQLyou could pass SQLRat a raw SQL query created from ClojureQL? I've used ClojureQL quite a bit, but I haven't attempted to verify its database agnoticity. I think having that is a good goal, though. I'd be curious to hear what the ClojureQL developers think of working with your project. Nick. -- 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: ANN: SQLRat - A Clojure 1.2 library to access Relational Databases using DataTypes
Shantanu--- This looks great! Can you compare it to ClojureQL? Is it attempting to do more or less the same thing? (Not sure what is happening with ClojureQL right now.) Thanks, Nick. On Aug 31, 1:19 pm, Shantanu Kumar kumar.shant...@gmail.com wrote: SQLRat 0.1 GA is pushed to Clojars. Maven/Lein details here:http://clojars.org/org.bituf/sqlrat The same is also reflected here:http://code.google.com/p/bitumenframework/ # Changes and TODO ## 0.2 / planned - [TODO] Support large sized query result-sets (by adding lazy loading option) - [TODO] Optimistic locks using time stamps - [TODO] DSL for the WHERE clause - [] Add :groupby and :orderby arguments to find-xxx functions ## 0.1 / 2010-Aug-31 (GMT + 5:30) - Entity definitions, meta data, relations - CRUD (Create, Retrieve, Update, Delete) functions for entities - Small-to-medium sized query result-sets (eager-fetching is the only option) - Query by COUNT(*) function - User can specify columns, WHERE clause in retrieve functions - CRUD (Create, Retrieve, Update, Delete) functions for entity- relations - Avoid N+1 Select Feel free to kick the tires and do share your experience/impression. Regards, Shantanu On Aug 18, 11:38 pm, Shantanu Kumar kumar.shant...@gmail.com wrote: Hi, I have uploaded source code (Apache 2 license) forSQLRat- a library for Clojure 1.2 to access relational databases using DataTypes (entities). It also lets you define relations between entities and navigate them. While this is a part of what typically Object- Relational Mapping (ORM) frameworks do, it is not an ORM framework per se -- it does not implement State managent, Identity management, Lazy loading, Eager fetching etc. The code is quite rough around the edges right now and beta-quality at best (at 0.1-SNAPSHOT), but it works nevertheless. I intend to release it as GA soon after Clojure 1.2 goes GA too. The source code is here:http://bitbucket.org/kumarshantanu/sqlrat/ Discussions can be posted here:http://groups.google.com/group/bitumenframework You may also like to keep a tab at this:http://code.google.com/p/bitumenframework/ The intent of this announcement is to gather feedback, so that I can fix as many warts as I can before doing a 0.1 GA release. It is not on Clojars yet, but the GA will eventually be there. The most important parts to review would be the API it exposes, followed by the implementation details. So, I would request you to give the library a try, ask questions (I would be happy to answer), give feedback, make suggestions and if you can, fork and contribute as well. The usage can be found in the dbblog.clj file, which contains the unit tests and describes how the library can be used. Regards, Shantanu -- 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: Extending Clojure's STM with external transactions
How about introducing a second part to the api? (store) creates a
wrapper for the persistent address, and refp then takes one of those
wrappers and the name?
I like that. I would go one step further and say refp should have a
default data store that is used unless you specify anything else via
'store' or additional arguments to refp. This would go partway
towards making persistence like garbage collection.
The reason I suggested persisting entire nampespaces was that
sometimes (often) the need to persist data is outside of any usage of
refs (or atoms, or agents). Maybe such a high-level facility could be
built on top of refp.
Another thing I'd like to see (as I mentioned) is an extension of map
syntax for the kinds of (e.g. SQLish or XMLish) data structures you
get out of persistent stores. One of the brilliant things about
Clojure is its unification of multiple sequence types. It was
something that was crying out to be done. I think that, similarly,
there could be a more unified and standard way of dealing with maps,
maps-of-maps, maps containing lists, etc.
There is already a nice shorthand syntax for maps: to get a key's
value out of a map, you pass it the key:
({:a 1 :b 2} :a) - 1
How about extending this system to selection among sets of maps (i.e.
relational data), by passing a key-value pair:
(#{{:a 1 :b 2}
{:a 3 :c 4}} {:a 3}) -
{:a 3 :c 4}
Which could then be further processed by just passing a key or set of
keys to project:
(... :a) - 3
Now consider nested maps with lists, which might come from XML or some
other kind of hierarchical data (note this is not what you would get
from read-xml; I'm trying to imagine a native structure that doesn't
refer to external concepts such as attributes, content, etc.):
{:catalog [{{:node :book :isbn 100}
{:author :Shakespeare :genre :play}}
{{:node :book :isbn 101}
{:author :Shakespeare :genre :sonnet}}
{{:node :book :isbn 102}
{:author :Knuth :genre :textbook}}]}
You might pass this a sequence of terms above a given node to
identify it:
(data [:book :author :Shakespeare :sonnet])
Which yields the entire hierarchy above any identified nodes:
- {:catalog [{{:node :book :isbn 100}
{:author :Shakespeare :genre :sonnet}}]}
This can then be further processed by projecting the node level you
want to look at:
(... [:catalog :node :book]) - {{:node :book :isbn 100}
{:author :Shakespeare :genre :sonnet}}
(... [:catalog {:node :book} :author]) - :Shakespeare
You could be as imprecise as you like in doing these queriesall
the way from sets of unordered terms (using set notation) to specific
key-value pairs (e.g. in the last example). The idea is to make the
best of your (sometimes partial) knowledge.
. This is a \very rough idea, and it completely ignores some edge
cases, but the basic point is that I am trying to query relational
data and hierarchical data in the same way. A further way of
unifying external data sources is to converge on a standard way of
dealing with relational or hierarchical data, and meanwhile allowing
the same methods of querying to be used on different representations.
For instance, maps themselves can be represented as maps, as a list of
alternating key-value pairs, a vector of two-place vectors, or a list
of keys and a list of values. We should be able to query all these
things in the same way, and there should be utility functions to
convert between them (I always end up writing my own).
In the case of relational data, different programs pick different
representations. There is Clojure's native way, which is sets of
maps. Incanter has a two item-map with :column-names and :rows.
ClojureQL does something else again. When I have relational-like data
in my own programs, I tend to pick one column as the key, and map it
to subsidiary data, e.g.:
{:screw {:price 0.1 :supplier :Acme}
:bolt {:price 0.2 :supplier :Nuts}}
It should be possible to query any reasonable representation in the
same way, and writers of libraries meanwhile should try to converge on
a single way of representing these things (why not Clojure's?).
--
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: Extending Clojure's STM with external transactions
I'm not aware of any, but +1 for seeing persistence handled as part of the language. A big project and a long-term one, to be sure, but could it not be considered a goal? In my student days, I was talking to a well-known Lisper (name suppressed for fear of Google indexing) about some data structures in MIT Scheme. When I asked about saving them to disk, he said in effect, You're on your ownthat's something that \should be handled, but never is. I think people are so used to this state of affairs they forget how ugly it really is. Programming languages are like Moses without Joshua: they lead your data in the wilderness, but when it comes to finding it a permanent home, you have to talk to someone else. And these someone elses (who seem to be as numberless as the sons of Abraham) each have their own habits and ways of talking. Persistence libraries always end up warping the entire codebase; I've never succeeded in keeping them at bay. Using data with Incanter is different from ClojureQL, which is different from just using contrib.sql, and all of it is different from dealing with just Clojure. (I've never even tried Clojure + Hibernate.) You might as well rewrite the program from scratch depending on what you use. Maybe other people have had better luck; but whatever luck they have, I'm sure it is a fight to keep programs abstracted from persistence. I'd like to be able to work with mere Clojure until my program is complete, and then work in a completely separate manner on how to read and write data. Or maybe there would be off-the-shelf solutions I could plug in for different needs: low latency, high read, high write, large stores, etc. On the Clojure side, you would simply call something like persist namespace, which would save the state of your current or given namespace (unless you pass it the names of variables as well, in which case it only saves those). And to read data, you would simply require or use it into your namespace: you could choose what granularity to give first-class status: just tables, or columns as well, etc. And you could do this equally well for XML, JSON, relational data, or a graph store; your choice. And the only difference between these and ordinary variables would beheaven forbid!a disk access might happen when you deal with them! To have such a system work well, you would need to enrich the way you query Clojure datastructures. I have some ideas on that, but I'd like to make sure I'm not shouting in the dark first. I'd like to see a day when programmers need to worry about persistence about as much as they worry about garbage collection now. -- 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: parallel execution
I ended up using pmap; I found that on a 2-core machine, it led to about a 1.6 time speedup; on an 8-core, it led to a 3 time speedup, which I found somewhat surprising; maybe all the cores are not being utilized. -- 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 1.3: Integrating clj-stacktrace?
problem, but the lack of full paths in the trace has bitten me. Since all of my namespaces have a core.clj this can mean a bit of detective work to find which core.clj is being reported. +1 for that. -- 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
parallel execution
I have a simulation program that runs a Number of random Simulations and then Averages them. It basically looks like this: (reduce Average (repeatedly Number Simulate)) What is the best way of making this parallel? I noticed there was no parallel version of repeatedly. I suppose I could pmap over a dummy series, but this seems a misuse of the function. Also, couldn't there be in theory a preduce? This seemed to be in clojure.parallel, but parallel is deprecated. Why is it deprecated, and what's the replacement for it? Thanks, Nick. -- 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: Flex as a Clojure Frontend
Thanks Rich--I'm actually interested in all kinds of configurations. For the time being, it will be a Flex frontend in the browser communicating with Clojure on the server. In the future, we might want to make the Clojure part into a Java applet that runs on the client side and does computations while Flex handles the interface; finally, I'm also (in the long-term) interested in building standalone apps that use Flex/AIR for the interface and Clojure/Java for the backend. It all seems rather complicated, but I've found Flex to be the best way of programming interfaces (so far). Concerning BlazeDS and AMF: what is the advantage of that over just using straight HTTP with say JSON? I know RTMP has push capability; any other reasons? -Nick. On Aug 15, 11:53 am, Richard Lyman richard.ly...@gmail.com wrote: On Sat, Aug 14, 2010 at 1:40 PM, nchubrich nchubr...@gmail.com wrote: I'm wondering if anyone has any experience developing Clojure applications with a Flex interface, and if so, what is the best way of going about it. I have quite a bit of experience. I've been writing an internal implementation of the non-media parts of RTMP, so that your backend can be anything that runs on the JVM (Java, Clojure, Scala, Groovy, JRuby, etc.) and your frontend can be pure ActionScript. The 'best way' probably depends on how you'll be deploying your application. Are you going with some J2EE container, are you packaging everything into a standalone app? (Or maybe something between the two...) I also wonder if anyone has used Las3rI'm a little reluctant to use it because the Flash Builder programming environment is so effective. Thanks, Nick. I don't have experience with Las3r - but it says it's a port of Clojure (parts of) to run on the AVM2. That's pretty different than the standard method of communication between a Flex frontend and a JVM backend. If I were you I'd look at getting Jetty or Tomcat (JBoss if you're very brave or previously-enterprise-skilled) to work with BlazeDS - then you can write your Clojure code compiled to JARs and expose the methods as AMF messagebrokers to a RemoteObject running from Flex. -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
Flex as a Clojure Frontend
I'm wondering if anyone has any experience developing Clojure applications with a Flex interface, and if so, what is the best way of going about it. I also wonder if anyone has used Las3rI'm a little reluctant to use it because the Flash Builder programming environment is so effective. Thanks, Nick. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure for system administration
Chouser--- The Parrot vm looks really great for Clojurepresumably Clojure could have continuations and TCO there. On Feb 5, 9:59 am, Chouser chou...@gmail.com wrote: On Thu, Feb 4, 2010 at 11:33 AM, Stuart Sierra the.stuart.sie...@gmail.com wrote: Clojure can certainly do these things; clojure-contrib contains many file and io-related utilities. But remember that Clojure, like any Java program, takes more time to start up than scripting languages like Perl/Bash/Ruby/Python, so it may be less suitable for programs that you intend to run at the command-line. This has been the main reason I haven't completely abandoned Python and ruby for such tasks. I think the original question was phrased perfectly -- wondering if the time is right. For me, I'd say not quite yet. I'm still holding out for Clojure-in-clojure targeting a unix-embracing, fast-starting host platform like golang or parrot. --Chouserhttp://joyofclojure.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: find source file for namespace?
But finding the source path from the namespace is what I can't figure out. You can look at metadata on a var, and this has a :file field, but typically :file says NO_SOURCE_PATH. On Dec 28, 12:33 am, Emeka emekami...@gmail.com wrote: Hello nchubrich, I thinking that you can do this with easy using namespace which would lead you to resolve the file name and then figure out the path. Emeka On Mon, Dec 28, 2009 at 2:43 AM, nchubrich nicholas.chubr...@gmail.comwrote: Does anyone know how to dynamically access the pathname for a particular piece of code? I.E., I'd like to be able to write a function that can be called in any context and returns the pathname for the code it was called in. (My intended use for this is to develop a testing package; I want to figure out an appropriate place to save the test files.) -- 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.comclojure%2bunsubscr...@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
find source file for namespace?
Does anyone know how to dynamically access the pathname for a particular piece of code? I.E., I'd like to be able to write a function that can be called in any context and returns the pathname for the code it was called in. (My intended use for this is to develop a testing package; I want to figure out an appropriate place to save the test files.) -- 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
Mike--- the thought that the key developer might just stop working on it doesn't exactly give me a warm fuzzy feeling. Look at the last paragraph of Rich's message. He has every intention to keep working on it. Surely he will speak for himself, but my impression is that he wants to be able to work on this full-time as opposed to part-time. I don't see any direct threats to abandon it. Larry Wall's project was not without risk of dying either. He could have lost his job and had to go to work for a less enlightened employer. In some ways, it is easier for you to evaluate the Clojure community than it is to evaluate the likely continuance of other circumstances in the founder's life. And a strong community may be better able to ride out a bubble bursting than a company. The sort of funding activities you are talking about would work, but they would inevitably take time away from core Clojure development. Is it worth being dunned for money to allow development to proceed that much faster? To me (and apparently plenty of other people), it is most definitely worth it. I'm not the first person to say this, and I won't be the last, but Clojure has been a dream come true. As great as it is now, I look forward to everything that Rich wants to addClojure in Clojure, declarative logic. I want him to be able to focus on these new things full time. I want him to work for the community, rather than for whoever he consults for, or whoever he lectures to. (The community has been greatif the number of dumb questions of mine that have been cheerfully answered is any indication) He has created something that has been of great value to me personally and in my work. I feel I owe him. If you are not sure what Clojure is worth to you yet, then you don't owe him anything. And if you believe that there should be no need to pay people whose open-source work you have found useful, you don't owe him anything either. There may be a version of the open-source ethos that disdains making money directly from coding. This ethos would claim that the way to repay people is in code, not in money. I think this attitude ends up being exclusionary. The vast majority of people cannot or do not contribute useful code. But they have just as much of a need for good software as programmers do, if not more, and yet their interests are not always well-served by open-source software. When your remuneration comes not from your core activity, but from various side activities, or when open-source coding itself is a side activity, you are bound to be distracted. When your only currency and standing comes from other programmers,, things that non-programmers need especiallyimportant but uninteresting things like documentation, interface polish and ease of setuptend to get neglected in the distraction. Not surprisingly, the open source movement has created a great deal of powerful software, but it has had mixed success creating software that the vast majority of people can use. If we want open-source software to live up to its full potential, we will have to abandon exclusionary attitudes, and most importantly think creatively about how to give people like Rich Hickey a living. I wish he did not have to ask for donations, but that's a lot better than him wasting his time. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Funding Clojure 2010
Maybe the _thing_ could be a more packaged version of Clojure; something for which setup is a little more seamless, etc. No extra features, just convenience. Maybe an IDE plugin with extra debugging/ instructional features, and more facilities for browsing libraries (java and clojure). It could be something you buy by default, but with an opt-out for people who want to build it themselves. On Dec 15, 8:50 am, Mike Hogye stacktra...@gmail.com wrote: +1 for the idea of offering a _thing_ for sale. The company I work for isn't going to give a donation; that's just not something it does. But if there were a _thing_ I could purchase on the company's dime, well ... it's much more standard for a company to make a purchase than a donation. Particularly if the thing offered is useful. Of course, it would take _work_ to make something to sell, and I don't really have any strong suggestions. Maybe the community can build something dual-licensed, whose proceeds go to developing Clojure itself? Boils down to devs donating effort instead of cash. On Dec 15, 4:00 am, olalonde olalo...@gmail.com wrote: I'm not convinced donations alone is a sustainable funding method. Why don't you derive a commercial product ? You could build an IDE for Clojure and sell it. You could write a book (although that is unlikely to really pay). You could build a stackoverflow-type community, organize events/conferences, etc. You might want to talk to some VC firm and see if they'd be interested in funding you. They could help you out figure a revenue model. Best of luck! On Dec 14, 9:33 am, Rich Hickey richhic...@gmail.com 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
Re: Funding Clojure 2010
Maybe it would be reasonable to charge for support if it added something to that already available on the list. After all, the list is made up for the most part of volunteers who do not need to earn a living answering questions, so it seems a little strange to gate access to them for \anyone, no matter how corporate. But corporations may want to pay for more intensive support to solve a particular problem. That could be provided by Rich himself, or any number of other contributors who would receive some money for the privilege, as would Rich in part. The results could be posted to the list as well so all could benefit. More speculatively, corporations (or individuals, for that matter) may wish to bid on features that would be specifically useful to them. This would provide a rigorous (though not necessarily ideal) prioritizing of features. Not only could they offer bounties for features within Clojure, they could offer bounties for contribs. An author of a contrib could be seen as writing a contrib as a sort of proposal, that once completed (for a fee) would be more useful. There is no reason that a number of people and corporations could not get together and offer to pay something for a completed feature. This is a risky approach, because it may encourage \more things to remain uncompleted until some payment is received; writing of incomplete features could become a form of shakedown. The hope would be that, once people realize a certain feature is probably not going to be paid for, they would go ahead and finish it anyway. But that introduces a delay. Hard-core open-source people are right to worry about the ill effects on motivations and priorities of introducing money into the system. That's why I suggested a packaging approach: money for packaging isn't going to distort the core functionality of Clojure in the way paying for support or features might. (The distortion of paying for support, is that there is an obvious incentive to make features that \need support.) On Dec 15, 5:20 pm, Mike Hogye stacktra...@gmail.com wrote: Maybe take your ease-of-use idea in a slightly different direction and call it support. Lots of business models rely on selling support. I have found the support available through the Clojure community (specifically: this Google Group, and the IRC channel) to be superb. Could commercial/corporate devs be required to pay for access to this community? Maybe: * Hobby-only devs still get free access to group and channel, just like now. * Corporate devs get free access to group and channel while evaluating Clojure. * Once a corporate dev is no longer just evaluating, payment is required (per-developer per-year). For me, that would justify spending my company's money. And if I were a potential Clojure user, it would not drive me away. On Dec 15, 3:09 pm, nchubrich nicholas.chubr...@gmail.com wrote: Maybe the _thing_ could be a more packaged version of Clojure; something for which setup is a little more seamless, etc. No extra features, just convenience. Maybe an IDE plugin with extra debugging/ instructional features, and more facilities for browsing libraries (java and clojure). It could be something you buy by default, but with an opt-out for people who want to build it themselves. On Dec 15, 8:50 am, Mike Hogye stacktra...@gmail.com wrote: +1 for the idea of offering a _thing_ for sale. The company I work for isn't going to give a donation; that's just not something it does. But if there were a _thing_ I could purchase on the company's dime, well ... it's much more standard for a company to make a purchase than a donation. Particularly if the thing offered is useful. Of course, it would take _work_ to make something to sell, and I don't really have any strong suggestions. Maybe the community can build something dual-licensed, whose proceeds go to developing Clojure itself? Boils down to devs donating effort instead of cash. On Dec 15, 4:00 am, olalonde olalo...@gmail.com wrote: I'm not convinced donations alone is a sustainable funding method. Why don't you derive a commercial product ? You could build an IDE for Clojure and sell it. You could write a book (although that is unlikely to really pay). You could build a stackoverflow-type community, organize events/conferences, etc. You might want to talk to some VC firm and see if they'd be interested in funding you. They could help you out figure a revenue model. Best of luck! On Dec 14, 9:33 am, Rich Hickey richhic...@gmail.com 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
Re: Clojure Scoping Rules
Richard--- It's not the same thing: (class (doall (map (fn [x] x) [1 2 3]))) - clojure.lang.LazySeq whereas (class (binding [*strict* true] (map (fn[x] x) [1 2 3]))) - clojure.lang.LazilyPersistentVector Also, having a dynamic var that turns laziness on and off would allow you to do it once for any given scope, without having to add the extra 'ceremony' of doalls. To quote Mark Engleberg: If you want to choose code simplification over laziness, it's not always even clear how to do that safely. For example, it's not uncommon to end up with lazy sequences of lazy sequences [...], and then a single doall isn't going to the trick. Wrapping doall around every single call in your code is unrealistic. I would add to that that casting your types back to what they were is also unrealistic. If there were a *strict* dynamic var, then you \could choose code simplification over laziness with a single line. What would be wrong with that? -- 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: positions
Thanks Emeka, I took a look at it. I still say it would be nice to organize the sequence functions (somehow). -- 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 Scoping Rules
Richard--- What if you accidentally cause a library to realize an infinite lazy sequence? True, that's a problem. But couldn't the library protect itself by putting a (binding [*strict* false] ...) in front of its code? (Having a namespace-level binding construct would be helpful.) This raises a more general thought about binding in general (while we're talking about new language constructs). Right now you have basically two choices for influencing code: Parameter passing, which is, nothing happens to my code without my permission, and dynamic binding, which is You might have the rug yanked from under you, and there's nothing you can do about it! (Exclamation point here is an indicator of mutation, not exclamation.) Well, this might be wildly speculative, but couldn't there be a middle way? I.E. a scope or a function body (if we are trying to unify these concepts then Scope and Function Body is really the same thing), instead of exporting variables of things that can be substituted, basically sets up a negotiation over what can and should be bound. It might state things like binding this such-and-such a way is a \really \bad idea, but if you do X first, it would be OK; and of course if you \insist The actual binding (if such a guard has been put up) then doesn't happen until the conditions have been run through. I'm not really sure what this construct would look like. Somebody else might have a better idea Maybe the problem with binding is not that it's inherently evil, it's just not democratic enough. -- 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 Scoping Rules
Richard, do you know where one can read about Rich Hickey's speculative work on scoping constructs? I did find a good description by him of what Clojure currently does, from 2007: http://markmail.org/message/kpuq4dvcavek26sp#query:+page:1+mid:mgfsubipgaqdmzru+state:results -- 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 Scoping Rules
Regarding Clojure sequence functions: why couldn't they have the option of returning non-lazy seqs? Because you don't always really need lazy seqs. It might be nice to have the option. (map (fn[x] x) [1 2 3] :strict) - [1 2 3] or even (binding [*strict* true] (map (fn[x] x) [1 2 3])) - [1 2 3] -- 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: positions
My 'requirements' were not so much for any particular need, but to try to think up a logical and complete API for dealing with multisets. I agree that there should be an actual collection type for multisets (implemented as an underlying map of values to frequencies I presume); but you might as well also be allowed to pass any kind of collections and have it do something order-preserving with them. It makes a good gathering point for sequence functionalities as \well as handling multisets. Alex is right that the keep-likes-with-likes option is a little weird. I'm not sure whether to just conj them next to the first instance, or try to equally distribute them as much as possible throughout the instances, leaving any remainders on the initial ones. Probably the latter. Of course when you have this kind of questioning, maybe it is not a good fundamental functionality to add. (My original spur for this was in merging argument lists in a permissive argument list macro I'm working on; the idea was you would get 'rest' type parameters anywhere in the list there is a repetition of variables under a keyword. Obviously you wouldn't want to have disparate instances of the same thing here. (My initial thoughts on this macro are at the bottom of the most recent discussion of keyword arguments. (How, by the way, do you do show quoted text?)) There is a sort of hierarchy of sequences for being sensible for multiset operations. First we have multisets themselves. Then we have sequences that are ordered but have no dislocated repetition of elements. Then we have arbitrary sequences. I'm inclined to want an API that handles all three. Maybe someone who does a lot of statistical work would have a better idea of how this API should work. Sean, regarding doall, the reason I wanted to have an internal override is to be able to preserve the collection type of the arguments. Sometimes it gets a little annoying to cast these back every time; and when you're dealing with small sequences, laziness is not really necessary. If you wanted to be \really evil about it, you could have a bind-able variable *lazy* that sets it one way or the other. -- 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: A macro for flexible keyword argument handling
I don't see why you couldn't simply check to make sure that there are no arguments without either default or supplied values. As I wrote above, If you left the arguments incomplete and unkeyworded it would apply what you put preferentially to the first arguments in the list without a default value. If there are any null arguments left over, the macro could throw an exception. The basic rule is, accept what you can, and only error our if you absolutely must. (Of course this variable application rule might get confusing in practice, at least without help from the IDE.) I think it's better than just a flat arguments list, because 1) it allows you to specify defaults and 2) it gives you the option of naming arguments by keyword. How can you do that with flat argument lists? My point is that the option of naming arguments is implicitly there any time you write a function, because variables have names; and there is no way to mistake a default value for a variable. So you might as well use these built-in distinctors. You could even do a little branching from within argument lists. Suppose for instance you had something like (dfnsk demo-branch [x 0 0 1 y 0 1 0] ) There can be only one default per variable, so what are the other values? These could only be possible passed-in values. x=0, y=1 is the first branch, x=1, y=0 is the second. Within the function body, you would have a predicate available that tells you what branch you are on, so for instance you could write something like (cond (branch? 1) ... (branch? 2) ...) or, if you passed in multiple function bodies after the argument list, (kind of like the variable arity thing), the first would be for the first branch, the second for the second, etc. Another 'generality' that could be added is to match arguments by type whenever there is a type annotation in the function definition and a discrepancy in the call; so for instance if you had a number of symbols that were supposed to be passed last, and you passed a symbol somewhere else, it would be applied to the first symbol-type argument in the function list without throwing an error. -- 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: A macro for flexible keyword argument handling
I should also add something I alluded to in another discussion (under 'positions'); this is the idea of making \any parameter into a rest parameter. For instance, if you had (defnsk add [addend augend] ...) you could call it like (add :addend 1 2 3 :augend 1 2) or (add [1 2 3] [1 2 3 4]). Must the poor programmer now check \all of his parameters to see if they have been magically turned into rest parameters without his knowing? Of course not! The function body is simply executed repeatedly, and the results put in a list: (add [1 2 3] [1 2 3 4]) - [2 4 6] If we were being \really permissive, we might want to return \two results, one the straightforward element-by-element adding, the other the 'cartesian' adding: [[2 4 6],[[2 3 4 5][3 4 5 6][4 5 6 7]]]. Or we might allow a flag passed to all functions :cartesian :sequential to turn this behavior on or off. If function writers want to explicitly manipulate these sequences, of course, that is fine; all I am saying is that if they do nothing, the function \caller gets his sequence code for free. To assist this way of programming, it might be a good idea to have another type of 'permissive' sequence abstraction, which you might call for old time's sake car and cdr: (car [1 2 3]) - 1 (cdr [1 2 3]) - [2 3] (car 1) - 1 (cdr 1) - nil A direct reference to a sequence as if it were a singular element, meanwhile, is an invitation to deal with the sequence at the level of the function caller as we do above (who if he passes elements as a sequence, presumably knows what he is doing). I guess this is getting to be a pretty epic macro! I figured it was worth inviting boos and/or cheers and suggestions before setting out... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: positions
If you think about it, the tower of sequence types is like this: seq | gathered seq /\ multiset permutation \ / set The way to do the various options I pointed out is to mix types: the keep-likes-with-likes would be (union permutation multiset). take-away-all would be (difference gathered-seq set), while take- away-some would be (difference gathered seq multiset). The problem is once you add seq on top, it gets a little defective, as Alex pointed out. (multiset seq) is easy, as is (permutation gathered-seq), but there's no unambiguous way of going from a seq to a permutation or to a gathered seq. The 'left' side of the tower is much happier than the right. It's also hard to sign an interpretation to all the combinations on the tower; for instance, what is the union of two permutations? This needs a little TLC from a category theorist... Nevertheless, this might be a good way of grouping functionalities into an API. The set API can be extended to all these types, and branch into additional combination operators as it moves up the tower (with really an infinite number for seqs). -- 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: positions
Thanks Sean, I'll do the exercise. I don't know how I missed it in seq-utils. After months of programming Clojure, I realize how much I still have to learn. (Knowledge is power; knowledge of lack of knowledge is power to power.) Nick. -- 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: positions
While we're on the topic, where is something like (subtract [1 2 3 3 4 4 5 6] evens) - (1 3 3 5)? Doesn't seem to be in seq-utils or API. Seems like there should be a parallel multiset library for colls, to clojure.set. (I guess there could be two versions of subtract, one that removes \all, and one that removes only as many as are in the subtracted set.) Maybe I will write this unless there is already some such out there. -- 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: positions
Yeah, remove will work for one kind of 'multiset' operator I am thinking of. The others might as well preserve as much order as possible. For instance, (add [1 2 3 4] [1 2 3 4]) could have two interpretations; you just append, or you add like elements to positions of like elements, so you get [1 1 2 2 3 3 4 4]. I guess you could specify that with a flag :append vs. :match. I'd also have a flag to choose eager evaluation vs. lazy (sometimes it's nice to preserve the collection type, and you don't need lazy evaluation for collections.). The native multiset type could be the map type you suggested, and that would be used to determine equality. -- 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
def a generated symbol?
How do you def a symbol that you make using (symbol)? I.E. if I try to do (def (symbol x) 2) I get: java.lang.Exception: Second argument to def must be a Symbol. (And why does it say the \second argument must be a symbol?) Thanks, Nick. -- 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: def a generated symbol?
I always wondered what intern was for; the answer was staring me in the face On Nov 17, 9:08 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: On Nov 17, 5:57 pm, John Harrop jharrop...@gmail.com wrote: How stable is the intern function likely to be? Quite stable, I think. It's a documented function in clojure.core, not a Java method. -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
Re: A macro for flexible keyword argument handling
Suppose one went for broke and made a variable binding form that was 1) Maximally permissive and 2) Notationally minimal Without saying whether this is \advisable, we might agree it would be an interesting exercise. It might look like this: \All arguments are potentially keywords; and since you can't bind a value to anything but a symbol, anything in the argument list that is not a symbol is interpreted as the default value of the preceding symbol. So if you wrote (dfnsk demo1 [x y 1 z u ~x] ..) it could be called either by (demo1 1 2 3 4) or something like (demo1 :z 3 :x 2). (If you left the arguments incomplete and unkeyworded it would apply what you put preferentially to the first arguments in the list without a default value. Thus (demo1 1) would specify x and (demo1 1 2) would specify x and z.) There needs to be another way of specifying defaults, because you may want to apply the same defaults to many different values. So at the end of the list, after any rest arguments, you could put any number of triplet vectors like [0 5 nil] or [p w 10]; where the last element is the default, and the first two are the range for the default to be applied to, specified either as a position or a variable name. When you mix keyword arguments and positional, there could be two potential interpretations. Consider (dfnsk demo2 [p q r s t u v w x y z [p z 0]] ...) If you called it like (demo2 :u 1 2 4 7), you could mean either 1) skip ahead in the list to u and fill the rest of the arguments from there or 2) 'consume' u from the list and then continue to call the list as ordered with a gap at u. So you would need an additional notation such as (demo2 :skip :u 1 2 4 7), but I'm not sure how to do that without potential name conflicts. Finally, you would have a set of predicates that tell you 1) how many arguments have been supplied and 2) whether a given argument has been supplied (as Constantine has done). You could make your defaults if expressions or cond expressions using these predicates (and whatever else you might want to pend on). You could say, if x has not been supplied, make y 2, etc. This could be an alternative (and I guess more general) way of notating variable arity argument lists. . I'm not trying to start an argument over whether this would be too complicated or tricky to use in practice (though this is a good argument to have too); my immediate question is, can it be any more general or minimal than this? Maybe there is some really neat way of encoding arbitrary preference rules and priorities in an argument list. It's not occurring to me though. In any case, the 'complication' is mostly an artifact of the way we program. If we move a little away from a pure program text and nothing-but while programming (as IDE's effectively do), we get all sorts of feedback and help on argument lists, so that it becomes in part like filling out a form when that helps; and hopefully this feedback ends up being not too intrusive or distracting. That, however, is a question for the \en\clojure list. -- 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: A macro for flexible keyword argument handling
(preceding message, re-formatted) Suppose one went for broke and made a variable binding form that was 1) Maximally permissive and 2) Notationally minimal Without saying whether this is \advisable, we might agree it would be an interesting exercise. It might look like this: \All arguments are potentially keywords; and since you can't bind a value to anything but a symbol, anything in the argument list that is not a symbol is interpreted as the default value of the preceding symbol. So if you wrote (dfnsk demo1 [x y 1 z u ~x] ..) it could be called either by (demo1 1 2 3 4) or something like (demo1 :z 3 :x 2) (If you left the arguments incomplete and unkeyworded it would apply what you put preferentially to the first arguments in the list without a default value. Thus (demo1 1) would specify x and (demo1 1 2) would specify x and z.) There needs to be another way of specifying defaults, because you may want to apply the same defaults to many different values. So at the end of the list, after any rest arguments, you could put any number of triplet vectors like [0 5 nil] or [p w 10]; where the last element is the default, and the first two are the range for the default to be applied to, specified either as a position or a variable name. When you mix keyword arguments and positional, there could be two potential interpretations. Consider (dfnsk demo2 [p q r s t u v w x y z [p z 0]] ...) If you called it like (demo2 :u 1 2 4 7) you could mean either 1) skip ahead in the list to u and fill the rest of the arguments from there or 2) 'consume' u from the list and then continue to call the list as ordered with a gap at u. So you would need an additional notation such as (demo2 :skip :u 1 2 4 7) but I'm not sure how to do that without potential name conflicts. Finally, you would have a set of predicates that tell you 1) how many arguments have been supplied and 2) whether a given argument has been supplied (as Constantine has done). You could make your defaults if expressions or cond expressions using these predicates (and whatever else you might want to pend on). You could say, if x has not been supplied, make y 2, etc. This could be an alternative (and I guess more general) way of notating variable arity argument lists. . I'm not trying to start an argument over whether this would be too complicated or tricky to use in practice (though this is a good argument to have too); my immediate question is, can it be any more general or minimal than this? Maybe there is some really neat way of encoding arbitrary preference rules and priorities in an argument list. It's not occurring to me though. In any case, the 'complication' is mostly an artifact of the way we program. If we move a little away from a pure program text and nothing-but while programming (as IDE's effectively do), we get all sorts of feedback and help on argument lists, so that it becomes in part like filling out a form when that helps; and hopefully this feedback ends up being not too intrusive or distracting. That, however, is a question for the \en\clojure list. -- 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 event handling
Thanks for posting these examples; I'd never thought of using multimethods that way. And thanks for the Swing example. I'm really interested in functional-reactive programming; hope we see lots of that stuff in Clojure. Anyone ever used FrTime in PLT? Here's the Swing events without the Swing. Didn't know you could override deref and invoke like that (import '(java.util.concurrent LinkedBlockingQueue) '(clojure.lang IDeref IFn)) (defn hydra returns a BlockingQueue, will return a new infinite lazy-seq wrapped in a delay evertime it is deref'ed. all items put in the LinkedBlockingQueue will be added to all the lazy-seqs producded by deref'ing [] (let [consumers (atom nil) producer (proxy [LinkedBlockingQueue IDeref IFn] [] (invoke [ x] (doseq [y x] (.put this y))) (deref [] (let [x (LinkedBlockingQueue.)] (swap! consumers conj x) (delay (repeatedly #(.take x))] (future (while true (let [x (.take producer)] (doseq [y @consumers] (.put y x) producer)) (def queue (hydra)) ;see it working (def results (atom nil)) (def show (fn [] (.start (Thread. (fn [] (doseq [i (force @queue)] ;derefing the lbq from hydra returns a delay wrapped lazy-seq (swap! results conj i))) -- 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 event handling
I'm curious what the best idiomatic way of handling events is (e.g. receiving a series of messages and dispatching functions on the basis of the messages). One could use the 'experimental' add-watch(er) functions. But it might also be nice to do something stream-oriented, e.g. a doseq on a stream of events. But the trouble is this dies as soon as the events stop arriving. Can event seqs be 'kept alive' somehow (preferably without blocking)? This seems like a pretty basic capability, so I figured it was worth provoking discussion about. Nick. -- 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 parser
Is there any way to access the clojure parser, i.e. something that gives you all the elements contained in an expression? I.E. (parse (+ 1 2)) would give you something like [:list [[:symbol +] [:literal 1] [:literal 2]]]. Thanks, Nick. --~--~-~--~~~---~--~~ 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 parser
Thanks, that's exactly what I was looking for. I didn't realize you could use read like that. --~--~-~--~~~---~--~~ 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: typed structs?
Chouser---
Hmm, what to do in the meantime. What I was trying to do was write
a package that would take care of indexing fields, adding
backreferences, and creating 'plural' fields. For instance, suppose
you had people and accounts. People have names, incomes and (human)
parents; accounts have balances and signers:
(person :name :income [:parents])
(account :balance [:signers])
(By boxing a field I'm declaring it plural, meaning that assoc adds to
rather than replaces; I already wrote the macro for this, but not much
else yet.)
The package would add another field of backreferences, so that we'd
have for instance
{:name chuck jr., :income 20k, :parents [ref to charles
sr.] :backreferences [{:parents ref to charlie III}]}
{:name charles sr. :income 80k...}
{:name charlie III..}
We'd also have indices (sorted-maps) to all the names, incomes, and
balances, so you can see why we need types.
I thought it would be good to have this facility once and for all
rather than ad-hoc, but can you see any problems with it? Maybe I
should just be using SQL?
---Nick
--~--~-~--~~~---~--~~
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: data structures for efficient range queries
Sounds like the tree is what I need (since the data will be changing quite a bit). As for using a hash-map: wouldn't you need a sorted map to be able to pull out all the keys in a range? And then are the seq functions efficient for this? (I.E. if you drop a number of them to get to the beginning of the range, is the drop O(1) or O(n)?) Thanks for your help! --~--~-~--~~~---~--~~ 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: data structures for efficient range queries
Thanks for the advice, everyone! Timothy, I guess if you had non- uniqueness but didn't care to have it indexed in more than one way you could just take Alex's example and have his maps point to vectors, right? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
typed structs?
I'm trying to develop a library for structs (hopefully will be generally useful), with an API parallel to the struct API. One of the capabilities I would like to have is \typed \structs, i.e., if you attempt to assoc something of the wrong type to a field, it throws an error. (I can't find anything like this in Clojure now; type annotations would not be appropriate, right?). Any suggestions on syntax/functionality? I was going to do something like this: a struct field declaration is a vector, with the first element containing a type prototype, e.g. (typed-defstruct test-struct [1 :a] [asdf :b] [:blank :c]), showing that field :a is an int, :b is a string, :c is a keyword. On the other hand maybe one should just declare the type, so that you could specify something in the numerical tower (e.g. Number as opposed to Int). Thoughts? Thanks, Nick. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
data structures for efficient range queries
I need to make a data structure for a query such as find everything that is priced $3.27 - $6.12 (and perhaps sum up the total revenue for all items in that price range). The naive way would be to make an array with one slot for each increment in the entire range, and have each slot pointing to a bucket with all items at that increment (here, price). But this would not be terribly efficient or feasible over very large ranges (imagine you wanted to query both large and small ranges: think of distances on a galactic, planetary, continental, city, human, etc. scale. Do you make multiple indices for coarse- grained and small-grained queries? Do you have coarse-grained slots pointing to smaller ranges, and so on ad infinitum? But that would seem to make evaluating large ranges very inefficient). Is there a cleverer/Clojurisher way to do it? The price example is what I'm doing, so I don't really need a galactiscalable data structure Thanks- Nick --~--~-~--~~~---~--~~ 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: a denilling macro
Gentlemen--- Thanks for fixing my newbish error and showing me a better way to do it! Nick. --~--~-~--~~~---~--~~ 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 denilling macro
I've been learning Clojure. I just wrote a macro to be used like so: (i-let [x nil 4 y 2 6 z nil 10] (+ x y z)) = 16 I.E. if the first value in the triple is nil, bind it to the second value in the triple. This is useful when you want to let something that might be nil and has a sensible default. (In practice I only see the need to do this \once, but I wrote it for multiple bindings for generality. And yes, I'm too lazy to type an if statement every time.) Here's the code: (defmacro i-let [bindings body] (assert-args i-let (vector? bindings) a vector for its bindings (= 0 (mod (count bindings) 3)) forms by three in binding vector) (if (empty? bindings) `(let ~bindings ~body) (let [nom (bindings 0) attempted-val (bindings 1) nil-val (bindings 2)] (if (nil? attempted-val) `(let [~nom ~nil-val] (i-let ~(vec (drop 3 bindings)) ~body)) `(let [~nom ~attempted-val] (i-let ~(vec (drop 3 bindings)) ~body)) Note that I've stolen the private code for assert-argswhy, by the way, is this private? Anyway I'd appreciate any critiques of the implementation; whether it's a useful thing or not; if there are more idiomatic ways of doing the same thing; and, if yes-no to the aforetwo, where's the best place to add this functionality? I've really been enjoying this language (I come from a Scheme background). One stumbling block for me is the seq functions. I'd really like versions of them that preserve the underlying type (so that, for instance, in the above macro I could just write (drop 3 bindings) instead of (vec (drop 3 bindings)). What is the reason for them only returning a common type? Thanks, Nick Chubrich. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
