JavaScript Objects, Opera's Error Console

The News:

Saw Steve Forbes on CNBC yesterday. He's still spouting the supply-side nonsense that Reagan abandoned after a single-year trial. Well, his reporters are still out there reporting, and they do a good job. Wonder what Oracle is up to? Here's Ellison's game plan.

Yet another attempt to mount a frontal assault on IBM. This stupidity seems to be contagious.

JavaScript Objects

Let's create a JavaScript object.


var martin = { name: "Martin Rinehart", current_activity: "blogging" };



That's right. No class; no constructor; just create an object.

Today I've got to figure out how to do a hash in JavaScript. Let's add that:


martin.next_google = "javascript associative array";



That's right, too. Need an attribute? Assign to it. Python works this way, too. Ruby requires more Java-like planning.

Sometimes a constructor is a good thing. A regular function, first letter capitalized by convention, serves as a constructor:


function Person( name ) { this.name = name; }



Let's use that constructor to create an array of Persons.


var names = [ 'Tom', 'Dick', 'Harry' ];
var people = [];

for (name in names) { people.push( new Person(name) ); }



If you are used to Java, that probably seems more organized. You UML fans are probably breathing a sigh of relief. Forget it.


martin.kayak = 'flatwater';
people['Harry'].kayak = 'whitewater';
people['Dick'].hobby = 'gourmet chef';



Harry and I share an additional characteristic. Note that Harry is a Person; I am not. Dick, and no one else, has a hobby. (Did you notice that I did that google? JavaScript arrays are associative.) JavaScript objects are also associative arrays:


people['Tom']."rock climbs" = "Half Moon";



Actually, all the characteristic names here are strings. If you have names (no spaces or funny characters), you don't need to type the quotes. This is a convenience. Is it a good practice?

Now, is this very free-form object model conducive to good code? I don't know. JavaScript is, traditionally, bug-ridden. (Not yours, of course? I doubt it. Open the Opera browser. Click Tools/Advanced/Error Console. Now visit one of your own sites. IBM's JavaScript is a mess. Why should yours be different?)

But study that Error Console dump. Are any of the errors caused by attempts to access non-existing characteristics? I've never seen that. Your own JavaScript will get cleaned up when your developers find out that you'll be running your own sites in Opera with the Error Console turned on.

Mid-Twentieth Century Languages

In the News:

Dell to buy Perot. Having trouble competing with HP? Here's an idea: go head-to-head with IBM.

Mid-Twentieth Century Languages

Ruby's powerful and full of Tim Toady. Python's powerful and pythonic. In one area, however, both are bad reminders of the 1960s.

I refer to the fact that both are strictly interpreted, according to the lamest definition of the term. They begin processing at the top of the file. Declarative code? Processed. Imperative statements? Processed.

The intelligent way, of course, is to read the file handling all the declarative code first. Functions, for example, are defined and ready for use when the imperative code is processed. Functions may be declared where they make sense. The structure of the source code is not dictated by the processor; it's decided by the programmer.

Ruby and Python? Nope. Don't place your imperative code at the top of the file; library functions at the bottom. You cannot call a function from statements above the function's definition; you cannot instantiate an object ... This is stupid.

JavaScript eats your source code's declarations first, then goes on to process your imperative code. JavaScript is not the world's most advanced language. That Ruby and Python are less advanced than JavaScript should be an embarassment to both.

If you remember Pascal from the early days of microcomputers you remember being forced to write your main program at the bottom of your file. This was, and is, a tragedy if you valued readability. This is how you must structure your Ruby and Python.

JavaScript gets this right. Java lets you put "main()" where you choose. This should be completely standard in this century.

Error Handling

Today is 9/11/09. John and I played an hour of tennis once a week from 7:30 to 8:30 in the morning. We played eight years ago on this day, quite happily ignorant of the events unfolding in Manhattan. By 9:00 we were a half-hour apart, at our respective offices, watching TV. We haven't played since. And so it goes.

Error Handling Overview

