Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > javascript is good

Reply
Thread Tools

javascript is good

 
 
Stone Zhong
Guest
Posts: n/a
 
      08-09-2010
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.
 
Reply With Quote
 
 
 
 
Michael Haufe (\TNO\)
Guest
Posts: n/a
 
      08-09-2010
On Aug 8, 11:52*pm, Stone Zhong <(E-Mail Removed)> wrote:
> 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?
 
Reply With Quote
 
 
 
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      08-09-2010
On 09.08.2010 8:52, Stone Zhong wrote:
> 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.
 
Reply With Quote
 
Ry Nohryb
Guest
Posts: n/a
 
      08-09-2010
On Aug 9, 7:49*pm, "Dmitry A. Soshnikov" <(E-Mail Removed)>
wrote:
> (...) (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. !
--
Jorge.
 
Reply With Quote
 
Stone Zhong
Guest
Posts: n/a
 
      08-10-2010
On Aug 9, 10:49*am, "Dmitry A. Soshnikov" <(E-Mail Removed)>
wrote:
> On 09.08.2010 8:52, Stone Zhong wrote:
>
> > 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.


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][i]);
}
};
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
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      08-10-2010
On 09.08.2010 22:40, Ry Nohryb wrote:
> On Aug 9, 7:49 pm, "Dmitry A. Soshnikov"<(E-Mail Removed)>
> wrote:
>> (...) (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. !


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

Dmitry.
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      08-10-2010
On 10.08.2010 11:33, Stone Zhong wrote:
> On Aug 9, 10:49 am, "Dmitry A. Soshnikov"<(E-Mail Removed)>
> wrote:
>> On 09.08.2010 8:52, Stone Zhong wrote:
>>
>>> 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.

>
> 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][i]);
> }
> };
> 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.
 
Reply With Quote
 
Michael Haufe (\TNO\)
Guest
Posts: n/a
 
      08-14-2010
On Aug 13, 8:10*pm, Stefan Weiss <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Ry Nohryb
Guest
Posts: n/a
 
      08-14-2010
On Aug 14, 3:10*am, Stefan Weiss <(E-Mail Removed)> wrote:
> On 10/08/10 19:13, Dmitry A. Soshnikov wrote:
>
> > On 09.08.2010 22:40, Ry Nohryb wrote:
> >> On Aug 9, 7:49 pm, "Dmitry A. Soshnikov"<(E-Mail Removed)>
> >> wrote:
> >>> (...) (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. !

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

>
> 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...
--
Jorge.
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      08-14-2010
On 14.08.2010 5:10, Stefan Weiss wrote:
> On 10/08/10 19:13, Dmitry A. Soshnikov wrote:
>> On 09.08.2010 22:40, Ry Nohryb wrote:
>>> On Aug 9, 7:49 pm, "Dmitry A. Soshnikov"<(E-Mail Removed)>
>>> wrote:
>>>> (...) (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. !

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

>
> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
good algorithms come with practice and reading good code/books? vlsidesign C Programming 26 01-02-2007 09:50 AM
Good slide scanning service vs. good slide scanner for Do-It-Yourself? LAshooter Digital Photography 0 06-25-2005 07:14 AM
Signs are good, but WAN no good =?Utf-8?B?bmV0bnV0?= Wireless Networking 2 08-21-2004 12:41 PM
JLO situation+ why fastglass is good+DSLR is good Hugo Drax Digital Photography 0 01-17-2004 11:41 PM
Not even a newbee. Good at school course. please advise good start sikka noel C++ 8 08-05-2003 06:43 AM



Advertisments