Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Google

Google's Dart Becomes ECMA's Dart 190

mikejuk writes "Google's Dart just reached version 1.0, but now it seems that it has aspirations to being an international standard. The question is will this make any difference to the language's future? Given that Google effectively owns Dart, what advantage does standardization bring? The answer to what Google thinks it brings is indicated in the Chromium blog: 'The new standardization process is an important step towards a future where Dart runs natively in web browsers.' and this seems reasonable. A standard is something that would be required before other browser makers decided to fall in line and support native Dart. It is probably a necessary but far from sufficient condition, however, with Microsoft, Apple and Mozilla having other interests to further. Last but not least, having the backing of a standard might just encourage possible users to believe that the language won't sink if Google gets distracted with other projects and decides that Dart is dispensable. However, a strong open source development community capable of supporting Dart without Google's input would be a better reassurance. If you want to help, Google would like you to join the committee. After all, it still doesn't have a Vice Chair. So can we expect to see ECMA CoffeeScript or TypeScript in the near future? Probably not."
This discussion has been archived. No new comments can be posted.

Google's Dart Becomes ECMA's Dart

Comments Filter:
  • ...as it doesn't become a Dodge Dart. [wikipedia.org]

  • by Anonymous Coward

    Go find an open source project that actually matters.

  • Who cares? (Score:2, Insightful)

    by Anonymous Coward

    Earlier versions of C# are also an ECMA standard, but nobody cares either way. It's like looking for a sales bullet point which doesn't make any practical difference.

    • Re:Who cares? (Score:4, Insightful)

      by StormReaver ( 59959 ) on Saturday December 14, 2013 @07:59PM (#45692155)

      Earlier versions of C# are also an ECMA standard, but nobody cares either way.

      More than that: after the OOXML ECMA debacle, no one takes ECMA seriously anymore. Submitting a standard to EMCA now is like announcing that your blue-chip company is selling penny stocks.

    • Earlier versions of C# are also an ECMA standard, but nobody cares either way. It's like looking for a sales bullet point which doesn't make any practical difference.

      Agreed but this might be more Mircosoft's fault than ECMA's:
      - MS did not bother to submit to ECMA any of the nice things that happened after .Net 2.0, like LINQ or async/await
      - The MS "Community Promise" not to assert patents on the standard is somewhat convoluted and lacking. It obviously doesn't cover anything past .Net 2,0
      Thus the ECMA .Net standard only allows you to implement a limited subset and .Net and maybe not be sued for patent infringement by Microsoft. Nothing indicates Google i

  • by Anonymous Coward

    Unless they can get Mozilla on board, It's just not enough.

    • by Anonymous Coward

      Mozilla will never get on board because Brendan Eich still thinks JavaScript is a decent language. Yes, he's that fucking retarded.

      • by narcc ( 412956 )

        So... what's wrong with it?

        • by HiThere ( 15173 )

          Well, for my purposes lacking file access is something that makes it unusable. I can understand why they don't have it, being as it was designed to be used in web pages, and mixing in file access has unpleasant security implications...unless you design it very carefully. But it still makes it unusable for my purposes.

          (Yes, a third party library could solve this problem. If I were interested enough. But I really prefer a compiled language over an interpreted one, even if I don't like C or C++.)

          • by narcc ( 412956 )

            It's more of an API issue than a language issue. Node.js offers a file system API, and the W3C File API has wide browser support.

            A third-party library simply isn't an option, as any such library would depend on the underlying API.

  • I don't much like Javascript, but I haven't taken the time to look Dart over.
    I do think the word standard should be better standardized.
    • The wonderful thing about standards is there are so many to choose from.
    • "I don't much like Javascript" translates to "I know very little or nothing about Javascript and I'm unwilling to learn".

      There - how about some honesty?

      PS: Obligatory link: http://www.youtube.com/results?search_query=douglas%20crockford&sm=3 [youtube.com]

      • by shutdown -p now ( 807394 ) on Sunday December 15, 2013 @01:45AM (#45693351) Journal

        No, it does not. It translates to "I know JavaScript rather well, but I also know several other languages", so I am capable of comparing things and seeing how many bad choices there are in JS language design.

        OTOH, the people who praise JS the language tend to be the guys who learned it after C or PHP, and who memorized that "JavaScript is like Lisp with curly braces" and accepted on faith that Lisp is uber awesome, without understanding what it all actually means - if you ask, they'll usually give you some canned reply along the lines of "it has first-class functions!!!1!!", as if it is somehow remarkable for a PL in today's age.

        • No, it does not. It translates to "I know JavaScript rather well, but I also know several other languages", so I am capable of comparing things and seeing how many bad choices there are in JS language design.

          However, when expressing such opinions on ./, it has become customary to omit what languages the poster is comparing the subject language against. Surely that only happens because the poster's great programming knowledge makes him forget that not everyone has similarly vast amount of experience and therefore is able to draw the same conclusions without presenting any actual comparison.

          • It is customary because virtually any other language in the same niche (dynamically typed "scripting" language) is sufficient to demonstrate the problems, except perhaps for PHP. Python, Ruby, Lua etc.

        • by HiThere ( 15173 )

          Well, Lisp *is* quite awesome. It's got a few problems that turn me off to it, but had it become popular early, they would have been fixed. (Some of it's documentation. Some of it's name usage. Some of it's naming conventions. I hate names like *This-is-a-special-variable* which, including asterisks, IS a valid Lisp name. And whether the case is significant is a compiler switch.)

          The problem with Lisp is that the libraries were never properly developed and standardized. JavaScript is something VERY di

          • Pretty much. The reason why Lisp comes up at all is that it's the poster child for higher-order functions and closures, so when people bring up this point with respect to JS, they say that it's "like Lisp" (or, sometimes, "like Scheme"). Of course, pretty much all mainstream languages are now "like Lisp" in that regard.

  • by Anonymous Coward

    If you like Java and can’t get yourself to like JavaScript, you program Dart.
    If you like Ruby and can’t get yourself to like JavaScript, you program CoffeeScript.
    If you like JavaScript, you program JavaScript.

    source [quirksmode.org]

  • Google is gaining way too much power over what you over the internet.

    The Internet is NOT google. They, Google, came along and appropriated a lot.
    And oh ueah, have yet to really show there is no partnership with others who might
    do user tracking not through software but through hardware.

    Listen: Google has NOT been in class with you!

    Oh, and all you MicroSofties: don't bother to chime in. I'm calling a spade a spade
    and you better not like it.
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      They created their own replacement for NPAPI plugins, and got Adobe to prefer it over NPAPI. Now they're not going to support NPAPI anymore in a year. As a result, Linux Flash is now only going to work on their browser, and it hasn't really improved the situation in Chrome enough to justify the switch.

      They didn't like other people's image formats, so they invented WebP, and got a lot of nickel-and-diming image hosters to start pressuring other browser vendors to support the format as if it's a proven tech..

      • HTTP2 not HTML2.

      • by swillden ( 191260 ) <shawn-ds@willden.org> on Saturday December 14, 2013 @06:59PM (#45691885) Journal

        Every one of your points is partially correct, but just wrong enough to make it misleading, and the combined effect is very misleading.

        They created their own replacement for NPAPI plugins, and got Adobe to prefer it over NPAPI. Now they're not going to support NPAPI anymore in a year. As a result, Linux Flash is now only going to work on their browser, and it hasn't really improved the situation in Chrome enough to justify the switch.

        Google's PPAPI fixes numerous problems with NPAPI, particularly around security, because NPAPI plugins run in the same process as the browser making them a perfect vector for compromising the security of the browser, and indeed many of the major NPAPI plugins are so riddled with security problems that Google blacklisted them some time ago. And it is those same security concerns that are driving Google's decision to deprecate NPAPI completely. This is a good thing and it will make the web safer. In addition, NPAPI standardizes the API and should make it possible for a single plugin to work with multiple browsers. The end result will be not only safer for users, but should actually encourage the creation of plugins, since they'll be more widely usable.

        With respect to Flash, Google didn't twist Adobe's arm. Adobe made its decisions for its own reasons; most likely because PPAPI is so much better to work with.

        They didn't like other people's image formats, so they invented WebP, and got a lot of nickel-and-diming image hosters to start pressuring other browser vendors to support the format as if it's a proven tech... even though it's a "standard" that has shifted so much it's turned into such a kitchen sink of a format that everyone will basically have to use their implementation.

        Again "didn't like" is misleading. The available image formats had serious deficiencies. Only GIF supported multi-frame animations, but did it in about the most inefficient way possible (storing each full frame, and compressing them individually with run-length encoding). JPEG works great for still images, but is far less efficient at compression than modern approaches, and also doesn't support layering, animations or transparency, and is limited to 24-bit color. JPEG2000 provided much more efficient compression, but lacked most everything else. PNG was pretty good at lossless stuff, but nothing else.

        And once again, Google didn't twist anyone's arms. It created a better image format, started supporting and using it, and then put it through the standardization process. Your implication that it's somehow "unproved tech" is rather laughable. It's not like there's any new technology there at all, just a better repackaging of what we already knew. And it's not a "kitchen" sink format at all. It supports both lossy and lossless modes, with variable bit depths and includes animation (because it's actually based on VP8, a video format, this was very easy). It's very flexible which means it's somewhat complex, but it's actually simpler than the raft of standards it's positioned to replace.

        They decided that Media Source Extensions were good enough that they could flip the switch on Youtube before other browsers were ready for it, thus rendering Firefox unable to play hi-def videos in HTML5 on Youtube.. though it was completely unnecessary to do so.

        I don't actually know anything about that situation. However, I suspect that your description is no more accurate than the others.

        They didn't like how long it was taking to make HTML2 so they invented SPDY. They then enabled it on the products that they popularized by using other people's standards, like Google Documents, thus forcing other browser vendors to support it or feel comparitively sluggish, even though HTML2 was coming along at the time anyway.

        And that's just the tip of the iceberg.

        In late 2012 the IETF HTTP committee solicited proposals from the industry, in competition

    • Re: (Score:2, Informative)

      by Anonymous Coward

      We currently have one of the largest Dart code bases and six full-time Dart devs, and when we asked about being allowed to run Dart on a server OS, their evangelist insulted us. He recommended we run Ubuntu on our servers since they decided Dart should require gcc 4.6+ and glibc 2.14 or newer. He said using Debian, SUSE, CentOS, or Red Hat is "what old people do." The kids running that company just don't damn get it.

      Of course, don't take my word on it. Look at how they just don't get it in the bug comme

      • So, people who actually want to get some work done are "old". Charming.

      • IDK why they don't just use a static musl-libc (or bionic) toolchain... it could even be included in the source tree.
      • Duh. This is what you get when you adopt unproven technology.

        *Real* old people use the stuff that were brought to market 10+ years ago.

    • Google is gaining way too much power over what you over the internet.

      I remember when the internet was pretty open, until Microsoft got their grubby hands on it with IE. At first everyone was happy because Microsoft was giving away a decent web browser for free. But then they got greedy... What did they do again? Ah right, they created their own "standard" language that was only adopted by their web browser.

      How quickly people forget the past.

      A web monopoly is never good, even if people think Google is friendly. Remember, Microsoft was once held in as high-ish regard is Google

  • I'm pretty sure the number of ads on that "I Programmer" page exceeds the limit Google specifies in their AdSense guidelines.

  • by Baldrson ( 78598 ) * on Saturday December 14, 2013 @06:26PM (#45691699) Homepage Journal
    When going to a new version of a language, the correct strategy is to come up with the highest level language one can conceivably jit-compile and rewrite the current language as syntactic sugars of the higher level language. "Pragmas" may be part of the sugaring (especially since there may be important pragmatic information provided by the lower level language) but it is better if the so-called "pragmas" are, instead, assertions written in the higher level language itself. The answer here is not a functional language but a relational one since functions are degenerate relations. Moreover, since one seeks to have assertions in the place of pragmas, the formal basis of the relational language should be sentence oriented. The sentence-oriented relational formalism most widely accepted across disciplines (including program specification) and with the most history is the predicate calculus. The brain-dead zombies will now start chanting things about Prolog even though it was never an implementation of the predicate calculus and tried to do things that probably should never have been attempted on a DEC-10 anyway. There are neo-zombies who will start chanting things about Erlang. Erlang is a bastardization of Prolog which is a bastardization of the predicate calculus. The best thing I can say about Erlang is that Mozart/Oz is much worse, being a bastardization of Erlang that is attempting to add relational constructs in without undoing the damage that Erlang did to Prolog -- when, in fact, they should have undone the whole mess, including Prolog, and gotten on with arranging a legitimate marriage of the predicate calculus with computers. If you are such a zombie, spare yourself the pain of reading further.

    So, here is the high level idea (despite the danger of inviting Prolog zombies I'll be using its syntax for the Horn Clause):

    The Idea

    Parallelism spawns independent computations.

    The Horn Clause:
    m(A,B,C):-x(A),y(B),z(C).
    expresses AND parallelism spawning 3 independent computations.

    The Horn Clause document:
    m(A):-x(A). m(A):-y(A). m(A):-z(A).
    expresses OR parallelism spawning 3 independent computations.

    In an operating system, parallel computations are scheduled for execution, allocating resources according to priorities.

    There are also computations which cannot be scheduled until the computations upon which they depend complete. The Horn Clause document:
    m(A,B,C):-m(A),m(B),m(C). m(A):-x(A). m(A):-y(A). m(A):-z(A).
    expresses 3 AND parallel computations, each depending on 3 independent OR parallel computations.

    This kind of data-dependency suspension of scheduling is also handled by operating systems.

    By focusing on these constructs:

    • AND parallelism
    • OR parallelism
    • Scheduling
    • Dependency suspension

    a radical reduction in semantic complexity can be realized.

    Tools

    Seymour Cray once said that much of engineering creativity comes from using old tools in never-before intended ways. The same is true of anything. New understanding of a thing's use is a way to create a new tool. Indeed, even when creating a new thing-in-itself as a tool (the ordinary means of creating a new tool), what comes first is its desired use. It is harmful to think about the fact that your hammer can be used as a paper-weight when you are pounding a nail into a piece of wood with a rock.

    With that in mind, let us properly-use the Horn Clause:

    • Branching is properly scheduled parallelism. This is even done in CPUs with instruction look-ahead threads and their abort.
    • Looping is either AND parallel recursion or it is properly scheduled OR parallelism.
    • Class hierarchy is properly scheduled polymorphism.
    • Polymorphism is OR parallelism.
    • Name space determination is word-sense disambiguation embodied in a particular choice among various clauses for the same predicate enjoying logical success.
    • Exception handling
    • Have you looked at Go?
  • I want to say I like Dart. I have translated some of my javascript stuff over to see how it compares. In many ways it is a big improvement. However, it still does things I hate about javascript. They are things that other people love like "you don't have to add semicolons but can but don't have to" or "functions in curly brackets with functions in curly brackets with functions... ad nauseam". They are all things I find to make code too difficult to read. I like the idea of the VM being in the browser

  • by Daniel Hoffmann ( 2902427 ) on Saturday December 14, 2013 @06:49PM (#45691829)

    People keep coming up with alternatives to javascript. Everything from whole languages that compile down to javascript, to building new languages into the browser, to javascript supersets, to plugins that makes your browser run compiled code. Not a single one of these caught on. The REAL problem is the DOM, the CSS and how they interact with each other. Javascript is a bad language, but it's not awful. What makes web development awful is the DOM and CSS with all its crazy and cross-browser incompatibilities. Why no one tries to replace THAT? I'm almost implementing myself a new api that runs on top of a 100% width/height canvas tag for christ sake.

    I'm not familiar with the Qt but QML ( http://en.wikipedia.org/wiki/QML [wikipedia.org] ) looks pretty good to me. Why can't browsers just implement that? Oh right, because it was not developed by google/m$/apple/mozilla so they can't guide it to the directions they want. Noooo, you have to have a completely new language that no one knows.

    If they want to replace javascript so much why don't they just take the python or ruby runtime, bundle it to the browser, sandbox it and add DOM mappings?

    • by BZ ( 40346 )

      Sandboxing the python runtime, say, means breaking most of the packages python developers take for granted, no?

    • Some people have a near religious approach about what a browser should do, and what it should not. For those guys, the browser is a piece of code that render a "document" ; this is by no mean a way to implement GUIs. The other part of the world is fighting hard to implement GUIs in browsers, and making sure that their GUIS work well in every browser ! Sadly, the standardization groups have many of the first category, and few of the second. And franckly, that really sucks.

      Why not aknowledging that a browser,

  • We see new languages all the time, most of them don't stand the test of time or are supplanted by others as time goes on -- but at this point there is a ton of industry experience in supporting a standardized Virtual Machine language / architecture / (whatever you want to call it). There's Sun/Oracle's JVM, along with several other implementations of this VM interface. The JVM will support any number of languages that target it. Microsoft has done this as well with their CLR (Common Language Runtime) as par

    • Already exists and is slowly moving forward with almost zero help. Supports many languages already.
      http://www.parrot.org/ [parrot.org]

      • Can C be compiled to Parrot bytecode?

        (i.e. does it support raw data and function pointers and unions?)

        If no, then you're not talking about the same thing as GP.

        • Well then we are talking about C, which is highly portable already. It's technical power combined with the build systems and support libraries are what make it a pain, not the language itself. If you think compacting it into a bytecode would help it, I think not... and C is already so close to a portable assembly you are not hiding a great deal by such a conversion. If you want the power of C but the ease of a VM like java, then you need to make a massive portable library that must be bundled with the com

          • The original context was a VM running in the browser - the entire point here is to have a cross-platform redistributable format that can be translated to efficient native code on the target machine. The reason why I brought up C is because, if a VM can handle it (and tailcalls), it can handle practically any other language. A good example is PNaCl, which uses LLVM bitcode for such a portable low-level format.

            Granted, C source code could itself be such a format. But I think it's a tad too high-level in place

            • Bad portability of C has created all these "solutions" which are less about C itself than the surrounding system. There needs to be more of a standardized runtime than what we have today and PNaCL does address this. I'm still quite skeptical of PNaCl; it's only significant contribution is addressing the base library issue... which it does with a really small focus because it exists for only 1 purpose.

              I've also not been a fan of how performance freaks (like myself) will sacrifice security and stability for

              • Did you read the paper about NaCl and PNaCl? There's no VM there in a traditional sense - it's not a JIT or an interpreter. It precompiles code to native, and runs that native code directly, using various creative hardware hacks to sandbox it.

    • Ever heard of asm.js [asmjs.org] ?

      • Yes. It's too primitive to be a foundation for a proper VM. Try doing something involving heavy pointer arithmetic in it, for example.

        Not to mention that it is a horribly ugly hack.

    • Google is doing that as well - that's what their Portable Native Client project is about: LLVM bitcode sandboxed in a browser.

  • CoffeeScript is nothing but syntactic sugar. I don't get why people are so excited about it, it is exactly javascript, with a different look. It is not a language of its own, and on top of that, doesn't run natively in its form and makes debugging a pain...
  • As far as i'm concerned, websites have little business using Javascript to start with. Now they want to add more? Sounds like Java to me which is for making applications, not websites.

    If your site needs native performance then write a native application.

  • Anything that Google tries to standardize with ECMA is going to become more controlled by Microsoft. Aside from this, ECMA is a European standards group (sort of). Their "standards" usually contain patented technology that then must be licensed (usually from Microsoft). I think it might suit Google's purposes better to form a working group and create a standard themselves that they can keep out of Microsoft's hands.

"All the people are so happy now, their heads are caving in. I'm glad they are a snowman with protective rubber skin" -- They Might Be Giants

Working...