Some processes can generate errors despite the most skillful coding. Disk I/O is one example. (User enters name of a file that doesn't exist. Data cannot be written because the disk is full.) I first met try/catch logic in the mid '90s in Java as a way to handle these sorts of errors. This is now a feature of most mainstream languages.

The basic idea is to surround a block of code (such as disk I/O code) with a "try this" instruction. Following the block to try there is an "if an error occurred" block. Some languages, Java included have an optional "whether or not there was an error do this" block. Code in the "try this" block (including, importantly, subroutines called in that block) can "throw" an error, often an Error or Exception object for use in the "if an error occurred" block.

Error Handling in Java

This is the basic Java syntax:

 try {
 }
 catch (Type1ExceptionOrError var1) {
 }
 [catch (Type2ExceptionOrError var2) {
 }]...
 [finally {
 }]

Java has both XxxException and XxxError classes. The builtin classes can be extended by the programmers to create more Exceptions and Errors. Multiple catch clauses allow code to be written to handle particular Exception or Error types. Importantly, catch (Exception e ) {} will catch all exceptions, though it loses the ability to use any added information in extending classes. Errors can be handled similarly, but are generally not handled. A Java Error would be something like a hardware failure that the program probably cannot deal with successfully.

If I were redesigning the language I would eliminate the finally block entirely. The catch blocks should simply branch to the code that follows the last catch block.

I would then use only a single catch block. If needed, the programmer can put a switch inside that block which calls code appropriate to the exception type.

That said, let's look at the ways some other languages address the issue.

Error Handling in JavaScript

JavaScript follows Java's try catch finally lead, with two important differences. First, there is only a single catch block. Second, the thing caught may be anything: object, string, number, ...

In JavaScript: The Good Parts, Doug Crockford eliminates the finally block, leaving exactly what I recommend for Java.

Error Handling in Python

Very like Java, but the catch block is known as an except block.

Error Handling in Ruby

Similar to Java, but Ruby stubbornly goes its own way. You don't try, you begin. You don't catch, you rescue. You don't finally, you ensure.

Ruby also features a retry keyword that repeats execution of the try block.

"Martin, don't forget that stupid Tim Toady! You can use catch blocks, too."

"Thanks, Monty. I'll put that in."

Monty, my pet python, knows just enough Ruby to criticize it.

Error Handling in C++

Like Java you have try and catch blocks. Unlike Java there is no finally block. Also unlike Java, there is no restriction on the type of thing caught. Strings and integers, for examples, can be caught. There is also a generic "catch anything" variant, though there is no way to hand the thing caught to the code in this catch block, a disadvantage of strongly-typed languages.

Google Books and the Three-Fold Path

News:

This NY Times article contains an excellent set of links to the pro and con positions re the settlement of authors and publishers v. Google. (The settlement will a: liberate books, or b: obliterate books say those who support or oppose it. I'm betting on c: boost books' Google search rankings.)

The Three-Fold Path to HTML Documents.

I have just released my first serious Ruby plugin for Google SketchUp. It is useful for creating multi-scene animations of a 3D model. Any non-trivial SketchUp Ruby UI is shown as a page in a browser, an HTML document. Here are the alternatives for creating an HTML document.

HTML

First, there is HTML, a simple set of markup commands that are the cyberspace equivalent of typesetting instructions. Let's look at a sample:

<table align=center bgcolor=#fofoff border=1>
    <tr>
        <th>Heading, column one</th>
        <th>Heading, columne two</th>
    </tr>
    ...
</table> 

The basics are a set of tags that come in <tag> ... </tag> pairs. Here you see table, table row, and table heading tags. Omitted are the table datum ( <td> ... </td>) tags that will be part of the additional rows that provide the table's contents. These tags can have embedded attributes. Here the table is centered, its background set to light blue and border set to one pixel wide. Other tags imply attributes. Table heading cells default to centered and boldface.

If you decide to learn basic HTML, to improve your blog posts, for just one example, my easyHTMLtutorial.com will get you up and running quickly. HTML is simple. It's also the underpinning of the second path to HTML documents.

JavaScript: document.write()

There are times when you leave the simplicity of HTML and use JavaScript programming to create your HTML customized to your viewer's data. My Ruby is one example: it creates a table of checkboxes based on the user's model. There is one row for each "layer" (grouping of model components) and one column for each "scene" in the animation. It can only be created after querying the user's model for, for example, a list of the names of each layer. JavaScript for my Ruby's table would look like this:

// query model for data
// construct a "model" object from the results
document.write( '<table align=center bgcolor=#fofoff border=1>' );
document.write( '<tr>' );
for ( var i = 0; i < model.scenes.length; i++ ) {
    document.write( '<th>' + model.scenes[i].name + '</th>' );
} 
...

This uses JavaScript's document.write() method to write HTML into the page. It is not as simple as plain HTML but it lets your UI be tailored to the users' specifics. In this case, it is writing as many column headings as the user has scenes in his model, using names read from the model. At a cost of one level of indirection, this creates a web page tailored to the user's data. Unfortunately, it is not always an option.

DOM scripting

In my Ruby, for reasons I'll skip here, document.write() was not an option. While technically, simple document.write() calls are a form of DOM scripting (Document Object Model), there is another, less simple, low level at which you can create a web page.

Each web page is a set of objects attached to the "document" object, or attached to other objects which are, in turn attached to the document. In our table example, the table is attached to the document. The table row is attached to the table and the table headers are attached to the table row. Skipping lots of details, the basic idea is this:

var table = document.createElement( 'table' );
// set table attributes here
document.appendChild( table );
var row = table.insertRow();
head = document.createElement( 'th' );
head.innerHTML = 'The Column Heading Text';
row.appendChild( head );
...

Working at this very low level, your JavaScript is in total command. The cost: the simplicity of HTML is gone. If you have to drop to this bottom level, the amount and cost of the JavaScript rises dramatically. Switching from document.write() to bottom level DOM scripting was one of the reasons my two-week Ruby project took six weeks to complete.

"We don't go here unless we need to. Right, Monty?" Monty, my pet python, doesn't hear me. He's busy playing with the kitten.

I Love JavaScript (Sometimes)

News:

From Business Week Big Blue's Global Labs

Building a global chain of "collaboratories." Good luck, IBM. May I loan you my copy of Fumbling the Future?

JavaScript:

Something like this:

    btn.onclick = click_func;
    document.body.appendChild( btn )

That, obviously, will never work. This will:

    document.body.appendChild( btn )
    btn.onclick = click_func;

Did I say "obviously"? That, obviously, was sarcasm.

When coding you exhaust all the rational possibilities first. With code still failing, you move on to the semi-rational possibilities.

After exhausting the rational possibilities, I briefly considered DLing the source for Mozilla, to just take a look for myself at the troubled area. Briefly. Just long enough to learn that there are about 2.5 million lines of code there.

It was Saturday, the 15th, when my Ruby writing ground to a halt with The Bug from Hell. I believe I can proceed again, albeit with the simplicity of document.write() in the rear view mirror.

Started yesterday building tables the slow way. Create a table element and attach it to the body of the document. Create a row element and attach it to the table element. Create cell elements and attach them to the row element. Create contents and insert or attach (depending on type) content to the cells. On to the next row.

My UI includes a table with a table. It's very complex so that the user will think it simple. It took a half day to build it with document.write() . I'm thinking five times the code, and five times the time, doing it the slow way. That, of course, doesn't allow for additional "gotcha"s.

Anybody going to bet against more "gotcha"s?

The Bug from Hell

Executive Summary

One full week lost. Zero output units. It was the bug from hell. If you have any faith in your software schedules, read on.

I am writing a SketchUp Ruby. Stuff that worked Friday stopped working Saturday morning. I got to the bottom of the problem Thursday morning. In a lifetime of coding I've never been stopped for five days by one bug. It was subtle.

The trickiest bit about Rubies is that your UI runs in a browser. That means that the Ruby code that manipulates the model has to communicate with the JavaScript in the browser. (Note: this is another case where you have two languages to use and zero choices about which you use.)

JavaScript on the Front Line:

The general idea is that since the user is in charge, JavaScript notes what buttons are clicked or whatever. JS can then call a Ruby function that will dig up whatever data is needed or manipulate the model in the manner requested. If it needs to send data, Ruby prepares a bit of JavaScript, like this:


script = 'name_of_javascript_function( whatever, facts, are, required )'


Ruby hands this script to a webdialog object (prepared by the web dialog and passed to the Ruby callback). The webdialog executes the script, presumably calling JS functions that make use of the data. The whole communication thing is at best inelegant. This is NOT pythonic.

"No, no, Monty! I didn't mean you. You are totally pythonic."

Monty, my pet python, has been crabby since I turned him into a vegetarian. Sorry for the interruption.

Ruby in the Trenches

Saturday morning I moved the JavaScript out of the HTML file and into a separate JavaScript file so I could validate the HTML. I've got validated HTML, but the code no longer worked. It seems that JavaScript correctly calls Ruby. Ruby correctly gathers the data wanted and correctly forms the script needed. But Ruby is definitely not succeeding in getting back to JavaScript. The final step, executing the JavaScript script, is not happening. At one point the JavaScript function that I wanted called by the script was reduced to launching an alert box that said, "Hooray! Finally!". It never said "Hooray! Finally!".

Note that the tool set is completely primitive. There is no NetBeans, no Eclipse, no debugger. On Windows, we can choose any browser we like, provided we choose MSIE. At one point it reported that I had an error in my JavaScript at line 51 million and something. Ugh. The tiniest little bit of error checking and it's too buggy to be helpful.

For debugging, you stick print statements into the Ruby and pop up alert boxes in JavaScript. Before Saturday ended I knew that my JS was correctly calling Ruby, that Ruby was preparing a valid script passing correct data and was calling the correct method of the webdialog (the webdialog that JS had passed to Ruby). And that was the end of the road.

Swapping Code

By Tuesday I knew that the same code that worked also failed. I started with a successful, small test package and the unsuccessful, larger actual package. I began removing parts of the larger package deleting bits one a a time until I could find the guilty party. I ended with a still-failing package no larger than the test package.

Wednesday found me copying Ruby source functions from the test to the failing routine. Still fails. Copy from the failing to the test? Still succeeds. So repeat this with the JavaScript functions. Same result.

Early Thursday I am convinced that it is a timing issue. How else could two copies of the exact same code fail and succeed?

"Martin, what are you talking about? It's single-user, single-threaded code! Timing issue?"

"OK, Monty. You explain it."

That got me back to Saturday morning. I had taken the JavaScript out of the HTML, where it had been at the end of the body of the page, and put it into a JavaScript file. I linked to the JavaScript file from the <head> section of the HTML, a common practice that I will never again practice.

Moving the "load the JavaScript file" command from the <head> of the HTML to the end of the <body> of the HTML turned the failing code to successful code. Bug in the SketchUp linkage: if your HTML is not completely processed, the webdialog that it passes to Ruby cannot execute the JavaScript script.

Moral?

(In Ruby convention, getters for booleans are suffixed with a "?". This section should return a boolean.) Moral? Maybe.

I let my ego get in the way. Hot shot programmers fix their own bugs, right? Instead of punching ahead on my own, I should have recruited an associate. Wise old programmers get help when they need it. I'll try to remember that.

JSON in Practice

Writing JSON:

I wrote a specific-purpose JSON writer, in Ruby, to encode the data I needed. It wasn't too tough:

# JSON to send to webdialog
def makeJson( layer_names, scene_names, vis ) 
 ret = '{ '
 ret += 'layers:' + makeJsonArr( layer_names )
 ret += ', scenes:' + makeJsonArr( scene_names )
 ret += ', vis:\"' + vis + '\"'
 ret += ' }'
 return ret
end

# convert array of names to JSON array
def makeJsonArr( names )
 ret = '[ '
 start = true
 names.each do |n|
  unless start
   ret += ', '
  else
   start = false
  end
  ret += '\"' + n + '\"'   
 end
 ret += ' ]'
 return ret
end

Reading JSON:

Since JSON is syntactically correct JavaScript, this is the reader that decodes it in JavaScript:

function rubySays( data ) {
 eval( 'obj = ' + data );

The rubySays() method then goes on to make use of the object it creates in its first line. I like code that weighs in at just tens of bytes.

Summary:

Writing JSON is easy. Reading JSON in JavaScript is effortless. Highly recommended!

JavaScript, Again

Opinion in Fortune:

"... most dismissive report ever produced by a Wall Street analyst" Fortune's Apple-watcher summary of an analysis of Microsoft's plan to launch stores to compete with Apple stores.

JavaScript, Encore:

The function concept and the basic syntax goes back to Fortran, c. 1960. (Born in 1956, Fortran, now structured and object-oriented, is still alive and well where scientists need to do serious number crunching.) In Fortran-descendant C you would write:

function add (num1, num2) {
    return num1 + num2;
}

(Actually, it's been a long time since someone wrote an "add" function, but you get the idea.)

That code will run, with only minor changes, through a wide range of compilers and interpreters, including Ruby and JavaScript. Unlike any of the others, here's JavaScript's functional programming alternative:

add = function( num1, num2 ) {
    return num1 + num2;
}

With the code in variable "add" you can use "add" like any other variable. For example, you can pass it to another method:

foo = function( bar ) {
    return bar(2, 2);

foo( add );
}

"foo" is a function with a parameter named "bar". "bar" is a method that foo will call with the arguments "2" and "2". This is certainly the hard way to get to four, but it has lots of powerful uses. Passing a comparison method to a sort routine, for instance.

This also means that in JavaScript, as in C, you can have an array of functions as easily as an array of strings (and without C's pointer mess). If you've ever needed an array of methods where you can't have one (Java comes to mind) you know how important this is.

Perhaps the best thing about this syntax is its pythonicness. Python itself has this capability but in a messy way with lambda functions. I do hope that the designers of future languages will learn from this innovation. (I doubt it, though. For functional programming you would study Lisp, as Python's designer Guido van Rossum did, and come up with lambda functions.)