There're a lot of them out there

NES games never wrote their own scrolling logic, or there own graphics logic. They wrote tile values into a background table and then told the NES how much to scroll the playing field, and the NES rendered and scrolled everything automagically.

NES games never drew their own sprites. They just said "Hey NES, write the sprite at this x and y location" and the NES did it.

Audio worked the same way.

Honestly, coding for the NES would be similar to working with a simple 2D graphics library. So I don't know if it would be accurate to say "every line of code is yours" on the NES. It's more just that the "libraries" used were implemented in hardware instead of software.

Yeah, but the hardware is so limited with weird corner cases that writing a bitblt might be easier. For example, some games have to reconfigure their sprites at the beginning of every horizontal scan line to overcome the hardware limitation on simultaneously displayed sprites (8).

For example, concepts like a scroll register don't typically appear in an abstracted API. They're a hardware detail that happens to assist in implementing a smooth scroll by reducing the necessary computation. But they aren't a "smooth scrolling API" because it works on the tilemap data only - you can also have sprites scroll. That necessitates a software implementation specifically for the task of sprite rendering. Witness the numerous NES games that either let sprites disappear when they hit negative X coordinates or put up a convenient black bar to hide it.

Plus it's really tough to attract out of state talent in Utah.

I think Salt Lake would be a very hard sell compared to what Amazon could easily get with Denver.

Or is there something here whooshing over my head?

In a world where the Red Book of Westmarch actually existed, this other translation would be legal.

http://en.wikipedia.org/wiki/Bored_of_the_Rings

Edit: this is a work of fiction 'blog post' in a pretty fictional-oriented 'blog'

This definitely is designed to maximize battery life

With that said, on wider level, what's the allure of these JavaScript replacement languages? Is JavaScript syntax really that difficult for some developers to wrap their head around? I can understand something like Dart that has an underlying goal of performance, but the purposes of things like this or CoffeeScript genuinely confuse me.

For example, safe object navigation. This code in Spider/CoffeeScript:

    var x = a?.b?.c?.d;

    var x = typeof a !== "undefined" && a && a.b && a.b.c ? a.b.c.d : void 0;

    var x = _.getPath(a, "b.c.d");

[1] http://documentcloud.github.io/underscore-contrib/

I'm mighty tempted to write a Webpack plugin to make `?` usable in vanilla JS.

Even if you don't know CS very well, I dare you to take a look at the JavaScript this compiles to and call it more readable:

    (req, res)->
      getUserIds(req.query)
      .then (ids)->
        Promise.all ids.map (id)-> 
          getUser(id).then (user)-> user.friends.count
      .then (response)-> res.send 200, response
      .catch (error)-> res.send 500, error

You code compiles to:

  (function(req, res) {
    return getUserIds(req.query).then(function(ids) {
      return Promise.all(ids.map(function(id) {
        return getUser(id).then(function(user) {
          return user.friends.count;
        });
      }));
    }).then(function(response) {
      return res.send(200, response);
    })["catch"](function(error) {
      return res.send(500, error);
    });
  });

Edit: But that aside, to be fair, I'll readily agree that it is easy to mess up CoffeeScript's significant whitespace if you don't pay attention to it. For example, you add a multi-line callback to one of those single-line callbacks at your peril!

But the tradeoff is, no mismatched braces/parenteses. Personally, I find the warts are not that hard to avoid, and the overall impact on my productivity is positive.

More readable? Eh...

I can grok either at about the same speed.

I mean, if you're talking about a deep understanding of what the code does, I agree with you. But when you're writing a lot of code that basically looks like that, it's useful to be able to take it in at a glance.

We wear whatever the hell we want to at the office, but if I conduct an interview and the interviewee comes wearing jeans and a T-Shirt with holes, I problem will end the interview short and thank him for his time. If he doesn't care about this job enough to even make an attempt at dressing up then why waste our time.

Same with swearing. If you can't show to us that you care about this job enough to use professional language for an hour then I probably won't consider you past the first round. It's not whether we care about swearing, it's about proving to us you really want this job.

If my employer won't swear in the interview out of principle, we are a bad culture fit.

I created an app using some of nathanborrors work that let's you browse through all of the Sonos Music services (Like Rdio, Spotify, Pandora, iHearRadio, etc). Setup your account, browse through your collections and play them on your system. I should submit a pull request to see if I can get this integrated into this project!

You can see the project here: https://github.com/drewying/Sonos-Music-Services-Browser

I also have an app on the App Store that turns your Sonos System into a wireless PA system. The current version is a little buggy but an update is coming shortly that makes it much more stable. You can check it out here:

https://itunes.apple.com/us/app/sonos-voice/id689673100?mt=8