Interesting Game

I liked this game so much that I could not resist myself for talking about it.
I will not say anything.
Just play it yourself and decide .

A programmer's view of the Universe, part 2: Mario Kart

This is the second installment of a little series of discussions. They're not much more than that, just discussions. And I hope I'm inviting discussion rather than quenching it. But I'll be honest — the goal of this series is to pound a stake through the heart of a certain way of thinking about the world that has become quite popular. If my series fails in that regard, I hope it may still provide some entertainment value.

Part one, The fish, was about a twisty line and a fish's examination of it. Today we move to a twisty plane.

Embedded Systems

There are many kinds of computer programs, and many ways to categorize them. One of the broadest and most interesting program categories is embedded systems. These systems are the centerpiece of today's little chat.

Embedded systems are a bit tricky to define because they come in so many shapes and sizes. Loosely speaking, an embedded system is a little world of its own: an ecosystem with its own rules and its own behavior. So an embedded system need not even be a computer program: a fish tank is also a kind of embedded system.

We call them embedded systems because they exist within the context of a host system. The host system provides the machinery that allows the embedded system to exist, and to do whatever it is that the embedded system likes to do.

For fish tanks, the host system is the tank itself, which you may purchase from a pet store. A tank has walls for holding the water in, filters and pumps for keeping the water clean, lights for keeping the fish and plants alive a little longer, and access holes for putting your hand through to clean the tank. There's not much to it, really. The embedded system is everything inside: the water, the plants, the rocks, the fish, and the little treasure chest with bubbles coming out.

For computer games, another popular kind of embedded system, the host system is the computer that runs the game: a PC, a game console, a phone, anything that can make a game exist for a while so that you may play it.

Programmers have been building embedded systems for many decades: a whole lifetime now. It is a well-studied, well-understood, well-engineered subject. Gamers understand many of the core principles intuitively; programmers, even more so. But in order to apply all that knowledge outside the domain of embedded systems, we will need some new names for the core ideas.

The most important name is the One-Way Wall. I do not have a better name for it. It is the most important concept in embedded systems. In lieu of a good name, I will explain it to you, and then the name will stand for the thing you now understand. It's the best I could come up with.

But first let's dive into an embedded system and see what this wall looks like from the inside.

Mario Kart

I will assume you've played Mario Kart, or you've at least watched someone else play it. Mario Kart is the ultimate racing game in terms of sacrificing realism for fun. It bears so little resemblance to reality that it's a wonder it tickles our senses at all. The Karts skid around with impossible coefficients of friction, righting themselves from any wrong position, and generally making a mockery of the last four centuries of advances in physics.

It's really fun.

Mario Kart, like all games, has a boundary around the edge of the playing area. In Mario Kart you bump into it more often than in most other games, which is part of the reason I chose it to be our Eponymous Hero. If you want to win a race, you will need to become quite good at accelerating around corners, which means you will spend a fair amount of time bumping up against an invisible wall.

You know the wall I'm talking about, right? It's invisible, so you can see right past it to the terrain beyond. But the wall is there, and you are not permitted to venture beyond it.

In slower-paced games, when you arrive at the invisible map boundary, you will sometimes be told by the game: "You can't go that way. Turn back!" And since that is your only option, you comply. These invisible boundaries are non-negotiable.

In other games, you may stop on contact with the boundary, or perhaps bounce off. But the boundary is always there.

Imagine Mario and Luigi chatting about the you-can't-go-that-way wall. Their conversation might go something like this:

Mario: "Luigi, my brother!"

Luigi: "Maaaarioooooo!"

Mario: "Yes, Luigi. I am a here. Tell me my brother, why is it that every a time I a spin around the cactus in the third a bend of the Desert a Track, I get a stuck and have to start accelerating from nooooothing?"

Luigi: "Whaaaaa?"

Mario: "Brother, the Desert a Track! It's Number a Three! You know the big a bend, where you have to slow down? I am always a forgetting to slow, and I just a stop. Just a like that!"

Luigi: "I don't know, Brother. That Bowser, he is always a squishing me right before I hit that turn, and I am a flat like a pan a cake for a looooong a time."

Mario: "What about that a time two races ago, where Wario hit you and you a spun around and you a headed for the hill, and you got a stuck and wailed for me?"

Luigi: "Ah, that Wario! I will get him next a time!"

Mario: "Why did you not just turn around then?"

Luigi: "My Kart, it did not a move, no matter how I wailed."

Mario: "That is a what I am a speaking of, Brother. Your Kart moves in all other places, but if you head for the hills, it just a stops a suddenly!"

Luigi: "I a hate a stopping a suddenly."

Mario: "Yes, Brother. So do I. But why can we not traverse that a part of the hill? What is on the other a side?"

Luigi: "I think it is Track 4, Brother. They do not want you to wind up in the lake."

Mario: "Whaaaa? Who is this a 'they'? And why can we a not see the lake from a Track a 3? I think there is a nothing there, Brother. Just a more hills."

Luigi: "No, my brother. I think it is a Track a 4. Or maybe Track a 2. There must be a something there."

Mario: "Perhaps you are a right, my brother. We should get a back to a racing now. We can talk a more about a this after the next a race."

Luigi: "Yes, brother. I will a get that Wario this a time!"

Well-formed nonsensical questions

In our Highly Realistic Dialog, Mario is wondering about the Invisible Boundary at the edge of the track. He asks his brother the seemingly obvious question: "What is on the other side?"

As a gamer, if you pause to consider the question at all, the answer seems to be: "Nothing I care about." The invisible (or sometimes visible) Boundary seems just like any other wall. It is designed to keep you in where you're at, or out of where you're not, depending on your point of view.

But the gamer's view is that the boundary does have another side. You have no way to get there, but it exists. For maximum gameplay immersion a game universe needs to appear consistent. Thus, when you peer through the wall it appears that the other side is just more of the same.

To an embedded systems programmer, Mario's question is complete nonsense, like a fish asking the temperature of the water on the other side of the glass. There is no water on the other side, and for that matter a fish can't ask questions, so the question itself is based on nonsense premises.

From a perspective within the Mario Kart universe, the "other side" of the Invisible Boundary is... a kind of nothingness. The embedded world quite literally ends at the boundary. The level designers usually try to make it appear as if the current world continues on, but this is an illusion. They discontinue the model's polygons beyond the line of sight. Put another way, the water stops at the edge of the tank.

The nothingness beyond the Invisible Boundary of an embedded system is much deeper and more significant than simply not having objects there. In that nothingness there is no programmatic substrate upon which to place objects. If you were to ask: "What lies between Mario's head and Luigi's head," the answer may well be "nothing", since no game objects may overlap the line between their heads at the particular time you ask the question. But that "nothing" is qualitatively different from the "nothing" on the other side of the Invisible Boundary. Between Mario and Luigi there is a space – a place in their universe where objects and forces and logic apply, even if they are Mario Kart's twisted versions of physics and logic. That universe ends abruptly at the surface of the boundary.

The question "What's on the other side" is well-formed in a strictly mathematical sense. You could project a line from Mario to the nearest boundary, and ask the more precise question: "If Mario is at distance D from nearest boundary B, what overlaps the point P obtained by extending the Mario-boundary line L to a distance D beyond B?" ("Whaaaaa?")

The new formulation of the question is more well-formed, but it is every bit as semantically nonsensical.

What's really on the other side

In the context of the Mario Kart universe, the system boundary truly only has on side, and Mario and Luigi are on that side. From their perspective, we can't meaningfully ask the question "What's on the other side?" However, there is a semantically significant interpretation of "the other side" of that invisible boundary. To get to this better answer we must leave Mario's universe.

From the perspective of an embedded systems programmer, the entire Mario Kart universe is data structures laid out in the memory space of some machine. There is a program — the game engine — that interprets the data in a way that makes it appear to be a universe that is similar to ours in various intuitively appealing ways, yet different from our universe in various fun ways.

It is very unlikely that the polygons and other level data are laid out in strictly contiguous order in the host machine's memory space. It is more likely that they are spread out, with gaps, like dominoes spilled on a tile floor.

The question "What's on the other side?", when viewed from the perspective of a systems programmer, might be phrased more precisely and meaningfully as follows: "What occupies the memory spaces adjacent to the memory used by the Track Three Desert Level?"

This is the same as Mario's question, but we had to step outside the Mario Kart universe in order to ask the question in a way that made sense. The Mario Kart universe, like most game universes and in fact most embedded systems, is designed to appear complete. There is apparently "stuff" beyond the boundary; you just can't go that way.

When we step up into the host system and ask the analogous question about the "other side", both the question and the potential answers become much more complex: many orders of magnitude more complex, in fact. Fortunately, due to the Mario Kart system being so simple, increasing the complexity still gives us a vaguely accessible problem.

Let's try to cook up an answer to this new, more complex question regarding the contents of the program memory space on the "other side" of the invisible wall.

In terms of atomic program units (say, bits or bytes), the amount of memory used by a game like Mario Kart is actually high enough to defy our sense of scale. A game with hundreds of megabytes or gigabytes of runtime data has billions of discrete elements, which is too many for us to keep track of individually. One of the key jobs of a programmer is to organize their code so that the elements can be managed at human-CPU scale: up to seven "things" at a time. But this organization can't mask the fact that billions of individual elements exist, each with its own role to play in supporting the embedded system.

Hence, even for a game as "simple" as Mario Kart, we're stuck imagining how it works internally. Even the programmers who built the game have only a dim and incomplete mental model of the game. It's like building a skyscraper, or a city: you build it a piece at a time, and it's rarely fruitful to try to picture everything inside of it simultaneously.

Anything that goes wrong or is out of place in the program could take days to track down with state of the art tools. That's just how it is. We're not able to comprehend large problems all at once; we can only attempt it in small increments.

Bearing this necessarily incomplete understanding in mind, what exactly would we find in the machine memory between the elements of Mario and Luigi's track mini-universe?

The answer is familiar to programmers and perhaps surprising to non-programmers. The answer is: almost anything. It could be elements of a different program, or random garbage not being interpreted by any program, or supplemental data for the Mario Kart universe, such as language translation strings. Or Luigi could be right: it could be Track 4, pre-cached for the next race. Perhaps not exactly the way he's imagining it, but... close.

Moving beyond the Wall

Our little visualization of the host system's memory raises another natural question: what would happen if you "zapped" Luigi's Kart across the boundary?

This question isn't entirely as nonsensical as "what's on the other side?" With the proper programming tools, you might be able to observe changes in the machine memory as Luigi's Kart moves, and these changes might follow an observable pattern that leads to a relevant prediction of sorts.

