javascript is good

[Stone Zhong]

Inspired by JavaScript, I am creating a scripting language/engine with
similar syntax to javascript, it is ideal for unix day-to-day
maintained or talking to database -- check it out at
http://www.stonezhong.net/os/index.html. If you are not interested,
pls ignore this message and I apologize for the spam.

 

[Michael Haufe (\TNO\)]

Inspired by JavaScript, I am creating a scripting language/engine with
similar syntax to javascript, it is ideal for unix day-to-day
maintained or talking to database -- check it out athttp://www.stonezhong..net/os/index.html. If you are not interested,
pls ignore this message and I apologize for the spam.

Why not just implement ES5 with Rhino style extensions instead of a
knock-off?

 

[Dmitry A. Soshnikov]

Inspired by JavaScript, I am creating a scripting language/engine with
similar syntax to javascript, it is ideal for unix day-to-day
maintained or talking to database -- check it out at
http://www.stonezhong.net/os/index.html. If you are not interested,
pls ignore this message and I apologize for the spam.

Looks interesting. Simplified by functionality and easy to learn, enough
for more-less complex scripting.

However, there are no some ideological concepts: closures, higher-order
function (or are they?), syntactic sugar for lists/array processing, and
so on. Are object mutable and dynamic? Is typing is dynamic?

So I wish good luck in this project and its development. It's not
necessary to repeat after existing languages. A better way -- to take
all good from them, and avoid all bad and old.

P.S.: also you may take a look on CoffeeScript (it removes some C-syntax
garbage from ES and provides some high-abstract sugar).

Dmitry.

 

[Ry Nohryb]

(...) (it removes some C-syntax
garbage from ES and provides some high-abstract sugar)

Nothing, *NO*THING* in C is garbage, Dmitry, my dear friend. !

 

[Stone Zhong]

Looks interesting. Simplified by functionality and easy to learn, enough
for more-less complex scripting.

However, there are no some ideological concepts: closures, higher-order
function (or are they?), syntactic sugar for lists/array processing, and
so on. Are object mutable and dynamic? Is typing is dynamic?

So I wish good luck in this project and its development. It's not
necessary to repeat after existing languages. A better way -- to take
all good from them, and avoid all bad and old.

P.S.: also you may take a look on CoffeeScript (it removes some C-syntax
garbage from ES and provides some high-abstract sugar).

Dmitry.

Thanks for the comments Dmitry.
Here are some points to clarify:

* closures
I am using a slightly different way, in OrangeScript, a function is
also a map, so a function can have it's own attributes. Instead of
allowing a function to access the variable defined outside the
function, I am consider these variable part of the function. Example
is:

var add = function {
var ret = function { return self["x"] + args[0]; };
ret::set_keys("x", args[0]);
return ret;
};
println(add(2)(3));

here, add(2) is a function, and apply it on 3 returns 5.

* syntactic sugar for lists
I do not have a forEach statement, it is easy to implement as a
function, for example:

var forEach = function {
for (var i = 0; i<args::get_length(); i = i + 1) {
args[1](args[0]);
}
};
forEach([1, 3, 2], function { println(args[0]); });

* All objects -- actually the are just map (aka hash table), yes, they
are dynamic
They can choose to not have "prototype", and member (function or non-
function value) can be set to other value at any time.
If you change an object's prototype, their behavior will change as
well.

- Stone

 

[Dmitry A. Soshnikov]

Nothing, *NO*THING* in C is garbage, Dmitry, my dear friend. !

In C -- maybe. But I said not about C, my dear friend, Jorge.

Dmitry.

 

[Dmitry A. Soshnikov]

Looks interesting. Simplified by functionality and easy to learn, enough
for more-less complex scripting.

However, there are no some ideological concepts: closures, higher-order
function (or are they?), syntactic sugar for lists/array processing, and
so on. Are object mutable and dynamic? Is typing is dynamic?

So I wish good luck in this project and its development. It's not
necessary to repeat after existing languages. A better way -- to take
all good from them, and avoid all bad and old.

P.S.: also you may take a look on CoffeeScript (it removes some C-syntax
garbage from ES and provides some high-abstract sugar).

Dmitry.

Thanks for the comments Dmitry.
Here are some points to clarify:

* closures
I am using a slightly different way, in OrangeScript, a function is
also a map, so a function can have it's own attributes. Instead of
allowing a function to access the variable defined outside the
function, I am consider these variable part of the function. Example
is:

var add = function {
var ret = function { return self["x"] + args[0]; };
ret::set_keys("x", args[0]);
return ret;
};
println(add(2)(3));

Yeah, I see. There's Python's ideology "explicit is better than
implicit". However, "too much explicit" often is less abstract and
brings unnecessary "noise", "syntactic garbage" to a code, diverting
from logical structure of a program to some syntactic constructions.

