Re: jQuery's latest stab at competence



On Feb 10, 3:57 am, Karl Tikjøb Krukow <karl.kru...@xxxxxxxxx> wrote:
Faisal Vali wrote:
I also follow some of the other programming newsgroups/blogs: std.c++,
c++.moderated, boost, es-discuss, lang.ruby, lambda-the-ultimate,
comp.programming.threads, vc.atl - I am generally humbled &
enlightened by some of the advice, insight and discussion I see on
some of those other groups (as I sometimes am on this group too). Yet
the *sense* I get is that the frequency and level of hubris,
abrasiveness & dismissiveness that litters the posts here (by some of
the truly competent wizards in this group) substantially outnumbers
that in the other groups mentioned above.

I have always found that interesting.

<snip>

Well let me expand upon why I found this so interesting.

Those JS topics that I have had to conceptually wrestle with the most
(*), I learned more about from following es-discuss (the javascript
analogue of comp.std.c++ - if the gurus here are js wizards, those
people are js gods - the creators and implementers of the language).
Yet the tone there is rarely hostile or hubristic.

Now this group, I find, tends to deal more with javascript/DOM than
specific javascript language/standard issues.

Since client-side web development is admittedly complicated and
frustrating - because of the nature of the ever-changing landscape/
domain and because of the issues with the standards and their
implementations in various browsers with regards to javascript, DOM,
HTML and CSS - the advice rendered by the knowledgeable on this group
can be very valuable and I could imagine a situation in which it could
save a developer hours if not days/weeks of work. But the advice and
insight offered here is rarely any more a triumph of sheer
intelligence and reason than what I see on some of the other groups.
Yet it comes with *far* more attitude. (And since hubris and attitude
are rarely conducive to a healthy intellectual atmosphere and
discourse - I would not justify them even if accompanied with the most
dazzling brilliance)

I think everyone notices it. Certainly all of the clj 'regulars' seem
extremely skilled, but there are a few of them that stand out as
unfriendly or even angry. <snip>

There are both positive and negative effects. On the negative side, I
think that it may make some newcomers disregard the technical contents
because the post is dismissed as a troll or a personal attack; in effect
the technical content is shadowed by the strong language. On the
positive side, those who do stick around tend to make an extra effort to
be precise in their questions, language and follow netiquette.


I see more negatives than you - and I think you can easily get the
positives by less-draconian measures (the basic underpinnings of a
democratic vs an autocratic world-view)

Regarding theories 'why'? Here are a few (although I personally haven't
settled on any):

* Intentionally trying to scare off certain types of people

what types - the uninitiated?


* Just a few angry (old?) men

I can buy this - but not as a good reason.


* Reasoning that strong language will make a stronger impression

And what evidence is used to support this reasoning?


* Being genuinely frustrated with seeing what is considered incompetence
over and over again

This is a tough one to rise above. I have the most sympathy for this
reason - but I have trouble using it to justify the scathing ad-
hominem attacks and the flat-out/reactive rudeness.


But in the end, unless you are simply curious or for some reason care
about making this group more friendly to newcomers, you shouldn't really
care. It is still the best place to get technical advice.

I give it some attention because I find value and importance in civil
discourse, since I often depend on it to learn (which reminds me - I
have a question about cookies I will be posting soon ;)

Yes - it is still the best place - but there is no good reason it
shouldn't be a gentler place.

peace,
Faisal Vali
Radiation Oncology
Loyola


(*) JS language issues
1) functions and their execution contexts
- the binding of outer variables & 'this'
- the arguments object
- hoisting (function scoped variables) of variables and issues
with function statements
- why functions won't play nice with macro systems
2) the nuances of prototype chains (construction, reading/writing
inherited properties)
3) the meta-descriptors of JS objects
4) the inexact/incomplete/unusual language of the ECMA 3.0 standard
(to be improved in 3.1)
.



Relevant Pages

  • Re: Adding new methods to existing classes
    ... I can learn from your dogmatic advice. ... The very specific reason is backwards compatibility. ... That is hardly "most every browser but IE". ... Prototype.js was written by people who don't know javascript for people ...
    (comp.lang.javascript)
  • Re: jQuerys latest stab at competence
    ... enlightened by some of the advice, insight and discussion I see on ... specific javascript language/standard issues. ... HTML and CSS - the advice rendered by the knowledgeable on this group ... I can buy this - but not as a good reason. ...
    (comp.lang.javascript)
  • Re: stdin help
    ... Alastair wrote: ... The reason is ... >> here to make those corrections, so bad advice may not be caught. ... > (therefore to do with the C language). ...
    (comp.lang.c)
  • Re: Redirect sqlplus output into a variable in tcsh script
    ... installations exist where the local guru shell-scripts in csh. ... you don't get to choose what language to work in. ... Though, if classical reason 3), "the OP is not ... get informed]", is applicable, then the given advice is better than the ...
    (comp.unix.shell)
  • Re: In 2009?
    ... but Javascript is just the language. ... The thing it's manipulating is usually the DOM, and -that's- browser-specific in many cases. ... Writing cross-platform Javascript is an utter pain, and thankfully one I've not had to do for quite some time. ... I agree that for anything standard there's no reason to not write a compatible app, but there's some things that definitely will be browser-specific. ...
    (uk.comp.sys.mac)