As just one possibility, Kart motion might be represented as shifting a Kart memory structure along the sequential indexes of an in-memory array. This arrangement is unlikely for performance reasons, but it's certainly possible, and should serve to illustrate the point. If you were to find that moving Luigi's Kart ten meters (in the scale of Luigi's track universe) resulted in a structure motion of 1000 memory addresses, then you might make the reasonable prediction that in another ten meters his representation would move another 1000 addresses.

This might well put him beyond the end of the physical memory array. In most real-world scenarios this would be a bug, and would result in some sort of nasty response from the machine, such as a game crash. Or in a more user-friendly environment, the game engine might simply prevent his motion in that direction and move him back into his universe. This might put his Kart in an uncomfortable position, but it will at least be a real position according to the logic of the Mario Kart universe. At least the Kart won't have disappeared.

However, it is infinitesimally possible that Luigi's Kart could be moved into another physical machine process in the host system — say, another instance of Mario Kart running on a time-sharing operating system or virtual machine — in such a way that Luigi and his cart physically disappear from the old universe (a process address space) and appear in the new universe (another process address space).

Even if this infinitely remote possibility were to occur, chances are high that the sudden appearance of Luigi and his Kart would wreak local or even global havoc in the new universe. He might get lucky and crush Bowser into a pan-a cake, but more likely he would wind up stuck in a stone wall or a hill, unable to move. Or even more likely, his Kart's memory structure would be copied into a non-game area, such as the translation string section, and Luigi's sudden mysterious appearance might manifest as nothing more than garbled speech from one of the other characters.

There are many possibilities, too many to imagine. The most important takeaway here is that no matter how unlikely Luigi's safe intra-universe migration may be, it is possible. With some external help from the host system, it would even be straightforward: perhaps no more than a few days work from a skilled programmer.

In real-world programs sharing adjacent address spaces, it's improbable (but possible!) that migrating data from one process to another in a randomly chosen destination spot would have semantically meaningful results in the destination address space.

To put it in simpler terms: under just the right circumstances, Luigi could teleport to the other side, and wind up in a different world.

Ghosts in the machine

An embedded system is a little environment. My Betta in the previous installment of this little series lived in a very simple embedded system. Its most obvious difference from my own environment is that the tank was filled with water, while my room was filled with air. The differences from the host system can yield different behavior and different rules. In the fish tank, the rules are only a little different — for example, most things are more buoyant inside the tank. In a virtual embedded system, the rules and behavior might be completely different from those of the host system. It all depends on how the embedded system was designed to work.

Every embedded system has a containing surface, which might be called its frontier. The frontier is one-sided in the sense that the rules of the embedded system may simply stop at the boundary: there is no "other side". In some embedded systems (such as a Euclidean space embedded in a non-Euclidean space), even the supposedly intuitive notion of extending a line across the boundary only has meaning on one side, the "inside" of the frontier.

If there is a formal mathematical term for this One-Sided Frontier idea, I've yet to come across it, and I've spent quite some time looking. If you have any suggestions, let me know. The closest I could find are the spaces that are undefined in noncontinuous functions, such as the Tangent function for a value of 90 or 270 degrees. If you ask a question f(x) at these values of x, the answer is something like "You can't go that way."

So the other side of the frontier is undefined. This statement has a deep, almost philosophical meaning to programmers. It does not mean "nothing"; no, no no! It means anything. It is a modern-day Wand of Wonder, a Bag of Tricks, a Horn of Plenty, a Box of Chocolates. You never know what you're going to get.

If a computer program's code inadvertently reaches into undefined, then it has stepped across a mystical wall into another universe, and anything could happen. It's as if Gremlins have taken over the machine. Your PC speaker might beep erratically or continuously. Your video array might burst into random fireworks. Your printer might fire up and print out mysterious symbols. Your program may even continue to operate normally, but with the addition of unexplainable and unrepeatable phenomena.

I have seen all these things happen. All C/C++/assembly programmers have seen bugs like this — program bugs with "crazy" behavior. The bugs are so spooky, and so hard to track down, that computers are now designed to be gatekeepers at the Wall, and when you try to step across they say STOP! It's much better to be blocked immediately than to let your program wander into undefined, where ghosts may take hold of your data in ways that may even cause your legal department to take notice. Stranger things have happened, as they say.

This computerized gatekeeping is commonly called "protected mode". The computer checks every addressing instruction, and any time a program tries to access the memory area outside its own, things halt immediately. When you see the message "segmentation fault", or a blue screen of death, or some other sign that a fatal, unrecoverable program error has occurred, it is almost always because someone or something in the embedded system tried to escape.

Holes in the Wall

From the perspective of a computer game, the system frontier is relatively uninteresting. It's not much different from any other obstacle.

However, in other embedded systems these frontiers are almost mystical in nature. They provide endless fascination for computer scientists working in the domain of programming languages, which are yet another kind of embedded system.

To see how it works, let's consider the situation in Mario Kart, which is simpler.

In Mario Kart, most of the racers are computerized opponents, or AIs. A few of them, usually at least one, are controlled by people, using steering wheels or other physical controllers. Sometimes (e.g. in simulation mode) all the opponents may be computerized.

In order for people to interact with the embedded system, there must be some way to send information back and forth across the system frontier.

Coming from the Mario Kart side, we typically have video and sound signals. The embedded system generates these signals and sends them to your TV or device.

Coming from the people side, we typically have motion input: which way to move the Karts. The signals begin as your physical motions: buttons you press, or in newer controllers, the direction you tilt the controller. They are sent from the host system to the embedded system and they generally produce observable effects in the embedded system. Like magic!

Mario Kart is especially interesting because the external camera is physically present within the game. You can see it in the instant replays of your races: a little guy with a camera, floating behind you on a little cloud. The game designers have arranged things so that you can almost never see him while racing, because he's always flying behind your head, along your line of sight.

But he's there. And in fact that camera is always there, in all video games. It's just that the Mario Kart designers have chosen to reify him as a cute little turtle guy with a camera, floating behind you on a cloud.

The external camera is a one-way hole in our one-way wall: it sends data out of the embedded system. For all intents and purposes it also sends the sound data, since the sounds are usually scaled as a function of distance from the camera.

During a race, there's a lot of stuff going on in the embedded system, and there's a lot of stuff going on in the host system. But they constrain their communication via mostly-invisible channels, and these channels are restricted in the kinds of communication they may convey. Your controller can send motion inputs, but (at least today) it can't send video data. And (at least today) the characters in the game can't control your arms and legs, the way you can control theirs.

Hopefully now you should have a mental picture of this magical wall between an embedded system and the Great Undefined Beyond on the "other side" of its system frontier. The wall may have deliberate holes in it: channels, really. Information may flow across these channels in predefined ways. And the channels are almost always invisible to occupants of the embedded system.

Reflections

I've spent a lot of effort telling you about a rather strange, twisty kind of surface: the frontier of an embedded system. This frontier exists for all embedded systems. It may have "holes" (data channels) in it. The number and nature of these channels is entirely up to the designers of the embedded system. Programmers sometimes call these channels "reflection" or "metaprogramming".

The holes in the frontier may or may not be detectable within the embedded system itself. They may only be detectable within the host system. This, again, is up to the designers. For most of the embedded systems I know of, the channels are "well defined", in the form of application programming interfaces offered to either the embedded system or the host system for communicating across the frontier.

But you need a channel for this kind of communication. Setting it up is usually not cheap. And setting up meta-reflection (in other words, being able to "see" the channel from within the embedded system or host system) is even more work.

So most of the time, channels through the embedded system frontier are completely invisible and undetectable from inside the embedded system. They're quite real, and information flows either one way or both ways, but they cannot be detected from within the embedded system, and their behavior is intrinsically non-repeatable via experimentation.

When data comes across these invisible channels, stuff "just happens" in the embedded system, with no clear indicator nor explanation as to why.

In our discussion so far, I have intentionally blurred the distinction between the host system (such as a fish tank or a game console device) and the host system's host system (such as your bedroom or living room). But you've probably noticed by now that all host systems are embedded in some larger system. This is just the way things work. The fish tank is in your bedroom, which is a system embedded in a house, which is a system embedded in a neighborhood, embedded in a county, a nation, a continent, a planet, a solar system, a galaxy, a universe.

It's perhaps not as clear in the case of fish tanks, but host systems often overlap and even cooperate. A city is composed of many interleaved subsystems. So is your body. It's not always a simple containment relationship. Systems are made of, and communicate with, other systems.

But one way or another, all systems are embedded systems.

There is no reason to assume that our Universe works any differently. Our Universe is a system; that much should be self-evident. It has boundaries; astronomers and astrophysicists have recently even determined that the boundary appears to be a dodecahedron.

We are already painfully aware of the question "what happened before the Big Bang, if in fact the Big Bang occurred in the way all the evidence suggests", and its inherent nonsensicality. What happened before the beginning of Time? What lies beyond the end of the Universe?

Programmers already know intuitively the answer to these questions. The answer is: undefined is there. Undefined is not the same as "nothing", no indeed. It's anything. And we can't go that way.

This has ramifications for the way we think about things today.

I believe I will have more to say about this soon. Right now I think I will go play Mario Kart: a game as fun as any I think I've ever played.

Fable II: Arguably Better than Getting Your Head Crapped On

I finished Fallout 3 maybe six or eight weeks ago, and it was hands-down one of the best games I've ever played. A game like that gets you in the mood for more gaming, so I thought to myself: "Hey, I should plop down $160 for Fable II!"

Actually that's not exactly what I thought, but it's what happened. I bought the game for $60, fired it up, got up to the part in the intro where a bird craps on your head (yes, this is how it starts), and it locked up hard. Reset the XBox, tried again, and this time got as far as some guy selling snake oil gadgets before it locked up again. Snake oil, indeed.

I tried playing for about an hour, with the game crashing every 3 to 5 minutes, and I finally went online to read about how it kills XBoxes and it's the Game of Death and blah blah blah, all interesting but not especially helpful. Eventually I stumbled across discussions of the "install to hard drive" option. Nobody actually said how to do it, so it took another hour of digging to deduce that you need to purchase a $100 wireless network adapter (or 100 feet of network cable, I guess). So I shut it down for the night, waited for the stores to open, forked over the $100, and installed the game to the hard drive. To Lionhead's credit the game never crashed again, making it significantly more stable than Oblivion or Fallout 3.

I tried hard to like Fable 2. I didn't even need to like it $160. I would have settled for a $60 value. I vaguely remember liking Fable 1, although I can't remember anything about the game except for one neat scene where you had to escort two NPCs through a dark valley. One of the NPCs has been bitten by a Balverine (a werewolf), and the two argue the whole trip about whether he's going to turn. It's a funny conversation and the scene has a funny ending. Other than that, I just have vague recollections of shooting birds on the roof of some guild, and needing to get a 6-foot handlebar moustache for some side quest. The rest of it is basically a blank. But I had set some flag to the effect that "I liked it," and I wanted to like the sequel too.

Unfortunately, with a few noteworthy exceptions that I'll call out in the "Highlights" below, the game is entirely forgettable. It's already fading from memory as we speak. It wasn't as bad as some people make it out to be. It's playable for a couple of days, and it has its fun moments. But it's not a very good game, and it's definitely not a very memorable game. This is sad, considering the amount of effort that went into its development.

The no-spoiler synopsis of Fable 2 is that it's a bad Zelda clone. You can smell the desperation; there are dozens and dozens of direct rip-offs from the Zelda franchise. Heck, I wouldn't have minded a half-decent Zelda clone; they're some of the best games of all time. But Fable 2 misses the mark by a mile. The humor is juvenile bordering on imbecilic, the hints are hamfisted, the areas are small and cramped, the minigames are lackluster, the music is virtually nonexistent, and the story pacing is rushed and breathless. It's a cargo-cult copy of Zelda that winds up having no identifiable soul: forgettable across the board.

I've given up every piece of Microsoft software and hardware I own except for the XBox, which I had been holding onto just for Fable 2. Now that it's come and gone like a bird crapping on my head, I'm giving up. No more XBox or PC games for me. Ever.

Hence, Fable 2 cost me $160. I hope you got it for cheaper than that.

Anyway, here's a quick rundown of the lowlights and highlights of the game, as I see them. Enjoy!

Lowlights

1) Humor. Fable 2 tries hard to incorporate humor into the game — too hard. The writers use the trusty old "stopped clock" approach to humor, in which they inundate you with jokes, and 1 out of every 43,200 of them is funny. Amazingly, this perseverance leads to 3 or 4 genuinely funny ones, mostly near the entrance to the Crucible (arena). But by the time you get there, you've already tuned out all attempts at humor and have probably even tried killing yourself a few times. So they may fail to register.

