http://bitbucket.org/afrankvt/fanast/

Its pretty crude, but works, and should be pretty easy to fix or modify to suite your needs.

So I was surprised when I saw that John Gruber was elected as “president”. John gets Mac software and good software in general, so this little project still has alot potential.

See info on Brent Simmon’s blog. Hope this goes somewhere.

  function foo()
  {
    try { return func(); }
    catch (err) { ... }
  }

I was able to work around by assigning to a local variable:

  function foo()
  {
    try { var x = func(); return x; }
    catch (err) { ... }
  }

Did a short Google on this, but nothing obvious turned up.

Not long after that, I realized I could access all my synced feeds in NewsGator from the browser. So now I could read my synced feeds on my daytime Windows dev box. The online NewsGator app is pretty much abysmal, but it works, and syncs, and since I couldn’t do any of that before, I was happy enough.

So when I got wind that the next release of NNW was dropping NewsGator syncing in favor of Google Reader, my ears perked up a bit. On one hand thats interesting since NewsGator bought NNW, but I was more interested in the browser experience. It had been several years since I’d tried out Google Reader, and while I thought it was ok, I don’t remember being overly impressed.

But I decided to give it another go. I exported all my feeds from NNW and imported them effortlessly into Google Reader. The UI seems to be the same as before. But this time it “felt” alot better, not sure why (is it the enormous performance gains we’ve seen in the last year or two that makes it feel zippy now?). I found it easy to scan and read all my feeds. In fact, I like it so much I might just drop NNW altogether and use Google Reader exclusively.

In general, though, I always tend to prefer static languages for anything but a small or quick and dirty project. Especially when its a code base I intend to maintain for some time.

I just spent the weekend refactoring Fan’s JavaScript compiler to change how I model Fan fields in JavaScript. The way I had previously done it looked like this:

// Fan
class Foo { Int x := 5 }

// JavaScript
Foo.prototype.x$get = function() { return this.x; }
Foo.prototype.x$set = function(val) { this.x = val; }
Foo.prototype.x = 5;

Which isn’t great, but didn’t really have alot of options. But it seemed nice enough. It grouped the accessors and storage neatly together. And in most cases, since I can access the storage directly, the code overall was fairly clean.

Unfortunately that model made it very difficult to make certain use cases of fields and methods work (like overriding a const field with a method). So I changed the JavaScript to look like this:

// Fan
class Foo { Int x := 5 }

// JavaScript
Foo.prototype.x = function() { return this.m_x; }
Foo.prototype.x$ = function(val) { this.m_x = val; }
Foo.prototype.m_x = 5;

That change would have been a bit painful in any language, since there was just alot of code to update (the sys library and all the native implementations are written directly in JavaScript).

However, since JavaScript does not have static type checking, I pretty much had to tackle errors one-by-one using the test suite and Fresco (the web UI I’m developing at SkyFoundry).

This is probably the biggest reason I prefer static languages. When you have to make sweeping changes on a large code base, you simply can’t verify your changes 100% in any language. But a compiler with static type checking can help you tremendously. Especially for code that is difficult to unit test, like UIs.

Out of the box, those scripts use document.write in place, which makes them very problematic if the script is not inlined in the initial HTML page. Trying to call them after the page is loaded will just nuke your document.

Luckily there’s a function (javaFxString) in the dtfx.js script that serializes the necessary code to a string which you can use:

var s = javafxString({
          codebase: "/s/fwt/javafx/dist/",
          archive: "Canvas.jar",
          draggable: true,
          width:  200,
          height: 200,
          code: "fan.fwt.Canvas",
          name: "Canvas",
          id: "app"
      });
someElement.innerHTML = s;

This will let you insert the JavaFx applet code anywhere in your DOM. I only tried this in IE8 so far (since this is a workaround for IE-only). But I assume this should work in all browsers.

var x = 0xffff;

var s = new Date().getTime();
for (var i=0; i<100000; i++) x = x >> 2;
var e = new Date().getTime();
var res1 = (e-s);

s = new Date().getTime();
for (var i=0; i<100000; i++) x = x / 4;
e = new Date().getTime();
var res2 = (e-s); 

alert(">> " + res1 + "ms\n" + "/  " + res2 + "ms");

Very unscientific results:

Browser               >> 2    / 4
--------------------  ------  -------
Chrome 2.0.172.31     2-3ms   4-7ms
Firefox 3.0.11 (win)  11ms    15-16ms
Safari 3.1 (win)      15ms    15ms
IE8                   63ms    62-78ms
Opera 9.64 (win)      46ms    63ms

Interesting to see the different performance b/w browsers, but also seems clear, overall, the bit-shift operators perform slightly better even with the box/unbox hit.

This is was my first attempt, which I assumed would work:

>>> var x = 15;
>>> x.$fanType = sys_Type.find("sys::Int");
>>> x.$fanType
undefined

But no dice.  After a bit of googling, I found this page, which says in order to add properties to the built-in types, you must create objects using the constructor syntax:

>>> var x = new Number(15);
>>> x.$fanType = sys_Type.find("sys::Int");
>>> x.$fanType
"sys::Int"

I assume this a performance optimization, where you can use a primitive int value in the first case, and have to allocate an object in the latter. Though since Javascript is a pure-OO language, I would be interested in seeing how VMs actually implement this behavoir.

Edit 8 Jun 09: Just realized using the object syntax breaks equality checks for numbers:

>>> var x = new Number(4);
>>> var y = new Number(4);
>>> x == y
false

Which sort of sucks, but you can work around it using valueOf, but still annoying.

>>> x.valueOf() == y.valueOf()
true