javascript is good

Discussion in 'Javascript' started by Stone Zhong, Aug 9, 2010.

  1. Stone Zhong

    Stone Zhong Guest

    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.
     
    Stone Zhong, Aug 9, 2010
    #1
    1. Advertising

  2. On Aug 8, 11:52 pm, 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 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?
     
    Michael Haufe (\TNO\), Aug 9, 2010
    #2
    1. Advertising

  3. 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.
     
    Dmitry A. Soshnikov, Aug 9, 2010
    #3
  4. Stone Zhong

    Ry Nohryb Guest

    On Aug 9, 7:49 pm, "Dmitry A. Soshnikov" <>
    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.
     
    Ry Nohryb, Aug 9, 2010
    #4
  5. Stone Zhong

    Stone Zhong Guest

    On Aug 9, 10:49 am, "Dmitry A. Soshnikov" <>
    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]);
    }
    };
    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
     
    Stone Zhong, Aug 10, 2010
    #5
  6. On 09.08.2010 22:40, Ry Nohryb wrote:
    > On Aug 9, 7:49 pm, "Dmitry A. Soshnikov"<>
    > 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.
     
    Dmitry A. Soshnikov, Aug 10, 2010
    #6
  7. On 10.08.2010 11:33, Stone Zhong wrote:
    > On Aug 9, 10:49 am, "Dmitry A. Soshnikov"<>
    > 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]);
    > }
    > };
    > 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.
     
    Dmitry A. Soshnikov, Aug 10, 2010
    #7
  8. On Aug 13, 8:10 pm, Stefan Weiss <> 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.
     
    Michael Haufe (\TNO\), Aug 14, 2010
    #8
  9. Stone Zhong

    Ry Nohryb Guest

    On Aug 14, 3:10 am, 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"<>
    > >> 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.
     
    Ry Nohryb, Aug 14, 2010
    #9
  10. 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"<>
    >>> 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.
     
    Dmitry A. Soshnikov, Aug 14, 2010
    #10
  11. Stone Zhong

    Stone Zhong Guest

    On Aug 14, 2:40 am, "Dmitry A. Soshnikov" <>
    wrote:
    > 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"<>
    > >>> 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.


    <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...
     
    Stone Zhong, Aug 17, 2010
    #11
  12. Stone Zhong

    Ry Nohryb Guest

    On Aug 17, 10:05 am, Stone Zhong <> wrote:
    > (...)
    > 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 !
    --
    Jorge.
     
    Ry Nohryb, Aug 17, 2010
    #12
  13. On 17.08.2010 13:13, Ry Nohryb wrote:
    > On Aug 17, 10:05 am, Stone Zhong<> wrote:
    >> (...)
    >> 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 !


    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.
     
    Dmitry A. Soshnikov, Aug 17, 2010
    #13
  14. Stone Zhong

    Scott Sauyet Guest

    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 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!

    --
    Scott
     
    Scott Sauyet, Aug 19, 2010
    #14
  15. Stone Zhong

    Ry Nohryb Guest

    On Aug 17, 4:27 pm, "Dmitry A. Soshnikov" <>
    wrote:
    > On 17.08.2010 13:13, Ry Nohryb wrote:
    >
    > > On Aug 17, 10:05 am, Stone Zhong<>  wrote:
    > >> (...)
    > >> 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 !

    >
    > 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... :)
    --
    Jorge.
     
    Ry Nohryb, Aug 20, 2010
    #15
  16. On 20.08.2010 11:15, Ry Nohryb wrote:
    > On Aug 17, 4:27 pm, "Dmitry A. Soshnikov"<>
    > wrote:
    >> On 17.08.2010 13:13, Ry Nohryb wrote:
    >>
    >>> On Aug 17, 10:05 am, Stone Zhong<> wrote:
    >>>> (...)
    >>>> 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 !

    >>
    >> 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... :)


    <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.
     
    Dmitry A. Soshnikov, Aug 20, 2010
    #16
  17. Stone Zhong

    Ry Nohryb Guest

    On Aug 20, 10:03 am, "Dmitry A. Soshnikov"
    <> wrote:
    > (...)
    > The one who doesn't go forward, that goes back. Nobody stands at the
    > current place.


    Except Chuck Norris and the C language.
    --
    Jorge.
     
    Ry Nohryb, Aug 20, 2010
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sikka noel
    Replies:
    8
    Views:
    437
    Mike Wahler
    Aug 5, 2003
  2. vlsidesign
    Replies:
    26
    Views:
    1,042
    Keith Thompson
    Jan 2, 2007
  3. Cliff  Martin
    Replies:
    1
    Views:
    3,080
    Larry Smith
    Jan 31, 2007
  4. SM
    Replies:
    9
    Views:
    529
  5. Casey Hawthorne
    Replies:
    18
    Views:
    653
    Beej Jorgensen
    Nov 6, 2009
Loading...

Share This Page