Prev: JavaScript (tm) hoax
Next: Reopen Pop-Up Window After User Closes It?
From: Ry Nohryb on 31 May 2010 14:35
On May 31, 8:01 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> On May 31, 12:11 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote:
> (...)
> > Keep up the good fight! Still programming in assembly language?
>
> That doesn't make any sense either.  I am programming in the same
> language as you and your "engineer" friends.  HTH.

Yes, the same language, not, the same API. The browsers provide an
(awful) lower-level API that you love to love. But people are moving
towards more powerful, higher level, much less awful APIs, by
extending the language. That's what the -many- libraries (attempt to)
provide. But you seem not to get it.
--
Jorge.
From: David Mark on 31 May 2010 15:00
On May 31, 1:46 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Kenneth Tilton wrote:
> > David Mark wrote:
> >> On May 30, 11:06 pm, Kenny <kentil...(a)gmail.com> wrote:
> >>> I think it was a breakdown in parallel universes. In mine qooxdoo works
> >>> brilliantly.
>
> >> Based on what evidence?  I'm guessing you tried it in a handful of
> >> browsers you had handy and figured if it appeared to work in those, it
> >> must be "brilliant".  Did it ever occur to you that the authors of
> >> qooxdoo tried the same browsers before you and inserted lots of hacks
> >> and sniffs to make them appear to work?  What do you think will happen
> >> in anything older, newer or unknown to the authors?
>
> > I'll lose 0.01% of my market for a week until the ten full-time
> > engineers paid to work on qooxdoo patch it?
>

Yes, time to check up on those wily (and paid!) "engineers".

> ,-[qooxdoo-1.1-sdk/framework/source/class/qx/Bootstrap.js:554]
> |
> | getClass : function(value)
> | {
> |   var classString = Object.prototype.toString.call(value);
> |   return (
> |     qx.Bootstrap.__classToTypeMap[classString] ||
> |     classString.slice(8, -1)
> |   );
> | },

That's a completely worthless and ill-conceived function that could
only have been designed by a neophyte. My guess is the whole mess
hinges on it. Hope they disallowed host objects.

>
> ,-[ibid.:554]
> |
> | isString : function(value)
> | {
> |   // Added "value !== null" because IE throws an exception "Object
> | // expected"
> |   // by executing "value instanceof Array" if value is a DOM element that
> |   // doesn't exist.

This looks like the sort of confused-as-all-hell comments I saw all
over Dojo. Skipping ahead a bit, I don't see any value instanceof
Array either.

And obviously they have not disallowed host objects for this one.

> It seems that there is a internal different between a
> |   // JavaScript null and a null returned from calling DOM.
> |   // e.q. by document.getElementById("ReturnedNull").

And there you have it. What is "a internal different" anyway? There
may be twelve of them, they may be paid and may well work full-time,
but these are not engineers (in any sense of the word). Worse still,
they clearly have no experience with JS or browser scripting and
apparently can't even explain their confusion in a coherent fashion.
You could have twelve-hundred such developers working double-time, on
weekends, holidays, etc. and you'd still have no hope (for anything
but a disastrous result).

> |   return (
> |     value !== null && (
> |     typeof value === "string" ||
> |     qx.Bootstrap.getClass(value) == "String" ||

Didn't disallow host objects for the other one either, which certainly
contributed to their confusion and subsequent attempt to patch the
"imaginary DOM element" problem.

> |     value instanceof String ||
> |     (!!value && !!value.$$isString))
> |   );
> | },
>

This illustrates the often-wide gap between the perceptions of an
impressionable neophyte and the realities of their chosen code.
Twelve full-time engineers working around the clock sounds impressive
until you look at their output.

And I bet if you tried to explain the issues to them, the response
would be "show me where it fails!" :)

Show me where this fails:-

var isIE = !!document.all;

function magic(a, b) {
return 0;
}

/* This might look funny, but it must be
done this way to work in all browsers
Trust us, we are engineers. */

function addTwoNumbers(a, b) {
return a + b + 8 + 10 - 8 - 10 - magic(a, b) + magic(b, a) * (isIE ?
2.5 : 3);
}

Passes the unit tests. Can't be bad. :)