2) Theresa. The game features an old lady who watches everything you do and talks at you constantly. This starts in the very beginning of the game and lasts until the very end, with no option to turn her off. Your character can't so much as take a crap without Theresa piping in with helpful advice on which hand to use. "That is ancient paper. Be cautious." She uses some magical form of communication system that only breaks down in the fog — probably shortwave radio — and there's no way to turn the fugging thing off.

I really hated Theresa.

3) Expressions. You can't talk to people. Instead, the game gives you a series of increasingly repugnant forms of nonverbal communication. Initially you're limited to belching, farting, giving people the finger and making lewd pelvic thrusting motions, but as you rise in fame Theresa informs you that you've earned the right to use the "kiss my ass" expression. I am not making this up. I tried to avoid using expressions altogether, but the game forces you to do it once in a while. Made me want to take a shower.

4) Retinal blindness. Fable 2 is nauseatingly saturated. They just don't know how to lay off the paint gun. There are a few OK-ish-ly tasteful areas, such as the big trees in Bower Lake, but most of the game is a frightully garish mix of lime greens, oranges, purples, reds, blues, and general oil-spill iridescence. It makes you color-blind fast, even if you didn't start that way. Finding anything onscreen is like trying to spot where someone threw up on a Matisse.

5) Linearity: the game is unrelentingly linear for the first hour or two (a _long_ time), after which it settles into, well, linearity. The gameplay occasionally approaches the smashing-through-lines-of-baddies feel of Gauntlet Legends, which I liked, but mostly it makes you feel like a rat running a big maze, following a neverending golden trail of cheese.

A major contributor to the linear feel, even after the game opens up, is the plethora of tiny little fences and obstacles that you can't hop. It makes it really hard to know where you can walk, and it feels like you're constantly bumping into things, because, well, you are. So the game is linear at all resolutions: high (the plotline), medium (most of the level designs) and low (the path designs). Linearity can cramp even the best of games — Kingdom Hearts comes to mind. It's just a bad way to design things. And Fable's linearity felt especially suffocating after just having finished Fallout 3, which is immense and wide-open.

6) Controls. It's been a long time since I played a game whose controls were so accident-prone. Normally a game's controls take some getting used to, and then it's like driving a car. In Fable 2, even after days of play, I'd still be trying to hop a fence and wind up shooting the front door off a mansion, blowing boards everywhere and scaring the shit out of the villagers.

Hell, even when I was trying to buy my final sword (this was a $50k sword I'd been looking for all day), I tried to bring up the "buy sword" menu for the blacksmith, and I accidentally wound up casting a massive Inferno spell, causing him to literally run screaming across town. It was weeks of in-game time before I saw him again. God dammit. They really should have had different controls in safe zones.

7) Elephantine mammary glands. I don't know what planet these guys have been living on, but giant udders fell out of fashion at least two or three decades ago. Every single woman in Fable 2 had knockers significantly bigger than her head. It reminded me of my trip to Paris, where every statue of a woman is bare-breasted, presumably so that you can tell it's a woman — a practice which unfortunately suggests that there's really no other way to tell. Dumb French statue-making assholes.

I mean, the people in Fable 1 were ugly — the main character worst of all. They all had this "I'm a programmer who never gets outdoors" look, and I expected (and got) no better from Fable 2. But I was really disappointed that every female in the game was a fugging dairy farm. I mean, someone with some taste and maturity should have a talk with these asshats, and explain to them what women actually look like. Or they should pick up a frigging Victoria's Secret catalog or watch a goddamn Target commercial or something. Jesus.

The milk jug thing... it was really just too much. I have zero respect for those jerk-offs at Lionhead.

8) Ass-kissing. This was probably the most serious problem with the game. It was a disease in Fable 1 that went malignant in Fable 2. Whoever designed these games was apparently neglected as a child, because the gameplay revolves around gaining "renown". Lionhead's hopelessly adolescent view of "renown" is that villagers should follow you around and say things like "yay!" and "hurrah!" It's even worse than I'm making it sound.

They spent so much time coding this crap that they forgot to code pushing into the game: you can't push people out of your way. So as soon as you wander into a dead-end alley you're fucked: a bunch of people will crowd in after you asking for autographs and offering you gifts and all this sickening bullshit.

To the game's credit, and I count this as a highlight, if you pull out your six-barreled rifle, take the safety off, and aim right at their heads, it clears everyone out pretty fast. You can imagine how desperate I was by the time I tried that approach. But they coded it correctly, bless 'em.

9) Too Easy. The game just wasn't hard, period. There were no hard fights. I never died. I don't even know what happens when you die in Fable 2. I used a couple of Resurrection Phials, but only because I had become so lazy in combat that I didn't care anymore. This was a serious flaw in the game: it essentially removed the element of fear, which was the only emotion (other than disgust) that the game had a chance of evoking.

10) Demon Doors. Oh man, oh man. These were probably the low point of the whole game. They made me want to puke. I would run past them as fast as I could so I didn't have to listen to their inane drivel. This was some of the worst game writing I've ever seen. I just don't want to talk about it.

11) Misguided innovation. They really should have stuck with copying Zelda, and Kingdom Hearts, and Gauntlet: Legends, and all the other games they copied blindly, and badly. Because whenever they introduced something entirely new, it almost invariably sucked. Examples? OK. Sure. Since you asked, and all.

How about the "innovation" that when you eat nearly any food (and it only takes a few bites), you bloat up to the size of Orson Welles, and the only way to get rid of it is to eat celery. No amount of exercise will make any difference, but eating a few bites of celery makes it go away. Innovative!

Innovation: you can purchase almost any property in the game. Is this realistic? No. In reality, not everything would be for sale (and especially not posted on the front doors). Real-estate transactions wouldn't be instantaneous. You would need the owner present to buy something. Etc, etc. So given that this feature makes the game less realistic, what purpose does it serve? Is it fun? No. Buying real estate is about as fun as attending insurance seminars, so I don't know what the hell they were thinking. It could have been fun in the right setting, with suitable other human participants, in a Parker-Bros. Monopoly kind of way. Maybe. But slapping it on the side of an RPG and calling it innovation? It boggles the mind.

And what about the the busywork jobs (blacksmith, woodcutter, bartender) for making gold? Um, dudes -- busywork jobs only exist in MMORPGs to limit per-player CPU usage. They're not fun. "Innovatively" bringing them into a single-player game was just flat-out brain damaged.

12) Nonexistent target audience. What age group is the target market for this game? If you enumerate the possibilities, you arrive at the inescapable conclusion that the game was either (a) created by imbeciles, or it was (b) created for imbeciles, or possibly (c) all of the above.

It's presumably not intended for kids, or you wouldn't be finding condoms in treasure chests, soliciting and obtaining sex from male and female prostitutes of all shapes and sizes, performing pelvic thrusts to solve quests, and so on.

It's not for adults either, or you wouldn't be bombarded with the constant barrage of scatological humor, beginning with the bird shitting on your head, continuing with warnings about "extending the fart command and messing it up", and going pretty much straight downhill from there.

Is it intended for teenagers, then? Poooossibly, but (a) that ignores their primary demographic, which is 30-year-olds, and (b) I don't know any teenagers that are that stupid, nor so hard-up for attention that they need AI villagers to yell "hurray!" whenever you pass them, even if you're in a graveyard at midnight.

Dipshits. This game was designed by dipshits. The coding was great, the artwork was great, the sound effects were great; the details were for the most part rock-solid. But the creative direction was just inexcusably bad.

Highlights

OK, I've been pretty tough on the game so far. Fable 2 did actually have a few genuine highlights worth calling out. You could even argue that these highlights make the game almost worth playing, in spite of all the crap you have to suffer through in order to get to them.

1) Banshees. Fable 2's banshees are, in a word, awesome. I've been racking my brain trying to think of a VG monster as cool as these banshees in any game I've ever played. I'm coming up with a few ties, but nothing that beats them. The YouTube videos don't come close to doing them justice. Fable II is worth playing just to get to Wraithmarsh.

The only real problem with the banshees is that since none of the combat is challenging (see Lowlight #9), they're nowhere near as scary as they could have been. But they're amazingly stylish. I'd call them an innovation, but I'm inclined to believe Lionhead stole their basic design from some other game, given all the other copying they've done. (The Fable 2 Trolls, for instance, are about as Zelda-clone-esque as you can get without inviting a lawsuit.)

2) Lucien's speech, where he addresses the recruits. Really great speech. Riveting and convincing. Amazing how Microsoft-run studios that are so consistently bad at humor are so good at creating convincingly evil speeches about taking over the world.

Actually the whole centerpiece drama in the tower was very nicely done. I have to give them credit for that part of the game: it was exceptional by any standard. It basically saved the game from being a total loss.

3) Hammer. She's cool. Great voice acting, surprisingly good scripting, neat character, lots of depth. One of the better-realized VG supporting characters I've seen in many years.

4) The dog. Apparently there was a lot of hype about the dog. Or so I hear, after actually having played the game. Whatever the hype, the reality is that it's a very believable dog. I especially liked how it would run ahead of you -- I've seen pets that follow you, but the dog would often anticipate your direction and run ahead, kinda turned back towards you like "c'mon! let's go!" I encountered no glitches with the dog; the coding was rock solid. Overall it was, well, very... doggy. And what more could you ask for in a dog, really?

