Another javascript pitfall: Hoisting

The problem is that, whether you realise it or not, javascript invisibly moves all the var declarations to the top of the function scope.

so if you have a function like this

var i = 5
function testvar () {
     alert(i);
     var i=3;
}
testvar();

the alert window will contain undefined. because internally, it's been changed into this:

var i = 5
function testvar () {
     var i;
     alert(i);
     i=3;
}
testvar();

this is called "hoisting". The reason Crockford so strongly advocates var declarations go at the top, is that it makes the code visibly match what it's going to do, instead of allowing invisible and unexpected behavior to occur. function definitions are also hoisted to the top of the scope.

Putting a var inside an if statement is not against "the rules" of the language, but it means that, because of var hoisting, that var will be defined regardless of whether the if statement's condition is satisfied. Javascript also does not have block scope, so declaring a variable inside a block is doubly confusing to those who come from languages that do have block scope, because of hoisting.

Keep in mind also that hoisting does not include the assignment, so the var declarations will be moved to the top, and left undefined until they're assigned later, as in the example above.

This is a feature that must have seemed like a good idea at the time, but it has turned out to be more confusing than helpful.

Insomniac Theater, A dream

I had a dream about a particular cinema. Not one that I know if in the waking world, but one that I visited quite avidly in this dream world.

At this theater, you could purchase a ticket to see a contemporary movie at around 11:30pm at the regular price. Then, you could stay at the theater on until 6am, and watch classic/old/public domain movies and cartoons for free.

The theater would recoup the cost of this through sales at the snacks counter. This might actually work, sleep deprivation can make people quite hungry.

Autodesk Animator

Here's a little story about a neat old computer program, and how I plan to save it from the brink of digital death.

For the past few years I've been fascinated by this program. Way back in the beginning, I became aware of the existance of dedicated communities devoted to solely pixel art.

One of the communities, pixelation, had a highly regarded tutorial titled "so you want to be a pixel artist?"

(Links are to mirrors, the original site is long gone). When I read that tutorial was the first time I became aware of the fact that there was a program called "Autodesk Animator". The native format of Animator (fli, flc) was certainly ubiquitous in the 1990's. Even today, Mac OS X doesn't need any special software to play FLI files, quicktime handles them natively. I have also been a participant in the pov-ray community, which used independant dos uitilities to string together raytraced frames into Animator's FLI and FLC format. Why? It was the very first widely available delta compressed video format!

What really grabbed my interest, was this spectacular animation by a guy named Paul Robertson.(NSFW!) who allegedly used Autodesk Animator to make it.

So cargo cultist that I am, I set about attempting to obtain the software. This is really difficult to do, it turns out. Eventually I succeeded. (*whistles). The software can only be run on a modern computer by means of emulation. DosBox is quite capable of running the software. Here's me on the DosBox forums trying to make that experience suck less.

The software is really very much like another contemporary peice of software called Deluxe Paint. Between Autodesk Animator, and Deluxe Paint, you can account for about 90%*(making shit up) of the game artwork produced between 1989 and 1999. These were *the* pixel art programs. They belong to a class of paint program designed around the limitations of computers that can only display small amounts of colors. A style of paint program that has really fallen into obscurity ever since the photoshops of the world took over with their fancy 24-bit color modes. (oh and by the way, Dr. Katz, Home Movies, and Science Court were made in Animator, also, most of these youtube videos, and also, my cool dinosaur animation)

What sets Animator apart from its contemporaries is its direct keyboard control over animation functions, a very useful Sprite animation mode, and a built in scripting language named PocoScript.

What sets it apart from Modern paint programs is that while it is only capable of producing 256 color images and animations, it has a vast number of tools, inks, filters, and effects that modern programs cannot use in their highly crippled 8-bit modes. In addition, the functions available for manipulating that limited palette are unmatched by any other program I've seen. These properties make it ideally suited for producing art for platforms with limited capacity (such as game consoles, mobile phones, toys, etc) in other words, "pixel art". In its own time, this was thought of as a severe limitation. Today, this is its advantage- this is its characteristic difference.

Just one problem.

So, I'm going to do something about it! I had an idea. In my research, I found out quite a bit about the history of this program. I found out that before it was a PC program named Autodesk Animator, it was an Atari ST program named "Cyberpaint'. Before that it was Aegis Animator, and Flicker, and a conglomeration of other small paint programs and experiments, all authored by a guy named Jim Kent, who had a funny habit of negotating software contracts that let him keep the rights to the source code. Hmm. Interesting little story about Jim Kent. In the year 2000, he mapped the human genome using a cluster of 40 commodity PC's in his basement, Beating out a biotech firm by a day, and thus saving the technology, and our genes from patents. Oh yeah, and he likes open source software.

So I decided to email him, asking if he might, maybe, kind of, consider maybe open sourcing our favorite program. This was his response:



Oh, and by the way...




So, he kept his rights to the source code, and now, he is granting me access to the source code, to make it available to you all! Well not so fast. He also asked me to get in touch with Gary Yost to ensure that he didn't object. (Former owner of Yost Group who licensed the original software to Autodesk), Well okay, that wasn't so easy, since he's now a big shot vice president in a tiny little company called Mental Images

But I managed, and I got his support too! So now that all the relevant parties are up to speed with my idea let's go!

Hold on, though, there's some chores to do first before I can release it to the public. I know I know, blah blah blah. First off, there's a bunch of material in these little zip files which suspiciously looks like stuff that Jim Kent did not write. There's piles and piles of documentation that looks suspiciously.. .copyright autodesk. There's piles of fonts licensed from-- Anim8 inc, a company that I can find ZERO information about. (help?) and Sample artwork that I can't use, because I don't know who made it.

