ptalk > Dear Lazzie

Is Steve right?

A reader from Germany writes:

What is the OL team’s take on Steve’s toughts on Flash?

Enjoy… http://www.apple.com/hotnews/thoughts-on-flash/

Gentle reader,

I agree regarding the support of open standards such as HTML 5, which OpenLaszlo heartily supports too. The greater standards compliance we have, the better.

But it is amusing that Jobs contrasts the ubiquitous Flash player with the ubiquity of the Webkit “player”. The primary difference is that Webkit is open source, which presumably saves us from being beholden to any one manufacturer for bug fixes. But in reality, that depends on whether individual manufacturers track the latest releases of Webkit on their devices. Somehow I don’t think that any phone manufacturer has a provision to run the Webkit nightly on their phone. [We have even run into this in Safari. The Webkit team made a severe optimization error in the current squirrelfish engine that OL tripped over (incorrect caching of prototype properties). They pretty quickly developed a fix for it and we verified it in the nightly, but they had to advise us that there was no way that fix would be out in a release for at least 6 months. So OL has to browser sniff and at runtime adopt a much less efficient class implementation on the current Safari release.]

The battery life and performance issue is a marginal point. Clearly they could set a standard/licensing term for that and just say that Flash has not met the bar (yet).

I disagree vehemently with the current license stance (which Jobs does not address in his note) that they are using to further lock Adobe out from delivering a cross-platform development environment. This has created a substantial amount of collateral damage. For instance, take the Frotz app, which implements the Infocom Z-machine. Technically under Apple’s current license this app is illegal and will eventually be removed from the store (it has not so far). Another that has already been removed is the Scratch player. This is in no one’s best interest. Scratch is potentially creating the next generation of programmers!

OpenLaszlo is not affected by the license, as I pointed out in my blog post, because we deliver a web app, not a native app. Presumably all interpreters could do the same, but that just points up the ridiculousness of the license restriction — it boils down to “you may only run an interpreter on the iPhone if it requires a network connection”. Huh?

How does one define an interpreter? Every program is an interpreter because every program has data that drives the state changes. iTunes is an interpreter of mp3’s. How is that any different that the Frotz player interpreting a .z5 file? Where do you draw the line between data and interpreted program?

Is OpenLaszlo illegal on the iPad?

A reader from San Francisco writes:

Dear Lazzie, I was reading this article, and it seems to spell doom for OpenLaszlo on the iPhone and iPad. Should I worry?

Gentle reader,

OpenLaszlo is indeed a cross-compiler, translating from the high-level declarative LZX language to various runtimes, such as Flash and DHTML. But, because OpenLaszlo generates standards-compliant HTML web apps, it is not covered by the Apple SDK agreement. Any application that runs in Mobile Safari will continue to run, regardless of how that application is generated.

OpenLaszlo does have the unique advantage of being able to generate a Flash-based version of your application if you need to deliver in an environment where CSS2/HTML4-compliant web browsers are not available, or if you need to integrate with other Flash-based technologies. But if your application is being delivered to modern web browsers (which includes the browser for the iPad and iPhone), OpenLaszlo can generate a DHTML-based version of your application with no changes required on your part.

In theory, OpenLaszlo could follow the approach of Adobe’s CS5 and build another back-end to generate native iPhone apps. If they did that, they would find themselves in the same boat as Adobe — developers using their product would be in violation of the new Apple SDK agreement[1]:

What remains to be seen is how Apple will enforce this new agreement, and whether the market (the ultimate arbiter) will go along with them. Veterans of the business will surely be reminded of IBM vs. Telex, where IBM tried to lock out competitors from making compatible peripherals for its mainframes. IBM succeeded for a long while; even wearing down the government’s effort to bring an anti-trust case against them. But in the long run, the market ruled against them (by moving away from mainframes altogether).

Power to the people!

—

[1]: It’s ironic that OpenLaszlo is able to generate applications for the Flash 10 player because Adobe’s FLEX SDK is open source. OpenLaszlo cross-compiles to ActionScript 3 and then uses the Adobe SDK to compile from there to Flash.

Equality and Identity in Javascript

A reader from Plymouth writes,

So I’m profiling along, and I find an anonymous function that is being called a number of times. It doesn’t cost a lot, but I’m curious why it is anonymous. It’s not really anonymous, because our compiler assigns a debugging name to anonymous functions that you can use to find them in the source. Here’s the anonymous function:

static var _ignoreAttribute = {toString: function () {
      return '_ignoreAttribute'}};
  

_ignoreAttribute is just a unique sentinel object that we use as a way to indicate that an attribute has already been processed, deep in the inner workings of LZX. Someone (probably me) graciously gave it a toString method, so that when you are debugging and trip across it, you will realize that it is not just any old empty object.

But I’m not debugging. I’m profiling. I’m not calling _ignoreAttribute.toString(). It’s nowhere in the source code that I can see. What is going on?

Gentle reader,

Well, here’s a problem:

if (null != this.datapath && dp != LzNode._ignoreAttribute) {
  this.datapath.setXPath(dp);
} else {

Can you spot it? When dp != LzNode._ignoreAttribute runs, dp is normally a string, and read the fine print for how equality is computed in Javascript (from p. 64 of ECMAScript Language Specification Edition 3):

1. If Type(x) is different from Type(y), go to step 14. […]
2. If Type(x) is either String or Number and Type(y) is Object, return the result of the comparison x == ToPrimitive(y).

Well, I won’t bore you with more gory details, but the bottom line is, every time we compare _ignoreAttribute to a String, the runtime has to call its toString method to see if it is “equal”.

The storal of the morey is, when you want to compare for “identity”, use the “strict equals operator” (=== or !==), not the “equals operator”. [For my money, the former should have just been called the “identity” operator, but unfortunately it isn’t quite. There are some odd edge cases that make it not a true identity operator.]

I am a hacker

A reader from Maine asks:

Are your computer skills such that you could be a hacker if you wanted to
be? I’m just curious.

Gentle reader,

I am a hacker.

The popular press has co-opted the label “hacker”, which was originally a compliment of your high degree of computer skills, to mean a person who uses those skills for evil.1

If you are asking “Could I break into someone’s computer”, the answer is “yes”. There is no magic here. I started my computer career working in computer security at MITRE. And, believe it or not, things have not really changed much since those days. If anything, computer security has gone downhill quite a bit. No one has ever succeeded in commercializing the research we did (to build a secure system from the ground up), instead commercial enterprises have all focussed on selling “barn door” solutions, so called because they are attempts to close the barn door, despite the fact that a lot of (Trojan) horses have already been through…

—

[1] http://en.wikipedia.org/wiki/Hacker(computing)#Hackerdefinition_controversy “Hacker (computing) - Wikipedia, the free encyclopedia”

OL 4.3!

We are pleased to announce that OpenLaszlo 4.3 is available now. You can download it from the OpenLaszlo Download page. It is the recommended platform for all application development for the SWF8, SWF9, and DHTML runtimes. OpenLaszlo 4.3 is a major release, with almost 300 bugs fixed since OpenLaszlo 4.2 introduced the SWF9 runtime.

OpenLaszlo 4.3 Released

‘nuff sed.

OpenLaszlo under a Bushel?

A reader from Germany writes:

Laszlo has to sell products and make money, but I think the OpenLaszlo platform has lost in priority with the current management. Not money-wise (how much money they spend on it), but seeing it as a marketing-vehicle for the company. I would love to see more DHTML apps, that would really convince people of the dual-runtime power.

Gentle Reader:

I look at it this way: OpenLaszlo is practically a separate entity. Laszlo is our main sponsor, so we mostly do what they ask. But, we do have other sponsors: G.ho.st directly, others through support contracts. So they also get attention. Community stuff comes last, because that has no $ attached to it. But community leaders can be given commit privileges and see their goals achieved directly.

While OpenLaszlo is a valuable technology base, the company can’t make (as much) money off of it as they can with a proprietary product. Laszlo is doing kind of the same thing as Apple: adding proprietary value to an open-source base. And, we like that, because it means they can “donate” more money to the OpenLaszlo team. :)

Laszlo is a venture-backed company, and venture capitalists are all about making money. They pretty much only see as far as the Webtop licenses. But the management has been made well aware of how the community has made the base they build on much more solid than what they would get with a closed source.

As to DHTML applications, in reality, swf9 is so different from swf8, that is the more convincing port to me! swf8 and DHTML are only different in their UI model, the Javascript is 99% the same. To do swf9, we really had to re-engineer the guts of the whole tag compiler and script compiler, to implement a lot of Javascript 2 (Harmony) and then compile down to Javascript 1 for swf8 and DHTML.

