Scheme in the browser (again)

I found myself reading “Popularity” over at Brendan’s Roadmap Updates...again.

This time, a comment by Mike Ivanov stood out to me:

It took almost a decade for ‘average developer’ to grok JavaScript. Now it is understood, at least. How much time would pass before Scheme achieved the same level of acceptance? I bet forever.

Which again has me questioning that. I can’t believe that anyone who has really “grokked” Javascript couldn’t have grokked Scheme. After all, Javascript essentially is Scheme with C syntax. Grokking the language behind that syntax is much more difficult than grokking the syntax.

I think that Javascript was in a unique position. I suspect almost no-one learned Javascript for its own sake. People learned Javascript because it was (essentially) the only game in town for the role it played. (Indeed, it is still too difficult, IMHO, to use Javascript outside that role.)

That’s certainly why I learned it. At the time, I would’ve much rather used Perl, but my customers had Javascript built into their browsers. I wasn’t going to ask them to install client-side Perl.

Likewise, I suspect that Javascript is one of those languages that was the first programming language for a lot of people. Those are people who aren’t coming in with syntax-bias.

Which may be pointless speculation, but that’s what thinking-out-loud is for. I still give thanks to Brendan that I’m required to regularly, at work, program in Scheme/Self even if it is with C syntax.

Guitar Hero stifling potential musicians?

Michael over at Fretbase wrote:

I’ve always argued that Guitar Hero is a tragic diversion for potential musicians who will never learn how to play an actual guitar. Worse, anyone playing Guitar Hero is not even responsible for making the music; they can only “hit” or “miss” the notes already laid out for them. The only way to remove a person any further from the process would be to handcuff them to a chair and blast an iPod Shuffle from across the room.

I think Michael is wrong on this. I haven’t seen any of the people I play Guitar Hero and Rock Band with thinking of it as playing music at all. They think of it as a game. For—I think—exactly the reasons Michael criticizes it. For the most part, it doesn’t feel like playing music at all. It feels like playing a game. I see nothing to convince me that any of the non-musicians among them would take up an instrument in the absence of these games, or that the musicians are making music less than they would. If these games are taking time away from something else, it is other games.

A friend once said to me, “I know a lot of people who own guitars, but you’re the only one who knows how to play it.” I find it hard to believe there are many potential guitarists who aren’t taking up the instrument because of Guitar Hero.

Moreover, another Fretbase contributor, Brian, posted an article about how a survey shows that—because of these games—players are more likely to start playing guitar or play more often if they already do.

Third hand

My Digitech RP350 (“Modeling Guitar Processor”) has the ability to control almost any parameter with its expression pedal. Some of the things I’ve had fun playing with have been...

• Reverb depth
• Tremolo speed
• Amp gain
• The mix between the original signal and the harmony generated by the intelligent pitch shifter.

When I do this, though, I always wonder how might do it with individual pedals. Well, I chanced across a device that claims to do exactly that: the Third Hand by Tone in Progress. An expression pedal that appears to be able to mechanically turn a knob on an effects pedal.

Good metagaming; bad metagaming

In role-playing game circles, metagaming often has a negative connotation. (Wikipedia also has an article on metagaming in role-playing games.)

In general, this is not the case, though. A metagame (“beyond the game”) adds an extra layer—a higher level—that can often (though not always) make the game more interesting. e.g. Trading in Monopoly could be considered a metagame.

I want to ramble about two scenarios today.

Scenario 1: A magic-user is about to drop a fireball on a bunch of enemies. The character doesn’t know that the party thief, who is out-of-sight, will get caught in the blast. The player, however, does know it. The player also knows that there’s a good chance the fireball will kill (or knock out) the thief.

One might argue that the player should have the magic-user choose a different action because: (1) A player shouldn’t knowingly have their character do something that substantially risks the fun of another player. If the thief character were to be killed by the fireball, the thief’s player is going to be out-of-the-game for an indefinite period of time. (2) There are surely other actions the magic-user could take that wouldn’t be out-of-place or out-of-character.

I tend to argue, however, that a large part of the fun of role-playing games for me is having things play out in a “natural” manner. Trying to prevent yourselves from getting caught in a situation like this and suffering the consequences when you do find yourselves in this kind of situation is important

Scenario 2: Black Dougal fails a saving throw versus poison and dies. (This also applies to characters who are otherwise disabled or simply not present at the current scene for some reason.)

What I’ve typically seen in this situation is that Black Dougal’s player is relegated to quietly watching the game since they no longer have a live and present character to speak through.

These days, however, I tend to think that there is no reason that players should not be able to advise other players.

(This post partially inspired by Grimm Studios podcast episode 19.)

Why MIT 6.001 switched from Scheme to Python

From wingolog: international lisp conference—day two:

The “debate” had an interlude, in which Costanza asked Sussman why MIT had switched away from Scheme for their introductory programming course, 6.001. This was a gem. He said that the reason that happened was because engineering in 1980 was not what it was in the mid-90s or in 2000. In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme—it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that’s all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.

But programming now isn’t so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don’t know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.

So the good thing about the new 6.001 was that it was robot-centered—you had to program a little robot to move around. And robots are not like resistors, behaving according to ideal functions. Wheels slip, the environment changes, etc—you have to build in robustness to the system, in a different way than the one SICP discusses.

And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all.

SICP is the textbook, Structure and Interpretation of Computer Programs.

Double-click

Back when the Macintosh was first being designed, user testing suggested that many people had a hard time remembering what more than one button on a mouse was used for. So, they put one button on the Mac mouse.

They really seemed to feel the need for more functionality, though, so they added double-clicks as a short-cut to some extended actions. Of course, double-clicks were hard for some people.

So the cardinal rules of double-clicks were:

• Double-clicks should never be the only way to do something; they should simply be short-cuts
• A double-click action should be a natural extension of the single-click action

Of course, one of the big problems was that users ended up learning to always double-click. I’ve run into people who were genuinely surprised to learn that a single-click did anything. Even more people didn’t realize that there were other ways to accomplish double-click actions.

It’ll be interesting to see how Apple’s choice to have some functions on the new iPod shuffle only accessible through double- and triple-clicks and holding works out.

Arbitrary

One of the great things about the Dragonsfoot forums is that some of the members made an effort to track down and invite a lot of old TSR employees—besides those who were already there—to come participate.

The more I know about people, the harder it is for me to call their creations “arbitrary”.