Re: to learn jQuery if already using prototype

On Apr 22, 7:39 pm, "Richard Cornford" <Rich...@xxxxxxxxxxxxxxxxxxx>
wrote:
Andrew Dupont wrote:
On Apr 19, 11:07 pm, Richard Cornford wrote:
Who is going to be deciding what 'constructive' means in
this context?

Each individual on his own.

Maybe, but there are circumstances were the best advice possible is to
delete something and start again from scratch, but most individuals who
hear that advice don't regard it is constructive when they do.

Or, in other words: say what you want to say, and I'll
brush off anything I think is unwarranted.

Presumably you mean you will brush off anything that you regard as
unwarranted?

How is that different?

I'm not
setting conditions for prior restraint here.

Requiring what you get to be "constructive" is not a condition?

You're hyper-parsing my statements. I think the response the OP got
_isn't constructive_ clearly you disagree. 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.


You mean that if someone is in a 'minority' then they must
be wrong? That is hardly an attitude that would allow
progress through the adoption of new ideas.

I never said anything of the sort. I said the minority need
to do more _persuading_.

OK. Why, what is in it for them?

Nothing. Go eat a taco if you like.


You stated that these libraries were junk

I very much doubt that I did.

Somewhere along the way I got you mixed up with Thomas. For that I
apologize.

Clearly it isn't common knowledge.

There are lots of things that are true but are not common knowledge.

I'm not arguing whether it's true or not. If I say "Martin Scorsese
can't direct for ***," 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_.

Maybe, but there is an objective "better" in the sense of using:-

if(elem == null){
    dojo.raise("No element given to dojo.dom.setAttributeNS");

}

- in place of:-

 if(
   elem == null ||
   ((elem == undefined)&&(typeof elem == "undefined"))
){
    dojo.raise("No element given to dojo.dom.setAttributeNS");

}

And you seem to say that a small handful of silly choices in a
framework mean the entire thing is worthless.


How do you know that? It seems likely to me that Thomas was
using his memory of the many (more or less detailed)
discussions of Prototype.js code that have happened here
over the past few years to inform a general assessment
of the code.

And I submit that is a matter of taste.

Thomas's memory is a matter of taste?

No, his assessment is a matter of taste. The part that connects his
memory and his opinion.

Not really. There are bugs and there are bugs. A typo in the middle of a
large block of code is something that can happen to anyone, and it could
also easily be missed by others reviewing that code. A glaring error in
something that experience would teach you to always double check and
also should be exposed in any reasonable testing is something else
entirely.

We disagree on the degree to which this is important. I think we've
gone as far as we can on this point.


of course, and we welcome bug reports. But you've gone
further than that; you've inferred from "evidence" that
code in Prototype does not do what its author means for
it to do.

No, I said that the evidence was that Prototype.js was (at least in
November last year) only doing what was (apparently) expected by
coincidence; that it had not actually been programmed to do what it was
doing. I also implied that were that evidence existed it was reasonable
to question the understanding of javascript that informed all of the
design decisions that occurred prior to that code being written; such as
the underlying design approach and the resulting API.

(I have also pointed out that Prototype.js is incredibly slow at doing
pretty much anything complex)

That's a very vague statement. A few examples would be greatly
appreciated. The words "slow," "anything," and "complex" are relative
to the individual, 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. Many people use
it anyway because they deem it to be worth the trade-off.



I think it's far more constructive to say "Most of us
are not library fans, so you're unlikely to find useful
answers here,"

That would not be a true statement (at least the second
part of it, and the first part if you take the word
'library' in its most general sense).

Then write your own words.

I did.

That way they'll be _from the heart_.

No they would not. They would be from the head.

You know the point I'm trying to make.

Not really.

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.

... . There is a lot to be said for the uncensored
exchange of ideas in public.

The word "censorship" doesn't come within miles of this
thread.

Well this is Usenet so there is no censorship.

I do not own a telecommunications company; I don't have
the means or authority to "censor" anyone.

You would not have the means to censor Usenet even if you did own a
telecommunications company.