Obviously, that's a made-up example, but some of the code in Dojo,
Prototype, etc. has ended up in a similar state after years of
community guesswork. One guy screws up in one module, another module
is adjusted to compensate, then a new browser comes out that breaks
the patches, a browser sniff is added, etc. Eventually you get a god-
awful mess of a patchwork that nobody understands (and most are
hesitant to touch) and comments, documentation, blog posts, etc. that
try to make sense of the senseless.
From: David Mark on 31 May 2010 15:09
On May 31, 2:35 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote:
> On May 31, 8:01 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > On May 31, 12:11 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote:
> > (...)
> > > Keep up the good fight! Still programming in assembly language?
>
> > That doesn't make any sense either.  I am programming in the same
> > language as you and your "engineer" friends.  HTH.
>
> Yes, the same language, not, the same API.

Uh, no. His "engineer" friends are in fact using the same API. He's
using their botched attempt to abstract something they don't
understand in the slightest. Nothing good will come of that.

> The browsers provide an
> (awful) lower-level API that you love to love.

Don't be a clod. It is what it is.

> But people are moving
> towards more powerful, higher level, much less awful APIs, by
> extending the language.

The trouble is they are doing it with such incompetence that the
results are often laughably inept. Did you read the rest of this
thread?

> That's what the -many- libraries (attempt to)
> provide. But you seem not to get it.

Of course I get it. I wrote one, remember?

Get better, Jorge!
From: Kenneth Tilton on 31 May 2010 16:38
David Mark wrote:
> On May 31, 1:46 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> wrote:
>> Kenneth Tilton wrote:
>>> David Mark wrote:
>>>> On May 30, 11:06 pm, Kenny <kentil...(a)gmail.com> wrote:
>>>>> I think it was a breakdown in parallel universes. In mine qooxdoo works
>>>>> brilliantly.
>>>> Based on what evidence? I'm guessing you tried it in a handful of
>>>> browsers you had handy and figured if it appeared to work in those, it
>>>> must be "brilliant". Did it ever occur to you that the authors of
>>>> qooxdoo tried the same browsers before you and inserted lots of hacks
>>>> and sniffs to make them appear to work? What do you think will happen
>>>> in anything older, newer or unknown to the authors?
>>> I'll lose 0.01% of my market for a week until the ten full-time
>>> engineers paid to work on qooxdoo patch it?
>
> Yes, time to check up on those wily (and paid!) "engineers".
>
>> ,-[qooxdoo-1.1-sdk/framework/source/class/qx/Bootstrap.js:554]
>> |
>> | getClass : function(value)
>> | {
>> | var classString = Object.prototype.toString.call(value);
>> | return (
>> | qx.Bootstrap.__classToTypeMap[classString] ||
>> | classString.slice(8, -1)
>> | );
>> | },
>
> That's a completely worthless and ill-conceived function that could
> only have been designed by a neophyte. My guess is the whole mess
> hinges on it. Hope they disallowed host objects.
>
>> ,-[ibid.:554]
>> |
>> | isString : function(value)
>> | {
>> | // Added "value !== null" because IE throws an exception "Object
>> | // expected"
>> | // by executing "value instanceof Array" if value is a DOM element that
>> | // doesn't exist.
>
> This looks like the sort of confused-as-all-hell comments I saw all
> over Dojo. Skipping ahead a bit, I don't see any value instanceof
> Array either.
>
> And obviously they have not disallowed host objects for this one.
>
>> It seems that there is a internal different between a
>> | // JavaScript null and a null returned from calling DOM.
>> | // e.q. by document.getElementById("ReturnedNull").
>
> And there you have it. What is "a internal different" anyway?

Why you old xenophobe, you! English is not their native tongue.

> There
> may be twelve of them, they may be paid and may well work full-time,
> but these are not engineers (in any sense of the word). Worse still,
> they clearly have no experience with JS or browser scripting and
> apparently can't even explain their confusion in a coherent fashion.
> You could have twelve-hundred such developers working double-time, on
> weekends, holidays, etc. and you'd still have no hope (for anything
> but a disastrous result).
>
>> | return (
>> | value !== null && (
>> | typeof value === "string" ||
>> | qx.Bootstrap.getClass(value) == "String" ||
>
> Didn't disallow host objects for the other one either, which certainly
> contributed to their confusion and subsequent attempt to patch the
> "imaginary DOM element" problem.
>
>> | value instanceof String ||
>> | (!!value && !!value.$$isString))
>> | );
>> | },
>>
>
> This illustrates the often-wide gap between the perceptions of an
> impressionable neophyte and the realities of their chosen code.
> Twelve full-time engineers working around the clock sounds impressive
> until you look at their output.
>
> And I bet if you tried to explain the issues to them, the response
> would be "show me where it fails!" :)
>
> Show me where this fails:-
>
> var isIE = !!document.all;
>
> function magic(a, b) {
> return 0;
> }
>
> /* This might look funny, but it must be
> done this way to work in all browsers
> Trust us, we are engineers. */
>
> function addTwoNumbers(a, b) {
> return a + b + 8 + 10 - 8 - 10 - magic(a, b) + magic(b, a) * (isIE ?
> 2.5 : 3);
> }
>
> Passes the unit tests. Can't be bad. :)
>
> Obviously, that's a made-up example, but some of the code in Dojo,
> Prototype, etc. has ended up in a similar state after years of
> community guesswork. One guy screws up in one module, another module
> is adjusted to compensate, then a new browser comes out that breaks
> the patches, a browser sniff is added, etc. Eventually you get a god-
> awful mess of a patchwork that nobody understands (and most are
> hesitant to touch) and comments, documentation, blog posts, etc. that
> try to make sense of the senseless.

