A couple thoughts, my own 2-cents-worth. First, I think I’m seeing an entirely legitimate concern being expressed by some developers that :use complicates life in their shops. Contrariwise, there’s clearly a set of developers who are in environments where :use feels very natural, and is of considerable convenience.
As someone who is generally in the latter situation, I have a hard time with notion of getting rid of :use, but I can equally well picture myself doing Clojure environments where the restriction was pertinent. So, how about if there was a compiler option that caused :use to be flagged with a warning or error? I’d say that was entirely acceptable solution that kept everyone happy. In general: if you’re talking about expanding the existing functionality to help solve people’s problems, I’m all for it. If you’re talking about restricting existing functionality to require conformity with your particular vision, that’s a problem. BTW, if you insist on making the :use functionality substantially less convenient, well, I know how I respond to such things. I recall a saying from long ago in the Lisp community that “if you don’t like the syntax, write your own!”---and so I do. I’ve already dealt with several perceived nuisances in existing Clojure by writing and using my own macros. Coming up with a custom replacement for the ns macro feels a little challenging, but I dare say I’d rise to the occasion if need be. If that becomes common practice, I’d say you’ve won the conformity battle but lost the war. (Hey, maybe we should get rid of macros to prevent such heinous acts, eh? It worked for Java…) Next, there's an "I can't tell where identifiers come from" thought. Yeah, I've felt that pain, and as I've indicated, I'm situationally sympathetic. But here's a thought: how is this different from any programming language where one file/class/module/whatever can be included by another? Might there already be technology for dealing with it---even technology that doesn't involve manually qualifying every non-local identifier? Finally, with respect to the “it’s too hard for newcomers” line of argumentation, my reaction is: this is silly. Do you *really* want to optimize Clojure for use by newcomers? Assuming you managed such a thing, would the result still be useful to experienced programmers---who are, after all, are the main constituency for Clojure? Newcomers don’t tend to stay newcomers for very long, right? Similarly, with respect to the “ns is too complex” meme, my response is: gimme a break. It really isn’t all *that* complicated, and reducing its set of options by one isn’t going to change that very much. In the overall scheme of things involving functional programming in general and Clojure in particular, this tiny spec of complexity hardly signifies. Now, what *is *a problem is one of explanation---like, how to make newcomers aware of a good-enough set of recipes to get them going, or a lucid description of what the options actually are, and where they should be applied. So, here's a suggestion: improve the documentation!! Have you looked at the docstring associated with ns? Yeeesh! It’s all proper and correct, and about as profoundly uninformative as can be. (I’ve been doing Clojure intensively for about three years now, and just now I had a hard time even parsing it.) In fact, I think I’d generalize on this, as a lot of the docstrings in core Clojure are, um, terse… so I’d suggest that if Clojure 2.0 is afoot, improving the documentation would be an excellent goal. FWIW... Howard -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
