Andrew said:
I will take that as a "yes". It does bring in to question the worth of
my saying anything at all.
You're hyper-parsing my statements. I think the response the OP
got _isn't constructive_ clearly you disagree.
If someone is going to make a mistake then being told that it is a
mistake certainly can be regarded as constructive, even if not as
constructive as being told why it may be a mistake.
I think some of
the criticism of Prototype that occurs in this newsgroup _isn't
constructive_, but some _is_. I am saying that I will disregard
things that I don't feel are constructive. Therefore there is no
"requirement" of any sort. Jesus.
But anyone then asserting that, for example, the best way forward with
Prototype.js would be to delete it and start again from scratch will be
disregarded even if they think that advice is constructive (and it is
virtually the only way that it would be possible to correct the mistake
of violating the language's specification's injunction against using the
'$' symbol as the initial character in Identifiers except when they were
machine generated).
Nothing. Go eat a taco if you like.
You wrote "... they obviously need to do more persuading", but not there
appears to be no obvious necessity here.
Somewhere along the way I got you mixed up with Thomas. For that
I apologize.
I'm not arguing whether it's true or not. If I say "Martin
Scorsese can't direct for shit," I expect people around me to
look at me funny, because whether my statement is true or not
it goes against consensus. Therefore I might feel a burden to
_elaborate_.
But would you still feel the need to elaborate in the company of people
who shared that opinion?
And you seem to say that a small handful of silly choices in
a framework mean the entire thing is worthless.
No, I am saying that when the people who designed frameworks/libraries
and the like are demonstrating fundamental shortfalls in the
understanding of the language they are using then the consequences of
that evident ignorance are likely to also manifest themselves in the
overall design of those frameworks/libraries. That is, they are
indicative of the consequences of design decisions (which may themselves
be regarded as largely subjective) being as uninformed (by both
knowledge and experience) and so that the whole of which they are a part
being in some sense 'junk'.
No, his assessment is a matter of taste. The part that
connects his memory and his opinion.
For some reason my memory connects the notion of genocide with "really
very bad", but I suppose that is just a matter of taste.
We disagree on the degree to which this is important. I think
we've gone as far as we can on this point.
Probably.
That's a very vague statement. A few examples would be greatly
appreciated.
Examples of what precisely?
The words "slow," "anything," and "complex" are
relative to the individual,
Only to a limited degree. They are more relative to the words "fast"
"nothing" and "simple", respectively.
and obviously must be taken into
account when making a technology decision. jQuery's central
API focus - fetching nodes by CSS selector - means that a
line of jQuery code is often much slower than the equivalent,
non-framework-aided code.
Yes, occasionally someone shows up here and complains that attempting to
sort 10,000 table rows is unacceptably slow. To which there is little
choice but to say that that is how it is and you deal with that by
designing the need to sort 10,000 table rows out of the system (a
response that is generally not taken as being constructive, despite
being the best advice going). I have seen people complaining that
JQuery's performance is unacceptable with as few as 400 table rows to
sort.
Many people use it anyway because
they deem it to be worth the trade-off.
To judge a trade-off it is necessary to know and understand the
alternatives. I suspect that the majority using these things are doing
so in order that they don't have to learn the alternatives and so carry
on using them regardless not as a result of assessing a trade-off but
rather because they have no real alternative.
Apparently I need to stop using sarcasm. I also need to stop
speaking abstractly, aside from basic declaratives (e.g.,
"Your tone is too harsh."). You are reading the most literal
of meanings into every single word I write.
Reading literally. Literally?
Case in point. I don't know why you think I was trying to
censor conversation in the first place.
I did not think you were trying to censor anything (beyond those things
that you will 'brush off' as a result of their not being 'constructive',
but that is only going to impact on you so it does not really count). I
observed that there were considerable advantages in the exchange of
ideas being censorship free, despite the fact that the consequences of
that may include the odd post here or there being a knee-jerk
generalisation rather than a reasoned argument.
My point is that
I can't (and don't want to) censor anything.
Beyond those things that you will 'brush off' as a result of their not
being 'constructive'.
Needlessly argumentative and willfully dense to the point
I'm making.
Try making your point in as many words.
Again, argumentative. The fact it's a bad name for a library
(which I agree with) is unrelated to the point I am making.
I thought that the point you were making was that attempting to look up
"prototype" in the archives resulted in such a food of responses that
fining the substance that (may or may not) inform the 'junk' assessment
was not practical.
This is like saying I ought to read the entirety of Donald Knuth's
published works before I write a simple algorithm.
More like saying that you maybe ought to read at least one book by
Donald Knuth before putting yourself forward as an arbiter of algorithm
correctness.
You may be right in your "bet," but that's not how a user in
need of help is going to _behave_, so what's the user of
pretending otherwise?
What has a "user" to do with anything? The purpose of this group is not
to help individuals with their problems (to the extent that that happens
at all it is no more than a side effect of the group). The group exists
to allow its participants to discuss javascript, and the reason that its
participants want to discuss javascript is to improve their own
understanding of the subject. All the question asking and answering is
just a convenient mechanism for getting the ball rolling (and carries on
because the vast majority of questions get reasonable good answers
(eventually)).
First of all: we don't sniff the UA string to detect IE.
So you are not continuing to argue about "technically baseless" or
"ineffective"? Certainly you are not pointing out the location of the
technical basses for UA string based browser sniffing for all to see.
We sniff
to distinguish between other browsers (e.g., between Gecko and
WebKit),
And for two years I operated IE 6 with the word 'Gecko' in its UA header
(in order to render MSDN usable), and at no point during that time was I
in violation of HTTP 1.1.
but we use a different heuristic for IE.
The test you are using for IE is an object inference test along the
following lines of:-
IE: !!(window.attachEvent && !window.opera),
- and that betrays its own folly. The reason for including the -
!window.opera - bit that Opera's creators have seen expedience in
providing their browser with 'IE compatibility' features. The problem
with that is that the same rational that motivated Opera's creators may
influence the manufacturers of any other web browser. And so any browser
may potentially have an - attachEvent - method of the window object, and
in the even that any do they are unlikely to bother to implement a -
window.opera - object as well (because Opera compatibility is not going
to be a worthwhile path to pursue). Object inference may by a marginally
superior strategy to UA string based browser detection but it is
predicated upon such a detailed and broad knowledge of web browser
object models that the only way of seeing it as a valid strategy would
be to pretend that there were only 3 or 4 browsers in existence.
Second: your gripe seems to be that we use any
heuristic at all - that it's not possible to detect
differences in UAs with 100% accuracy.
You make it sound like browsers can be differentiated with some degree
of accuracy. User Agent string based browser sniffing cannot
differentiate between browsers that use the same sequence of characters
in their User Agent headers, and cannot handle unexpected header content
(despite there being no technical grounds for expecting anything
specific in any such header). Object inference is only ever as good as
the direct (and detailed) knowledge of browser object models, and a more
detailed knowledge than the majority of those attempting it demonstrate
in the tests they devise. And it suffers from necessitating much ongoing
code maintenance because knowledge of browser object models can only be
knowledge of existing browser object models, so not even including the
next version of any existing browser let alone any new browsers that may
come into existence.
History has already exposed the fact that object inference browser
detection sows the seeds of its own invalidity. It is no accident that
browsers have been observed that implement an - ActiveXObject - global
function even though they were designed to be cross-OS (and you cannot
instantiate an ActiveX object on non-Windows OSs). It was a direct
consequence of javascript authors attempting to use the existence of
that object to infer that a browser was IE, and so turn otherwise
perfectly usable browsers into apparently non-functional browsers. The
manufacturers of those apparently non-functional browsers then become
well motivated to spoof enough of the IE object model to fool such
tests.
99.99% accuracy is good enough for me. I'm not insisting
that you must agree;
That may be acceptable if it could be known to be 99.99% (or even
something approaching it), but that is no more than a guess, and a
very flawed guess at that. Where would that number come from, if
not derived from web browser usage statistics? Even disregarding
the inherent issues with statistics gathering over HTTP (the
unknowable and probably inconsistent influence intermediate caches
being just one) and the self-biasing nature of browser usage
statistics, the browser identification issue remains. Browser
usage statistics use User Agent string based browser sniffing
(with a few throwing in some rudimentary object inference
testing). Which means that if you used browser usage statistics
to justify your guess of 99.99% accuracy of your browser
identification techniques you would be implying that those browser
usage statistics were, more or less, accurate despite their
employing pretty much the same techniques. That is, the accuracy
of the techniques you use would be being justified by the
assumption that those same techniques were accurate. But if
they are not accurate then there is nothing to justify your
claims of 99.99% accuracy. Making that a somewhat circular
argument.
I'm only asking not to be regarded as a savage.
You will have to make that particular appeal to a different audience.
No, I would rely on the unit tests to demonstrate a consistent
behavior. It doesn't give me 100% certainty because I can't
test every string on earth. (In this case, obviously, we didn't
test enough strings.)
More like you did not write the unit test such that they exposed to code
to input that was likely to be miss-handled. But that was just the
consequence of the experience shortfall that mentioned previously (and
you deny exists at all).
Again: someone else did notice it. But it did go unfixed for
about a year, and I find that disappointing and unusual. We
agree on the former but not the latter.
Again, you're being oddly argumentative. I don't care how it
sounds to you.
And I would rather not see this type of BS at all (and even if nothing
else is "constantly" certainly is BS).
Yes, the Titanic's problems were in the fundamental design not how shiny
the trimmings were.
The bug submission screen has a gigantic text box in which
you can make any sort of condescending judgment you like.
How can you resist?
Very easily.
Richard.
but not for the reason you are possibly