As a tribute to the believability of the dog, I'll offer a minor spoiler. (Skip ahead if you don't want a spoiler!) At the end of the main storyline, you are granted one wish. Your choices are: (a) get all the people who died back, (b) get your dog back, or (c) get a bunch of money. What I really wanted was a sort of amalgam of the 3 choices: I wanted my money back for this dog of a game. But when push came to shove, I picked the dog. I kinda missed him.

5) Architecture. Overall the architecture was really nice. The only somewhat dubious exception was Bowerstone, which looks almost exactly like Euro Disney. I kept expecting Tigger to come waltzing around, cursing in French under his breath, just like he did on my real-life trip to Euro Disney a few years back.

Other than the Euro Disney influence, which I could take or leave, I thought the architecture was nice throughout the game. I liked the waterfront town of Bloodstone. I liked the manors in Oakfield. I liked the gypsy wagons. I liked the vendor carts. I loved pretty much every creepy structure in Wraithmarsh. The overall look of the game was beautiful, once you got past the color-saturation problem, and the architecture was a huge contributor.

6) Fight music. Unlike in Fable 1, most of the music in Fable 2 is forgettable background/atmosphere music. They didn't get Danny Elfman this time around, and it shows. The theme for Bower Lake is nice as far as it goes, which is exactly 2 chords over and over and over. But it's still OK. The rest of the music didn't leave any sort of impression on me at all, except for the fight music, which almost made up for everything. It was very good. There were at least two fight themes and both of them were cool. If only the rest of the music had been... present. It was like it wasn't even there. It phoned in its performance.

Folks at Dorkhead studios: Zelda's music is one of the top five reasons for its success as a franchise. Same goes for Mario and Kingdom Hearts and Final Fantasy. Their music is always great, and it's always in your face. The music isn't muttering or mumbling; it's shouting. And they can get away with it because it's always great. Even when it's bad or annoying, which is rare, the music still anchors each place and event in the game in your memory, in a way that only music can. You guys really screwed the pooch on this one.

7) Mixed-tactic fighting. They did a great job of setting things up so that you could use melee, ranged weapons and magic effectively in combat. It was refreshing to be able to switch styles in mid-fight: you could use your sword to kill everything near you, then start blasting everything ten feet or more distant with your rifle. Or you could clear a little space and cast a time-slowing spell, and then just start zinging around whaling on bad guys. The combat was never hard, but it was on the whole fairly satisfying.

The downside of ultra-convenient access to melee, range weapons and spells was that you could effortlessly use them all simultaneously while trying to buy vegetables from a produce stall in the main market. I really wish they'd made it just a teeny bit harder to cast spells in public areas.

8) Well, damn. I can't think of a Highlight #8. I thought of some more lowlights, though: long area loads, unresponsive controls during "scenes", only a handful of available spells, months of coding/design effort wasted on useless features like "groin shots" and tatoos...

Oh, and the lack of control over when quest scenes actually unfold — they trigger from proximity to the relevant NPC rather than interacting with the NPC because, oh, that's right, you can't interact with anyone except to fart on them or give them the finger. Oops! So you're always accidentally wandering into a dungeon that triggers some quest, and there's no way out except to back entirely out of that phase of the quest, which may involve losing hours of your time, all because you walked through the wrong door. Damn that pissed me off.

And how the hell do you sleep in an Inn? I never managed to figure it out. I'd wind up spending $10k for some hovel just to get a frigging bed to sleep in. It was amazingly bad UI design, if there even is a way to do it. If not, then their helpful tutorial message lied to me at least a dozen times.

Argh. Well, this highlights section is going downhill in a hurry, so I think I'll end it here.

Better than a crap on the head?

Maybe, maybe. But compared to Fallout 3, Fable 2 pretty much sucked. It had a couple of nice features, but they were drowned in an ocean of painfully adolescent design. Such a shame.

I've tried to be fair here. I don't mean to discourage you from playing the game, since for all I know there's nothing better out there right now.

If you do decide to play it, I hope I've set your expectations very low. That way, well, who knows? You might actually have some fun with it.

But if you open even one of those Demon Doors I'll lose all respect for you.

Selamat Natal 2008 & Selamat Tahun Baru 2009
KelahiranNya memberi semangat baru untuk terus berkarya memberikan yang terbaik ...

POS UN dan PERMEN UN 2009