Thx for the tech review! I forwarded it to the qooxdoo list in case they
are not reading here. Meanwhile, there is a difference between being a
good engineer and a God of Javascript. You may know more Javascript, but
that does not make them bad engineers. I have been into the internals,
once to get more performance out of the remote data model class, other
times just to understand how things work. The code is great, which tells
me that some day they'll catch up with you on Javascript. I also ended
up in Dojo and YUI code. Well, Dojo was such a nightmare I do not recall
digging in all that far. But YUI? Simple things simply did not work, and
when I investigated and saw the code I was horrified.

qooxdoo is the fastest, most extensive, easiest to learn, and best
functioning JS library out there with the excellent code inside and
documentation outside -- methinks they know what they are doing.

kt

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
From: David Mark on 31 May 2010 17:04
On May 31, 4:38 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote:
> David Mark wrote:
> > On May 31, 1:46 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
> > wrote:
> >> Kenneth Tilton wrote:
> >>> David Mark wrote:
> >>>> On May 30, 11:06 pm, Kenny <kentil...(a)gmail.com> wrote:
> >>>>> I think it was a breakdown in parallel universes. In mine qooxdoo works
> >>>>> brilliantly.
> >>>> Based on what evidence?  I'm guessing you tried it in a handful of
> >>>> browsers you had handy and figured if it appeared to work in those, it
> >>>> must be "brilliant".  Did it ever occur to you that the authors of
> >>>> qooxdoo tried the same browsers before you and inserted lots of hacks
> >>>> and sniffs to make them appear to work?  What do you think will happen
> >>>> in anything older, newer or unknown to the authors?
> >>> I'll lose 0.01% of my market for a week until the ten full-time
> >>> engineers paid to work on qooxdoo patch it?
>
> > Yes, time to check up on those wily (and paid!) "engineers".
>
> >> ,-[qooxdoo-1.1-sdk/framework/source/class/qx/Bootstrap.js:554]
> >> |
> >> | getClass : function(value)
> >> | {
> >> |   var classString = Object.prototype.toString.call(value);
> >> |   return (
> >> |     qx.Bootstrap.__classToTypeMap[classString] ||
> >> |     classString.slice(8, -1)
> >> |   );
> >> | },
>
> > That's a completely worthless and ill-conceived function that could
> > only have been designed by a neophyte.  My guess is the whole mess
> > hinges on it.  Hope they disallowed host objects.
>
> >> ,-[ibid.:554]
> >> |
> >> | isString : function(value)
> >> | {
> >> |   // Added "value !== null" because IE throws an exception "Object
> >> | // expected"
> >> |   // by executing "value instanceof Array" if value is a DOM element that
> >> |   // doesn't exist.
>
> > This looks like the sort of confused-as-all-hell comments I saw all
> > over Dojo.  Skipping ahead a bit, I don't see any value instanceof
> > Array either.
>
> > And obviously they have not disallowed host objects for this one.
>
> >> It seems that there is a internal different between a
> >> |   // JavaScript null and a null returned from calling DOM.
> >> |   // e.q. by document.getElementById("ReturnedNull").
>
> > And there you have it.  What is "a internal different" anyway?
>
> Why you old xenophobe, you! English is not their native tongue.

You have me confused with someone else. And I've seen such slovenly
comments made by native English speakers. Usually it is an indicator
of haste.

>
>
>
> >  There
> > may be twelve of them, they may be paid and may well work full-time,
> > but these are not engineers (in any sense of the word).  Worse still,
> > they clearly have no experience with JS or browser scripting and
> > apparently can't even explain their confusion in a coherent fashion.
> > You could have twelve-hundred such developers working double-time, on
> > weekends, holidays, etc. and you'd still have no hope (for anything
> > but a disastrous result).
>
> >> |   return (
> >> |     value !== null && (
> >> |     typeof value === "string" ||
> >> |     qx.Bootstrap.getClass(value) == "String" ||
>
> > Didn't disallow host objects for the other one either, which certainly
> > contributed to their confusion and subsequent attempt to patch the
> > "imaginary DOM element" problem.
>
> >> |     value instanceof String ||
> >> |     (!!value && !!value.$$isString))
> >> |   );
> >> | },
>
> > This illustrates the often-wide gap between the perceptions of an
> > impressionable neophyte and the realities of their chosen code.
> > Twelve full-time engineers working around the clock sounds impressive
> > until you look at their output.
>
> > And I bet if you tried to explain the issues to them, the response
> > would be "show me where it fails!"  :)
>
> > Show me where this fails:-
>
> > var isIE = !!document.all;
>
> > function magic(a, b) {
> >   return 0;
> > }
>
> > /* This might look funny, but it must be
> >    done this way to work in all browsers
> >    Trust us, we are engineers. */
>
> > function addTwoNumbers(a, b) {
> >   return a + b + 8 + 10 - 8 - 10 - magic(a, b) + magic(b, a) * (isIE ?
> > 2.5 : 3);
> > }
>
> > Passes the unit tests.  Can't be bad.  :)
>
> > Obviously, that's a made-up example, but some of the code in Dojo,
> > Prototype, etc. has ended up in a similar state after years of
> > community guesswork.  One guy screws up in one module, another module
> > is adjusted to compensate, then a new browser comes out that breaks
> > the patches, a browser sniff is added, etc.  Eventually you get a god-
> > awful mess of a patchwork that nobody understands (and most are
> > hesitant to touch) and comments, documentation, blog posts, etc. that
> > try to make sense of the senseless.
>
> Thx for the tech review! I forwarded it to the qooxdoo list in case they
> are not reading here.