Yes, you may manually "set_keys" for all inner function (even avoiding
complete activation frame saving, but just needed vars -- although, I
think engines make optimizations for closures in such moments), but if
will be some more-less complex structure and many needed closured vars,
the program will suffer from this non-main-logical operation, but
syntactic "noise".

However, you have functions as first-class, and this is already good.

here, add(2) is a function, and apply it on 3 returns 5.

* syntactic sugar for lists
I do not have a forEach statement, it is easy to implement as a
function, for example:

var forEach = function {
for (var i = 0; i<args::get_length(); i = i + 1) {
args[1](args[0]);
}
};
forEach([1, 3, 2], function { println(args[0]); });

Yeah, and functions as I see are higher-order. Presence of first-class
higher-order functions means often presence of closures (in functional
languages at least or in languages which supports its paradigm, as e.g.
ECMAScript)

* All objects -- actually the are just map (aka hash table), yes, they
are dynamic
They can choose to not have "prototype", and member (function or non-
function value) can be set to other value at any time.
If you change an object's prototype, their behavior will change as
well.

Yep, delegation based inheritance with dispatching (used in ES). Another
prototype based model is concatenative as you know.

Dmitry.

 

[Michael Haufe (\TNO\)]

C-- ?

C-- was created as a target intermediate language for higher level
languages by Simon Peyton Jones (1997).
http://www.cminusminus.org/

I believe the initial demand for its creation was to support Haskell
better than the alternatives, though I don't believe this is the case
any longer.

 

[Ry Nohryb]

C-- ?

I've only been away for a week, and I've already missed the creation of
a new language. Jorge and Dmitry, my dear friends, I am confused!

Back on topic - the OP may want to look at CommonJS*. We're finally
getting to the point where plain old JS is becoming usable as a
server-side or standalone scripting language. Inventing new languages is
always fun, but in addition to the basic syntax, they'll need all kinds
of modules and adaptors (db access, file system access, threads, mail,
ldap, etc), many of which are already provided by CommonJS-compliant
projects.
If the main goal is to have a "unix day-to-day" scripting language based
on ECMAScript, CommonJS should be a hot candidate. On the other hand, it
may be more exciting to create an entirely new language anyway

*)http://www.commonjs.org/

"server-side or standalone scripting language" ?? -->> Node.js, of
course...

 

[Dmitry A. Soshnikov]

C-- ?

Whoop What a funny misunderstanding, sorry, my fault. It's just a
"dash". I didn't mean C--, I meant "Yeah, in C it's possibly so, but..."

I mostly meant (and I already mentioned it in this thread) that a new
language should forward to higher and higher abstraction (although, "the
highest" (e.g. just like a talk with a human) is also possibly won't be
good, because it will lose a generality of abstract description of a
program). But, that's mostly a philosophy.

More exactly I said that in my opinion C's syntax has some "noise" or
inefficient (from the human readability and logic viewpoint!) constructs
(so, they are efficient at the implementation level). And every language
which completely borrows some C's constructs (to be "known and
intuitive" for new programmers) -- Java, JS, PHP etc. "forget" that C
could use such ugly construct because of /problems and issues/ of e.g.
code generation at the implementation level.

Of of such constructs is a "very noisy" C' /switch-case/ construction.
You don't have a human-logical explanation why it works so non-logical
in its control-flow. Why you should pollute your code with that "noise"
like every time to put that useless (again, from the human viewpoint)
/break/ keyword after each case. Why, if you forget that "break", the
control-flow will catch all other cases even if your testing value is
not in this case? Why the "default:" section, being placed not at the
end and without that useless "break" will again carry you through all
/not your/ cases?

But all this becomes very-logical if we look at the auto-generated
assembly code. There all conditions are put at the beginning and after
that described all evaluation blocks of every conditions. And then just
/jmp/'s to the needed block. In every block, if you put "break",
unconditional "jmp" is generated to the end of the whole switch-case
construction address. This seems efficient from the machine viewpoint.
If you don't put "break", consequently, there is no "jmp" is generated
and you get into the next (not your!) block (the next address after the
end of your block).

Is it design mistake? Or they couldn't do it better at the code
generation level? Don't know.

But why then, JS, being written at least in C (a high abstract language)
should borrow that "ugliness" because its "syntax-ancestor", C, have it
because its own problems?

That's why I like Coffee's/Ruby's switch-case better:

http://jashkenas.github.com/coffee-script/#switch

