From: RobG on
On Feb 1, 11:19 am, Jorge <jo...(a)jorgechamorro.com> wrote:
[...]
> Any ideas as for what would be a reasonable, short C vs. JS
> benchmark ? :-)

Is there any point?

Such comparisons only really matter where you have a choice of doing
something in both languages and other criteria for discrimination are
(more-or-less) equal.

For example, if the objective is a program that can be downloaded and
run in most browsers, C is probably a not a consideration no matter
how much faster it runs. On the other hand, if the requirement is for
complex server-side processing, javascript probably isn't in the race
as it doesn't have any built-in input/output mechanism and is
dependent on a suitable host environment. If requirements indicate a
scripting language, a platform-native shell script may be the best
choice.

Do you have a proposed scenario?


--
Rob
From: RobG on
On Feb 2, 2:13 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> RobG wrote:
> > denis wrote:
> >> Please have a look at the FOLDOC (http://foldoc.org/) definition of
> >> JavaScript:http://foldoc.org/javascript
> >> and send any comments or corrections via the feedback button. Thanks.
>
> > There doesn't seem to be much to recommend it at all. How can a
> > definition of JavaScript be considered complete if it doesn't mention
> > ECMAScript? Or the standards involved? Nor does it attempt to
> > distinguish between JavaScript, the trade mark, and the generic term
> > "javascript" used to describe ECMAScript implementations that interact
> > with DOMs, mostly in browsers.
>
> The term "javascript" is the invention of a wannabe here that failed to see
> the differences between the many implementations, and fell into common use
> because of other wannabes here that failed to or did not want to see them..

Regardless of its heritage, it is by far the most popular general term
for the various ECMAScript implementations. If agreement could have
been reached to use Netscape's trademark for the standard, it would be
called JavaScript.

But that was not to be, so JavaScript is a Sun trademark and the name
used by Mozilla for one of its ECMAScript implementations.
Consequently it is necessary to distinguish (here) between the generic
term "javascript" and the specific implementation or trademark
"JavaScript".


> > | (Formerly "LiveScript") Netscape's simple,
>
> > What are the criteria for "simple"? If the criterion is features
> > provided by the base language, then ECAMScript is more complex than C,
> > but C is not described as simple.
>
> Perhaps simple as compared to Java, because that was the intention for
> creating it.

So you agree that some criterion for "simple" should be included in
the statement.


> > | cross-platform,
>
> > That might be better as "platform independent".
>
> It is neither.

It's not designed for any specific platform (where "platform" is taken
to be an operating system and hardware combination) so it fits my
definition of platform independence.

Do you have a suggested improvement?


> > | World-Wide Web scripting language, only very vaguely
> > | related to Java
>
> > It isn't related to Java at all, at least not any more than it's
> > related to say C.
>
> Incorrect. JavaScript™ was designed to be a Java-like scripting language;

I don't think Java had much influence on JavaScript at all. From the
quotes I've seen from Brendan Eich, the link with Java was just
chance. Netscape were developing a simple scripting language for
browsers. Java was released at about the same time (1995) as he was
working on Mocha, which became LiveScript and then JavaScript in the
space of about 6 months.

Changing the name and linking it to Java was mostly a marketing
exercise when Netscape teamed up with Sun to leverage the hype
surrounding Java[1], so I don't think there was a specific intention
to be "Java-like".

[...]
> > | (which is a Sun trademark).
>
> > So is JavaScript.
>
> And that does not make you think?

That JavaScript is simplified Java? No. Sun wanted to protect the name
Java and JavaScript, so they acquired the trademark. I don't see any
link between the languages as a consequence.

And the article doesn't mention that JavaScript is a Sun trademark.


> > | JavaScript is intimately tied to the World-Wide Web,
>
> > More correctly, it is used most commonly for scripting in browsers on
> > the World Wide Web.
>
> If you adopt the position that this dictionary entry should not only
> describe JavaScript™, but also JScript aso.,

I don't.

> you have to take into account
> that there is Server-Side JavaScript on NES-compatible servers, and
> Service-side JScript (.NET) in ASP (.NET).

Yes, but those uses are far less common than the use in browsers.


> Therefore, the statement above is correct, and your "more correct" version
> is in fact "less correct".

No, it's not. You seem to have missed the phrase "used most commonly",
or misread it as "used exclusively".


> > | and currently runs in only three environments
>
> > If you are talking specifically about JavaScript(tm), perhaps.
>
> You do know what a dictionary is, don't you?

I don't understand your point. There is an assertion that javascript
runs in *only* three environments, I provided additional environments
(as did you) to show the statement is incorrect. A dictionary should
not contain errors of fact so the statement should be corrected.


[...]
> > | JavaScript originated from Netscape and, for a time,
> > | only their products supported it. Microsoft now supports
> > | a work-alike which they call JScript.
>
> > Now? For at least 15 years,
>
> You are exaggerating. JScript 1.0 was released with Internet Explorer 3.0
> for Windows in 1996-08 (CE).

