Friday, November 28, 2008

Choosing an Assignment Operator

If you were to write your own programming language (as I still intend to do someday even if only for the learning experience it provides me), what symbol (or symbols) would you use to represent the assignment operator?

Even though it would looks like BNF or old-school Pascal, I would lean towards using := as the assignment operator. That would leave me free to use = for equality and there wouldn't be the issue of = vs. == tripping up new programmers. Besides, performing assignments is more common than making comparisons, so perhaps assignment should have the more distinct operator. Going one step further, if the language I wrote was not strongly typed, I would use == as the identity operator (as like PHP's ===). := and = to == seems a more logical progression to me than = and == to ===.

I suspect I wouldn't use = as both assignment and comparison as Basic does because of the ambiguity it causes. For example:
x = y = 0
Does this mean "assign 0 to both x and y", or "assign the boolean comparison whether the value of y is 0 to x?" Statements such as these:
x := y = 0
x := y := 0
are then both clear in their meaning.

I think my second choice would be just : and have something like:
x: 2 + 2
The lvalue appears as if it were a label, giving the visual representation that x means 2 + 2. Plus, it would be one (of many) syntaxtic differences that would separate my language from the others. I don't know of any languages that currently use : as an assignment operator.

Of course, this all presumes the elements of a statement are written in a certain order. If you were to use a keyword such as set:
x set 2 + 2
just appears awkward to me. It would have to be:
set x 2 + 2
But if you always require the assignment target on the left-hand side of your operator, then is an explicit assignment operator really required as all? The implied assignment operation of something like:
x 2 + 2
is clean and succinct.

Monday, November 10, 2008

JavaScript Frameworks Suck

There's been an interesting discussion off and on around the office this past couple of weeks about JavaScript frameworks, specifically which framework is the best so we can standardize on one. Of course I have to be difficult... my answer is none of them.

As a general rule of thumb, "frameworks are evil." There are exceptions, but frameworks seem to cause a lot of unnecessary bloat, make tasks difficult to accomplish if they fall outside the intended scope of the framework, create obstacles to efficient debugging, and adversely affect page load times causing the application to appear slow and sluggish. The real question ought not be what framework is best, but rather be what exactly are you trying to accomplish with client-side scripting in the first place.

Creating a rich user experience with standard JavaScript is not difficult. Many of the niceties the frameworks provide aren't magic... for example, $() is just function(x) document.getElementById(x);}. And AJAX is easy if you forgo XML in favor of JSON as your transfer format. If you don't understand your goals then you might as well just shoot yourself in the foot.

Once you have identified exactly what your needs are, and if those needs suggest you use a framework, then those needs will also dictate which framework would be suitable for use. If you need widgets, for example, then YUI! would stand out more as the best choice. If you need modularity and flexibility instead, then MooTools might be the way to go.

To further illustrate my point to a coworker that frameworks don't always make things easier, I implemented a basic Accordion widget in MooTools and straight-up plain old JavaScript. The development time in JavaScript proper was half-that of developing with MooTools because I didn't have to learn any special APIs, scrounge the documentation for a list of dependency files, etc. My implementation weighs in at 50 lines vs. MooTools' 3,100+ lines and 21 dependency files.
function $$(className) {
    var classElements = new Array();
    var els = document.getElementsByTagName("*");
    var pattern = new RegExp('(^|\\s)' + className + '(\\s|$)');

    for (var i = 0, j = 0; i < els.length; i++) {
        if (pattern.test(els[i].className)) {
            classElements[j] = els[i];
            j++;
        }
    }

    return classElements;
}

function Accordion(headerClass, panelClass, showIndex) {
    this.headers = $$(headerClass);
    this.panels  = $$(panelClass);

    for (var i = 0; i < this.headers.length; i++) {
        this.headers[i].args = {
            index: i,
            headers: this.headers,
            panels : this.panels
        };
        this.headers[i].onclick = function () {
            var a = this.args;
            for (var i = 0; i < a.panels.length; i++) {
                a.panels[i].style.display = ( i == a.index) ?
                    "" : "none";
            }
        };
    }

    (showIndex === undefined ? this.headers[0] : 
        this.headers[showIndex]).onclick();

    return true;
}

window.onload = function() {
    new Accordion("a_header", "a_body");
};
Sure it's not as "feature rich" as MooTools' Accordion, but any additional features can easily be added when the time comes, and they certainly wouldn't require 3,050 more lines of code.

People want fast front-ends. They're impatient and don't want to wait. Bloated code slows down the front-end and gives them impression of a slow back-end. Half the development time and 98.4% less code? Now that sounds good to me!