Explicit semicolon, you understand it, is also a
"syntactic-noise/garbage". It should be done by the machine, if needed
(if there is no new line terminator e.g.). In well-written ASI mechanism
(which is used in many languages) it plays a good role. I use of course
explicit semicolon in JS, but, juts as a habit mostly (a habit related
with concrete known issues of course). But I think, I wouldn't if there
were know that issues.

I've only been away for a week, and I've already missed the creation of
a new language. Jorge and Dmitry, my dear friends, I am confused!

Yeah

Back on topic - the OP may want to look at CommonJS*. We're finally
getting to the point where plain old JS is becoming usable as a
server-side or standalone scripting language. Inventing new languages is
always fun, but in addition to the basic syntax, they'll need all kinds
of modules and adaptors (db access, file system access, threads, mail,
ldap, etc), many of which are already provided by CommonJS-compliant
projects.
If the main goal is to have a "unix day-to-day" scripting language based
on ECMAScript, CommonJS should be a hot candidate. On the other hand, it
may be more exciting to create an entirely new language anyway


*) http://www.commonjs.org/

There are many good scripting languages, yeah, every can be used for
"day-to-day" scripting. And writing of the own is a good programming
task: design and technical.

Dmitry.

 

[Stone Zhong]

Whoop What a funny misunderstanding, sorry, my fault. It's just a
"dash". I didn't mean C--, I meant "Yeah, in C it's possibly so, but..."

I mostly meant (and I already mentioned it in this thread) that a new
language should forward to higher and higher abstraction (although, "the
highest" (e.g. just like a talk with a human) is also possibly won't be
good, because it will lose a generality of abstract description of a
program). But, that's mostly a philosophy.

More exactly I said that in my opinion C's syntax has some "noise" or
inefficient (from the human readability and logic viewpoint!) constructs
(so, they are efficient at the implementation level). And every language
which completely borrows some C's constructs (to be "known and
intuitive" for new programmers) -- Java, JS, PHP etc. "forget" that C
could use such ugly construct because of /problems and issues/ of e.g.
code generation at the implementation level.

Of of such constructs is a "very noisy" C' /switch-case/ construction.
You don't have a human-logical explanation why it works so non-logical
in its control-flow. Why you should pollute your code with that "noise"
like every time to put that useless (again, from the human viewpoint)
/break/ keyword after each case. Why, if you forget that "break", the
control-flow will catch all other cases even if your testing value is
not in this case? Why the "default:" section, being placed not at the
end and without that useless "break" will again carry you through all
/not your/ cases?

But all this becomes very-logical if we look at the auto-generated
assembly code. There all conditions are put at the beginning and after
that described all evaluation blocks of every conditions. And then just
/jmp/'s to the needed block. In every block, if you put "break",
unconditional "jmp" is generated to the end of the whole switch-case
construction address. This seems efficient from the machine viewpoint.
If you don't put "break", consequently, there is no "jmp" is generated
and you get into the next (not your!) block (the next address after the
end of your block).

Is it design mistake? Or they couldn't do it better at the code
generation level? Don't know.

But why then, JS, being written at least in C (a high abstract language)
should borrow that "ugliness" because its "syntax-ancestor", C, have it
because its own problems?

That's why I like Coffee's/Ruby's switch-case better:

http://jashkenas.github.com/coffee-script/#switch

Explicit semicolon, you understand it, is also a
"syntactic-noise/garbage". It should be done by the machine, if needed
(if there is no new line terminator e.g.). In well-written ASI mechanism
(which is used in many languages) it plays a good role. I use of course
explicit semicolon in JS, but, juts as a habit mostly (a habit related
with concrete known issues of course). But I think, I wouldn't if there
were know that issues.


Yeah



There are many good scripting languages, yeah, every can be used for
"day-to-day" scripting. And writing of the own is a good programming
task: design and technical.

Dmitry.

<quote>There are many good scripting languages, yeah, every can be
used for "day-to-day" scripting. And writing of the own is a good
programming task: design and technical.</quote>