Ok, 13 years and 5 months and perhaps a few days, as of 2010-02-02.
And counting...


[...]
> The language standard for JavaScript is ECMAScript. That holds true
> whether we adopt your position that this entry should also be about
> other implementations of ECMAScript or not.
>
> > There are standards for ECMAScript
>
> Nonsense. ECMAScript *is* (the name of) the standard.

Ok, there's a standard with a couple of versions.

[...]
> Yes, those guesses are non-encyclopedic. The statement is also wrong
> because it has been established (citing Brendan Eich and Eric Lippert)
> that J(ava)Script is _not_ "purely interpreted", and never has been.

I didn't assert that it is "purely interpreted", the emphasis is
yours. Clearly some implementations are going to compile it to make it
faster, I agree Lasse's interpretation of "interpreted".

[...]
>
> > | Netscape and Sun have co-operated to enable Java and
> > | JavaScript to exchange messages and data.
>
> > That seems to be a very out dated comment.
>
> No, it still holds true.

Yes, but the statement seem to infer that is the only development
worth mentioning.

[...]
> I am therefore glad that your comments will probably have no impact on
> FOLDOC since they have been made in the wrong place.


Even though you agreed with some of them and provided useful criticism
of others? I intend to send feedback as requested in the OP, but am
glad to have had my comments reviewed here first. Thank you for
contributing.

1. <URL: http://www.infoworld.com/d/developer-world/javascript-creator-ponders-past-future-704
>


--
Rob
From: kangax on
On 2/1/10 11:13 AM, Thomas 'PointedEars' Lahn wrote:
> RobG wrote:
[...]
>> | This could be attributed to the slow progress of JavaScript
>> | through the standards bodies.
>>
>> But there is no standard for JavaScript, it's just a trade mark.
>
> The language standard for JavaScript is ECMAScript. That holds true
> whether we adopt your position that this entry should also be about
> other implementations of ECMAScript or not.
>
>> There are standards for ECMAScript
>
> Nonsense. ECMAScript *is* (the name of) the standard.

Not exactly.

The name of the standard is *ECMA-262*, not ECMAScript. ECMAScript is a
name of the *language* (defined by ECMA-262 standard).

[...]

--
kangax
From: Thomas 'PointedEars' Lahn on
RobG wrote:

> Thomas 'PointedEars' Lahn wrote:
>> RobG wrote:
>> > denis wrote:
>> >> Please have a look at the FOLDOC (http://foldoc.org/) definition of
>> >> JavaScript:http://foldoc.org/javascript
>> >> and send any comments or corrections via the feedback button.
>> >> Thanks.
>> > There doesn't seem to be much to recommend it at all. How can a
>> > definition of JavaScript be considered complete if it doesn't mention
>> > ECMAScript? Or the standards involved? Nor does it attempt to
>> > distinguish between JavaScript, the trade mark, and the generic term
>> > "javascript" used to describe ECMAScript implementations that interact
>> > with DOMs, mostly in browsers.
>> The term "javascript" is the invention of a wannabe here that failed to
>> see the differences between the many implementations, and fell into
>> common use because of other wannabes here that failed to or did not want
>> to see them.
>
> Regardless of its heritage, it is by far the most popular general term
> for the various ECMAScript implementations. If agreement could have
> been reached to use Netscape's trademark for the standard, it would be
> called JavaScript.
>
> But that was not to be, so JavaScript is a Sun trademark and the name
> used by Mozilla for one of its ECMAScript implementations.
> Consequently it is necessary to distinguish (here) between the generic
> term "javascript" and the specific implementation or trademark
> "JavaScript".

However, it is a mistake to use one term for all the implementations that
does not make it obvious that several languages are being discussed (by
contrast to, e.g. "ECMAScript implementation*s*"). AISB, "javascript"
promotes the common misconception of the one scripting language where there
are in fact several, different ones that need to be considered when writing
especially client-side script code (not considering non-ECMAScript-
compliant ones, of course).

>> > | (Formerly "LiveScript") Netscape's simple,
>>
>> > What are the criteria for "simple"? If the criterion is features
>> > provided by the base language, then ECAMScript is more complex than C,
>> > but C is not described as simple.
>> Perhaps simple as compared to Java, because that was the intention for
>> creating it.
>
> So you agree that some criterion for "simple" should be included in
> the statement.

No.

>> > | cross-platform,
>>
>> > That might be better as "platform independent".
>>
>> It is neither.
>
> It's not designed for any specific platform (where "platform" is taken
> to be an operating system and hardware combination) so it fits my
> definition of platform independence.
>
> Do you have a suggested improvement?

Omission.

>> > | World-Wide Web scripting language, only very vaguely
>> > | related to Java
>>
>> > It isn't related to Java at all, at least not any more than it's
>> > related to say C.
>>
>> Incorrect. JavaScript™ was designed to be a Java-like scripting
>> language;
>
> I don't think Java had much influence on JavaScript at all.

Of course not. You misunderstand.

