The Next Javascript

Recently, I've been more interested in Javascript than I have been in a long time. However, after reading some of proposed features for Javascript 2, I feel like I'm watching a simple language with a few warts turn into a bloated C++.

From the proposal, I get the distinct impression that the committee designing Javascript 2 has some contempt for prototypical inheritance and dynamic typing. The proposal includes support for packages, classes, static typing etc. All things that appear to come straight from Java and other enterprise-y languages that I find are slow to develop in. Thankfully, it will be optionally typed, meaning you don't have to statically type your variables unless you want to. I haven't decided which side of the fence I fall on in terms of that debate yet, but I do feel like it statically typed languages can feel like a straight jacket from time to time.

All in all, the changes are way too much, way too quickly. For starters, all of the major browsers will need to support this new, hugely unproven language right out the gate. Undoubtedly there will be mistakes made in implementations, if they are even implemented at all. No one from the Web Development community will be able to use Javascript 2 at all being that it's so vastly different from Javascript 1.x and there is still a need to support older browsers for their applications.

You simply cannot force the sort of change this new language spec imposes in one go. It may as well be a new language for all the changes it includes. I believe, a more fruitful approach to moving Javascript 1.x to where this committee thinks it should go would be to incrementally add these changes to the existing language. I couldn't tell you where to start, as I'm fairly happy the current language, but I'm sure the community as a whole will be able to give feedback to the language designers in terms of what features are actually needed as opposed to what the designers think is needed.

In the end, if the committee goes forth with this specification for Javascript 2 it will be a long, hard, bumpy road to get stable, completely implementations in the browsers that are actually being used. Perhaps, more effort should be spent tackling the issues around the same-origin policy instead of giving new features that we can't possibly use for another 5 years.

Leopard

I upgraded to Leopard the weekend after it came out and so far, I've been pretty happy. There's only one thing I've noticed so far that's bothered me, Remote Desktop's VNC protocol is busted.

I did some research and it turns out I'm not the only person having this problem. Luckily, some of the others that have been having problems found out that they could connect using TightVNC. It's kind of a shame though, because RealVNC has been my Windows client of choice for the past few years.

So, while I wait for Apple to fix it, I suppose I'll have to settle with Vine Server which has worked flawlessly for me for years.

As a side note, I never knew that Apple had VNC support under Tiger until I started trying to find out why it's Apple would ship a broken new feature under Leopard. Shows how much I know.

Functions ARE Objects!

Javascript is a functional, object-oriented language - but what exactly does that mean to you a developer? It means that functions ARE objects. You can add members to functions just as you could any object. Take for example, the following function that keeps track of how many times it's been called:

function count_times() {
 count_times.call_count = (count_times.call_count || 0) + 1;
 print(count_times.call_count);
}

Trivial example I know, but let your imagination go wild.

arguments.callee

Javascript Tip: Ever wonder what arguments.callee is for? Well, it contains the function being evaluated, so you can write anonymous recursive functions like the following:

(function(n) {
  if (n > 1)
     return n * arguments.callee(n-1);
  else
     return 1;
})(5);

Which is the same as the following written in a more traditional way:

function fact(n) {
   if (n > 1)
      return n * fact(n-1);
   else
      return 1;
}

fact(5);

Java 1, Bryan 0

Java is a really bad language for getting things done quickly. I don't mean in terms of processing speed, I mean in terms of the amount of time it takes to write something that works.

Friday I spent a bunch of time writing what I thought would be a trivial Java program with some pretty simple requirements. My program was to open a stream to a URL and pump a file at it. Additionally, I wanted my program to do this continuously with a bunch of threads.

After about an hour I had all but given up. In that hour I'd had problems with ports being left open, and data just not showing up on the other end of the connection. You might be tempted to say "oh the fool, he didn't close his streams", or "what an idiot, he never flushed the streams". You'd be wrong on both counts.

I probably missed something, but you know what? it doesn't matter. Java just isn't in the language to be using when you need to get things done quickly. Java is a systems language, not a get-things-done-quickly language. I really should have written this in something like Ruby or Python. The only problem is that while I know the syntax of these languages, I'm not familiar with the libraries.

I'm willing to bet that I would have been able to get this simple program written in about an hour, even without knowing the libraries, and it would have worked, unlike my Java version.

Erlang != NBL

I was browsing InfoQ this morning and read a blog post about how Erlang may be the next big language after Java.

I tend to disagree with the points made. Erlang seems to me to be more of a niche language, much like Smalltalk. Sure it's powerful and grand, but the next big language it isn't. The syntax, from what I've seen, isn't what programmers are used to. That alone is probably the biggest strike against it. Even if the syntax was more C-like, the language isn't well known outside of the functional language geek crowd, and it lacks a "killer app".

If you want my honest opinion, I agree with language that Steve Yegge alluded to in his The Next Big Language post a while back: Javascript. It's used more than most people want to believe, it's functional, object-oriented, and embeddable. In short, it's everywhere. The only problem is that it's current implementations don't make concurrent programming any easier. But since when has the next big language ever been about the right tool for the job?

Ergonomics

Today I'd like to take some time to say a special thank-you to Logitech for creating the Marble Mouse. Without it I wouldn't be able to be a programmer anymore.

In the summer of 2005 I noticed a pain in my right wrist. I bought a wrist brace to help stabilize my wrist, and it worked great at night, when I had a hard time orienting my wrist in a neutral position while I slept, but it was too bulky to be able to use all the time. As the weeks went on it became quite aparent that what I was doing wasn't working and I needed to try something else.

I talked to a few people at work. Some suggested taking a vacation, others said accupuncture. I was in school at the time and couldn't really afford a break, and I'm not a big fan of needles so I thought I'd try accupuncture as a last resort. A few people suggested getting a trackball. I had tried a trackball before and I found them to be horribly inaccurate so I was a little bit skeptical, but I thought I could get used to it.

I peeked over the cubicle wall, and a friend of mine was using the Logitech Marble Mouse. It seemed a little bit odd but because my problem seemed to stem from clicking I figured it'd be a good one to try. (The Marble Mouse is shaped kinda like a mouse, except there's a ball where the buttons should be and the buttons are on the side. You just roll your hand to click).

I have to say, after an hour of using it I couldn't believe what a difference it made. Not only that, but I was reasonably accurate with it too, unlike the thumb style ones I'd used before.

I'm not posting this hoping for free stuff, I'm posting it as one extremely satisfied customer.

DVORAK Keyboard Layout

I just read a Slashdot post about the DVORAK keyboard layout. While I'll agree that it probably does improve your typing speed, I don't understand why a programmer would want to use it for that reason.

Unless your job is to crank out tons of code as fast as possible, improving your typing speed won't make you any faster. Most programmers that I know (myself included) aren't I/O bound, they're CPU bound. Just because we can type faster doesn't mean that we'll be able to produce more code, or that the code will be any better.

Not that I have any personal experience with XP, but I think this is probably the same reasoning behind pair programming. And, the common thought that faster typing = more productive programmers is probably why everyone I've talked to balks at pair programming.