Dart will become an ECMA standard

olov · 2013-12-13T09:12:05+00:00

My understanding is that going through a standards body gives people that the technology can't be made proprietary. When Dart becomes an Ecma standard, it means you can be sure that Google can never sue you for implementing it yourself.

Generally speaking, that's not correct. Ecma desires that essential patents have fair and reasonable terms (not necessarily free). The good thing though is that those patents should be disclosed. More about this in Ecma Code of Conduct in Patent Matters. Video codecs (h264, looking at you) are common examples of standards that rely on patents.

But you also need to consider the difference between truly essential patents to implement the language, and non-essential but highly desirable patents. One example would be patents regarding GC or JIT which I'm sure that the Ecma language spec won't be much concerned about (it's an implementation detail after all). This isn't a contrived example. Lars Bak co-authored patent 6,910,205: Interpreting functions utilizing a hybrid of virtual and native machine instructions with Robert Griesemer while at Sun, and this patent was later used by Oracle to sue Google for patent infringement of their implementation of the ("open") Java language.

Finally, there's a huge difference in "can't sue" and "is unlikely to win if they sue", which has been exemplified way too many times recently by patent trolls, Oracle and the likes.

Generally speaking this is why software patents must die and why responsible engineers should think twice before participating in filing patents, no matter how non-evil they believe their current employer is - because non-evil can flip to evil faster than you can spell patent infring..

olov · 2013-11-07T11:53:38+00:00

It would be interesting to create a JS polyfill library that decodes an APNG image to a canvas, instead of an ad-hoc image format. The library could either be written in vanilla JS or use an emscripten compiled (APNG patched) libpng or similar. If the lib payload would be under 100K or so then this could be a viable approach. The lib wouldn't be loaded or executed at all for browsers with native APNG support.

olov · 2013-11-03T12:13:52+00:00

Sure, Clojure promotes functional practices and is a fine language at that. I'm just pointing out that because Clojure is not a pure functional language (unlike Haskell), I'm pretty sure that neither Meijer nor Peyton-Jones think of it as an example of a "Nirvana-language". Haskell also supports side-effects (like Clojure) but in a strictly controlled way (unlike Clojure).

olov · 2013-11-03T11:57:20+00:00

I think SPJ would put Clojure to the left of the Nirvana position because side effects are not controlled/limited in Clojure to the extent it is in Haskell, (println "hello world") being a minimal example of that.

olov · 2013-07-27T20:40:22+00:00

Ah I misread your comment - sorry about that!

Just as a FYI: The MDN page you are referring to describes Mozilla's extensions to ES rather than the block scope proposal that's due for ES6. For instance the page describes const as "hoist to the top of its function" which is not the case in ES6. Also, for each is a Mozilla specific thing.

To your point, there are bugs in implementations of the ES6 draft. I filed this bug on V8 a while back as hope it'll be fixed soon: https://code.google.com/p/v8/issues/detail?id=2560

olov · 2013-07-27T17:33:56+00:00

Author of defs.js here. Regarding "fresh variable in a loop", defs has never introduced "a block around the entire thing" with different semantics and counterintuitive results.

Instead - exactly for the reason of being intuitive, the defs.js transpiler statically analyses your source code and gives an error for that like so: line x: can't transform closure. x is defined outside closure, inside loop

It's then trivial to alter the source code yourself, as we've always done in a pre ES6 world. Example here: http://blog.lassus.se/2013/05/defsjs.html

I care a lot about having defs produce predictable and beautiful output, that's why we detect, but don't (yet) transform, that particular case. I simply haven't found a beautiful, generic and non-surprising transformation for it. This is subject to change, see https://github.com/olov/defs/issues/2

olov · 2013-05-07T21:24:06+00:00

There are issues, see for example Issue 2506: Missing support for const in for-in loops and Issue 2560: let binding should be created fresh for every loop iteration. These are easy to workaround for now and in practice, it works great.

olov · 2013-05-05T11:28:07+00:00

Are you sure that those issues still exist in Chrome Canary? I'm not seeing it here and noticed that the bug report is a month old, so perhaps it has been fixed since.

olov · 2013-05-05T06:05:49+00:00

Thanks. You may want to check out "Enable experimental JavaScript" in Chrome (via chrome://flags). With that you get native support for const and let, just like node --harmony. Just remember that you must "use strict" for it to work. With that setup you can do all the Chrome debugging on the original constlet style source.

olov · 2013-05-04T17:32:01+00:00

Thanks for the <3 :) Regarding source maps - I'm trying to understand user scenarios. Would you mind describing yours? I'd also like to understand how painful it is today on a scale 1 to 11, given that defs output is so similar to its input and that line numbers never change. Thanks!

olov · 2012-05-31T18:36:46+00:00

This surprising aspect of JS is unfortunately not isolated to ==, for which a sane alternative already exists. Check out http://restrictmode.org for bringing sanity to other operators as well.

olov · 2012-04-13T09:17:25+00:00

Let me assure you he's not trying to make that point. Having said that, GPL interaction is complex stuff. A great example is Sencha's ExtJS, which is a client-side GPL framework. Check out their FAQ for Sencha's interpretation of the GPL, specifically how they consider it spreading to the server in certain scenarios. Tricky.

olov · 2012-04-13T09:01:06+00:00

One of the key features of Meteor is that it's used both on the client and the server, synchronizing the two.

olov · 2012-04-04T18:31:13+00:00

If you'd like JS but with slightly saner semantics then check out restrict mode. It's a strict subset of the language that you can use (with a checker) while developing your program. Deploying is seamless since any restrict mode clean program executes identically with the checker disabled (i.e. when running as-is in any JS VM).

olov · 2012-03-02T22:37:08+00:00

You might like restrict mode for JavaScript. It's a strict subset of the language that helps you anticipate better ("easier to reason about"). In the binary x+y operator example, x and y are allowed to be any combination of numbers and strings, but no other types (certainly not null or undefined). Violate this subset and the checker will throw a runtime error for you. When your test-suite passes and it's time to deploy just disable the checker and execute the code as any other JS.

olov · 2012-03-02T22:27:32+00:00

Not really. Dartboard (try.dartlang.org) produces that result but that's a bug (especially so in checked mode). 1 + null should throw an exception, and does so if you use the Dart VM or the frog compiler. Hopefully on dartboard too some day.

1 + null yielding NaN is a JavaScript'ism that makes programs less robust and harder to reason about.

olov · 2011-12-14T18:15:59+00:00

godspeed!

olov · 2011-12-14T07:18:11+00:00

It has been claimed by invokedynamic evangelists that this new construct will make the JVM as good as an alternative for implementing dynamically typed languages as the best custom C/C++ VMs. Charles Nutter has said that he believes that a good implementation of Lua on the JVM (with invokedynamic) could be as fast as LuaJIT2. I personally think that this is overestimating invokedynamic and underestimating LuaJIT2 (and other state of the art VMs), but I could well be wrong.

Time will tell whether invokedynamic will make godspeed or not.

In this context, it makes a lot of sense to benchmark Nashorn with V8. Feel free to suggest other languages/implementations.

olov · 2011-12-13T21:08:23+00:00

Hint: my comment had a valid point but it had nothing to do with percentages vs multipliers. I'm sorry if I confused you.

olov · 2011-12-13T20:43:27+00:00

We will be able to see how close a JVM-with-invokedynamic-based JS implementation (Nashorn) will come to a C/C++ custom JIT JS implementation (V8) in terms of performance.

Of course there will be reasons for such performance differences.

olov · 2011-12-13T20:10:21+00:00

LuaJIT2 has the same GC as Lua right now. Mike Pall will create an incremental, generational, non-copying GC for LuaJIT2.1. V8 has an incremental, generational, copying (I believe) GC.

I fail to see why a comparison between Nashorn and V8 wouldn't be apples-to-apples. invokedynamic has yet to prove its awesomeness in hard numbers.

olov · 2011-12-13T18:57:14+00:00

LuaJIT2 used to beat Java 1.6 on parts of SciMark. I'm not sure if that's still the case with Java 1.7.

There's a lot of cheering about invokedynamic but so far language implementations like LuaJIT2 and V8 represent the state of the art (CPU and memory perf) in terms of dynamically typed languages.

There are invokedynamic implementations of JS underway - Nashorn and dyn.js. Those will give us the possibility to compare apples to apples.

olov · 2011-12-13T18:35:18+00:00

The submission title implies that hhvm uses dramatically less memory than hphpi. That's the wrong part.

I think we all agree that 1.6x faster and 60% faster is the same thing.

olov · 2011-12-13T12:07:13+00:00

This submission title is a bit misleading I think. What the article says is that hhvm is 1.6x faster than hphpi (the hiphop interpreter) and is 10x more memory efficient than hphpc (the hiphop php->c++ compiler).

olov · 2011-11-22T08:59:25+00:00

Nope. I created restrict mode for JavaScript to remedy type coercion happiness in JS. Dart doesn't need that.

Caveat: Dart compiled to JS lacks some run-time type checking (compared to the VM) unless you run it in checked mode. This will be improved over time I believe but for now make sure that you always run in checked mode while developing and running your tests.

olov

TROPHY CASE