> From the quotes I've seen from Brendan Eich, the link with Java was just
> chance.

Read again.

> Netscape were developing a simple scripting language for
> browsers. Java was released at about the same time (1995) as he was
> working on Mocha, which became LiveScript and then JavaScript in the
> space of about 6 months.
>
> Changing the name and linking it to Java was mostly a marketing
> exercise when Netscape teamed up with Sun to leverage the hype
> surrounding Java[1], so I don't think there was a specific intention
> to be "Java-like".

Regardless what you think, that is what it was. The name and syntax was
_not_ chosen by mere coincidence, nor is the statement of "Java-like" there
in the Specification since ECMAScript Edition 1 by mere chance.

> [...]
>> > | (which is a Sun trademark).
>> > So is JavaScript.
>> And that does not make you think?
>
> That JavaScript is simplified Java? No. [...]

Then you are a fool.

> And the article doesn't mention that JavaScript is a Sun trademark.

So what?

>> > | JavaScript is intimately tied to the World-Wide Web,
>>
>> > More correctly, it is used most commonly for scripting in browsers on
>> > the World Wide Web.
>>
>> If you adopt the position that this dictionary entry should not only
>> describe JavaScript™, but also JScript aso.,
>
> I don't.

Yes, you do. This dictionary entry is specifically about JavaScript™, yet
you by your own account you want it to contain more elaborate descriptions
about this "javascript" fantasy, JScript, ActionScript aso. That does not
belong there, it belongs in the entries about "javascript", JScript, and
ActionScript aso., if that.

>> you have to take into account
>> that there is Server-Side JavaScript on NES-compatible servers, and
>> Service-side JScript (.NET) in ASP (.NET).
>
> Yes, but those uses are far less common than the use in browsers.

Stop making assumptions, show some facts for a change. Your assumptions
do not belong any more in that entry than the original author's about JS
speed.

>> Therefore, the statement above is correct, and your "more correct"
>> version is in fact "less correct".
>
> No, it's not. You seem to have missed the phrase "used most commonly",
> or misread it as "used exclusively".

No, I didn't.

>> > | and currently runs in only three environments
>>
>> > If you are talking specifically about JavaScript(tm), perhaps.
>>
>> You do know what a dictionary is, don't you?
>
> I don't understand your point.

This entry is about JavaScript, not about any delusions of "javascript".

> There is an assertion that javascript runs in *only* three environments,
> [...]

There is no assertion about a "javascript" there at all!

> [...]
>> The language standard for JavaScript is ECMAScript. That holds true
>> whether we adopt your position that this entry should also be about
>> other implementations of ECMAScript or not.
>>
>> > There are standards for ECMAScript
>>
>> Nonsense. ECMAScript *is* (the name of) the standard.
>
> Ok, there's a standard with a couple of versions.

_Editions_, and _revisions_ of those (most notably, revisions ES3 and ES3F,
and editions ES1 to 3, and ES5).

> [...]
>> Yes, those guesses are non-encyclopedic. The statement is also wrong
>> because it has been established (citing Brendan Eich and Eric Lippert)
>> that J(ava)Script is _not_ "purely interpreted", and never has been.
>
> I didn't assert that it is "purely interpreted", [...]

But the original author did. Learn to read.

> [...]
>>
>> > | Netscape and Sun have co-operated to enable Java and
>> > | JavaScript to exchange messages and data.
>>
>> > That seems to be a very out dated comment.
>>
>> No, it still holds true.
>
> Yes, but the statement seem to infer that is the only development
> worth mentioning.

In your dreams.

> [...]
>> I am therefore glad that your comments will probably have no impact on
>> FOLDOC since they have been made in the wrong place.
>
> Even though you agreed with some of them and provided useful criticism
> of others?

Yes. Hopefully this discussion will help to sort out all the
misconceptions that are so common about this language and these
languages first.

> I intend to send feedback as requested in the OP, but am
> glad to have had my comments reviewed here first. Thank you for
> contributing.

OK.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on
kangax wrote:

> Thomas 'PointedEars' Lahn wrote:
>> RobG wrote:
> [...]
>>> | This could be attributed to the slow progress of JavaScript
>>> | through the standards bodies.
>>>
>>> But there is no standard for JavaScript, it's just a trade mark.
>>
>> The language standard for JavaScript is ECMAScript. That holds true
>> whether we adopt your position that this entry should also be about
>> other implementations of ECMAScript or not.
>>
>>> There are standards for ECMAScript
>>
>> Nonsense. ECMAScript *is* (the name of) the standard.
>
> Not exactly.
>
> The name of the standard is *ECMA-262*, not ECMAScript. ECMAScript is a
> name of the *language* (defined by ECMA-262 standard).

You are mistaken. ECMA-262 is _not_ the name, it is merely the original
registry number. Another registry number for the standard of the same name
is ISO/IEC 16262:2002. Much as RFC0959 or STD 9 are only registry numbers
for the Internet Standard named File Transfer Protocol (FTP).


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>