Case in point. I don't know why you think I was trying to censor
conversation in the first place. My point is that I can't (and don't
want to) censor anything.

I mean that they weren't participants before their first post.

And they weren't human before they were conceived.

Needlessly argumentative and willfully dense to the point I'm making.

Many posters, I would venture, only come here when they
need help, and therefore aren't already familiar with the
quirks of the community.

There is no need to "venture" that, it is self-evidently true.

they come by only when they have problems. They can't
be expected to catch up on the backstory.

They can. Expecting someone to do a few web searches before they ask
to
be spoon fed is not too unreasonable.

Please search this newsgroup for the terms "Prototype"

What are you expecting? You give a library the same name as a
significant aspect of the language it written in and then cannot find
specific references to it in the archives of a newsgroup dedicated to
that language. It was a predictably bad choice of name.

Again, argumentative. The fact it's a bad name for a library (which I
agree with) is unrelated to the point I am making.


and/or "jQuery" and see how quickly you find a well-summarized
critique of either library.

Who said finding that sort of thing out was going to be quick? I bet the
search would still turn out to be informative even if it could not be
instantaneous.

This is like saying I ought to read the entirety of Donald Knuth's
published works before I write a simple algorithm. 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?

To be sure, there are other UA sniffs in Prototype that
hard-liners would decry as unnecessary.

It is not 'unnecessary' that is the questionable aspect of
browser sniffing, but rather that it is technically baseless
and demonstrably ineffective.

You haven't demonstrated that anything is baseless

How would you expect me to demonstrate the lack of any technical
foundation for UA string based browser sniffing? I can hardly point to
something that doesn't exist and say "there is the absence of any
technical foundation for all to see".  Of course if there was any
technical foundation then that could be pointed at quite easily, but as
the navigator.userAgent string is a reflection of the HTTP User Agent
header then any such direction must lead to the definition of the header
in the HTTP specification, and that definition pretty much says that the
User Agent header is an arbitrary sequined of zero or more characters
that is not even required to be consistent from one request to the next
(i.e. that it is not specified as being a source of information at all).

or ineffective;

Does that need to be demonstrated (again)? It is known that web browsers
use User Agent headers that are indistinguishable form the default UA
header of IE, so how could it be effective to discriminate between
browsers using the UA string whenever two different browsers use UA
headers that are indistinguishable?

First of all: we don't sniff the UA string to detect IE. We sniff to
distinguish between other browsers (e.g., between Gecko and WebKit),
but we use a different heuristic for IE.

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.
99.99% accuracy is good enough for me. I'm not insisting that you must
agree; I'm only asking not to be regarded as a savage.

So you would not be certain what the code was going to do, but you would
know that whatever it did it would take about the same amount of time to
do it wherever it was running? I certainly do not have a taste for that
design philosophy.

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.)

But I suppose that you would not agree that being able to
find an obvious rookie mistake in less then three seconds
of looking (at a library that is already a good few years
old) tends to support the "junk" assessment.

The check-in is only one year old. It is Thomas's bug, but he
is no rookie,

Hansom is as hansom does. But that was not really my point. One of the
things that gets proposed as a justification for libraries of this sort
(a reason for their not being junk by virtue of what they are) is that
with many individuals contributing there are plenty of eyes looking at
the code to be able to find these sorts of things and fix them up front.
But if it takes me three seconds to find what nobody else had noticed
then it must be the case that there is nobody involved looking with my
eyes.

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.

We listen to criticism, we read bug reports, and we constantly
search for ways to improve the feedback loop.

That all sounds very 'marketing-speak'.

Again, you're being oddly argumentative. I don't care how it sounds to
you.


So does John Resig, by the way, so I'd suggest you file a bug
on jQuery's Trac about the "makeArray" mistake.

Why? Polishing the handrails on the Titanic may have made it more
appealing to look at but didn't change the rate at which it sank after
the design flaw coincided with the iceberg.

Are you sure? 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?

Cheers,
Andrew

.

Loading