This is very true. I have to agree I do not know CommonJS and Mozilla
Rhino at the beginning. But it is a good practice to build a scripting
engine and realize the challenge. The purpose of a language is to
express logic, in that sense, a better language can express more
abstract logic -- I believe the way human thinking is too complicated
for any existing computer language to express :-(, a good way to
express the problem is almost important as solving the problem.

About C junk, hmm, I am breathing it every day so I do not even
realize there are junks in C, it is a good discussion that opens my
mind and directs me to think about such topics, sorry the discussion
has been deviated from JavaScript too far...

 

[Ry Nohryb]

(...)
About C junk, hmm, I am breathing it every day so I do not even
realize there are junks in C (...)

C is the best. Long live the C !

 

[Dmitry A. Soshnikov]

C is the best. Long live the C !

C is good, nobody said it's junk. I said that some /higher/ abstracted
(than C) languages repeating (cloning) completely constructions used in
C, possibly (if you wish ) do it not the best way. Because they can do
it better. From the usability viewpoint, but not the machine viewpoint.
That exactly the way of increasing the abstraction.

At the same time I don't say that low-abstracted languages are bad or
obsolete. No, if there will be question of performance, they will help.
Although, new hardware and good code generation may lead that higher
abstracted languages may be (possibly) even faster.

And mentioned above /switch-case/ was just an example. There are also
/reversed meaning/ alternatives for that "break" (e.g. some versions of
Perl, which uses vice-versa "continue" if want to "fall through" to
other blocks).

Can be interesting: http://en.wikipedia.org/wiki/Switch_statement

Moreover, regarding exactly C's switch, there is even some interesting
hacks based on that "missing break" features. E.g. "Duff's device" --
http://en.wikipedia.org/wiki/Duff's_device.

And C, of course, is not a junk. All its constructions can be quickly
become habitual. The other question, that more usable and easy-to-read,
easy/shorter-to-write constructions, more logical-control-flow, etc.
constructions can be invented based on analysis of "bad parts" of
previous languages.

But yeah, this talk is already off-topic about C, so I conclude

Dmitry.

 

[Scott Sauyet]

Inspired by JavaScript, I am creating a scripting language/engine with
similar syntax to javascript, it is ideal for unix day-to-day
maintained or talking to database -- check it out athttp://www.stonezhong.net/os/index.html. If you are not interested,
pls ignore this message and I apologize for the spam.

Like Stefan, I've been gone for a while, in my case, two weeks. Looks
like I missed some fun.

This looks to be a very interesting language. I hope I have time to
play with it soon.

One suggestion about the documentation. The Coffeescript page linked
to earlier is much easier to learn from than the snippets on your
site. If you really want a tree for mavigation, perhaps it could
simply help scroll through a large document in the content area.

Nice job, though!

 

[Ry Nohryb]

C is good, nobody said it's junk. I said that some /higher/ abstracted
(than C) languages repeating (cloning) completely constructions used in
C, possibly (if you wish ) do it not the best way. Because they can do
it better. From the usability viewpoint, but not the machine viewpoint.
That exactly the way of increasing the abstraction.

At the same time I don't say that low-abstracted languages are bad or
obsolete. No, if there will be question of performance, they will help.
Although, new hardware and good code generation may lead that higher
abstracted languages may be (possibly) even faster.

And mentioned above /switch-case/ was just an example. There are also
/reversed meaning/ alternatives for that "break" (e.g. some versions of
Perl, which uses vice-versa "continue" if want to "fall through" to
other blocks).

Can be interesting:http://en.wikipedia.org/wiki/Switch_statement

Moreover, regarding exactly C's switch, there is even some interesting
hacks based on that "missing break" features. E.g. "Duff's device" --http://en.wikipedia.org/wiki/Duff's_device.

And C, of course, is not a junk. All its constructions can be quickly
become habitual. The other question, that more usable and easy-to-read,
easy/shorter-to-write constructions, more logical-control-flow, etc.
constructions can be invented based on analysis of "bad parts" of
previous languages.

But yeah, this talk is already off-topic about C, so I conclude

Dmitry, C is like a wheel: there's no need to reinvent it, nor to
modify it, because it works wonderfully as it is: round...

 

[Dmitry A. Soshnikov]

Dmitry, C is like a wheel: there's no need to reinvent it, nor to
modify it, because it works wonderfully as it is: round...

<mega-off-topic>

Of course. Crude meat which first people ate in caves also was also a
food (and even is today in restaurants, with a blood -- as a delicacy
). For what to invent something else, e.g. fried meat? Because crude
meat does what it does -- feeds the people.

But I don't compare C with crude meat As I said, C is good (and will
be good for some/long time in the future). I just answer on your
unwillingness to see alternatives, and possibly good alternatives.

E.g. JS can't already change some syntax because of backward comptats. I
mentioned recently discussion of Brendan Eich from 2003 where `with'
instruction already at that time was deprecated. And only after 7 years
it is officially marked as obsolete and deprecated. But even with
marking it as obsolete they still afraid to remove it completely because
of that "mega-powerful thing" -- backward compatibilities.

Possibly, JS wants to rearrange, reorganize something, but can't. And
one of good ways to do this -- is to invent a new language which takes
all good parts and excludes all bad parts (as e.g. CoffeeScript does
regarding JavaScript).

The one who doesn't go forward, that goes back. Nobody stands at the
current place.

</mega-off-topic>

Dmitry.

 

[Ry Nohryb]

(...)
The one who doesn't go forward, that goes back. Nobody stands at the
current place.

Except Chuck Norris and the C language.