Javascript Plus Plus

My first year of programming in college, which was my third year in college, was taught in c++. I was part of a new experimental major at RIT christened Information Technology. It was trying to find a happy space in-between hardcode Computer Science and the useless Information Systems programs out there. The major was around 5 years old when I started, and they were still working out some kinks. It had a reputation as a hideout for CS majors who couldn’t hack it. I confused everyone by being an ex-photojournalism major.

The year before I started there were three core programming classes that everyone had to take. I don’t remember the names, but the numbers were 208, 210, and 212; Intro/Intermediate/Advanced. The year I started they dropped 212 as a requirement and let you slot in any general programming course.

While the classes were taught in c++, they were meant more as a general intro to programming for non-CS majors. This is a Loop, This is a Function, etc. The 208 class was designed to be an easy A to give people the confidence to tackle the 210 class. It was a concerted effort to avoid the usual “well, if you can’t hack pointers in your second week, then you don’t belong here” attitude that’s prevalent in most CS programs.

The intermediate course, 210, was a bit of a mess. It started out at a similarly slow pace, covering c++’s object oriented features. An object is like a struct with methods, etc. Then, about half way through the course they dropped everyone off a cliff with operator overloading, pointers and other low level abstractions that are the meat and potatoes of the C languages.

Lots of people struggled with this. I did OK, but I got through the class mostly via a lot of trial and error glopping. I never got a chance to wrap my head around pointers, linked lists and other “real” programming tasks. I understood the abstractions on a base level, but because the classes had been so basic, I never wrapped my head around why they were such powerful abstractions.

I had a chance to talk to some of the professors who designed the courses, and they flat out admitted that they ran out of time while designing 210, and the cliff everyone fell off was the point where they just started adding back stuff from the previous curriculum.

The next year a decision was made to move away from c++ as the language for the intro programming courses. The choices were Java and Visual Basic … and the department chose VB. Everyone who had to suffer through the c++ courses screamed bloody murder, but there was a large faction within the IT program that felt if a student wanted a more formal programming background they could take more programming courses. I also remember an argument against Java based around it’s newness (this was in ’95/’96) and an uncertainty if it’d be relevant.

Oops.

So, I went on to hack on perl, HTML, Javascript, and Lingo (as in, Macromedia Director Lingo) and never got the formal education in C/C++ that a lot of programmers get. I also missed out on the Design Patterns revolution; The importance of OOP when I was in school was all about inheritance and code reuse and it’s only in the past three years that my mind has aligned with what some of the formally defined design patterns can offer.

Forward to the Past

Which brings me to the present. For the past week or so I’ve been working my way through the Second Edition of The C Programming Language, considered the book for old greybeards and those who wish to understand them better. With a decade of actual programming experience under my belt and working at my own pace, it’s making a lot more sense this time around.

C is a procedural language. No OOP out of the box. That said, consider this very crude program. It’s valid ANSI-C, and will compile.

#include<stdio.h>

struct foobarbaz{
    int one;
    int two;
    int three;
    int (*exampleMethod)(int, int);
};

int addTwoNumbers(int a, int b){
    return a+b;
}

int main()
{  
    //define the function pointer    
    int (*pointerToFunction)(int, int) = addTwoNumbers;         

    //lets make sure we can call the pointer
    int test = (*pointerToFunction)(12,12); 
    printf ("test: %u \n",  test);

    //now, define an instance of our struct
    //and add some default values
    struct foobarbaz fbb;
    fbb.one   = 1;
    fbb.two   = 2;
    fbb.three = 3;   

    //now add a "method"
    fbb.exampleMethod = addTwoNumbers;

    //try calling the method
    int test2 = fbb.exampleMethod(13,36);    
    printf ("test2: %u \n",  test2);   

    printf("\nDone\n");
    return 0;
}

This is the particular line you should pay attention to

int test2 = fbb.exampleMethod(13,36);    

By using a function pointer inside a struct, we have the first building block of a traditional object, the method. By using more and more abstraction and clever patterns, you can develop patterns that will allow methods to access internal properties in a this like content, as well as start adding public, private and protected variables. There’s a lot of coding overhead that goes into maintaining the patterns, but C is powerful enough to support these constructs.

Eventually someone decided we needed a new language that formalized some of these patterns into the language, and c++ was born. No one seemed happy with c++ so the object people went off and got Sun to develop Java, which made some people happy but pissed off people who wanted their programming language to be close to the iron.

This should sound familiar to any working Javascript programmer today.

Back to the Future

There’s been a lot of buzz lately around Javascript 2. The biggest buzzing seems to be around some <a href=”http://ejohn.org/blog/bug-fixes-in-javascript-2/>overdue bug fixes/clarifications, and some Java like OOP.

There’s a big question in my mind as to how relevant this will be. The first, obvious problem is browser support. The Mozilla Corporation seems to be behind the move, and some of this (Native JSON, for example) is already in Firefox 3. What’s not so clear is how much support companies like Apple, Opera and Microsoft will put into meeting the Javascript 2 spec in browser.

One suggested approach from the computer scientists is “Write it in Javascript 2, then compile down to Javascript 1 for release”. Google Web Tools already lets you take this approach, (although I haven’t had a chance to play with it yet).

I can see this approach working for people who write the various Javascript frameworks, but it would be ill advised for your average, run of the mill web-app developer. Cross browser debugging is hard enough without having to contend with compact/opaque code that any Javascript 2 to Javascript 1 compiler is going to spit out.

The other big Javascript grail is a server side framework (Sorry ASP for Jscript, you don’t count). Javascript 2 seems like a better fit there, but as geeky-cool as modern, server side javascript is I don’t see there being anything or anyone to drive adoption of a framework like this.

There are social patterns that emerge in software development as the same problems are solved over again, creating new, slightly different problems which cause the same problems to be solved over again [ed: I think they call that recursive]. Javascript 2 is certainly an important development, but unless you’re a framework writer, or willing to completely change the way you work, dont expect to start reaping the benefits anytime soon. If ever.