We knew it would be a lot of work, but we knew if we could do it, we would really prove we had a platform-independent language in LZX, and we ended up with a much more robust system in the end.

There is a rule of thumb: 2 ports does not make you platform-independent, it is the 3rd that is the test!

In the end, we were very pleased that we were able to keep nearly all the dynamicity of LZX and target a strongly-typed, much more static platform. The strong-typing and ‘true’ classes of Javascript 2 have given significant performance gains (some claim a speed-up of 5-6 times), but the OpenLaszlo compiler has been able to shield the LZX developer from most of the requirements of declaring types and overrides in their LZX code and has been able to keep dynamic features like <state>s and constraints.

Let me conclude by saying, overall you are right. OpenLaszlo needs more publicity, whether for Laszlo as a company, or just for it’s own growth. Let’s hope this little post can help it along the way…

The difference between `.` and `[` in Javascript

We recently had a bug report that the debugger started issuing a warning in code where it had not before:

 WARNING: reference to undefined property 'length'

The initial fix proposed was to simply change:

 foo.length

to:

 foo.['length']

Advice for the OpenLaszlo optimizer

Since the OpenLaszlo compiler does not do common-subexpression elimination, when you are trying to optimize things, pretend you are writing in 1985 C. Instead of:

if (d.c[d.f]) d.c[d.f]( sd )

say:

var f = d.c[d.f];
if (f) f(sd);

Even better, when you find yourself having to write a null check, ask yourself if it would be cleaner, simpler, and more efficient to have the variable you are referencing not be nullable. For instance, if a variable is an array, consider using an empty array for its initial value, rather than null. This is a time/space trade-off: if there are many operations on the array and the variable is almost always not null, it will be more efficient to use an empty array; if there are few operations and the variable is usually null, then not allocating the empty array is the better choice.

(In Javascript 2, you will have the option of declaring a variable to be of a particular type, and you will have the option of declaring whether or not that variable can also be null. If you declare it not to be nullable, then the compiler will give you a compile-time warning if it cannot prove that the variable is never null, and it will insert the appropriate runtime check for you.

// This can be null, you have to check before using
var uplinkArray: Array;

// This cannot be null, you have to give a valid initial value
var uplinkArray: Array! = new Array();

Even though we don’t yet support the type declarations, we can follow the pattern and be ready…)

Undefined redux

A reader from Maynard asks:

My understanding is that in js, if a variable is declared var foo, and then it is read without an explicit initializer or setter being called, the variable still has a value of undefined and an error is signaled. If that is so in all js dialects then I don’t see any reason why adding variable declarations [to a class declaration] should ever cause problems. I don’t see how it could affect inheritance, for example. Am I missing something?

Order in the code

A reader from San Mateo writes:

I expected this to print the words of my phrase in order. It did not. What gives?

lzx> words = "The quick brown fox".split(" ") 
«Array(4)#55| [The, quick, brown, fox]» 
lzx> for (var w in words) Debug.write(words[w]); 
fox 
brown 
quick 
The

Gentle reader,

for in iterates over the ‘keys’ of an object. An array is just an object that happens to have (mostly) numbers as keys (and auto-maintains a length property that is one larger than the largest numeric key).

An object is just a hash table, and there is no implicit order of elements of a hash table (Java has LinkedHashMap which preserves entry order for iteration, and TreeMap which sorts entry order for iteration, but Javascript is a simpler language).

If you want to iterate over an array’s entries in order, use for (var i = 0; i < array.length; i++).

lzx> for (w = 0; w < words.length; w++) Debug.write(words[w]); 
The 
quick 
brown 
fox

If you want to iterate over an object’s keys in a particular order, you have to pull the keys out into an array, sort that array, and then iterate over that array:

var keys = new Array();
foreach (var k in array) { keys.push(k); }
keys.sort(function (a, b) {
  return (a > b) - (a < b);
});
for (var i = 0; i < keys.length; i++) {
  Debug.format("%s -> %s\n", keys[i], array[keys[i]]);
}

The fact that any particular runtime iterates over object keys in any particular order reveals an implementation detail of their hashes, but if you write your code to depend on that you are setting yourself up for a fall. Most Javascript runtimes just happen to use particularly trivial hash implementations that give you the illusion the keys are iterated in order.

See also the yellow box caution here.