This post takes quite a lot of things to extremes, but I think the main argument still stands.
We need good defaults, not to totally change clojure into a newbie-friendly thing at the expense of what makes clojure special. This proposed change fixes a pervasive pain point in many codebases because :use is easy in the small and complex in the large, and it does it by simply raising the perceived cost of 'use' slightly. We spent time at my company on our own internal style debate over this, and I'm sure other companies do the same. Any time I spend significant time in a namespace, I move the code over to :require, so that's already not-inconsequential effort that doesn't need to exist. Advanced users are willing/able to do whatever it takes to make things easier for themselves, adjust to change quickly, and are likely more vocal and critical about change in the first place. I think that the negative impact of a change will always be a bit overblown. I guess it comes down to whether the negative impact is outweighed by the increase in clarity. Negative impact is obvious and instant, clarity is mostly invisible and its benefits are realized over time. People need some kind of feedback, a change in core is far-reaching with some downsides. On Fri, Jul 26, 2013 at 1:30 PM, greenh <greenh.greenh...@gmail.com> wrote: > 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. > > > -- -- 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.