They are almost certainly not reading here. None of the "major"
library developers do AFAIK. If any of them do, they are a curiously
silent bunch (which should tell you something). Of course, these
posts get syndicated all over the place, so eventually bits and pieces
get through. I've heard they like to gripe and whine about the
rumblings from this "antiquated" newsgroup in the cozy (and ostensibly
more modern) confines of their respective IRC channels. :)

More likely they are programming with blinders on to keep reality from
messing with their fantasies.

And I predict your attempt at cross-pollination will be less than
productive. You either know this stuff or your don't. Generally
those who don't are laboring under the delusion that they do, so it is
typically hard to get through to them.

> Meanwhile, there is a difference between being a
> good engineer and a God of Javascript.

If you are a good engineer, then you take the time to learn the
language and *basic* browser scripting concepts before setting out to
write a framework. And you sure don't have to be a god to see that
the cited code is gobbledygook.

> You may know more Javascript, but
> that does not make them bad engineers.

You really don't know what you are talking about. That's why you are
stuck using qooxdoo. That wouldn't be so bad if the authors of that
framework knew what they were doing. But alas, like the authors of
Dojo, YUI, Prototype, jQuery, etc. they don't.

> I have been into the internals,
> once to get more performance out of the remote data model class, other
> times just to understand how things work. The code is great, which tells
> me that some day they'll catch up with you on Javascript.

So you looked at the "internals", concluded they were "great" and that
tells you that some day they will "catch up" with me. On the other
hand, I've looked at their code, concluded it was rubbish. Perhaps
one day they will gain a minimal clue about this stuff, but how does
that help you today? And I wouldn't hold your breath as browser
scripting has a very steep learning curve.

> I also ended
> up in Dojo and YUI code. Well, Dojo was such a nightmare I do not recall
> digging in all that far.

It doesn't take long to diagnose that one.

> But YUI? Simple things simply did not work, and
> when I investigated and saw the code I was horrified.

You want horror? Try reading their change logs. :)

>
> qooxdoo is the fastest, most extensive, easiest to learn, and best
> functioning JS library out there with the excellent code inside and
> documentation outside

And what leads you to that delusion?

> -- methinks they know what they are doing.

Obviously, youthinks wrong.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: JavaScript (tm) hoax
Next: Reopen Pop-Up Window After User Closes It?