Mozilla Foundation is already a 501(c)(3) and has been for two years. We are not going to reincorporate it as another kind of non-profit. For one thing, we have received, and we will continue to receive, charitable donations.
Your response, with its dramatic use of bold, seems to be saying "gotcha". Got what? Why exactly do you think that the Mozilla Foundation should be a 501(c)(4)?/be
There's no reason that that a non-profit corporation can't have revenues. In fact, they can have massive revenues. The profits just can't accrue to private profits.
The issue with non-profits in the US is not about accruing "private profits" but about the type of activities pursued for the non-profit's "public benefit purpose". "Acting as if" we were a for-profit entity is a problem, even if we never accrued private profits and never distributed them somehow to the owners (in this case, the Mozilla Foundation is the sole owner).
So even if we act to further our public-benefit purpose, and distribute funds as grants, or otherwise avoid profit-taking, if our action in the market and with partners resembles for-profit commercial activity, we may lose our non-profit status. That is something the Foundation does not want to risk.
This is the main reason for the reorganization.
Yes, it means Firefox is making money, and in ways that may put us in the position of "acting as if" we are a for-profit commercial entity.
No, we will not start charging for Firefox or any of our other free (beer and speech) products.
My point was that JS ought to respond to feedback in its niches, not stay unchanged for years on end (as it has, apart from bug fixes). I agree it doesn't need six legs or two heads. But "evolve" -- as in "respond to feedback from users" -- means more than "bug fixing". See my roadmap blog for more on this.
JS certainly has design flaws. It was designed very quickly, and evolved under some absurd deadlines at Netscape and in ECMA committee, with the sad, stale background of the "browser wars" (MS crushing Netscape; Netscape mutilating itself with bad decisions, only some of which were due to that rarified competitive pressure).
Here's the design decision you hate: a JS object is a single-namespace collection of properties, each mapping a string to an arbitrary value. I made that decision quickly, but consciously, so I'll take blame. "Brain-dead" is too strong, though. Is Python "brain-dead" for lacking real closures (see http://store.yahoo.com/paulgraham/icadmore.html/)?
Using strings as property names helps users who commonly want to map "1" and 1 to the same value in an object (not necessarily an Array object -- any object).
If (as you seem to want) JS had mapped value to value, treating all strings of the same length and characters as a single identity, but also mapping objects, numbers, booleans, etc. according to some equivalence relation (you probably want ===, which maps -0 and 0 to the same equivalence class; you must treat all NaNs as the same not-a-number), then many users would have to say String(1) or Number("1") where today they do not. Users would have had to write
anArray[Number(aForm.anInput.value)] -- a lot.
The influence I acted under came from awk. JS's design target was string-oriented processing in scripts embedded in client and server markup language processing. It seemed better to simplify the object model by defining property identifier as string-typed, with implicit conversion, than to allow arbitrary values mapped under some more complicated non-identity equivalence relation.
From your later comment, it seems you believe that this decision requires comparing string keys when looking up 1 or "1" -- not so. It's trivial to optimize non-negative integer property identifiers that fit in machine-word containers from string to int when storing, accessing via hash tables, etc. A JS Array indexing from 0 to 2^30 - 1 in the Mozilla JS engine, SpiderMonkey, requires no string storage for the element ids, only for the interned 'length' property id. Methods, as you note, are stored in the same namespace, but not in each instance -- rather, in this example, only once, in Array.prototype.
This is the result of a very few design decisions carried to their conclusions, with simplicity given greater weight than almost any other good. A mistake? Sure -- and worse, incomplete due to the rushing (as with Python, JS has had to evolve some corrections and necessary limbs). But not brain-dead.
FYI, if you want to map names such as a["width"] = 1, a["breadth"] = 2, don't use an Array. Use an Object. To count these properties, you can use __count__ in SpiderMonkey. I never got near to persuading the ECMA working group to think about standardizing this extension. Using the standard, you have to count, with a var n=0; for (var i in a) ++n; loop.
Listen, idiot: I clearly wrote "our mistake" and put a rueful joke at our expense about "putting the Java in JavaScript", so I'm obviously not proud of cloning Gosling's y2k mistake. There's nothing there to brag about, and you must be tone-deaf to misread my post that way.
You can toady for MS all you want, but the fact that it used standards bodies to come from behind Netscape in the mid-to-late nineties does not take away from its abuse of monopoly, and utter lack of standards-following on the web, since IE took majority browser market share.
Of course the *FullYear methods were implemented in a version of IE before ECMA approved 262 -- MS was playing nice and leading the standards charge when it suited its business interests. Oh, and FYI: everyone involved in ECMA TG1, including Guy Steele of Sun, had the same desire to fix the y2k bugs cloned from java.util.Date, so MS (or you, if you're not working for MS) can't claim exclusive credit for such obvious fixes.
Fullsome praise for acting with naked self-interest stands the usual ideas of noblesse oblige on their head. They're saints now for not acting selflessly? What crap.
Microsoft has perpetrated its share of y2k-level mistakes too. No one is infallible, so snipe and suck up consistently, or again you will look like a paid toady. Or keep it up -- paid toady would be more respectable than unpaid.
Don't sweat it, I'm a member of ECMA TG1 and I will take these lisp-y Array extensions to the group and propose that they be added to Edition 4.
Standardization follows implementation here, and in many cases. Where standardizers wait to implement, and instead design on paper and by consensus, you usually get something bigger, slower, and later than if implementors had competed, or taken first base by moving fast and doing a good enough job.
I'm hoping to avoid design-by-committee bloating ECMA-262 Edition 4. Wish me luck!
I delegated the chore of implementing the Date class to Ken Smith at Netscape, who kindly volunteered to help, and we both agreed to model it on java.util.Date, which IIRC was James Gosling's code.
We thereby inherited obvious y2k bugs, and soon enough, Sun deprecated java.util.Date in favor of a Calendar class. But for a time, our mistake really put the "Java" in "JavaScript".:-/.
ECMA-262 standardized these getYear/setYear methods only in a non-normative annex, and added getFullYear, setFullYear, etc., as required parts of the ECMA-262 standard. Netscape and therefore Mozilla have supported these methods since then, so I have no idea why you think Microsoft JScript differs from our implementation in conforming to the spec.
(Clues: ECMA-262 Edition 3 specifically allows for added methods and other properties in standard objects, and backward compatibility required keeping these y2k-bug methods back when Netscape had market share.)
Another point of confusion: many companies belonging to ECMA contributed to ECMA-262, including Microsoft. Parodying a *GASP* that no informed person would ejaculate looks like silly I'm-so-clever-I-can-defend-MS-on-slashdot posing.
Spare us, and while you are at it, educate yourself about the history of the ECMAScript standard and its Date methods.
Quoting from my post, the grand-parent of this one, in full:
In http://slashdot.org/comments.pl?sid=150560&cid=126 36090 [slashdot.org], you wrote "We were talking about Javascript not Python" as if there were a difference. Since the dominant implementation of Python does not compile to machine code, it is not different in kind from JS.
Now you have the nerve to quote selectively and try the freshman-law-school trick of putting your misquoted words in my mouth. I'll write this only once more: JS and Python do not differ in their commonly-used implementations being "interpreted" (not compiled to machine code) -- that's exactly what I said explicitly, quoted above.
So *of course* I am not saying that there is no difference between two commonly interpreted programming languages. Somehow I doubt you are this dense, but the alternative interpretation makes you a troll. Give me a better choice.
But seriously, my point is that it doesn't make sense to write javascript code for nearly every application just because HTML and HTTP don't provide the needed functionality.
Of course if we were going to skip the browser completely (as your comment hints) we'd better off using a compiled language than an interpreted one like Javascript.
True, you never bothered to say "speed" when going on in this and other posts (replying to an a.c. who grew as impatient as I have with your evasive vagueness), in answer to the question begged by your assertion that a language's practical implementation being compiled was "quite relevent to what language we might choose". If you were not saying "compiled" for speed, then for what other benefit of compilation over interpretation?
We weren't talking about Python Period. It doesn't matter whether it was compiled, interpreted or shredded.
You can't even keep your own shoddy, fallacy-ridden argument straight.
In http://slashdot.org/comments.pl?sid=150560&cid=126 36090, you wrote "We were talking about Javascript not Python" as if there were a difference. Since the dominant implementation of Python does not compile to machine code, it is not different in kind from JS.
It's as if we were arguing about whether the internal combustion engine was too low-powered compared to a jet engine for a certain application involving roads and moderate speeds, and you said "we were talking about BMW not Saab". BMW and Saab both make cars that perform fine on roads at moderate speeds. The fact that both BMW and Saab can produce (or have in the past produced) jet engines proves nothing about whether the application we were arguing about requires jet engines.
Then in http://slashdot.org/comments.pl?sid=150560&cid=126 47749 you wrote "The fact that Python is both compiled and interpreted and Javascript is only interpreted (in practice) is quite relevent to what language we might choose."
This shows more confusion. Python is not used in a compiled-to-machine-code way by most people, and the existence of IronPython and other compiling or JITting implementations does not say anything about whether a browser scripting language must be compiled. What's more, JavaScript can be and is compiled to machine code in some settings (.NET). That too proves nothing one way or the other about the compiled vs. interpreted requirements on browser scripting languages.
Now was that sufficiently pedantic for you?
It was finally sufficiently clear and direct for me to conclude that you don't know what you are talking about.
There is zero "evidence" (I invite you to produce some to the contrary) that interpreted languages are "too slow" for scripting tasks, including JS in web browsers.
As I wrote earlier, the Mozilla JS engine has never shown up dominating the critical path of any user-level task. It can start to show up in heavy DHTML profiles, but even then it's almost always second to the DOM native code that it is calling, which is the critical path blocker. Thoughtful analysis of these DHTML profiles shows not that we need to compile JS, but that such DHTML hard cases need better graphics primitives, so they don't have to use div tags and scripted CSS positioning for lots of few-pixels-wide sprites.
All other major browser implementations use the same level of JS interpretation (bytecode) or an even less efficiently-compiled level (parse tree walking), from what I have learned talking to closed source (MS, Opera) colleagues, and looking at other open source (Apple) browsers.
The fact is (to return to the analogy you invited) that you don't need a jet engine to get from point A to point B in town, and asserting or implying over and over that jet engines are faster than internal combustion engines doesn't prove anything about the requirements of the application (getting around town, or browser scripting languages) over which we were arguing.
Compiling can be faster than interpreting -- but may not be, for very short programs that execute zero to a few times. Did you ever consider this case, which arises often in JS embedded in HTML? Apparently not.
Web browser scripting does not require compilation to machine code in general. Sophomoric arguments of the form "compiled is always faster than interpreted, faster is always better" are false on at least two counts.
We were talking about Javascript not Python. How many browsers support client-side compiled Javascript?
Just answer the question: by "compiled" do you mean compiled to machine code? If so, then your "not Python" was nonsense, since the dominant Python implementation does not compile to machine code.
Please say exactly what "compiled" meant in your earlier posts, and why it was important in your earlier posts.
we'd better off using a compiled language than an interpreted one like Javascript.
Do you mean compiled to machine code, or to an interpreted bytecode? Do you know what you are even talking about?
Clue #1: Traditional Python is compiled to an interpreted intermediate form, not to machine code.
Clue #2: JS in Mozilla clients is compiled to bytecode, which is interpreted.
Clue #3: JS in some browsers is compiled to IL which may be JITted. Does that make such a browser one whit better for end users? Time will tell, but I doubt the answer has anything to do with "compiled" vs. "interpreted".
The JS interpreter in Mozilla has *never* been on the critical path of the schedule for any particular high latency user-initiated task.
And where have you been? What exactly have you done? I created JavaScript and the DOM, then co-founded mozilla.org and helped it get to the current, over-hyped (but welcome anyway) poster-child-for-open-source status that all the herd of independent thinkers who used to dump on the project have now bestowed on it.
My comment to the reporter was the truth: at least marca and I spoke explicitly about people building web apps in the browser, in JS, that didn't make whole-page round trips to the server; that had advanced graphics (via Java, we thought -- oh well); that had a rich set of HTML and other UI primitives.
See web.archive.org and look for hidaho.com from late '95 through '96.
As I posted elsewhere, any fool with half a brain could see that potential future. It wasn't prescience, but it apparently looks like so amazing a prediction to you, that you presume I'm faking it to grab "glory".
Here's a clue for you: AJAX is a bogus term which I reject, or at least try to ignore so as not to waste even more time debating its meaning and merit. I don't give a rat's ass about glory attaching to my name from it or anything else so hype-ridden. When a reporter asks an obvious question with an equally obvious answer, I don't feel the need to lie so you'll feel less outraged, or insecure, or whatever's wrong with you.
Oh, more blink whining -- the sign of an insecure position. Get over it. It has been over ten years.
What two versions of the JS object model do you mean? Are you sure you're not mixing up the DOM (never fully standardized by w3 members) with the core language?
No, read comment 202 -- this bug was fixed, thanks to jst implementing something based on an idea I pitched after I wrote comment 158, in Firefox 1.0 and Mozilla 1.7.x (x in the future still, but soon). It's not fixed in Camino, but it could be./be
Ok, I composed plain text but posted as HTML by accident, and this is a repost. Here's a hint to make up for that goof: the VP that I believe scc meant was not around for Netscape's IPO, but was acquired later. Hint 2: the acquisition had nothing to do with anything in Netscape 4.
A lot of ignorance about Mozilla and web pages here, but I'll comment only on this item:
(2) As it happens, most web pages probably are built with XHTML 1, since that is simply the XML version of HTML 4 - and since an enormous number of web pages nowadays will be being generated using XML processing they will therefore be using XHTML 1.
The vast majority of web pages, > 99%, and irrespective of how they were generated, are not well-formed XHTML 1.
Too many such pages are tag soup from the old or even recent days. Anyone who has built *and shipped* a browser to millions of web users knows this -- ask Gecko, KHTML, and Trident hackers.
Web pages are served as text/html. Even if such a page were actually XHTML 1, browsers would have to treat it as tag soup, were it served via text/html. See http://www.hixie.ch/advocacy/xhtml.
Recent Mozilla Firefox libtxxpath_s.a size -t output (x86_64 gcc -Os):
text data bss dec hex filename 91988 4576 0 96564 17934 (TOTALS)
MSVC6 optimized is 60893 text, 61491 text+data.
This XPath implementation was contributed as part of Transformiix, by Keith Visco et al., in 2000. It has been extended to track DOM Level 3. There is more to the XPath specs than can be implemented with a few regexps, but it's not 150k on any x86 platform.
XPath is in Mozilla, has been for years. The XPath extensions needed by XForms look easy enough, although no one has signed up to do them yet.
Schema-based node validation is not in Mozilla. No one has come up with a plan yet to integrate an existing validator. T. V. Raman has suggested using Xerces wholesale, but the footprint hit seems big (1MB was a guesstimate). This is the big ticket item in the work to be done. Volunteers who know their way around Mozilla and Xerces would be ideal.
XML Events support is being implemented now, and should be done soon, provided the incomplete spec issues can be settled with the w3c, or by reasonable inference based on DOM precedent (never a safe thing with under-tested, _de jure_ standards).
Apart from these pieces, XForms needs only some generalization of Mozilla's form submission code, and the XForms processor itself. No one has signed up for these tasks yet.
Strategic analysis:
To understand how the Mozilla/Opera effort results in simplification, you should recall your own words in Mozilla's layout newsgroup, where you argued that XForms is a compelling feature in enterprise settings, not on the Web. The Mozilla/Opera effort is about the Web. Content authors for web pages do not generally need to know all the XML standards required by XForms, let alone know XForms. This is unlikely to change, given IE's dominance and the lack of free/small XForms plugins for it.
Developers who use XForms must be working for businesses and other organizations who have intranet or vertical markets in which the right plugin or extended client (Mozilla, maybe) has been deployed. Web developers who use Web Forms 2.0 and other specs resulting from the whatwg.org effort need only use next year's Opera, Mozilla, Safari, or HTC-extended IE.
Two different developer markets, two different approaches to forms. Or at least two -- Adobe and Microsoft are doing their own, non-XForms, non-HTML or -evolved-HTML forms. The proprietary approaches are more likely leak onto the web in a few years if the whatwg.org effort fails.
My later bug comment on likelihood reflects my judgment that people are not willing to build XForms "on top of the platform", so it won't be small enough -- or that it won't be built at all, because there's no point in anyone investing in a Mozilla-only implementation.
That judgment has nothing to do with my and some other drivers' statement that we would turn XForms on in the default build if it were small enough. One is an assessment of odds. The other is a "what if [the long odds event occurred]" position. Do you see the difference now?
One more point: my attempts to lay down ground rules in the XForms bug about under what conditions the code would be included as an extension, or turned on by default, were not meant to advocate for or against XForms (or MNG, or any other such rarely-used-on-the-web thing).
My comments on the w3c were, as you say, advocacy -- counter-advocacy, to be precise. That's a prerogative I claim from being a project founder and leader, but I'll try not to abuse it. Still, I didn't start it, and I meant to finish it in that bug. Thanks for cooperating, for your part. See you in news://news.mozilla.org/netscape.public.mozilla.la yout, or another Mozilla newsgroup.
I'll repeat for the last time that Mozilla will take an XForms implementation that builds on the existing code. If it's small enough, several drivers@mozilla.org including me have said we'd ship it in the default build.
I have never heard you say this before, which is why I asked about it. I re-read your comments in bugzilla and I see you talking (comments #71, #80) about reasons why it might be undesirable, but none that say what it would take to include it. It appears you've either softened your stance, or I misunderstood it.
You need to read better. See http://bugzilla.mozilla.org/show_bug.cgi?id=XForms #c26, my second paragraph, quoted here:
I would join roc, as a driver@mozilla.org, in wanting to take a performant, low
overhead, smoothly integrated implementation of XForms, provided jkeiser and
other Gecko owners and peers agree (cc'ing dbaron, he should be in on this too).
Since XHTML 2.0 has been done in Mozilla using only XBL/JS (see
http://w3future.com/weblog/gems/xhtml2.xml), why can't XForms be done, as roc
suggested, using XBL? Do we need to revive the stalled XBL form control work,
to have scriptable interfaces for form submission?
Who will own this bug? A bug assigned to nobody@mozilla.org is not going to get
re-targeted from the Future.
Notice the low comment number. Reading the whole bug to which you are coming late may help keep you from spitting bile at me unjustly.
I'm tired of repeating myself. I don't "recoil" at reasoned consideration of any spec, and for that reason Mozilla implements many w3c recommendations. But no one should bow down before a standards body blindly, especially not a minority market-share browser vendor that cannot cause content authors to increase the support of standards simply by spending (considerable) scarce resources on implementing the long list of w3c recommendations, out of blind faith in magic standards fairies causing the world to change for the better.
Here's yet another fact: XForms is not new. Four years in the standards process, about a year and a half at CR (Conditional Recommendation, which is a greenlight to implementors). Good luck to it, it needs it.
Take a closer look. XAML is just XML, but it maps 1:1 to "WinFX" class instances, and attributes map to properties, methods, and events. It's another CLR source language, but a terrific one for the easy-programming crowd of graphic designers, web content hackers, VB consultants, etc.
It's trivial to extend XAML with C# or any other CLR source language, too.
Your XML reprocessor is going to do *what*, exactly, when it encounters some inline C#? And to what are you going to translate the whizzy graphics, animations, videos, and other effects?
XAML is just the surface, an easy-to-use XUL + Flash language. Scratch below that and you get the Avalon engine and the.NET runtime. That combination is not something lying around on today's Linux, and not something you can whip up in an evening.
Although Mono gives us a good start on half of the substance behind XAML....
Then change the mozilla mission statement so that it doesn't include "standards compliance" as one of its points. A standard is inhernetly an authority. If you want to reject W3C, then you are appointing yourself as the authority.
We are not arguing about religion here. Each of us, including you and me if we are to communicate usefully, has to use reason, not authority, to persuade one another. There are so many standards in the world, including ones that contradict other standards, that "a standard is inherently an authority" is a false statement.
Your appeal to the w3c as the sole judge of "standards", and your interpretation of Mozilla's mission statement to mean that Mozilla must implement whatever the w3c recommends, is therefore unreasonable. There are standards from the w3c that we try to implement (CSS 2.1, DOM, HTML 4). These are actually used on the web, along with way too much IE DOM and tag-soup from the old days.
There are other standards that suffer from the w3c's design-by-committee, years-long lead-time, and inconsistent-with-other-w3c-standards problems I have cited, but that still hold enough promise that Mozilla is evaluating them based on reason, not faith. Among these are SVG.
XForms is a different case, for these reasons:
It is a large spec, requiring extra declarations and more indirection, therefore hard for the average web designer to learn and use.
It depends on XPath, XML Schemas, and many other new standards that most browsers don't support and most authors don't know.
It is therefore not well-tested in the market, and it is not being adopted much -- there is no significant demand for it.
No top-four browser apart from Mozilla is likely to implement it.
The plugins that implement it are not selling well enough to grow the XForms market, Oracle and Novell to the contrary notwithstanding. The tide may turn, but there's no sign of it yet.
Server-side translators that turn XForms into DHTML create a substandard experience in all respects, including for XForms authors (no real client-side DOM for the XForms XML, e.g.).
Adobe, Macromedia, and others are doing their own advanced forms standards.
These are all facts. They have nothing to do with evil me and my blowhard opinions. You can quibble with my summary of them, but they won't go away. Where there is smoke, there is fire. So why not drop the ad hominem arguments and the appeals to your mullahs in France?
The rest of your message shows an inability to read accurately. For example, I never said "everyone is going to be using XAML in a few years".
If Oracle wanted to waste money on native XForms support in Mozilla, they would have done that already; we have a good relationship with Oracle. Obviously, they favor a plugin because it can work in IE, which they must target. Adding a native implementation in Mozilla gains them very little, and costs a lot. Porting the IE-targeted plugin makes better business sense, although they have not approached us about that.
I'm sorry you think votes in bugzilla should decide anything. Fortunately, they don't. But volunteer effort can and does provide alteratives and extensions, and I'll repeat for the last time that Mozilla will take an XForms implementation that builds on the existing code. If it's small enough, several drivers@mozilla.org including me have said we'd ship it in the default build.
Thanks for the reply, it's useful. A few quick points:
I agree that Apple could make money porting more than iTunes to Windows, but they won't, and you're right that Linux has not matched the Apple apps and OS features people want most. Not for lack of trying, either.
But if GNOME, say, were to set off in a "let's clone OS X and its killer apps" direction, they *still* would not raise the migration rate on PCs from Windows much. People who want a Mac, get a Mac. (This is essentially your argument against cloning XAML.) PCs are dirt-cheap, and to get users to switch from Windows, users need workalike "hot, new" (what you mean by killer) apps and "daily essential" (what I mean by "killer") apps such as browsers , device plug-n-play, and even lower total cost of ownership.
Unfortunately, studies I've seen say that Linux desktops do not have lower TCO. And not for want of consistent user interface among apps, or fancy desktop GUIs.
BTW, no Mozilla leader has proposed cloning XAML, so don't worry about us wasting time on that.
Mozilla Foundation is indeed doing cross-platform app-development, as you suggest. But to do more apps, we would need to raise capital. In the mean time, other avenues of funding that don't require us to grow horizontally are competing for our attention. And volunteers and entrepreneurs such as Daniel Glazman are free to help do more apps.
I will push to make sure our HTML editor app story gets better soon.
Slashdot Mirror
Mozilla Foundation is already a 501(c)(3) and has been for two years. We are not going to reincorporate it as another kind of non-profit. For one thing, we have received, and we will continue to receive, charitable donations.
/be
Your response, with its dramatic use of bold, seems to be saying "gotcha". Got what? Why exactly do you think that the Mozilla Foundation should be a 501(c)(4)?
The issue with non-profits in the US is not about accruing "private profits" but about the type of activities pursued for the non-profit's "public benefit purpose". "Acting as if" we were a for-profit entity is a problem, even if we never accrued private profits and never distributed them somehow to the owners (in this case, the Mozilla Foundation is the sole owner).
So even if we act to further our public-benefit purpose, and distribute funds as grants, or otherwise avoid profit-taking, if our action in the market and with partners resembles for-profit commercial activity, we may lose our non-profit status. That is something the Foundation does not want to risk.
This is the main reason for the reorganization.
Yes, it means Firefox is making money, and in ways that may put us in the position of "acting as if" we are a for-profit commercial entity.
No, we will not start charging for Firefox or any of our other free (beer and speech) products.
My point was that JS ought to respond to feedback in its niches, not stay unchanged for years on end (as it has, apart from bug fixes). I agree it doesn't need six legs or two heads. But "evolve" -- as in "respond to feedback from users" -- means more than "bug fixing". See my roadmap blog for more on this.
Here's the design decision you hate: a JS object is a single-namespace collection of properties, each mapping a string to an arbitrary value. I made that decision quickly, but consciously, so I'll take blame. "Brain-dead" is too strong, though. Is Python "brain-dead" for lacking real closures (see http://store.yahoo.com/paulgraham/icadmore.html/)?
Using strings as property names helps users who commonly want to map "1" and 1 to the same value in an object (not necessarily an Array object -- any object).
If (as you seem to want) JS had mapped value to value, treating all strings of the same length and characters as a single identity, but also mapping objects, numbers, booleans, etc. according to some equivalence relation (you probably want ===, which maps -0 and 0 to the same equivalence class; you must treat all NaNs as the same not-a-number), then many users would have to say String(1) or Number("1") where today they do not. Users would have had to write anArray[Number(aForm.anInput.value)] -- a lot.
The influence I acted under came from awk. JS's design target was string-oriented processing in scripts embedded in client and server markup language processing. It seemed better to simplify the object model by defining property identifier as string-typed, with implicit conversion, than to allow arbitrary values mapped under some more complicated non-identity equivalence relation.
From your later comment, it seems you believe that this decision requires comparing string keys when looking up 1 or "1" -- not so. It's trivial to optimize non-negative integer property identifiers that fit in machine-word containers from string to int when storing, accessing via hash tables, etc. A JS Array indexing from 0 to 2^30 - 1 in the Mozilla JS engine, SpiderMonkey, requires no string storage for the element ids, only for the interned 'length' property id. Methods, as you note, are stored in the same namespace, but not in each instance -- rather, in this example, only once, in Array.prototype.
This is the result of a very few design decisions carried to their conclusions, with simplicity given greater weight than almost any other good. A mistake? Sure -- and worse, incomplete due to the rushing (as with Python, JS has had to evolve some corrections and necessary limbs). But not brain-dead.
FYI, if you want to map names such as a["width"] = 1, a["breadth"] = 2, don't use an Array. Use an Object. To count these properties, you can use __count__ in SpiderMonkey. I never got near to persuading the ECMA working group to think about standardizing this extension. Using the standard, you have to count, with a var n=0; for (var i in a) ++n; loop.
Listen, idiot: I clearly wrote "our mistake" and put a rueful joke at our expense about "putting the Java in JavaScript", so I'm obviously not proud of cloning Gosling's y2k mistake. There's nothing there to brag about, and you must be tone-deaf to misread my post that way.
You can toady for MS all you want, but the fact that it used standards bodies to come from behind Netscape in the mid-to-late nineties does not take away from its abuse of monopoly, and utter lack of standards-following on the web, since IE took majority browser market share.
Of course the *FullYear methods were implemented in a version of IE before ECMA approved 262 -- MS was playing nice and leading the standards charge when it suited its business interests. Oh, and FYI: everyone involved in ECMA TG1, including Guy Steele of Sun, had the same desire to fix the y2k bugs cloned from java.util.Date, so MS (or you, if you're not working for MS) can't claim exclusive credit for such obvious fixes.
Fullsome praise for acting with naked self-interest stands the usual ideas of noblesse oblige on their head. They're saints now for not acting selflessly? What crap.
Microsoft has perpetrated its share of y2k-level mistakes too. No one is infallible, so snipe and suck up consistently, or again you will look like a paid toady. Or keep it up -- paid toady would be more respectable than unpaid.
Standardization follows implementation here, and in many cases. Where standardizers wait to implement, and instead design on paper and by consensus, you usually get something bigger, slower, and later than if implementors had competed, or taken first base by moving fast and doing a good enough job.
I'm hoping to avoid design-by-committee bloating ECMA-262 Edition 4. Wish me luck!
We thereby inherited obvious y2k bugs, and soon enough, Sun deprecated java.util.Date in favor of a Calendar class. But for a time, our mistake really put the "Java" in "JavaScript". :-/.
ECMA-262 standardized these getYear/setYear methods only in a non-normative annex, and added getFullYear, setFullYear, etc., as required parts of the ECMA-262 standard. Netscape and therefore Mozilla have supported these methods since then, so I have no idea why you think Microsoft JScript differs from our implementation in conforming to the spec.
(Clues: ECMA-262 Edition 3 specifically allows for added methods and other properties in standard objects, and backward compatibility required keeping these y2k-bug methods back when Netscape had market share.)
Another point of confusion: many companies belonging to ECMA contributed to ECMA-262, including Microsoft. Parodying a *GASP* that no informed person would ejaculate looks like silly I'm-so-clever-I-can-defend-MS-on-slashdot posing.
Spare us, and while you are at it, educate yourself about the history of the ECMAScript standard and its Date methods.
Now you have the nerve to quote selectively and try the freshman-law-school trick of putting your misquoted words in my mouth. I'll write this only once more: JS and Python do not differ in their commonly-used implementations being "interpreted" (not compiled to machine code) -- that's exactly what I said explicitly, quoted above.
So *of course* I am not saying that there is no difference between two commonly interpreted programming languages. Somehow I doubt you are this dense, but the alternative interpretation makes you a troll. Give me a better choice.
You certainly did claim, in the post at http://slashdot.org/comments.pl?sid=150560&cid=126 25420, that any programming language required where HTML and HTTP aren't sufficient should be "compiled". Here's the full quote:
True, you never bothered to say "speed" when going on in this and other posts (replying to an a.c. who grew as impatient as I have with your evasive vagueness), in answer to the question begged by your assertion that a language's practical implementation being compiled was "quite relevent to what language we might choose". If you were not saying "compiled" for speed, then for what other benefit of compilation over interpretation?You can't even keep your own shoddy, fallacy-ridden argument straight.
In http://slashdot.org/comments.pl?sid=150560&cid=126 36090, you wrote "We were talking about Javascript not Python" as if there were a difference. Since the dominant implementation of Python does not compile to machine code, it is not different in kind from JS.
It's as if we were arguing about whether the internal combustion engine was too low-powered compared to a jet engine for a certain application involving roads and moderate speeds, and you said "we were talking about BMW not Saab". BMW and Saab both make cars that perform fine on roads at moderate speeds. The fact that both BMW and Saab can produce (or have in the past produced) jet engines proves nothing about whether the application we were arguing about requires jet engines.
Then in http://slashdot.org/comments.pl?sid=150560&cid=126 47749 you wrote "The fact that Python is both compiled and interpreted and Javascript is only interpreted (in practice) is quite relevent to what language we might choose."
This shows more confusion. Python is not used in a compiled-to-machine-code way by most people, and the existence of IronPython and other compiling or JITting implementations does not say anything about whether a browser scripting language must be compiled. What's more, JavaScript can be and is compiled to machine code in some settings (.NET). That too proves nothing one way or the other about the compiled vs. interpreted requirements on browser scripting languages.
It was finally sufficiently clear and direct for me to conclude that you don't know what you are talking about.
There is zero "evidence" (I invite you to produce some to the contrary) that interpreted languages are "too slow" for scripting tasks, including JS in web browsers.
As I wrote earlier, the Mozilla JS engine has never shown up dominating the critical path of any user-level task. It can start to show up in heavy DHTML profiles, but even then it's almost always second to the DOM native code that it is calling, which is the critical path blocker. Thoughtful analysis of these DHTML profiles shows not that we need to compile JS, but that such DHTML hard cases need better graphics primitives, so they don't have to use div tags and scripted CSS positioning for lots of few-pixels-wide sprites.
All other major browser implementations use the same level of JS interpretation (bytecode) or an even less efficiently-compiled level (parse tree walking), from what I have learned talking to closed source (MS, Opera) colleagues, and looking at other open source (Apple) browsers.
The fact is (to return to the analogy you invited) that you don't need a jet engine to get from point A to point B in town, and asserting or implying over and over that jet engines are faster than internal combustion engines doesn't prove anything about the requirements of the application (getting around town, or browser scripting languages) over which we were arguing.
Compiling can be faster than interpreting -- but may not be, for very short programs that execute zero to a few times. Did you ever consider this case, which arises often in JS embedded in HTML? Apparently not.
Web browser scripting does not require compilation to machine code in general. Sophomoric arguments of the form "compiled is always faster than interpreted, faster is always better" are false on at least two counts.
Please say exactly what "compiled" meant in your earlier posts, and why it was important in your earlier posts.
Do you mean compiled to machine code, or to an interpreted bytecode? Do you know what you are even talking about?
Clue #1: Traditional Python is compiled to an interpreted intermediate form, not to machine code.
Clue #2: JS in Mozilla clients is compiled to bytecode, which is interpreted.
Clue #3: JS in some browsers is compiled to IL which may be JITted. Does that make such a browser one whit better for end users? Time will tell, but I doubt the answer has anything to do with "compiled" vs. "interpreted".
The JS interpreter in Mozilla has *never* been on the critical path of the schedule for any particular high latency user-initiated task.
Do you have enough clues yet?
My comment to the reporter was the truth: at least marca and I spoke explicitly about people building web apps in the browser, in JS, that didn't make whole-page round trips to the server; that had advanced graphics (via Java, we thought -- oh well); that had a rich set of HTML and other UI primitives.
See web.archive.org and look for hidaho.com from late '95 through '96.
As I posted elsewhere, any fool with half a brain could see that potential future. It wasn't prescience, but it apparently looks like so amazing a prediction to you, that you presume I'm faking it to grab "glory".
Here's a clue for you: AJAX is a bogus term which I reject, or at least try to ignore so as not to waste even more time debating its meaning and merit. I don't give a rat's ass about glory attaching to my name from it or anything else so hype-ridden. When a reporter asks an obvious question with an equally obvious answer, I don't feel the need to lie so you'll feel less outraged, or insecure, or whatever's wrong with you.
No, read comment 202 -- this bug was fixed, thanks to jst implementing something based on an idea I pitched after I wrote comment 158, in Firefox 1.0 and Mozilla 1.7.x (x in the future still, but soon). It's not fixed in Camino, but it could be. /be
Nope. Next guess?
Ok, I composed plain text but posted as HTML by accident, and this is a repost. Here's a hint to make up for that goof: the VP that I believe scc meant was not around for Netscape's IPO, but was acquired later. Hint 2: the acquisition had nothing to do with anything in Netscape 4.
> No, the likely candidate is Mike Homer. Nope. Next guess? /be
Too many such pages are tag soup from the old or even recent days. Anyone who has built *and shipped* a browser to millions of web users knows this -- ask Gecko, KHTML, and Trident hackers.
Web pages are served as text/html. Even if such a page were actually XHTML 1, browsers would have to treat it as tag soup, were it served via text/html. See http://www.hixie.ch/advocacy/xhtml.
This XPath implementation was contributed as part of Transformiix, by Keith Visco et al., in 2000. It has been extended to track DOM Level 3. There is more to the XPath specs than can be implemented with a few regexps, but it's not 150k on any x86 platform.
Technical details:
XPath is in Mozilla, has been for years. The XPath extensions needed by XForms look easy enough, although no one has signed up to do them yet.
Schema-based node validation is not in Mozilla. No one has come up with a plan yet to integrate an existing validator. T. V. Raman has suggested using Xerces wholesale, but the footprint hit seems big (1MB was a guesstimate). This is the big ticket item in the work to be done. Volunteers who know their way around Mozilla and Xerces would be ideal.
XML Events support is being implemented now, and should be done soon, provided the incomplete spec issues can be settled with the w3c, or by reasonable inference based on DOM precedent (never a safe thing with under-tested, _de jure_ standards).
Apart from these pieces, XForms needs only some generalization of Mozilla's form submission code, and the XForms processor itself. No one has signed up for these tasks yet.
Strategic analysis:
To understand how the Mozilla/Opera effort results in simplification, you should recall your own words in Mozilla's layout newsgroup, where you argued that XForms is a compelling feature in enterprise settings, not on the Web. The Mozilla/Opera effort is about the Web. Content authors for web pages do not generally need to know all the XML standards required by XForms, let alone know XForms. This is unlikely to change, given IE's dominance and the lack of free/small XForms plugins for it.
Developers who use XForms must be working for businesses and other organizations who have intranet or vertical markets in which the right plugin or extended client (Mozilla, maybe) has been deployed. Web developers who use Web Forms 2.0 and other specs resulting from the whatwg.org effort need only use next year's Opera, Mozilla, Safari, or HTC-extended IE.
Two different developer markets, two different approaches to forms. Or at least two -- Adobe and Microsoft are doing their own, non-XForms, non-HTML or -evolved-HTML forms. The proprietary approaches are more likely leak onto the web in a few years if the whatwg.org effort fails.
My later bug comment on likelihood reflects my judgment that people are not willing to build XForms "on top of the platform", so it won't be small enough -- or that it won't be built at all, because there's no point in anyone investing in a Mozilla-only implementation.
That judgment has nothing to do with my and some other drivers' statement that we would turn XForms on in the default build if it were small enough. One is an assessment of odds. The other is a "what if [the long odds event occurred]" position. Do you see the difference now?
One more point: my attempts to lay down ground rules in the XForms bug about under what conditions the code would be included as an extension, or turned on by default, were not meant to advocate for or against XForms (or MNG, or any other such rarely-used-on-the-web thing).
My comments on the w3c were, as you say, advocacy -- counter-advocacy, to be precise. That's a prerogative I claim from being a project founder and leader, but I'll try not to abuse it. Still, I didn't start it, and I meant to finish it in that bug. Thanks for cooperating, for your part. See you in news://news.mozilla.org/netscape.public.mozilla.la yout, or another Mozilla newsgroup.
I'm tired of repeating myself. I don't "recoil" at reasoned consideration of any spec, and for that reason Mozilla implements many w3c recommendations. But no one should bow down before a standards body blindly, especially not a minority market-share browser vendor that cannot cause content authors to increase the support of standards simply by spending (considerable) scarce resources on implementing the long list of w3c recommendations, out of blind faith in magic standards fairies causing the world to change for the better.
Here's yet another fact: XForms is not new. Four years in the standards process, about a year and a half at CR (Conditional Recommendation, which is a greenlight to implementors). Good luck to it, it needs it.
It's trivial to extend XAML with C# or any other CLR source language, too.
Your XML reprocessor is going to do *what*, exactly, when it encounters some inline C#? And to what are you going to translate the whizzy graphics, animations, videos, and other effects?
XAML is just the surface, an easy-to-use XUL + Flash language. Scratch below that and you get the Avalon engine and the .NET runtime. That combination is not something lying around on today's Linux, and not something you can whip up in an evening.
Although Mono gives us a good start on half of the substance behind XAML....
We are not arguing about religion here. Each of us, including you and me if we are to communicate usefully, has to use reason, not authority, to persuade one another. There are so many standards in the world, including ones that contradict other standards, that "a standard is inherently an authority" is a false statement.
Your appeal to the w3c as the sole judge of "standards", and your interpretation of Mozilla's mission statement to mean that Mozilla must implement whatever the w3c recommends, is therefore unreasonable. There are standards from the w3c that we try to implement (CSS 2.1, DOM, HTML 4). These are actually used on the web, along with way too much IE DOM and tag-soup from the old days.
There are other standards that suffer from the w3c's design-by-committee, years-long lead-time, and inconsistent-with-other-w3c-standards problems I have cited, but that still hold enough promise that Mozilla is evaluating them based on reason, not faith. Among these are SVG.
XForms is a different case, for these reasons:
It is a large spec, requiring extra declarations and more indirection, therefore hard for the average web designer to learn and use.
It depends on XPath, XML Schemas, and many other new standards that most browsers don't support and most authors don't know.
It is therefore not well-tested in the market, and it is not being adopted much -- there is no significant demand for it.
No top-four browser apart from Mozilla is likely to implement it.
The plugins that implement it are not selling well enough to grow the XForms market, Oracle and Novell to the contrary notwithstanding. The tide may turn, but there's no sign of it yet.
Server-side translators that turn XForms into DHTML create a substandard experience in all respects, including for XForms authors (no real client-side DOM for the XForms XML, e.g.).
Adobe, Macromedia, and others are doing their own advanced forms standards.
These are all facts. They have nothing to do with evil me and my blowhard opinions. You can quibble with my summary of them, but they won't go away. Where there is smoke, there is fire. So why not drop the ad hominem arguments and the appeals to your mullahs in France?
The rest of your message shows an inability to read accurately. For example, I never said "everyone is going to be using XAML in a few years".
If Oracle wanted to waste money on native XForms support in Mozilla, they would have done that already; we have a good relationship with Oracle. Obviously, they favor a plugin because it can work in IE, which they must target. Adding a native implementation in Mozilla gains them very little, and costs a lot. Porting the IE-targeted plugin makes better business sense, although they have not approached us about that.
I'm sorry you think votes in bugzilla should decide anything. Fortunately, they don't. But volunteer effort can and does provide alteratives and extensions, and I'll repeat for the last time that Mozilla will take an XForms implementation that builds on the existing code. If it's small enough, several drivers@mozilla.org including me have said we'd ship it in the default build.
I agree that Apple could make money porting more than iTunes to Windows, but they won't, and you're right that Linux has not matched the Apple apps and OS features people want most. Not for lack of trying, either.
But if GNOME, say, were to set off in a "let's clone OS X and its killer apps" direction, they *still* would not raise the migration rate on PCs from Windows much. People who want a Mac, get a Mac. (This is essentially your argument against cloning XAML.) PCs are dirt-cheap, and to get users to switch from Windows, users need workalike "hot, new" (what you mean by killer) apps and "daily essential" (what I mean by "killer") apps such as browsers , device plug-n-play, and even lower total cost of ownership.
Unfortunately, studies I've seen say that Linux desktops do not have lower TCO. And not for want of consistent user interface among apps, or fancy desktop GUIs.
BTW, no Mozilla leader has proposed cloning XAML, so don't worry about us wasting time on that.
Mozilla Foundation is indeed doing cross-platform app-development, as you suggest. But to do more apps, we would need to raise capital. In the mean time, other avenues of funding that don't require us to grow horizontally are competing for our attention. And volunteers and entrepreneurs such as Daniel Glazman are free to help do more apps.
I will push to make sure our HTML editor app story gets better soon.