5 hari yang lalu Puspendik merilis POS UN ( Prosedur Operasi Standar Ujian Nasional ) 2009 dan PERMEN ( Peratutan Mentri ) UN 2009 bisa di download disini , berikut beberapa bagian isi dari POS UN itu :1. Pelaksanaan Ujian Nasionala. Senin ( 20/4/09 ) :- Bahasa Indonesia : 50 soal- Biologi (IPA), Sosiologi (IPS), Sejarah Budaya/Antropologi (Bahasa), Ilmu Kalam (Agama) : 40 soalb. Selasa ( 21/4/09

Google Insights

Mungkin anda sudah tahu bahwa salah satu layanan mbah google yang bernama Google Insights for search, ya sebuah layanan dimana mbah google memberikan data tentang "kata kunci" apa yang sering digunakan oleh para pengguna internet ketika browsing menggunakan google. Gambar di atas adalah hasil yang didapat ketika saya menggunakan kata matematika sebagai search term nya ( Untuk wilayah Indonesia

Estimation of Angles

Play 'n' Learn

Teaching and learning of mathematics is fun. While teaching my daughter about angles , I used an e tool which is basically a game of start and stop of a stop watch kind of a thing. This tool is available here. Here is a screenshot of estimating 45 degrees. It is much closer to accurate result, so the score is 10 points. Try this!

Pembahasan Peluang

Meskipun jumlah soal yang hadir di Ujian Nasional pada materi peluang relatif sedikit ( biasanya hanya satu soal ) bukan berarti kita tidak memberikan perhatian yang cukup untuk materi ini. Justru biasanya pada materi soal - soal Ujian Nasional yang jumlah soalnya relatif sedikit tingkat kesulitan soalnya lebih rendah daripada materi yang memiliki soal dalam jumlah banyak ( 2 atau 3 soal ).Materi

Errors in Mathematics

Students of Grade 8 committed following mistakes at the time of examination.

1. Cancellation of numerator and denominator terms

2. Solving exponents

3. Numerical transformations ...70 is not equal to square of 35

4. Importance of putting brackets

Making a 5x5 Magic Square

Children love Magic Square making activity. Numbers fascinate all of us. Look the following picture and learn how to make a magic square of order 5x5. This is top right approach of making a magic square. Follow the direction of arrows from 1 to 25. The challenge is that by watching this path try to make Magic Squares of other odd orders.

Catatan Matematika, Pentingkah?

Seringkali ada anggapan bahwa catatan pelajaran matematika itu tidak penting. Argumentasi yang sering dikemukakan adalah bahwa semua yang dijelaskan guru sudah ada di dalam buku pelajaran. Namun yang harus diingat, kadang guru menggunakan banyak sumber referensi dan apa yang dijelaskan kadang tidak ada di dalam buku teks kita. Alasan lain kenapa perlu membuat catatan adalah dengan menulis kembali apa yang kita pelajari, kita akan jadi lebih paham dibanding jika hanya sekedar membaca atau mendengarkan penjelasan guru. Ketika mencatat, berarti kita secara tidak langsung mengulangi kembali apa yang sudah dijelaskan oleh guru atau apa yang sudah kita baca.
Catatan pelajaran pada dasarnya digunakan untuk membantu mengingat kembali apa yang sudah pernah dipelajari. Mengingat kapasitas otak dan daya ingat kita terbatas, catatan akan sangat berguna untuk memudahkan kita dalam belajar di masa mendatang.
Tentu tidak semua yang diucapkan guru di kelas, atau apa yang kita baca di dalam buku teks pelajaran, kita tulis atau salin begitu saja dalam buku catatan kita. Berikut ini adalah beberapa tips untuk membuat catatan matematika di kelas.
1. Catatlah point-point penting yang dituliskan guru di papan tulis. Jangan membuang-buang waktu dengan menuliskan apa yang sudah ada dalam buku teks pelajaran. Karena tentu saja kita seharusnya telah membaca buku teks tersebut secara cermat sebelum pelajaran untuk mengetahui apa yang ada di dalam buku itu.
2. Catatlah penjelasan guru. Yakinkan bahwa kita sudah menuliskan penjelasan yang disampaikan guru di buku catatan kita. Seringkali guru tidak memberikan catatan ketika menjelaskan suatu konsep atau suatu soal tertentu, sehingga kita harus mencatat sendiri penjelasan guru tersebut. Catatan itu akan dapat membantu menjelaskan kepada kita bagaimana mengerjakan suatu jenis soal tertentu atau membantu menjelaskan kepada kita mengapa guru memilih menggunakan suatu rumus atau suatu metode tertentu, bukan rumus atau metode yang lain untuk menyelesaikan soal yang diberikan.

3. Catatlah contoh-contoh soal dan langkah-langkah penyelesaiannya yang diberikan oleh guru di kelas. Kemudian tulislah penjelasan tambahan untuk masing-masing langkah tersebut dengan menggunakan bahasa/kata-kata sendiri sehingga kita sungguh paham dan tahu apa yang mesti dikerjakan dalam menyelesaikan soal-soal tersebut.
Sebagai contoh misalnya bagaimana menyelesaikan persamaan kuadrat dengan cara memfaktorkan.


Bersambung...

Measurements in Math

Learning about measurements is an integral part of learning math concepts. Be it about measuring length , mass or time, all play a significant role in mathematics.

I stumbled upon this interesting website on learning measurements when I was exploring some readymade e resources for teaching my daughter.

Here is its screenshot

menu via kwout

Mengedepankan Keterlibatan Siswa Dalam Proses Pembelajaran Matematika

Mengedepankan Keterlibatan Siswa Dalam Proses Pembelajaran Matematika
Oleh: HJ Sriyanto

Menarik, apa yang terjadi di kelas matematika saya beberapa waktu yang lalu. Ketika mengawali materi pelajaran, saya meminta siswa untuk membuat tiga buah kalimat yang terkait dengan materi tersebut. Para siswa yang semuanya laki-laki dan dikenal memiliki kreatifitas yang cukup tinggi itu sempat terbengong. Untuk beberapa saat mereka seolah tidak percaya dengan apa yang akan dilakukan. Baru setelah saya meyakinkan beberapa kali mereka mulai bersemangat mengerjakannya, sambil masih menyisakan senyum di bibirnya. Mungkin mereka belum cukup yakin.

Membuat kalimat adalah salah satu cara untuk memfasilitasi proses berpikir. Ketika seseorang membuat kalimat dengan menggunakan istilah tertentu, maka disana ada proses untuk berpikir. Orang akan berpikir terlebih dulu, berusaha memahami arti atau makna istilah tersebut, baru kemudian bisa menyatakannya dalam satu rangkaian kalimat. Dari proses tersebut akan dapat diketahui sejauh mana pemahaman siswa terhadap istilah itu. Inilah titik awal siswa memahami konsep yang akan dibahas dalam proses pembelajaran selanjutnya.

Setelah semua siswa selesai membuat kalimat mereka memilih satu kalimat yang dianggap menarik dan membacakannya untuk forum kelas. Seperti sudah saya duga, ada banyak ragam kalimat menarik. Dan masing-masing siswa berusaha membuat kalimat yang berbeda dari temannya. Kelaspun menjadi lebih hidup, sengaja saya membiarkan komentar dari siswa lain ketika satu siswa selesai membacakan kalimatnya. Kesempatan itu sekaligus menjadi ruang bagi siswa untuk mengekspresikan diri; ide, gagasan dan kreatifitasnya. Dari kalimat-kalimat itu tampak bagaimana karakter masing-masing pribadi siswa, interestnya dan juga latar belakangnya. Selain itu, tanpa disadari mereka telah mengumpulkan banyak informasi tentang materi yang akan dibahas. Peristiwa itu juga menjadikan materi pelajaran lebih dekat dengan realitas kehidupan mereka sehari-hari. Bahwa apa yang dipelajari sebenarnya terkait dengan kehidupan nyata, bahkan mungkin pernah dialaminya sendiri.

Proses pendidikan seharusnya menjadi media bagi siswa untuk mengembangkan ide, gagasan dan kreativitasnya. Selayaknya pendidikan memberi ruang seluas-luasnya bagi pengembangan daya imajinasi dan daya kreativitas peserta didik. Mengembalikan ruang kreativitas siswa untuk berpikir, menggali potensi dan terbuka terhadap pemikiran-pemikiran baru. Namun acapkali yang terjadi adalah sebaliknya, proses pendidikan di sekolah seringkali malah memenjarakan ide, gagasan, imajinasi dan kreativitas peserta didik. Tanpa disadari sistem persekolahan kerapkali mengerdilkan dan memiskinkan daya kreatif dan daya imajinasi peserta didik. Anak-anak yang dahulunya penuh ide kreatif ketika memasuki bangku persekolahan kehilangan imajinasi dan kreatifitasnya, berubah menjadi anak-anak yang “penurut” dan “penakut”. Takut untuk menyatakan pendapat, ide atau gagasannya dan tidak kreatif, melakukan sesuatu hanya apabila ada perintah atau petunjuk dari guru. Sistem persekolahan dengan kurikulumnya yang begitu padat, lebih berorientasi pada hasil daripada mengedepankan proses, metode pembelajaran yang monoton dan tidak inspiratif telah menjauhkan peserta didik dari kemandirian berpikir dan sikap kritis. Mendorong anak-anak tumbuh dalam sikap kepatuhan tanpa kesanggupan menyatakan diri secara penuh dan utuh.



Proses pendidikan bukanlah proses mengisi botol kosong, dimana siswa dianggap sebagai botol kosong yang harus diisi tanpa memiliki kemampuan dan kesanggupan untuk mencari, mengolah dan menemukan makna dari proses pendidikan yang dijalaninya. Sementara guru sebagai yang serba tahu, empunya ilmu pengetahuan dan merasa “bertanggungjawab” untuk mengisi siswa dengan berbagai kecakapan. Peserta didik bukanlah bejana kosong, tapi merupakan pribadi yang hidup yang memiliki rasa, karsa dan daya cipta. Tugas guru adalah mendampingi dan mendorong mereka mencapai kepenuhan diri, membantu mengembangkan seluruh sisi kemanusiaannya tumbuh secara seimbang dan optimal.

Proses pendidikan di sekolah yang termanifestasikan dalam proses pembelajaran dikelas seringkali banyak didominasi oleh guru. Selama ini proses pembelajaran di kelas cenderung berpusat pada guru dan bersifat monologis. Proses pembelajaran demikian akan membentangkan tembok yang membatasi interaksi antara guru dan peserta didik. Ada jarak terbentang yang memisahkan guru dan siswa. Pola interaksi demikian memposisikan guru sebagai “penguasa” yang memiliki hegemoni dan dominasi sepihak dalam menafsir makna materi pembelajaran yang kebenarannya tanpa terbantahkan oleh siswa yang manapun. Pada titik inilah terjadi relasi yang timpang antara guru dan siswa.
Perlu kiranya untuk mengedepankan proses pembelajaran yang dialogis dan berpusat pada siswa. Mendorong proses pembelajaran yang memberikan ruang lebih banyak bagi partisipasi dan keterlibatan aktif peserta didik. Pembelajaran yang parsipatoris dan dialogis mengandaikan terjadinya interaksi aktif antara guru dan siswa dalam sebuah relasi yang egaliter. Bahwa proses pembelajaran menjadi peristiwa belajar yang dialami bersama-sama oleh guru dan siswa. Dan sejauh ini pengalaman menunjukkan bahwa kedekatan relasi guru-siswa sangat mendukung keberlangsungan proses pembelajaran yang efektif.

Dalam proses pembelajaran yang partisipatoris dan dialogis, proses pembelajaran bukan sekedar proses memorasi dan recall ataupun penguasaan pengetahuan semata. Bahwa proses pembelajaran tidak hanya sebatas mengolah ranah kognitif, competence belaka. Namun Consience dan compassion juga mendapatkan perhatian. Disana tersirat adanya proses internalisasi, proses untuk menerima, menghayati nilai dari sesuatu yang berada diluar dirinya menjadi bagian dari dirinya. Sesuatu yang sebelumnya merupakan pengetahuan dari luar yang disampaikan sebagai pengetahuan kognitif dalam internalisasi diproses untuk menjadi bagian yang menyatu dalam dirinya, sebagai acuan yang bernilai dan bermakna bagi kehidupannya. Dengan demikian proses pendidikan akan sungguh mampu mengembangkan seluruh sisi kemanusiaan peserta didik secara penuh dan utuh.@

Matematika SMP

Kalau sebagian dari anda ada yang membutuhkan baik soal maupun teori tentang materi pelajaran matematika tingkat SMP, mungkin blog yang satu ini bisa memenuhi keinginan anda. Beberapa entri yang telah diterbitkan di blog tersebut antara lain :1. Materi Peluang dan soal latihannya2. Kumpulan soal kesebangunan3. Juga soal soal - soal tentang himpunan, aljabar, dll.kalau anda membutuhkan informasi

Alat peraga Matematika

Kamarudin, Penemu Alat Peraga Matematika

Sumber: Kompas, Sabtu 17 Desember 2005

Pelajaran Ilmu Pengetahuan Alam dan Matematika kerap kali menjadi momok menakutkan bagi para siswa. Namun, Kamarudin mampu menjadikan siswa senang, malah dengan santai, mempelajarinya, khususnya murid kelas rendah: kelas I, II, dan III sekolah dasar.

Caranya, Kepala Sekolah Dasar Nomor 1 Kenawa, Desa Kenawa, Lombok Tengah, Nusa Tenggara Barat, ini membuat alat peraga yang disebutnya Blok/Petak Bilangan. Saya mencoba membuat alat peraga ini dengan mengombinasikan antara belajar dan bermain, tutur Kamarudin (45), ayah dari enam anak hasil pernikahannya dengan Hayatun itu.

Alat peraga itu amat sederhana. Papan tripleks dilubangi sedemikian rupa berbentuk persegi. Kemudian ada sejumlah potongan papan seukuran panjang dan lebar bidang papan yang dilubangi tadi yang bergambar pohon, buah, ikan, kelereng, bola, wayang, dan lainnya di satu sisinya dan angka-angka di sisi lainnya.

Papan ukuran kecil itu ada yang diberi engsel atau isolasi biar bisa dilipat sehingga gambar pohon, buah dan angka, dan lainnya sebagai unsur untuk menambah-mengurangi bisa langsung ditunjukkan kepada siswa.

Bolongan-bolongan tersebut dimaksudkan agar potongan papan bergambar itu bisa dikeluar-masukkan pada lubang bidang papan tersebut. Di bagian paling atas bidang papan terdapat lubang yang ukuran sama untuk wadah hasil akhir (jumlah) dari menambah dan mengurangi bilangan. Sedangkan gambar-gambar dan angka-angka masing-masing pada bagian kiri dan kanan bidang papan.

Dengan alat peraga ini, siswa kelas I, II, dan III SD, bahkan murid taman kanan-kanak, akan lebih mudah mengenal huruf, angka, dan bercerita. Siswa pun bisa belajar menulis karena di atas papan bergambar itu dilengkapi kertas maupun plastik transparan, tinggal mengikuti bentuk-bentuk huruf dan angka.

Cara ini mengganti metode menulis di udara, atau siswa diajak membayangkan angka dan huruf dalam udara, yang sebelumnya diajarkan kepada siswa. Alat peraga ini juga tidak menimbulkan ketakutan siswa untuk belajar Matematika karena mereka serasa diajak bermain.

Ketakutan terhadap mata pelajaran Matematika lebih disebabkan kurangnya peran guru dalam memahami kemudian mengembangkan konsep dasar pelajaran berhitung. Misalnya, 2 x (kali) 2 = 4, oleh guru dinyatakan dalam bentuk hafalan. Mestinya, hasil itu dijabarkan prosesnya sehingga siswa mengerti perolehan angka empat dari perkalian tadi.

Ikut lomba

Ide membuat alat peraga itu didasari pengalaman mengajar di berbagai SD. Dia melihat kondisi memprihatinkan para siswa kelas V-VI yang tidak paham menambah dan mengurangi, apalagi membagi dan mengalikan angka-angka. Kamarudin berpikir keras untuk mengatasi persoalan itu. Kebetulan saat itu, tahun 1980-an, dia diutus mengikuti penataran alat peraga di Balai Pelatihan Guru Mataram. Dari sekitar 90 peserta (guru), dengan karya Blok/Petak Bilangan, ia dinyatakan lulusan terbaik.

Pada tahun yang sama, Kamarudin ikut lomba alat peraga tingkat nasional di Cipayung, Bogor. Saya pilih ikut lomba peraga Matematika mengingat banyak guru IPA di NTB mahir membuat alat peraga, tuturnya. Dalam tempo dua minggu sebelum lomba dimulai, Kamarudin mengumpulkan bahan-bahan dan deskripsi alat peraga. Sebelumnya, nyalinya sempat kecut mengingat alat peraga yang dirancang peserta sejumlah provinsi sangat baik.

Namun, Kamarudin dengan percaya diri mempresentasikan alat peraga di hadapan tim penguji Balitbang Departemen Pendidikan Nasional. Rupanya karya cipta Kamarudin menarik perhatian tim penguji sebab waktu untuk presentasi dibatasi 30 menit, dan saat dia diuji waktu diulurkan menjadi 45 menit, bahkan tim penguji memuji karyanya.

Rupanya pujian dan bonus waktu tadi sebuah pertanda awal sebuah keberhasilan. Alat peraga bikinannya, yang dirasakan nyaris tidak menimbulkan kekaguman kalangan peserta, justru menduduki urutan terbaik. Setelah itu, alat peraganya diuji di sebuah SD di Cipayung, dengan hasil tidak beda jauh saat proses uji pada siswa kelas rendah di Kecamatan Kopang, yaitu dengan tingkat keberhasilan 75-95 persen masing-masing untuk siswa SD pedesaan dan perkotaan.

Sayang alat peraga itu, yang kalau dibuat lengkap memerlukan biaya Rp 500.000 satu set, belum bisa diproduksi massal karena gaji guru golongan IIID ini hanya cukup untuk menyambung hidup. Pernah memang dua perusahaan di Jakarta bersedia memproduksinya, bahkan diperkuat penandatanganan nota kesepahaman (memorandum of understanding) segala. Namun, kontrak kerja itu tak pernah terwujudkan sampai kini.

Dengan alat peraga itu, hanya satu keinginan Kamarudin, Yang penting siswa kelas I, II, dan III lebih mudah belajar membaca, menulis, dan berhitung. Itu saja.

Soal Minggu Ini 01122008

Setiap hari Pak Joyo bekerja naik sepeda. Ia berangkat dari rumah pukul 06.00 dan sampai di tempat kerjanya pukul 07.20. Apabila ia berjalan kaki, maka kecepatannya 7km/jam kurangnya dari jika ia bersepeda. Pada suatu hari Pak Joyo pulang dari bekerja naik sepeda dengan kecepatan 3km/jam kurangnya dari biasanya. Setelah menempuh jarak 12 km, sepedanya rusak, terpaksa ia harus menuntun sepedanya sampai di rumah, setelah menempuh perjalanan selama 2 jam. Berapakah jarak rumah Pak Joyo ke tempat kerjanya?

Selamat Mencoba...

What have you prepared for the National Examination in 2009 ?

MySpace Countdowns

Tips Bertanya di Kelas

Tips Bertanya di Kelas PMRI

Oleh: Dian Armanto


Di dalam kelas guru adalah instrumen pembelajaran yang utama, bukan sebagai pengantar materi semata ataupun penyaji utama pelajaran, melainkan sebagai fasilitator terjadinya aktivitas belajar di kelas. Sebagai fasilitator yang baik guru diharapkan memiliki keterampilan dasar mengajar (kompetensi) minimal seperti membuka dan menutup pelajaran, bertanya, memberi penguatan, mengadakan variasi pembelajaran, menjelaskan, membimbing diskusi, mengelola kelas, dan mengajar kelompok kecil. Keterampilan dasar ini merupakan keterampilan generik dan komplek yang harus dikuasai untuk menjadi guru dan perlu diintegrasikan ketika mengajar di kelas.

Tulisan ini mencoba memberikan beberapa tips untuk diujicoba guru di dalam kelas. Diharapkan contoh ini dapat membantu meningkatkan aktivitas belajar siswa di kelas. Selain itu juga diharapkan adanya peningkatan motivasi dan minat belajar siswa. Guru juga terbantu untuk menambah wawasan belajar dan pembelajaran di dalam kelas. Tips ini disarikan dari Workshop PMRI di beberapa kota yaitu Bandung, Surabaya, dan Yogya.



TIPS BERTANYA DI KELAS PMRI

* BERTANYA UNTUK MEMINTA PENJELASAN
Contoh:
Harap jelaskan jawabanmu.
Mengapa begitu?


* BERTANYA UNTUK MENCARI KLARIFIKASI
Contoh:
Siapa yang punya pertanyaan untuk Budi? Bagaimanakah pendapatmu tentang alasan Sugi?


* SAMPAIKAN PERTANYAAN KEPADA SEMUA ORANG
Contoh:
Siapa yang dapat menjawab pertanyaan Aminah?


* BERTANYA UNTUK MEMINTA PENDAPAT
Contoh:
Apakah kamu setuju dengan pendapat Ani?


* PASTIKAN SISWA MENDENGAR DAN PAHAM
Contoh:
Apakah kamu mendengar yang dikatakannya? Dapatkah kamu mengulangnya kembali?



(Prof Dr Dian Armanto, adalah dosen Universitas Negeri Medan (UNIMED))

BIlangan Bersahabat

Mencari pertemanan atau persahabatan melalui social networking mungkin sudah menjadi rutinitas sebagian dari kita. Tentu saja kesempatan itu kita lakukan agar semakin banyak " pertemanan atau persahabaatan" yang kita dapat dari dunia maya. Friendster, Face Book, My Space atau yang lainnya merupakan beberapa contoh dari social networking yang digemari oleh para peselancar di dunia maya. BTW, kalau

Soal Minggu Ini 24112008

Sejumlah murid di suatu sekolah mengumpulkan uang sebanyak Rp. 960.000,-. Setiap murid harus memberi iuran yang sama. Kemudian ternyata ada 4 orang yang tidak dapat memberikan iuran karena alasan tertentu. Akhirnya untuk menutup kekurangannya, murid-murid lain harus menambah iurannya masing-masing Rp. 20.000,-. Berapah jumlah murid yang membayar?

Selamat Mencoba....

Pembahasan Integral 2

Pembahasan tentang materi integral yang saya bagi menjadi dua sesi ( yang pertama mengenai teknik pengintegralan ) memang belum sepenuhnya rampung atau diselesaikan. Tetapi daripada harus menunggu lebih lama lagi, karena memang ngga sempat / " ngga disempatkan ngerjainnya " akhirnya dengan terpaksa pembahasan yang baru setengah jadi ini saya upload juga. Tetapi meskipun pembahasannya baru

"Blog"
Upaya Menjadi Lebih Dipercaya

Oleh PEPIH NUGRAHA

Sederhana saja mengukur penerimaan masyarakat atas blog di negeri ini. Tahun lalu, pada Pesta Blogger 2007, jumlah peserta hanya 500 orang. Kini, ketika Pesta Blogger 2008 kembali digelar, jumlah peserta yang terdaftar mencapai 1.200 orang. Jika tidak dibatasi, jumlahnya bisa jadi di atas 2.000 orang.

Memang parameter yang digunakan terlalu sederhana. Bukan maksud mengukur apakah blog diterima atau tidak oleh masyarakat, sebab hal itu tidak terlalu bermanfaat untuk dibahas. Lebih baik mengetahui bagaimana masyarakat memanfaatkan blog itu untuk berbagai keperluan, tidak sekadar bergaya atau asal punya blog. Maklum, sejak kelahirannya sampai kini blog masih dicibir banyak orang.

Padahal, dalam perkembangannya, blog ada yang mewujud sebagai citizen journalism, media indie yang menjadi bacaan alternatif. Dengan citizen journalism, siapa pun bisa memanfaatkan blog sebagai media penyampai pesan. Adagium ”media (blog) adalah pesan itu sendiri” menjadi terbukti di sini. Dan Gilmor dengan bukunya, We Media, mengklaim bahwa setiap orang adalah wartawan.

Kegiatan melaporkan suatu peristiwa dan menuliskannya pada media untuk disebarluaskan kepada khalayak bukan lagi milik jurnalis media arus utama. Warga bisa menjadi wartawan! Namun, tentu saja Gilmor mengatakan hal itu setelah tumbuh dan berkembangnya media online, web, dan kini blog yang bisa diperoleh secara mudah. Namun, karena mudahnya, blog didapat, ada anggapan bahwa ia tidak harus dipelihara dengan baik.

Dianggap tidak kredibel karena ulah segelintir blogger yang memanfaatkan blog untuk kepentingan sensasi belaka. Contoh ketika blog menjadi kontroversi dan dianggap sebagai penyebar fitnah setelah beredarnya rumor bahwa calon wakil presiden AS dari Partai Republik, Sarah Palin, tidak tahu Afrika merupakan benua. Rumor murahan ini ternyata berasal dari blog seseorang yang mengaku bernama Martin Eisenstadt.

Sayangnya, isu ini lalu ditangkap mentah-mentah media arus utama dan disiarkan tanpa berupaya melakukan cek dan ricek, meski pada akhirnya diralat.

Keterlibatan Amerika Serikat

Kalau begitu, apa yang harus dilakukan seorang blogger agar setiap posting-annya dapat dipercaya. ”Think before posting”, demikian pesan yang seharusnya ditangkap oleh setiap blogger sebelum menaruh tulisan dan gagasannya di blog. Apa yang di-posting-kan di blog harus menjadi tanggung jawab masing-masing blogger.

Wartawan senior harian ini, Ninok Leksono, pernah menulis di blog Kompasiana yang beralamat di http://kompasiana.com mengenai bagaimana seharusnya blog menjalankan fungsinya. Menurut dia, setiap pemilik blog berkepentingan agar blog miliknya tetap kredibel dan dipercaya warga pembaca lainnya. Bahkan, untuk Indonesia, katanya, ”Kredibilitas masih perlu ditambah dengan kearifan.”

Kembali ke Pesta Blogger 08 yang kali kedua ini digelar di Auditorium Gedung BPPT II Jakarta, Sabtu (22/11), ini menjadi sebuah pesta yang layak disimak. Bukan karena berkumpulnya komunitas blogger secara masif di sana, tetapi karena keterlibatan Pemerintah Amerika Serikat di sini. Nah, keterlibatan apa yang dimaksud?

Chairman Pesta Blogger 08, Wicaksono—yang dalam jagat blogger dikenal sebagai Ndoro Kakung—sebagaimana ditulis blogger Aris Heru Utomo di Kompasiana, mengaku sudah dapat mengira bahwa berperannya AS dalam mensponsori pesta blogger kali ini akan menimbulkan purbasangka dan curiga. Alasannya, ada sentimen dan prasangka tertentu dari sebagian kalangan terhadap AS.

Bagi Duta Besar AS untuk Indonesia Cameron R Hume, meraih blog berarti melaksanakan diplomasi publik di tingkat akar rumput. Tidak sekadar menakar ke mana arah kebijakan pemerintah masing-masing (G to G), tetapi juga bisa meraba perasaan warga masyarakat Indonesia melalui blog, melalui apa yang disebut Aris sebagai diplomasi publik. Selain itu, adalah tugasnya selaku diplomat untuk selalu memperkenalkan dan memelihara pemahaman tentang negerinya di masyarakat di mana dia bertugas.

Untuk itu dapat dipahami mengapa Kedubes AS di Indonesia berkenan menjadi sponsor Pesta Blogger 2008 yang mengusung tema blogging for society. Dengan cara ini, demokrasi dan semangat kebebasan berbicara yang selalu didengungkan AS ke pelosok dunia menjadi bukti nyata, tidak asal omong. Bagi Hume, kegiatan blog atau blogging merupakan bentuk dari kebebasan bicara yang individualistis sekaligus egaliter.

Kruger dan Obama

Di belahan dunia lain, blog sejatinya digunakan sebagai media alternatif untuk menyampaikan berita yang ”tidak seksi” alias tidak cukup menarik bagi media arus utama. Masalah kesehatan penduduk lokal, masalah ketimpangan pendidikan, ketidakadilan dalam kesempatan memperoleh pekerjaan, hanyalah contoh kecil saja di mana blog bisa berperan di dalamnya. Blog bisa menyampaikan semua ”ketidakadilan” itu tanpa dibatasi ruang dan waktu.

Pada tahun 2008 ini blog naik daun seiring dengan terpilihnya Barack Obama sebagai Presiden AS. Obama, seperti telah banyak ditulis, memiliki blog sendiri dan menjadi bagian dari belasan situs pertemanan seperti Facebook. Padahal, Justin Hall, pemuda kelahiran 16 Desember 1974 yang juga seorang wartawan paruh waktu, tidak berpikir sejauh itu saat menjadi blogger pertama yang menulis catatan hariannya di internet tahun 1994.

Masih segar dalam ingatan, bagaimana pemenang Nobel bidang Ekonomi, Paul Krugman, demikian lugas menuangkan gagasannya yang jauh lebih segar dibanding dengan apa yang ditulisnya di The New York Times versi print saat ia menulis di blog miliknya. Di http://krugan.blogs.nytimes.com yang juga menjadi bagian koran ternama itu, Krugman menulis persoalan berat menjadi ringan dan enak dibaca. Alhasil, Krugman lebih dikenal sebagai blogger ketimbang sebagai kolumnis atau analis ekonomi.

Usia blog belumlah terlalu lama. Kalau menyebut Hall sebagai orang pertama yang ngeblog, usianya baru 14 tahun. Namun, di usinya yang tergolong muda, blog telah dimanfaatkan berbagai golongan masyarakat dengan berbagai tingkatan usia.

Jangan heran kalau Uskup Bandung yang sudah tergolong usia senja, Pujasumarta, memiliki blog sebagai media untuk memberitakan kegiatannya sekaligus menyapa jemaatnya. Ada juga Marsekal Muda (Purn) Prayitno Ramelan yang mengisi masa-masa pensiunnya dengan ngeblog. Violis Maylafflayza sudah sejak lama memanfaatkan blog dan situs pertemanannya sebagai media komunikasi untuk menyapa penggemarnya.

Anda belum ngeblog? Jangan dengar ledekan Jenderal Naga Bonar ”Apa kata dunia?” Mulai sajalah ngeblog saat ini juga!
Sumber: KOMPAS Kamis, 20 November 2008 | 01:19 WIB

Ejacs: a JavaScript interpreter for Emacs

So! I have all these cool things I want to write about, but I broke my thumbnail. Can you tell that's a long story?

See, this summer I got excited about playing guitar again. I usually switch between all-guitar and all-piano every other year or so. This summer I dusted off the guitars and learned a bunch of pieces, and even composed one. I was prepping for — among other things — a multimedia blog entry. It was going to have a YouTube video, and a detailed discussion of a wacky yet powerful music programming language you've probably heard of but never used, and generally just be really cool.

And then it all came crashing down when I busted my thumbnail off. And I mean off — it broke off at least a quarter inch below where the nail and skin meet. Ick. I just accidentally jabbed my steering wheel, and that was that.

I remember reading an interview with some dude who said he had punched a shark in the nose. He said it was like punching a steering wheel. So now I know more or less what it's like to punch a shark in the nose, I guess. There's always an upside!

Anyway, that was going to be my magnum opus (literally: Op. 1) for the year, but it fell through for now. I'll have to revisit the idea next year. My thumbnail's back, but it's been at least 2 months since I touched my guitar, so I'll have to start over again.

Work has been extraordinarily busy, what with having to collect all these Nuka-Cola Quantum bottles and so on. I'm sure you can imagine. So I haven't had much time to blog lately.

But I do like to publish at least once a month, whether or not anyone actually cares. It's been about a month, or it feels that way anyway, and all I have to show for it is this box of Blamco Mac and Cheese.

So I'm cheating this month.

You know how on Halloween how you walk around in your costume holding your little bag and you say "trick or treat", and every once in a while some asshole does a trick instead of dumping half a pound of candy into your bag? And then he has to explain to all the dumbfounded and unhappy kids that "Trick or Treat" means that a trick is perfectly legal according to the semantics of logical-OR, and the kids remember that a-hole for the rest of their childhoods and avoid his house next year?

Yeah.

So I'm doing a trick this time. Hee. It's actually kind of fun when you're on the giving end.

My trick is this: in lieu of saying anything meaningful or contemporarily relevant, I'm writing about something I did over a year ago. And there isn't much to say, so this really will be short.

Ejacs

Around a year ago, I wrote a blog called Stevey's Boring Status Update, mostly in response to wild rumors that I'd been fired from Google. Not so. Not yet, anyway.

In that blog I mentioned I was working nights part-time (among other things) on a JavaScript interpreter for Emacs, written entirely in Emacs Lisp. I also said I didn't have a name for it. A commenter named Andrew Barry suggested that I should not call it Ejacs, and the name stuck.

Ejacs is a port of Narcissus. Narcissus is a JavaScript interpreter written in JavaScript, by Brendan Eich, who by pure unexpected coincidence is also the inventor of JavaScript. Narcissus is fairly small, so I thought it would be fun to port it to Emacs Lisp.

It turns out Narcissus is fundamentally incomplete. It cheats. It's that trick guy on Halloween. Narcissus has a working parser and evaluator, but for its runtime it calls JavaScript. So it's kind of like saying you're building a car by starting from scratch, using absolutely nothing except for a working car.

This meant I wound up having to write my own Ecma-262 runtime, so that the evaluator would have something to chew on. In particular, the Ecma-262 runtime consists of all the built-in properties, functions and objects: Object, Function, Array, String, Math, Date, RegExp, Boolean, Infinity, NaN, parseInt, encodeURIComponent, etc. A whole bunch of stuff.

I basically did this by reading the ECMA-262 specification and translating their algorithms into Emacs-Lisp. That spec is lousy for learning JavaScript, but it's absolutely indispensable if you're trying to implement JavaScript.

I didn't know Emacs-Lisp all that well before I started, but boy howdy, I know it now.

Emacs actually has a pretty huge runtime of its own — bigger than you would ever, ever expect given its mundane title of "text editor". Emacs has arbitrary-precision mathematics, deep Unicode support, rich Date and Calendar support, and an extensive, fairly complete operating system interface. So a lot of the porting time was just digging through Emacs documentation (also extensive) looking for the Emacs version of whatever it was I was porting. That was nice.

I had big plans for Ejacs. I was going to make it a full-featured, high-performance JavaScript interpreter, with all the Emacs internals surfaced as JavaScript native host objects, so you could write Emacs customizations using object-oriented programming. It was totally going to be the "meow" part of the cat.

And then I broke my thumbnail.

Actually, what happened was js2-mode.

js2-mode

After I got the interpreter working, I was at this crossroads. There were two big use cases: a JavaScript editing mode, or a JavaScript Emacs development mode. Both were going to be a lot of work.

It turns out you really want the editing mode first, if possible, so that when you're doing all your JavaScript programming you have a decent environment for it. So I picked the editing mode.

Unfortunately I found the Ejacs parser wasn't full-featured enough for my editing needs, since at the time I was working on my Rhino-based Rails clone and writing tons of JavaScript 1.7 code on the JVM.

I spent a little time trying to beef up the parser, then realized it would be a lot faster to just rewrite it by porting Mozilla Rhino's parser, which is (only) about 2500 lines of Java code. Ejacs is something like 12,000 lines of Emacs-Lisp code, all told, so that didn't seem like a big deal.

So I jumped in, only to find that while the parser is 2500 lines of code, the scanner is another 2000 lines of code, and there's another 500 or so lines of support code in other files. So I was really looking at porting 5000 lines of Java code.

Moreover, the parse tree Rhino builds is basically completely incompatible with the Ejacs parse tree. It was richer and more complex, and needed more complicated structures to represent it.

So after I'd ported the Rhino parse tree, what I really had was a different code base. I went ahead and finished up the editing mode, or at least enough to make it barely workable (another 5000 lines of code), and launched it. It was a surprisingly big effort.

And it left poor Ejacs lying unused in the basement.

So today, faced with nothing to write about, I figured I'd dust off Ejacs, launch it with lots of fanfare, and then you'd hardly notice that I cheated you. Right?

You're not coming to my house next year. I can tell already.

Anyway, here's the code: http://code.google.com/p/ejacs/

There's a README and a Wiki and installation instructions and stuff. I can't remember how to put the code in SVN, and I'm having trouble finding it on the code.google.com site. As soon as I figure it out I'll also make it available via SVN.

Emacs Lisp vs. JavaScript

In the interests of having something resembling original worthwhile content today, I'll do a little comparison of Emacs Lisp and JavaScript. I know a lot about both languages now, and a few folks mentioned that a comparison would be potentially interesting.

Especially since I think JavaScript is a better language.

So... the best way to compare programming languages is by analogy to cars. Lisp is a whole family of languages, and can be broken down approximately as follows:

• Scheme is an exotic sports car. Fast. Manual transmission. No radio.
• Emacs Lisp is a 1984 Subaru GL 4WD: "the car that's always in front of you."
• Common Lisp is Howl's Moving Castle.

This succinct yet completely accurate synopsis shows that all Lisps have their attractions, and yet each also has a niche. You can choose a Lisp for the busy person, a Lisp for someone without much time, or a Lisp for the dedicated hobbyist, and you'll find that no matter which one you choose, it's missing the library you need.

Emacs Lisp can get the job done. No question. It's a car, and it moves. It's better than walking. But it pretty much combines the elegance of Common Lisp with the industrial strength of Scheme, without hitting either of them, if you catch my drift.

Anyway, here's the comparison. Here's why I think JavaScript is a better language than Emacs Lisp.

Problem #1: Momentum

A recurring theme is that Elisp and JavaScript both will both exhibit a particular problem, and there are specific near-term plans to fix it in JavaScript, but no long-term plans to fix it in Elisp.

It's easier to resign yourself to a workaround when you know it's temporary. If you know the language is going to be enhanced, you can even design your code to accommodate the enhancements more easily when they appear.

People are working on improving JavaScript. It's not happening quite as fast as I'd hoped earlier this year, but it's still happening. As far as I know, Emacs Lisp is "finished" in the sense that no further evolution to the language is deemed necessary by the Emacs development team.

Problem #2: No encapsulation

Every symbol in Emacs-Lisp is in the global namespace. There is rudimentary support for hand-rolled namespaces using obarrays, but there's no equivalent to Common Lisp's in-package, making obarrays effectively useless as a tool for code isolation.

The only effective workaround for this problem is to prefix every symbol with the package name. This practice has become so entrenched in Emacs-Lisp programming that many packages (e.g. apropos and the elp elisp profiler) rely on the convention for proper operation.

The main adverse consequence of this problem in practice is program verbosity; it makes Emacs-Lisp more difficult to read and write than Common Lisp or Scheme. It can also have a non-negligible impact on performance, especially of interpreted code, as the prefix characters can approach 5% to 10% of total program size in some cases.

The problems run slightly deeper than simple verbosity. Without namespaces you have no real encapsulation facility: there is no convenient way to make a "package-private" variable or function. In practice there's little problem with program integrity; it's hard for an external package to change a "private" variable inadvertently in the presence of symbol prefixes. However, it makes it annoyingly difficult for users of the package to discern the "important" top-level configuration variables and program entry points from the unimportant ones. Elisp attempts a few conventions here, but it's a far cry from real encapsulation support.

JavaScript also lacks namespaces. They're being added in ES/Harmony, but in the meantime, browser JavaScript code typically uses the same name-prefixing practice as Emacs-Lisp.

However, JavaScript has lexical closures, which provide a mechanism for creating private names. One common encapsulation idiom in browser JavaScript is to wrap a code unit in an anonymous lambda, so that all the functions in the code unit become nested functions that close lexically over the top-level names in the anonymous lambda. This trick is nowhere near as effective in Emacs-Lisp, for several reasons:

• elisp is not lexically scoped and has no closures
• elisp nested defuns are still entered into the global namespace
• CL's `flet' and `labels' are only weakly supported, via macros, and they frequently confuse the debugger, indenter, and other tools.

Some elisp code (e.g. much of the code in cc-engine) prefers to work around the namespace problem by using enormous functions that can be thousands of lines long, since let-bound variables are slightly better encapsulated. Even this is broken by elisp's dynamic scope:

(defun foo ()
  (setq x 7))

(defun bar ()
  (let ((x 6))
    (foo)
    x))  ; you would expect x to still be 6 here

(bar)
7  ; d'oh!

So let-bound variables in elisp can still be destroyed by your callee: a dangerous situation at best.

Emacs is basically one big program soup. There's almost no encapsulation to speak of, and it hurts.

Problem #3: No delegation

One of the big advantages to object-oriented programming is that there is both syntactic support and runtime support for automatic delegation to a "supertype". You can specialize a type and delegate some of the functionality to the base type. Call it virtual methods or prototype inheritance or whatever you like; most successful languages support some notion of automatic delegation.

Emacs Lisp is a lot like ANSI C: it gives you arrays, structs and functions. You don't get pointers, but you do get garbage collection and good support for linked lists, so it's roughly a wash.

For any sufficiently large program, you need delegation. In Ejacs I wound up having to implement my own virtual method tables, because JavaScript objects inherit from Object (and in some cases, Function, which inherits from Object).

Writing your own virtual method dispatch is just not something you should have to do in 2008.

Problem #4: Properties

I wrote about this at length in a recent blog post, The Universal Design Pattern. JavaScript is fundamentally a properties-based language, and it's really nice to be able to just slap named properties on things when you need a place to store data.

Emacs Lisp only offers properties in the form of simple plists – linked lists where the odd entries are names and the even entries are values. Symbols have plists, and symbols operate a little bit like very lightweight Java classes (in that they're in the global namespace), but that only gets you so far. If you want the full JavaScript implementation of the Properties Pattern, you'll have to write a lot of code.

And so I did. Your implementation choice for object property lists has a huge impact on runtime performance. Emacs has hashtables, but they're heavyweight: if you try to instantiate thousands of them it slows Emacs to a crawl. So they're no good for the default Object property list. Emacs also has associative arrays (alists), but their performance is O(n), making them no good for objects with more than maybe 30 or 40 properties.

I wound up writing a hybrid model, where the storage starts with lightweight alists, and as you add properties to an object instance, it crosses a threshold (I set it to 50, which seemed to be about right from profiling), it copies the properties into a hashtable. This had a dramatic increase in performance, but it was a lot of work.

I experimented with using a splay tree. I implemented Sleater and Tarjan's splay tree algorithm in elisp; Ejacs comes with a standalone splay-tree.el that you can use in your programs if you like. I was hoping that its LRU cache-like properties would help, but I never found a use case where it was faster than my alist/hashtable hybrid, so it's not currently used for anything.

And then in the end, after I was done with my implementation, it was a library (at least from the Emacs-Lisp side of the house). It wasn't an object system for Lisp. It's only really usable inside the JavaScript interpreter, where it has syntactic support.

You really want syntactic support. Sure, people have ported subsets of CLOS to Emacs Lisp, but I've always found them a bit clunky. And even in CLOS it's hard to implement the Properties Pattern. You don't get it by default. CLOS has lots of support for compile-time slots and virtual dispatch, but very little support for dynamic properties. It's not terribly hard to build in, but that's my point: for something that fundamental, you don't want to have to build it.

Problem #5: No polymorphic toString

One of the great strengths of JavaScript is the toSource extension. I don't know if they support it over in IE-land; I haven't been a tourist there in a very long time. But in real versions of JavaScript, every object can serialize itself to source, which can then be eval'ed back to construct the original object.

This is even true for functions! A function in JavaScript can print its own source code. This is an amazingly powerful feature.

In Emacs Lisp, some objects have first-class print representations. Lists and vectors do, for instance:

(let ((my-list '()))
  (push 1 my-list)
  (push 2 my-list)
  (push 3 my-list)
  my-list)
(3 2 1)

(let ((v (make-vector 3 nil)))
  (aset v 0 1)
  (aset v 1 2)
  (aset v 2 "three")
  v)
[1 2 "three"]

But in Emacs Lisp, many built-in types (notably hashtables and functions) do NOT have a way to serialize back as source code. This is a serious omission.

Also, trying to print a sufficiently large tree made entirely of defstructs will crash Emacs, which caused me a lot of grief until I migrated my parse tree to use a mixture of defstructs and lists. Note that simply typing the name of a defstruct, or passing over it ephemerally in the debugger, will cause Emacs to try to print it, and crash. Fun.

The problem of polymorphic debug-printing (or text-serialization) is, I think, a byproduct of Emacs not being object-oriented. If you want a debug dump of a data structure, you write a function to do it. But Emacs provides a half-assed solution: it debug-prints lists very nicely, even detecting cycles and using the #-syntax for representing graph structures (as does SpiderMonkey/JavaScript). But it has no useful debugging representation for hashtables, functions, buffers or other built-in structures, and there's no way to install your own custom printer so that the debugger and other subsystems will use it.

So it sucks. Printing data structures in Emacs just sucks.

The situation in Ecma-262-compliant JavaScript really isn't that much better, although you can at least install your own toString on the built-ins. But any competent "server-side" JavaScript implementation (i.e. one designed for writing real apps, rather than securely scripting browser pages) has a way to define your own non-enumerable properties, so you can usually override the default behavior for things like toString and toSource.

And all else being equal, at least JavaScript functions print themselves.

Emacs advantages: Macros and S-expressions

Pound for pound, Emacs Lisp seems roughly as expressive as JavaScript or Java for writing everyday code. It shouldn't be that way. Emacs Lisp ought to be more succinct because it's Lisp, but it's incredibly verbose because of the namespace problem, and it's also verbose to the extent that you want to use the properties pattern without worrying about alist or hashtable performance.

Elisp does have a few places where it shines, though. One of them is the cl (Common Lisp emulation) package, which provides a whole bunch of goodies that make Elisp actually usable for real work. Defstruct and the loop macro are especially noteworthy standouts.

Some programmers are still operating under the (ancient? legacy?) assumption that the cl package is somehow deprecated or distasteful or something. They're just being silly; don't listen to them. Practicality should be the ONLY consideration.

The cl package wouldn't have been possible without macros. JavaScript has no macros, so even though it has better support for lambdas, closures, and even (in some versions) continuations, there are still copy/paste compression problems you can't solve in JavaScript.

Emacs Lisp has defmacro, which makes up for a LOT of its deficiencies. However, it really only has one flavor. Ideally, at the very least, it should support reader macros. The Emacs documentation says they were left out because they felt it wasn't worth it. Who are they to make the call? It's the users who need them. Implementer convenience is a pretty lame metric for deciding whether to support a feature, especially after 20 years of people asking for it.

Elisp is s-expression based, which is a mixed bag. It has some advantages, no question. However, it fares poorly in two very common domains: object property access, and algebraic expressions.

JavaScript is NOT s-expression based (or it wouldn't be a successful language, many would argue), but it does offer some of the benefits of s-expressions. JSON is one such benefit. JavaScript's declarative object literals (or as a Lisp person would say, "syntax for hashes") and arrays provide a powerful mechanism for designing and walking your own declarative data structures.

JavaScript also has all the usual (which is to say, expected) support for algebraic operators. And unlike Java, JavaScript even got the precedence right, so it's not full of redundant parentheses.

Overall Comparison

In the end, it comes down to personal choice. I've now written at least 30,000 lines of serious code in both Emacs Lisp and JavaScript, which pales next to the 750,000 or so lines of Java I've crapped out, and doesn't even compare to the amount of C, Python, assembly language or other stuff I've written.

But 30,000 lines is a pretty good hunk of code for getting to know a language. Especially if you're writing an interpreter for one language in another language: you wind up knowing both better than you ever wanted to know them.

And I prefer JavaScript over Emacs Lisp.

That said, I suspect I would probably prefer Clojure over Rhino, if I ever get a chance to sit down with the durn thing and use it, so it's not so much "JavaScript vs. Lisp" as it is vs. Emacs Lisp.

I would love to see Emacs Lisp get reader macros, closures, some namespace support, and the ability to install your own print functions. This reasonably small set of features would be a huge step in usability.

However, for the nonce I'm focusing on JavaScript. I've found that JavaScript is a language that smart people like. It's weird, but I keep meeting really really smart people, folks who (unlike me) are actually intelligent, and they like JavaScript. They're always a little defensive about it, and almost a little embarrassed to admit it. But they think of it as an elegant, powerful, slightly flawed but quite enjoyable little language.

I tell ya: if you're a programming language, it's a very good thing to have smart people liking you.

It doesn't make me smart, but I kinda like it too. Even though there's (still) a lot of hype these days about Java, and people tootling on about how Java's going to be the next big Web language... I just don't see it happening. There are too many smart people out there who like JavaScript.

So enjoy the interpreter. Ejacs is just a toy, but I think it also shows a kind of promise. Scripting Emacs using JavaScript (if anyone ever actually implements it) could be really interesting. It could open up the world's most powerful, advanced editing environment to millions of people. Neat.

In the meantime, it doesn't actually do squat except interpret EcmaScript in a little isolated console, so don't get your hopes up.

Reminder — here's the Ejacs URL: http://code.google.com/p/ejacs - enjoy!

And with that, I'm off to find some Nuka-Cola Quantum. I just wish those bastards hadn't capped me at level 20.