On Aug 6, 2013, at 7:55 AM, Curtis Summers wrote: > I agree that wildcards make it "easy" (in the nearness sense), but from a > long-term maintainability standpoint, I'd prefer to have explicit imports as > is. When I'm reading your code a year from now and need to look-up the docs > on a class, wildcards make me (and anyone else in the future) have to do that > look-up every time. It's almost the same argument as to why (:use) is a bad > idea--you're dumping a bunch of symbols into your namespace. So, you're > trading some upfront ease for some long-term simplicity.
This makes perfect sense if long-term maintainability is one of your higher priorities, which it certainly should be in many programming contexts. But not in many others. I do realize that many (most?) programmers spend lots (most?) of their time reading and maintaining code rather than writing original code. But not every programmer is "most" programmers :-). For me and I suspect many other researchers/teachers/students/artists/etc. upfront ease is really valuable and in fact crucial, and I can worry about long-term maintainability if/when that becomes a relevant concern. If I have an idea then I want to try it out ASAP by writing just the code I need to try it out, and it's a total drag when a language/environment makes me engage in a time-consuming and distracting bureaucratic process -- doing stuff that the system could really do for me -- on the way to expressing and trying my idea. If something works well, and I want to build on it and/or share it, then yes, I should re-engineer it for readability and maintainability. But that doesn't mean I want to -- or should have to -- jump through lots of hoops to play with ideas in the first place. FWIW if you find my perspective here to be crazy I think that it's close in some ways to ideas that Paul Graham has expressed much better in some of his essays about Lisp, language design and programming methodology (http://www.paulgraham.com/articles.html -- mostly the ones near the bottom of the list). In other words, "don't use wildcards" may be an excellent rule for programmers in many contexts, but that doesn't mean that it's a good idea for a language to impose it on everybody all of the time. And more generally, it's probably not a good idea to impose rules on all users of a language just because they're good rules for some/most programmers to follow some/most of the time. -Lee -- -- 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.