There's also the technical challenges. It would be nice before I release the source code, if I knew all the tools and software that it depends on, and how to compile it. It would be even better if I could adapt the code to compile with tools that are Free and Open Source, rather than tools that are proprietary, out of date, and impossible to find

So I know it's frustrating, but I'm going to have to sit on the code for a short while, so I can sort these issues out. I'm soliciting for anyone that can help with writing documentation, any artists that are willing to make sample artwork using the software, any lawyers that are willing to offer me advice on how to avoid stabbing myself in the foot, and anyone who is a particularly clever programmer that knows anything about programming for MSDOS, or is willing to try their hand at pocoscript to make some sample scripts. I'm kind of a clever cookie myself, and given enough time I can probably get a lot of this stuff done on my own, but it will take me a loooong time without help. I will detail the technical challenges in an upcoming post for those interested, and document my progress through this new project.

Something I've learned

When it comes to huge complicated things like software, it is almost always better to build on previous efforts than to try to demolish those previous efforts to start from scratch.

This is best encapsulated in the following quote, via Daring Fireball

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

—John Gall

How to deal with the newspaper crisis

What about a journalism "auction" site? Journalists would have accounts at the site, and post briefs on a topic of investigation. Say, a 2 or 3 paragraph abstract.

Based on this, the general public is then able to contribute: in essence, throw a pledge into a hat until a given threshold of funding is reached. This money is taken from a paypal account or a credit card until that threshold is reached by a certain date. If it is not reached, the money is returned to the users account. (or perhaps the site itself could hold virtual credits). The idea here is to collectively fund the investigation, so that no single sponsor has to bear the full cost.

Pros: Places journalists in a closer relationship with their audience. Rather than a publishing company brokering the funding between audience and advertisers and journalists, it would essentially run on a social networking or web2.0 type of model funded directly by the audience. This funding is then used for investigation and reporting of that abstract. (with allowances for the investigation leading to new interesting areas at the journalist's and editor's best judgement.)

Rather than expecting users to pay directly for content which already exists, it's giving the audience personal ownership, by allowing them select and fund the creation of new content.

Cons: The tendency for the general public to vote for baser and less enlightening stories may present a problem. Perhaps this could be mitigated by some kind of "tax" on general articles which could be directed towards articles selected by a qualified editor. That way, editors could in essence overrule the public on some portion of funding for articles to get important and educational things through- while at the same time, the general public can in essence overrule an overidealogical editor for funding on other articles, thus providing some checks or balances.

Feel free to improve expand, or implement this idea in any way you choose. I, the author hereby release this blogpost, unconditionally, into the public domain.

The emotional growth of characters

Alan Moore about Watchmen:

"Watchmen" is widely regarded to have brought an aura of realism to comics.

I think that more often it's a more supposed physical realism rather than any kind of emotional realism. Yes, books like "Watchmen" did make it fashionable to show grimly the consequences of violence, which I suppose initially was a good thing because it's better that people know that violence results in terrible injury and pain and suffering than that they think that it's just something that, you know, people get a sock on the jaw and they are unconscious for a couple minutes and then they come around and they are taken off to the police station.

But I think that when you are talking realism in comics you have to realize it's an ongoing process, especially emotional realism. That when the comic book industry started you had characters who were, let us say, one-dimensional in that they only had one quality. They were good or that they were bad. By the 1960s Stan Lee with Marvel Comics had the brilliant idea of two-dimensional characterization where they are still good or bad but now they have some kind of, perhaps a medical complaint or some sort of emotional suffering. What we were trying to do with "Watchmen" was to make it at least three-dimensional. So that the characters that we were talking about were complex human beings that weren't defined by one simple set of behavior patterns. With some things like Todd McFarlane's "Spawn" or a lot of these modern comics, they will show greater violence because they know that actually that is what a lot of the audience wants, for prurient reasons, not trying to show the emotional depth and complexity of the characters.

It's occured to me that many of the characters I've seen in various fiction are incapable of growth or change. A character is concieved as a brand with a certain set of unchangable characteristics that can be exploited by the narrative again and again and again. Consider the simpsons, and their world which resets at the end of each episode to exactly the way it was at the start. None of the characters get older, nor do they actualy learn anything from their adventures that modifies their future behavior, or makes them quantifiably better people.

How would a fictional character look, if it was capable of growing and learning? What if in the process of that growth, they abandoned the main attribute that made them recognizable as that character, and that change persisted to future stories? Is emotional growth the third dimension Alan Moore speaks of?

Javascript Constructors

Javascript has a problem with constructors.

function Thing () {
   this.foo="bar";a
   this.bar="baz";
}

this is okay if you call Thing as
var thing = new Thing();

That creates a new object, whose prototype is Thing.prototype, and binds that object to "this", and then executes the Thing function.

However, if you do this:

var thing = Thing();

"this" instead gets bound to the global object, and you end up with the global variables "foo" and "bar".

Douglas Crockford concieved a function named "object", that will be baked into the next version of the ecmascript standard. (as a static method named "Object.create" )

The object function takes an object as a parameter, and creates a new object whose prototype is the given object, and simply returns it. The implementation goes like this:

function object (o) {
  var f = function () {};
  f.prototype = o;
  return new f();
}

you can use this to create safer constructor functions.

function Thing () {
   var that = object(Thing.prototype);
   that.foo="bar";
   that.bar="baz";
   return that;
}

Now, this function does exactly the same as the above Thing function when you call it like this.

var thing = new Thing();

but when you forget the "new" keyword

var thing = Thing();

it still does exactly the same, avoiding global namespace pollution.