javascript is good
in [JavaScript]
|
From: Dmitry A. Soshnikov on 10 Aug 2010 13:13 On 09.08.2010 22:40, Ry Nohryb wrote: > On Aug 9, 7:49 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com> > 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.
From: Dmitry A. Soshnikov on 10 Aug 2010 13:31 On 10.08.2010 11:33, Stone Zhong wrote: > On Aug 9, 10:49 am, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com> > 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.
From: Stefan Weiss on 13 Aug 2010 21:10
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"<dmitry.soshni...(a)gmail.com> >> 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/ -- stefan |