On Mon, Mar 28, 2011 at 8:51 AM, Lee Spector <lspec...@hampshire.edu> wrote: > > On Mar 28, 2011, at 5:16 AM, Luc Prefontaine wrote: > >> Given the huge number of libraries/projects available these days >> and the diverse profile of library maintainers, a totally >> automated/transparent >> dependency manager is not for today. It would require a crystal ball to cope >> with a number of situations. >> >> That "garbage" has to be dealt with in day to day use by most of us. >> You should get used to it or live as an hermit on some far away mountain. >> Which I am tempted to do from time to time but for real bureaucratic >> issues like income tax reports :) >> >> Life can be hard... > > Luc's response here and also Shantanu's on the same thread have inspired me > to coin a new word, "FANPERV," for someone who Fails to Appreciate the > Newbie's PERspectiVe. > > Fanpervs typically make two moves in response to confused newbies: > > 1. Explain (correctly) why the perfect solution requires complexity, and then > assert (incorrectly) that newbies (and others with simple needs) should or > must deal with that complexity from the start. > > 2. Provide a (correct) solution to the newbie's problem while asserting > (incorrectly) that the solution is simple or obvious, thereby implying that > nobody should bother to provide a truly simple or obvious solution to future > newbies.
You left out 3. Flame the newbie, call him stupid, condescend. 4. Give a correct-but-incomplete solution assuming the newb can fill in the blanks or will even be aware that there are blanks to fill, etc. 5. Create software systems that newbs basically cannot use due to a ridiculously steep learning curve accompanied by a dense and technical manual full of neologisms unrelated to the terms used for similar things in similar, competing software systems, also making UI conventions utterly at odds with the ones in those same systems, up to and including the UI used to access, browse, search, and exit the help. For item 3, I note that there seems to be little flaming here -- thankfully. Usenet newsgroups on the other hand are rife with it, and comp.lang.java.programmer, which a lot of us being JVM-targeting developers probably follow, is a particular culprit at times. For item 4, I seem to recall having had a TeX problem one time and asking in comp.text.tex about it. There was a swift response with a hunk of code to copy and paste into my document's preamble, which made the compiler barf. I came back with a reply to the effect of "that didn't work", and the swift response to this boiled down to "you needed to put \makeatletter ... \makeatspecial around it, stupid" or words to that effect. Actually, I guess that's a combination of 3 *and* 4. With the added two lines of code, it did work as desired. But the responder could have actually included them in the first place instead of assuming that they went without saying. Most TeX users, including me, aren't also TeX hackers that delve deeply into the guts of the thing; beyond the odd \newtheorem or \newcommand use to macro automate something, we don't tend to do much more than write our documents. As for item 5, the most egregious culprit I can recall encountering in that regard is a piece of software that gets mentioned daily around here, is not Maven, and we'll just leave it at that. ;) > Fanpervs are often really smart and hard-working and kind and well > intentioned, but for some reason or another -- probably usually because they > know too much -- they just don't see how the newbies see things. I think this may be true even of the ones guilty of flaming; the flaming stems from frustration and impatience instead of genuine malice. On the other hand, there's a definite contingent that do hold newbs in low esteem and are deliberately rude to them, regarding them as low-status individuals on the techno totem pole. Why does this type bother to reply to newbie questions at all? As near as I can tell they break down into two subtypes: 1. hate seeing newbie questions, the group has a mix of newbie questions and more advanced topics instead of separate lists/groups for each, and they refuse to ignore/killfile these; and 2. gets off on being the superior smarmy know-it-all. The latter, especially, are deserving targets of snarky responses if you catch them in a serious error or omission. This list seems to mostly lack the genuinely newbie-hostile contingent. On Usenet, though, they tend to be a very vocal minority in every unmoderated technical group, usually with significant overlap with the contingent (one of which is found in *every* unmoderated group that gets nonzero levels of nonspammer traffic) of self-appointed moderators (who invariably are the #1 source of off-topic traffic themselves, usually in the form of flames, in-jokes among their own cliques, and complaints about other posters' off-topic traffic). > In the present discussion I don't think that newbies are asking for "totally > automated/transparent dependency management" but rather for a way to avoid > the issue entirely for simple projects that just use core and contrib (yes > that can be a challenge if you're new to java classpaths, and for many other > languages it's simpler because you just have to put the library in the same > directory as your source code) or maybe a few other libraries that they could > just download (yes that can be a challenge e.g. if the library's instructions > just say how to do it from lein but you're using some other dependency > management system because you want a Clojure-aware editor that doesn't > require you to go down an emacs configuration and learning-curve rabbit hole). FWIW, my own position here is that we should have a Clojure environment that can be used out of the box to produce usable jars with little mess or fuss if there are no uncommon dependencies (and java.*, javax.*, clojure.*, and clojure.contrib.* together cover a great deal of territory already). The language has matured enough that we need such a thing now; its lack will be an increasingly serious impediment to wider adoption of Clojure and thus to Clojure's future as a language. We may be near a critical point that will decide if Clojure is going to become a big deal on a par with Python, perl, or ruby, or just remain another obscure niche language tucked in with the likes of F# and Scala. -- 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
