question on clojure library coding standards
The standards doc on the wiki here: http://www.assembla.com/wiki/show/clojure/Clojure_Library_Coding_Standards Makes this recommendation: Idiomatic code uses destructuring a lot. However, you should only destructure in the arg list if you want to communicate the substructure as part of the caller contract. Otherwise, destructure in a first-line let. Example: my snake code from the book fails this test, doing too much destructuring in arg lists. I'm not entirely sure how to interpret this. If a function is expecting a certain argument structure, isn't it always better to document that in a destructuring argument list? I'm finding that destructured signatures generally help me track my dataflow better. Can somebody elucidate this distinction a bit? -- 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: slow raw io
On Aug 7, 5:43 am, Peter Schuller peter.schul...@infidyne.com wrote: Interesting. Why do you consider it recommended to read one character at a time in a case like this? Maybe there is such a recommendation that I don't know about, but in general I would consider it contrary to expected practice when doing I/O if performance is a concern. That's not a practice I'm familiar with either. Everything I've ever read on I/O tuning suggests that reading single char is worst-case performance, which seems borne out here. Maybe this seems like a low-priority issue but I think slurp is likely to be very commonly used. For instance, the Riak tutorial just posted to Hacker News uses it: http://mmcgrana.github.com/2010/08/riak-clojure.html -- miles -- 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: slow raw io
Any chance of getting this in before 1.2? On Jun 25, 7:43 am, cageface milese...@gmail.com wrote: Thanks Stuart Peter for following up on this. Now I can get back to plowing through this mountain of ldiff data with Clojure! -- 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's n00b attraction problem
On Jun 29, 8:17 pm, Michael Richter ttmrich...@gmail.com wrote: A good salesman also doesn't come across as smugly self-satisfied and projecting a sense of superiority. I did a moderate amount of CL hacking in 2003-4 and I've been dipping my toes back in lately with Clojure but I hardly count as a lisp weenie. I say Lisp and FP are hard not because I have mastered them but because I am still learning and *I* have found them hard. From what I've observed in other programmers I'm far from alone in this. Honestly I think it's noobs like me that are going to make the most difference in the near-term success of Clojure. We're the experienced Python and Java and Ruby programmers in Chas' survey that are looking for a better way to solve the problems we face in our work. We recognize that languages like Clojure might be the answer, but also that they require a new, different, and initially painful way of thinking. We're motivated enough to get over hurdles like classpaths, java installs, IDEs etc. and those of us that do have the determination and ability to stick with it will be the ones that build the killer app that puts Clojure in the spotlight. The reality is that a lot of us are going to fall by the wayside. I was comfortable in Ruby after a few weekends. I still struggle with FP Lisp after 10 years of study. If you're one of those people to whom s-expr syntax, recursion, immutability etc seem simple natural and logical congratulate yourself but also show some humility. You're the exception, not the norm. So, what do noobs like me need from Clojure? Honestly not much. The tools are there to get real work done and because of Clojure I'm more optimistic about Lisp than I've ever been. More extensive documentation, a single blessed build tool, some tutorials on protocols etc would all be welcome but the lack of these things isn't stopping anybody that wouldn't have been stopped anyway. -- 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's n00b attraction problem
On Jun 30, 10:17 am, Sean Allen s...@monkeysnatchbanana.com wrote: The larger the clojure community gets, the more you should be prepared for those dogs then. To put it more bluntly - the day that clojure no longer interoperates smoothly with java is the day it becomes useless to me. I'm all for hiding the guts from beginners but it's going to be a good long while before you can actually get anything done with clojure without directly interfacing with java. For example, I'm using clojure for two things at work: replicating data between a sybase and oracle DB and syncing data from ldap to an xml-rpc client and a proprietary calendaring solution with it's own java api. I can defend my use of clojure here because it's actually better than python at this - faster and with more mature drivers and able to invoke java apis directly. My code is full of direct calls to various java methods, invocations of java constructors etc. Without clojure's excellent java support it would be off the table as an option for this project and without decent knowledge of java I wouldn't be able to use it. I suspect most of the non-trival tasks for which other people are using clojure rely on a number of java libraries for which no clojure wrapper exists and I don't think is likely to change soon or even that we *should* wrap everything. I don't know what the implementation plans are exactly for clojure-in- clojure but abandoning the JVM would be extremely unwise. -- 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: Let's respect CLOJURE_HOME
My clj file looks like this: #!/bin/sh export CLASSPATH=$CLOJUREPATH:./lib/*:.:$CLASSPATH if [ -z $1 ]; then exec java -server jline.ConsoleRunner clojure.main else SCRIPT=$(dirname $1) export CLASSPATH=$SCRIPT/*:$SCRIPT:$CLASSPATH exec java -server clojure.main $1 $@ fi Having clj look in the current directory for jars/classes/.clj files the same way Python and Ruby do makes dealing with libraries easier. So, +1. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure's n00b attraction problem
On Jun 30, 5:15 pm, Chas Emerick cemer...@snowtide.com wrote: An oldie-but-goodie post from Chouser talking about what clojure-in- clojure is and why it matters: http://blog.n01se.net/?p=41 To quote: But a more fascinating benefit is that porting Clojure to non-JVM targets will be much easier. The majority of the effort so far put into ClojureCLR and ClojureScript has been rewriting the data structures for the target platform. This has required a lot of hand- written C# and JavaScript (respectively) all of which can become quickly obsolete as changes are made to the primary Java versions. ... stuff about running on Parrot etc... Presumably over time we'll have more pure clojure-layers over the ugly java libs. Having to maintain a port version of each of these wrappers for C# and JS and any other target sounds like a lot of unpleasant grunt work to me. I've been working on wrapping the JNDI stuff up in a less retarded interface, for example, but I'm definitely not going to take the time to port it to C# and JS is obviously out so that's at least one tiny step towards a fractured clojure world. I sure don't have fond memories of dropping #+sbcl and #+cmu and # +allegro readers all over my CL code to make all the different CL implementations happy and I don't anticipate much joy in a similarly balkanized clojure world. A clojure written mostly in clojure but still exclusively a jvm lang makes sense but the rest of this just sounds like idle hackery for its own sake. Far be it from me to condemn consenting adults for the ways they choose to spend their spare time though. -- 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's n00b attraction problem
On Jun 29, 1:22 pm, Chas Emerick cemer...@snowtide.com wrote: Any talk about how Clojure might be too much for some, for whatever reason, is out of bounds IMO. Clojure, as a language, is *simpler* than just about all of the popular alternatives out there, and the language is eminently approachable and practical for programmers from varying domains and with varying levels of experience. It just isn't. Recursion, s-expr syntax, non-mutability, macros and the difference between compilation and evaluation etc etc are just *harder* for most people to understand than simple infix imperative code. Even MIT has thrown in the towel in this battle and switched to Python for the SICP courses. I remember having discussions with Peter Siebel about this while he was working on his Lisp book. Like a lot of Lisp lovers, he seemed to think that making Lisp popular was just a matter of making people see how eminently logical and simple and practical it is. It's not that easy. Look at the results of your own usage poll. The top languages people would use if Clojure were unavailable to them are: 1. scala 2. common lisp 3. haskell 4. scheme These people just *aren't* the median. To insist otherwise is to live in denial. -- 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's n00b attraction problem
On Jun 29, 12:54 pm, Chas Emerick cemer...@snowtide.com wrote: Indeed, there are many nontrivial personas that actively wish for a smaller (or at least not maximally large), more exclusive community. Only a fool would actively wish for a smaller community. Some of just recognize that selling a sports car to grandma might not be in her or our best interests. Make Clojure as easy as possible for the beginner as long as you don't make it less useful for the expert in the process. -- 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's n00b attraction problem
On Jun 29, 7:24 pm, Chas Emerick cemer...@snowtide.com wrote: More talking up the complexity of Clojure, to its detriment. Stop it. Familiarity is not a metric that anyone is aiming at, least of all the language principals -- capability in various axes is, and that's what's attracting people from all sides. A language advocate is a salesman. A good salesman knows his product and his audience. Many here seem to have some extremely naive ideas about this. Push Clojure as a Python/Ruby/blub replacement and you'll get a inbox full of this kind of thing: http://www.benrady.com/2010/06/a-bit-of-heresy-functional-languages-are-overrated.html This *is* mostly tangential to the OP though. I don't think anybody is arguing that there's anything wrong with making the initial user experience as pain-free and rewarding as possible. Questions about the scope of Clojure's audience will be answered in 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: Clojure's n00b attraction problem
On Jun 29, 6:25 pm, Michael Richter ttmrich...@gmail.com wrote: Are you *trying* to evoke the Smug Lisp Weenie vibe, cageface, or is this just a natural byproduct of being a burgeoning Smug Clojure Weenie? How many times do I have to say I'm in favor of making things as easy as possible for beginners before I'm exempt from this charge? How many decades does Lisp have to spend on the sidelines before Lispers admit that maybe, just maybe, it's not for everybody? Tying the fortunes of Clojure to Java was a brilliant move and one that I've advocated for years but the trend I've seen lately to try to paper over the Java underpinnings of the language worries me, as does talk of making Clojure-in-Clojure. There's a small but viable market for people doing difficult things in a Java-flavored Lisp (Runa, Flightcaster, BackType etc), but this is where the future of Clojure lies - as a power tool for heavy lifting on the Java platform. -- 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's n00b attraction problem
Let's rephrase this slightly. I completely agree with the spirit of this article: http://programmingzen.com/2008/10/26/what-arc-should-learn-from-ruby/ i.e. - That the tipping point for any language into wide use occurs when it makes it significantly easier to solve a common, but painful problem. For Ruby this was clearly Rails and webapps. What do you think this might be for Clojure? In what application domain(s) will the benefits outweigh the downsides of a new language? What kinds of people will be working in those domains? -- 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: the joys of lisp
I haven't done any Erlang coding but I have heard various complaints in blogs etc that Erlang isn't great for string handling. Is that what you mean? Is Erlang a good or bad example of this? On Jun 27, 1:11 pm, Timothy Baldridge tbaldri...@gmail.com wrote: 1. a string/text type *cough * Erlang *cough * Tim -- 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: the joys of lisp
On Jun 28, 11:09 am, Daniel Gagnon redalas...@gmail.com wrote: That feature would *not* be a simple macro. It isn't simply a call to .close on whatever object, it's an arbitrary cleanup procedure on any object that implements the feature. The whole standard library implements it and objects know how to clean after themselves. So do most third objects like database connexions and what not. So in order to make this work in Python the *entire* standard library had to be modified to support it? That's worse than I thought. It's an interesting point though. In a certain sense, a macro is establishing an interface across a set of objects. In writing a macro you are implying that there exists a set of objects for which the macro's transformation is logical. The python with statement required implementation of the implied interface across all valid arguments, whereas the macro version takes advantage of the fact that most of the applicable objects just happen to have a .close method. In both cases you're dealing with with-able objects. The difference is that the interface that objects can expose to macros is much richer because arbitrary syntactic fragments are objects in this sense. The python approach is superior if you believe, as Guido apparently does, that the useful set of syntactic constructs is small and well- bounded. If you think, as most lispers do, that syntactic manipulation is the essence of expressive power then the work it takes to add *one* new keyword to a language like python seems farcical. -- 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's n00b attraction problem
As I said in the HN thread, I think you're right that getting started with a productive clojure environment is harder than it has to be. However, as I also said in the thread, I think the *real* obstacles for a noobie are the concepts in the language itself. Clojure is very elegantly designed, but it builds on some very powerful and somewhat difficult concepts. Stuart's book is a big help here but I'm afraid that Clojure is simply over the heads of a lot of noobs anyway. So I wonder how much making the first few baby steps easier is really going to help the uptake of Clojure. I have to imagine that the kind of person that can't figure out a CLASSPATH is going to have his head explode when he has to figure out how to restructure all his iterations in terms of loop/recur. -- 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: the joys of lisp
On Jun 28, 12:04 pm, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: The Python approach leads to more readable code:http://www.mired.org/home/mwm/papers/readability.html You don't seem to be very sympathetic to the Lisp way of doing things. What's your interest in Clojure? -- 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's n00b attraction problem
On Jun 28, 12:25 pm, Daniel Gagnon redalas...@gmail.com wrote: I believe that the success of ruby is due in great part to *Why's Poignant Guide to Ruby* and *Learn You a Haskell* is doing the same for Haskell. It's fun to read, it holds your hand in setting up everything you have to and it makes you want to learn more. I'm not so sure. Certainly things like the poignant guide made getting started with Ruby easier, but I'd argue that the success of Ruby has a lot more to do with how simple the core language it is and how easy it makes it to get simple things done. Conversely, despite increasingly beginner-friendly docs and one-shot installers I don't get the impression there's a bit upsurge of interest in Haskell outside of circles of elites or language afficionados. Haskell just isn't the kind of language that lets you slap a couple of web forms on a database 30 minutes after getting started. It's a power language for power users, like Clojure. I've been following FP for about ten years now and in that time I've seen Ruby and Python grow like gangbusters while languages like Haskell make very small, incremental inroads into niche areas. I don't expect this to change. Again though, I'm all for making the beginner's experience no harder than it absolutely has to be. No point having people turned away by things extrinsic to the language. I often find myself frustrated browsing through the docs that there aren't concrete examples for most of the functions in the API. I always have to google their usage or find an example in the clojure code. I'd be happy to help flesh out the docs with some usage examples if this kind of help is wanted. -- 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: the joys of lisp
On Jun 28, 1:10 pm, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: Not true as I understand the Lisp way. You also need to reread the last paragraph again. I actually agree with you that the typical block of lisp code is less readable than the typical block of python. It bugs me when lisp advocates present s-expr syntax as the right way instead of the engineering tradeoff that it is. You forgo the niceties of a more ergonomic, less primitive syntax in exchange for unparalleled syntactic flexibility and corresponding power it brings. To me this *is* the Lisp way - building up the language to your problem by defining new constructs that other languages have to implement from scratch. The difference between clojure's with-open and python's with illustrates this pretty clearly, the Java legacy that makes with-open a 95% solution notwithstanding. What does the Lisp way mean to you? Lately, it seems like the JVM integration comes with more problems than it solves, and makes me wonder about building Clojure with gjc. The JVM does create some problems for clojure but I'm pretty sure we wouldn't be having this conversation at all if it weren't for clojure's java interop. It's a devil's bargain but it's also the main reason I see more momentum behind clojure now than I've seen behind any lisp in 10 years of dilettante-ish lisping. -- 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's n00b attraction problem
On Jun 28, 2:26 pm, Brian Hurt bhur...@gmail.com wrote: I'd argue that it's a bad idea to teach students a professionals language as their first language. You don't learn to fly in a 747, even if that's what the professionals fly. There are reasons for this. I have to agree with this. I wouldn't dream of giving somebody Clojure as a first language. If I really wanted to teach an s-expr language as a first language I'd use one of the nice integrated scheme environments. I don't think the goals of making Clojure a little easier to start with and keeping it a professional language are necessarily totally at odds but efforts to build something like Processing or even DrScheme on it seem misdirected. -- 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's n00b attraction problem
On Jun 28, 2:44 pm, Daniel Gagnon redalas...@gmail.com wrote: 1. you don't have to worry about PYTHONPATH for a while with a standard install, although the day will come No, you never have to.It's taken care of by virtualenv. Maybe it's just me but I think virtualenv is far more intimidating than getting a basic clojure install going: http://pypi.python.org/pypi/virtualenv If I were a python noob how would I even know it exists, nevermind what problems it solves or what easy_install is or how I get *that* working? Even if you don't find those to be obstacles you will sooner or latter have to grapple with the idea that languages bundle code in files and those files exist in directories and that an interpreter/ compiler has to be told in which directories and in what order to look for those files. What makes languages like Python easy to start with is that they either come in the form of one-click executables or they're already installed on the system with a decent set of libraries. If people had to bootstrap their own install you'd find confusion similar to what some clojure beginners complain of. -- 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
usage examples in clojure api docs
Several people have suggested that usage examples in the docs would be helpful and this is something I often find myself wishing for. Are patches introducing examples welcomed by the core team? -- 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's n00b attraction problem
On Jun 28, 9:14 pm, Michael Richter ttmrich...@gmail.com wrote: Ah. The Clojure community has already started down the road to Common Lisp-style, smugness-generated obscurity and disdain. Bravo! Well-played! Not at all. Nothing would make me happier than Clojure for Dummies and Wrox Professional Clojure books on the shelves of every Barnes Noble programming section. It's pained me to watch Python and Ruby far outpace the growth of any functional language in the last ten years. I'd love to stop looking for excuses to sneak things like Clojure under the radar at work and actually have a management mandate to use them. The fact remains though that Clojure trades in heavy concepts. The syntax alone will simply be a non-starter for at least half the potential audience. Toss in concurrency and non-mutability and ubiquitous recursion which are tricky concepts no matter how cleanly exposed in the language. As many posters have said in this thread, you really do have to have a decent grasp on Java to do real work in Clojure so you're already on the hook for two languages, one of which is a baroque and provincial monster. Like any engineering problem, language design is about tradeoffs. Obviously Rich has worked hard to make Clojure as approachable as possible but you can't simultaneously emphasize tackling the really hard problems in software engineering and making CRUDDY webapps as painless as possible for the average programmer. Believe that Lisp, perhaps this time in the guise of Clojure, will conquer the world some day if you wish. There was a time when I wanted to think so too. As it is, I'd be happy if Clojure becomes acceptable enough for hard problem work that I'm not forced to use a soft fuzzy tool like Java or Python instead. -- 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's n00b attraction problem
On Jun 28, 9:39 pm, Brent Millare brent.mill...@gmail.com wrote: While I agree his wording wasn't really the best, I think it can also be interpreted differently depending on what kind of n00b he is talking about. For the record, noob was not my choice of terms. Like any other profession, programming attracts people with a wide range of ability. Education makes a difference, but, for whatever reason, some people just seem to have more of a knack for it than others. In this sense you can be a pro at 20 or a noob at 60. A lot of programmers are going to work through a Clojure tutorial or two and run with the headache it gives them back to Python and the many tasks for which something like that is perfectly adequate. Common Lisp is not a niche language today because it presents a poor beginner experience. Good, turnkey IDEs and documentation have been available for years. The problem is that actually getting anything done with Common Lisp is a nightmare. Libraries are sparse and incompatible among implementations. Crucial things like FFI and concurrency are non-standard. Interfacing with the rest of the world is tedious. The reason there's so much buzz about Clojure and Scala right now is that you can actually get real work done in them. Drop them on top of an existing java system and you've got everything you need to solve real problems, with a much nicer language than Java. I'm optimistic about Clojure because it allows *good* programmers to jump over the walls that stop you in other lisps. Again, I'm all for making Clojure as beginner-friendly as possible. But I think that the success of Clojure in the long run will depend a lot more on making sure that the minority that actually have the skill to absorb and work in its paradigms derive a real competitive advantage from it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
the joys of lisp
When I read about new features in other languages that would be simple macros in Lisp I just have to smile: http://docs.python.org/dev/reference/compound_stmts.html#with -- 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: the joys of lisp
Python definitely seems to be the product of a very different design philosophy than Lisp. I've always felt it was too prescriptive. Omitting features that *might* be misused in an effort to keep the language simple seems to have backfired on them. Too keep up with the competition they've had to add so many new features to the core language (list comprehensions, annotations, iterators, with statement, properties etc) that Python doesn't feel like a small, simple language to me at all anymore. Anyway, I don't mean to pick on Python because it's not a bad language. I think this just illustrates that it's better to build from a simple, flexible core than to bolt on pieces later. I think you can go too far in the other direction too though. Certainly Scheme is a very elegant language but omits so much from the spec that you have dozens of incompatible OO implementations floating around. I think at a minimum a language should provide a single, consistent, standard implementation of the following: 1. a string/text type 2. an abstract datatype/object model 3. container types 4. concurrency primitives 5. ffi Clojure covers these points well, I think, and I'm not worried about Clojure fracturing into a babel of incompatible macro-based dialects. -- 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: the joys of lisp
On Jun 27, 1:17 pm, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: Not quite - it's to keep the language *readable*. And if there's a use case for a feature that outweighs the damage done by abusing it, they'll add it. Witness with, list comprehensions, and those never-to-sufficiently-cursed augmented assignment operators. This implies simple only to the extent that it shouldn't get so large that one person can't keep the entire language in their head. Python passed that point for me a long time ago. I'm always referring to the docs. But that's true of most of the languages I work with now. So how does providing a drill press and bolt set (i.e. - macros) to the end user fit into this? Certainly macros can be dangerous if used recklessly or clumsily, but isn't trusting the programmer and giving him powerful tools what Lisp is all about? No other language provides the same power of expression. A tour through the Clojure code demonstrates just how powerful this idea is and how easy it makes it for the language implementors to implement features in a few lines of code that are major bullet-point features in other languages. Well, there are already multiple OO implementations on top of 1.1. Most of them are more to show that you can do that if you really want to, and I'm not sure how much the additions to 1.2 will obsolete them. I have to admit it's not entirely clear to me how to reconcile java objects, tagged hashes, and protocols as alternative OO models in Clojure It's probably just a lack of effort on my part in reading the source and docs but I can't say that the ADT/OO story in Clojure is as simple as the Python/Ruby approach, at least from the point of view of the beginner. -- 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: slow raw io
Thanks Stuart Peter for following up on this. Now I can get back to plowing through this mountain of ldiff data with Clojure! -- 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: slow raw io
Has anyone else had a chance to try this? I'm surprised to see manual buffering behaving so much better than the BufferedReader implementation but it does seem to make quite a difference. -- 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: slow raw io
I put a self-contained test up here: http://gist.github.com/452095 To run it copy this to slurptest.clj and run these commands java clojure.main slurptest.clj makewords 100 (100 seems good for macs, 300 for linux) java -Xmx3G -Xms3G clojure.main slurptest.clj slurp| slurp2 Trying either slurp or slurp2. I see big timing differences on both macs and linux machines but it would be interesting to see if other people do too. -- 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
slow raw io
Not sure if this is a clojure issue or a something else but I'm seeing
surprisingly slow I/O on large text files.
For example, on a unix machine try this:
1. create a large file
rm -f words; for x in $(seq 300); do cat /usr/share/dict/words
words; done
2. create a clj file that just slurps it
#!/usr/bin/env clj
(slurp *in*)
3. time the slurp
cat words | cat.clj
On my machine this takes 17 seconds.
If I make a simple java program:
import java.io.BufferedReader;
import java.io.InputStreamReader;
public class Cat {
public static void main(String[] args) throws Exception {
BufferedReader reader;
reader = new BufferedReader(new InputStreamReader(System.in));
StringBuffer fileData = new StringBuffer();
char[] buffer = new char[4096];
int numRead = 0;
while ((numRead = reader.read(buffer)) != -1) {
fileData.append(buffer, 0, numRead);
}
reader.close();
}
}
and try this:
cat words | java -Xmx3G Cat
It only takes 2.3 seconds.
I thought this might have to do with the -Xmx max heap flag but I
added this to the java invocation in my clj wrapper script and it
didn't seem to make any difference. Line-oriented I/O seems similarly
slow.
--
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: slow raw io
For the record, this program runs in 3.3 seconds so I guess that points to the implementation of slurp: (import '[java.io BufferedReader InputStreamReader]) (let [reader (BufferedReader. (InputStreamReader. System/in)) file-data (StringBuffer.) buffer (char-array 4096)] (loop [total 0] (let [num-read (.read reader buffer)] (if (not= -1 num-read) (do (.append file-data buffer 0 num-read) (recur (+ total num-read))) (println total) -- 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: slow raw io
Sure. Here's my clj script: #!/bin/sh if [ -z $1 ]; then exec java -server jline.ConsoleRunner clojure.main else SCRIPT=$(dirname $1) export CLASSPATH=$SCRIPT/*:$SCRIPT:$CLASSPATH exec java -Xmx3G -server clojure.main $1 $@ fi (Usually I don't have the -Xmx flag there. I added it for this test) I'm using a fresh build of clojure and clojure-contrib from the github 1.2.0-MASTER branch. If I try to run it with the 1.1.0 jars I get this error: Exception in thread main java.lang.ClassCastException: clojure.lang.LineNumberingPushbackReader cannot be cast to java.lang.String (cat.clj:0) at clojure.lang.Compiler.eval(Compiler.java:4658) at clojure.lang.Compiler.load(Compiler.java:4972) at clojure.lang.Compiler.loadFile(Compiler.java:4939) at clojure.main$load_script__7405.invoke(main.clj:213) at clojure.main$script_opt__7442.invoke(main.clj:265) at clojure.main$main__7466.doInvoke(main.clj:346) at clojure.lang.RestFn.invoke(RestFn.java:426) at clojure.lang.Var.invoke(Var.java:363) at clojure.lang.AFn.applyToHelper(AFn.java:175) at clojure.lang.Var.applyTo(Var.java:476) at clojure.main.main(main.java:37) How big is your words file? 100 copies of /usr/share/dict/words on this machine is 267 megabyes. On Jun 23, 6:20 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: I am seeing more like 1.8 seconds for the raw version, vs. 2.8 seconds for slurp (master branch). Can you post a complete example (including the clj script you use, and what version of Clojure), so we can be apples-to-apples? -- 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: slow raw io
Another example. I'm running this on a Ubuntu 10.04 laptop with this
java:
java version 1.6.0_18
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
and this command line:
java -Xmx3G -server clojure.main cat2.clj
(require '[clojure.java.io :as jio])
(defn- normalize-slurp-opts
[opts]
(if (string? (first opts))
(do
(println WARNING: (slurp f enc) is deprecated, use (slurp
f :encoding enc).)
[:encoding (first opts)])
opts))
(defn slurp2
Reads the file named by f using the encoding enc into a
string
and returns it.
{:added 1.0}
([f opts]
(let [opts (normalize-slurp-opts opts)
data (StringBuffer.)
buffer (char-array 4096)]
(with-open [#^java.io.Reader r (apply jio/reader f opts)]
(loop [c (.read r buffer)]
(if (neg? c)
(str data)
(do
(.append data buffer 0 c)
(recur (.read r buffer)
(time
(with-open [f (java.io.FileReader. words)]
(println (count (slurp f)
(time
(with-open [f (java.io.FileReader. words)]
(println (count (slurp2 f)
I get this output:
$ java -Xmx3G -server clojure.main cat2.clj
279440100
Elapsed time: 17094.007487 msecs
279440100
Elapsed time: 5233.097287 msecs
So at least in my environment there seems to be a big difference
between slurp2 with an explicit buffer and the core/slurp one, which
appears to be reading a character at a time from a BufferedReader
stream.
--
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.xml/parse cannot handle filenames containing #
It looks like it's having trouble figuring out if test#1.log is a file path or a URI. Not sure what a real solution is but this seems to work as a workaround: (clojure.xml/parse (java.io.File. test#1.log)) On Jun 23, 12:30 pm, Zak Wilson zak.wil...@gmail.com wrote: (clojure.xml/parse test1.log) works correctly, output omitted (clojure.xml/parse test#1.log) Premature end of file. [Thrown class org.xml.sax.SAXParseException] $ mv test\#1.log test2.log (clojure.xml/parse test2.log) works correctly, output omitted test#1.log is a copy of test1.log Confirmed on Linux and Mac OS -- 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: slow raw io
Interesting. Here are the times I get:
LINUX:
slurp, *in* 18.8 seconds
slurp, System/in 18.2 seconds
slurp2, *in* 6.7 seconds
slurp2, System/in 5.7 seconds
I have an intel iMac here too, running 10.6.4:
slurp, *in* 20.4 seconds
slurp, System.in 19.0 seconds
slurp2, *in* 7.2 seconds
slurp2, System/in 6.0 seconds
For another data point, I wrote a simple java version:
import java.io.BufferedReader;
import java.io.InputStreamReader;
public class Cat {
public static void main(String[] args) throws Exception {
BufferedReader reader;
reader = new BufferedReader(new InputStreamReader(System.in));
StringBuilder fileData = new StringBuilder();
char[] buffer = new char[4096];
int numRead = 0;
long totalRead = 0;
int c;
if (args[0].equals(single)) {
// single-char
read
while ((c = reader.read()) != -1) {
totalRead++;
fileData.append((char)c);
}
}
else {
// buffered
read
while ((numRead = reader.read(buffer)) != -1) {
totalRead += numRead;
fileData.append(buffer, 0, numRead);
}
System.out.println(totalRead);
}
}
}
Runnning this like so:
$ javac Cat.java cat words | time java -Xmx3G -cp . Cat single
gives 14.5 seconds on linux and 17.1 seconds on the mac
running it like this:
$ javac Cat.java cat words | time java -Xmx3G -cp . Cat buffered
gives 2.5 seconds on linux and 5.4 seconds on the mac
I'm not sure it's totally analogous but it does seem to indicate that
the single-char reads are slower on both platforms.
--
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
cond formatting
Picky syntax question: In common lisp cond requires more parenthesization than clojure: (cond ((evenp a) a);if a is even return a (( a 7) (/ a 2));else if a is bigger than 7 return a/2 (( a 5) (- a 1));else if a is smaller than 5 return a-1 (t 17)) vs clojure: (cond (even? a) a ;if a is even return a ( a 7) (/ a 2) ;else if a is bigger than 7 return a/2 ( a 5) (- a 1) ;else if a is smaller than 5 return a-1 t 17) Of course, fewer parentheses are usually better, but I'm finding cond in the second form a little harder to read with more complex clauses: (defn compare-row [a b] ;; compare null rows as to advance cursor (cond (and (nil? a) (nil? b)) [0,0] (and (nil? a) (not= b nil)) [1, 0] (and (not= a nil) (nil? b)) [-1, 0] true (loop [col 0 a a b b] (let [cmp (compare-fields (first a) (first b))] (if (and ( col (count a)) (= cmp 0)) (recur (+ 1 col) (rest a) (rest b)) [cmp,col]) In this case it takes some visual parsing to see what the predicates and results are and if you break them up onto individual lines you have to count evens to figure out what the results are. The extra level of indentation in the CL case makes it a lot easier. The only easy solution I've considered for this is to add an extra blank line between each clause, but this looks weird. Any thoughts on this or other approaches? -- 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: cond formatting
This is fine when you just have simple clauses like this, but what if the clauses are more complex, even containing subclauses? A quick scan through clojure contrib suggest that people are inserting blank lines between clauses when they get more complex. I guess this is idiomatic for clojure? On Jun 22, 1:41 pm, David Nolen dnolen.li...@gmail.com wrote: I like lining things up. -- 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: cond formatting
This looks nice but requires more hand-indenting, right? I really like being able to select a block in emacs and hit indent-region and get predictably tidy code. (The failure of emacs to do this 100% with scala code is a pet peeve). On Jun 22, 1:50 pm, Michael Gardner gardne...@gmail.com wrote: Try this: (defn compare-row [a b] ;; compare null rows as to advance cursor (cond (and (nil? a) (nil? b)) [0,0] (and (nil? a) (not= b nil)) [1, 0] (and (not= a nil) (nil? b)) [-1, 0] true (loop [col 0 a a b b] (let [cmp (compare-fields (first a) (first b))] (if (and ( col (count a)) (= cmp 0)) (recur (+ 1 col) (rest a) (rest b)) [cmp,col]) -- 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: cond formatting
I think I'm going to take this route. The style seems pretty common in clojure contrib and it's readable, if a bit odd at first. On Jun 22, 2:20 pm, David Powell djpow...@djpowell.net wrote: I tend to write the condition and action on separate lines, and put a blank comment in between each, like this: -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Enhanced Primitive Support
Maybe it's only because I'm coming from Ruby, in which number promotion is automatic and everything is slow, but if I have to choose between correctness and performance as a *default*, I'll choose correctness every time. I think there's a good reason that GCC, for instance, makes you push the compiler harder with compiler flags if you want to squeeze extra performance out of a program and accept the corresponding brittleness that it often brings. I also always thought that the transparent promotion of arithmetic was one of the strongest selling points of Common Lisp. My impression has always been that performance of numerics is rarely the bottleneck in typical code (web stuff, text processing, network code etc), but that unexpected exceptions in such code are the source of a lot of programmer heartache. On the other hand, I think 99% of the cases in which I've had a number exceed a 64 bit value were also examples of errors that might as well have been exceptions because they indicated a flaw in the code. -- 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
scala
Quick disclaimer - there are a lot of things I like in Scala and I think Odersky crew have done some very impressive work bringing functional language concepts to the VM and giving Java developers a path forward. I also don't think Clojure vs x language battles are very productive and don't want to encourage one. Anyway, I imagine my trajectory as a developer over the last 10 years is pretty typical. I started out doing Java stuff but fell in love with Ruby and Rails in 2004 and have been working almost entirely in Ruby since. The idea that all that heavy, cumbersome Java cruft could in many cases be dispensed with was a revelation and the discovery that I could build software in a language that offered *no* compile time error checking that was still robust was a very pleasant surprise. Like a lot of Ruby hackers though, I also saw some warts in the language and also remained curious about other approaches. Also like a lot of Ruby hackers, the recent rise of new JVM languages has piqued my interest, particularly Scala and Clojure. Scala seemed like a more natural step from Ruby and my first experiences with it were encouraging. It seemed to offer a lot of the expressiveness of Ruby but with potentially much better performance and more robust runtime and, intriguingly, static type checking. However, after writing a handful of small but non-trivial programs in it the complexity lurking under the surface started peeking through and the intricacies of the type system and the significant complexity of the language itself became more apparent. It started to feel like a step back to the rigors of Java and heavyweight syntax and fights with the compiler. The predominant Scala web platform, Lift, also seemed to have a very heavy, enterprisey sort of correctness about it that felt overengineered. So I bounced over to Clojure and its clean, elegant core and minimal, flexible syntax seemed very refreshing. It felt much more in the liberal, malleable spirit of Ruby. The functional stuff was a bit of a stretch but it also seemed built on a simpler set of core concepts than the featureful but complex Scala collections. Unfortunately there seems to be a lot more commercial momentum for Scala though. It's still a blip compared to the mainstream languages but I'm seeing more and more job posts mentioning it, and hardly any for Clojure. I don't think Scala is a bad language overall, but I'm not sure I'd dump Ruby for it. On the other hand, I can imagine migrating most of my dev work over to Clojure with the right project. Has anybody else wrestled with this choice? Any thoughts? -- 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: Why I have chosen not to employ clojure
So perhaps it would be worthwhile to create, like jruby, a single zip/ tgz file containing clojure, clojure-contrib, and a reasonable bin/clj file that will find at least the core clojure jar files on its own? I don't see how you're going to actually deploy any clojure apps, or connect to a database, or really use any third party code at all without understanding how java's classpath works but at least you can get a REPL going. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
On Mar 23, 11:09 am, Michael Kohl citizen...@gmail.com wrote: http://github.com/citizen428/ClojureX/archives/1.1.0 Sorry, really not trying to pitch my project here, but the archive above basically contains what you are asking for. Cool. Maybe we could link this and/or Stuart's labrepl from the getting started page? -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
On Mar 22, 2:48 pm, Sean Devlin francoisdev...@gmail.com wrote: There are a ton of people who are ready for dabbling with Clojure but aren't ready for production systems. You'd be surprised how linearly independent system administration skills and software development skills really are. They aren't quite orthogonal, but it's amazingly close. Maybe so, but if getting into Clojure is a series of struggles with unfamiliar concepts then dealing with a jar file is by far the least daunting. Naturally I'm all for making the new-user experience as pleasant and simple as possible but I'm not sure what exactly could be done at this point to make it much easier than it is. Certainly anybody that expects to be able to build it from source on an exotic Linux distro should also be prepared to roll up their own sleeves a bit. Perhaps it would be useful to at least included a ready-to-go clj shell/batch script in the default distribution? That's what Scala, Groovy and Jruby do? The only obstacle I remember from my first experiments with Clojure was getting a working clj shell script together. Had I started with Stuart's book that wouldn't have been a problem either. On the other hand, if you go to the getting started pages of Jruby, Groovy they're actually far more daunting (IMO) than Clojure's: http://groovy.codehaus.org/Tutorial+1+-+Getting+started http://kenai.com/projects/jruby/pages/GettingStarted -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Why I have chosen not to employ clojure
What a strange reason to dismiss Clojure. And also strange to refuse any further input. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: type hint puzzler
That was it. I was fixated on the ResultSet object and didn't consider overloading. Adding the (int) hint sped things up considerably. Thanks! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
type hint puzzler
I'm trying to eliminate some reflection overhead in little SQL utility I'm working on and can't seem to get the type hint right for this code: (import 'java.sql.ResultSet) (set! *warn-on-reflection* true) (defn rs-get-row [#^ResultSet rs] (if (.next rs) (let [cols (.. rs getMetaData getColumnCount)] (doall (for [i (range 1 (+ 1 cols))] (.getObject rs i nil)) When I run this I get this warning: Reflection warning, /tmp/simple.clj:11 - call to getObject can't be resolved. Reflection warning, /tmp/simple.clj:11 - call to getObject can't be resolved. Is the #^ResultSet hint correct? If so, what else do I need to do to resolve this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Two potential map-util functions
On Mar 9, 12:09 am, Meikel Brandmeyer m...@kotka.de wrote: How about this? (defn leafs ... This should be leaves, not leafs, right? Another one of those weird irregular English plurals. -- 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
monkeypatching in clojure
I've been reading about some of the clever things Scala does to allow safer monkeypatching and this started me thinking about Clojure's approach to this technique. Maybe I'm overlooking something but is this just a non-issue in Clojure? Since functions aren't attached to objects it seems to me you can just define a new function on an existing type or another method clause in a multi or if necessary. Maybe you have to be careful about messing around with an established type hierarchy or multi definition but it doesn't seem to me you need any special machinery to make this work, 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
Re: monkeypatching in clojure
On Mar 8, 11:48 am, Raoul Duke rao...@gmail.com wrote: uh, hey, wait a second, please note that is about type checking, not about OO vs. FP! Yeah I'm not talking about OO vs FP but about the function-centric approach that Lisps and languages like Haskell take as opposed to the object, or noun-centric approach of languages like Java or Ruby. Intead of db.statement, db.query, db.results etc you have db- statement, db-query, db-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: monkeypatching in clojure
On Mar 8, 12:47 pm, Richard Newman holyg...@gmail.com wrote: Interesting reading from 2006: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns... Yeah I was just reading that this weekend actually. To be clear, I'm not knocking the verb-oriented approach. I guess I just think it's interesting that even in dynamically typed languages or heavily type-inferred languages like Haskell you still winding up using type prefixes to some extent. For example, my Ocaml and Haskell experience is very limited but I understand that record field accessors in both languages share a common namespace, so in practice you tend to give them type prefixes to prevent clashes. And I guess we do the same thing in Clojure. We have a repeat function in core and in the contrib.string module so it's good practice to qualify the import of contrib.string and use string/repeat. -- 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
building clojure from scratch
Takes 15 seconds on my i7 laptop. Gotta love it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: name clash/problem with refer
On Mar 3, 11:03 pm, Meikel Brandmeyer m...@kotka.de wrote: Almost correct: (use '[clojure.contrib.string :exclude (repeat)]) That did it. Thanks! I finally had to do this to get the whole package to load: user= (use '[clojure.contrib.string :exclude (repeat butlast reverse get partition drop take)]) I wonder if it would make sense to rename some of those functions to reduce the number of clashes with core. -- 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: name clash/problem with refer
On Mar 4, 7:21 am, Stuart Halloway stuart.hallo...@gmail.com wrote: Preferred is (require '[clojure.contrib.string :as str]) That's an easy solution. Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
objects, interfaces and library design
I've been reading through the examples of OO in clojure using multi- methods and they certainly seem very flexible and powerful. I'm wondering, however, how people handle interface library design. If people can implement objects as maps, structs, or just about anything else you can discriminate on via a dispatch function, how do you handle code reuse and sharing of libraries. If we're all using our own home-grown OO systems how do we communicate? Is this something that the deftype/protocol proposals are meant to address or do people just work around it in other ways or is it just not a real issue in practice? -- 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: objects, interfaces and library design
On Mar 3, 2:05 pm, Jarkko Oranen chous...@gmail.com wrote: Well, it seems to me that the universal interface is the sequence. Turns out many things can be represented as sequences. :) And since maps are just collections of key/value pairs, very generic code can be written to process them, too. As long as the wanted keys are there, any extra information the map might be carrying can often be ignored. So is it generally the case that people implement objects as maps? That's what I've been doing in my dabblings with the language so far and it seems flexible 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
name clash/problem with refer
In trying to build compojure with the git MASTER versions of clojure contrib I ran into this error: Clojure 1.2.0-master-SNAPSHOT user= (use 'clojure.contrib.string) java.lang.IllegalStateException: repeat already refers to: #'clojure.core/repeat in namespace: user (NO_SOURCE_FILE:0) So I figured I'd try to use the :exclude option but got this: user= (use 'clojure.contrib.string :exclude [repeat]) java.lang.IllegalArgumentException: Don't know how to create ISeq from: java.lang.Boolean (NO_SOURCE_FILE:0) Digging a little deeper I tried to diagnose the problem with refer: user= (refer 'clojure.contrib.string :exclude [repeat]) java.lang.IllegalStateException: repeat already refers to: #'clojure.core/repeat in namespace: user (NO_SOURCE_FILE:0) Looking at the code of the refer function I'm *guessing* that the code that filters out the :excludes isn't working because [repeat] evaluates to an existing function in the current namespace and not a bare symbol to be matched against the incoming symbols from the target lib, but I'm not sure. -- 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
