On a computer-related forum, someone pointed out that almost every time a discussion starts up along the lines of "Which programming language is better?", someone always pipes up with "It doesn't matter because Turing said you can write any program in any language".

And, yes, it's true that the Church-Turing thesis does show something like that.

(In practice, of course, the question often isn't asked about abstract languages but about an abstract language and all it's generally available implementations, along with library code to provide access to the hardware and/or operating-system services, so the waters get a bit muddied there.)

But it's irrelevant anyway. Yes, you could write the software for an Air-Traffic Control system or nuclear reactor in a language such as INTERCAL or brainfuck. These two languages are Turing-complete and can therefore express any expressible computer program. They're what's known as Turing Tar-Pits; you *can* write any program in them, but if you try to write anything worthwhile you are almost guaranteed to fail.

For example, take a simple brainfuck program that prints out "Hello World":

[code]++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.[/code]

Forgites who are also interested in programming might note the similarity here to the claim of "System doesn't matter". Yes, neither choice of programming language or roleplaying rules set changes the absolute limits of what program or game you can have. You can have your reactor controls in INTERCAL and your narrativism in Synnibar.

What those choices do effect are the ease by which you can achieve your desired program or game, and therefore how good a program or game you are likely to get (if, indeed, you manage to get one at all).

This is complicated and depends on a subtle mix of factors (the people involved, the precise characteristics of the thing desired, and so on). And this kind of subtle reasoning, about levels of performance probably achievable by some specific group of people according to some fairly subjective measure, is messy and often unsatisfying and requires a level of intellectual effort that most people aren't willing to give, especially on an internet forum.

So people say "system doesn't matter" and "programming language doesn't matter" because they can't be bothered to think about complicated things with many subtle factors. Both of these are attractive because they're easy answers.

I take it this is a "let me reiterate System Does Matter so it makes sense to me" post, right? You're not expecting anyone to disagree? I guess the metaphor is okay, except it doesn't quite get the whole issue.

A lot of role-players don't even acknowledge that system is different than written rules. You can't, in fact, run a game of Synnibar in a way that goes against its grain, if by "Synnibar" you mean "the written rules of Synnibar*" To play  it differently, you'd have to drift the system away from the written rules.

So System Does Matter goes beyond saying that it's difficult to run games with poorly-selected rules (i.e. written rules / published game entities) -- it says it's quite likely impossible to get what you want that way. I don't know what the programming equivalent would be on this.

Also don't forget that SDM is about a lot more than "are we playing G, N or S?" Creative Agenda itself is bigger than that, and there are other agendas to consider as well, which makes the above point even clearer. If you have a technical agenda to roll dice, Amber is not ever going to give you that, period...unless you're drifting to add dice, and then it's clearly no longer Amber-as-written.

* Though since those rules are probably incomplete, in terms of real play advice, you'd have to inclue "the way the designer intended it to be played" as well.

To be more precise:

Your metaphor says "you can accomplish any kind of play with any rule system, it may just be unncessarily hard."

That's more-or-less true, in that you can drift any published set of rules to do whatever you want (use whatever system you want) and still call it the same thing if you feel like it. But SDS is ultimately talking about system itself, not the labels we put on it. And it says, "you can't accomplish any kind of play with any kind of system."

I take it this is a "let me reiterate System Does Matter so it makes sense to me" post, right? You're not expecting anyone to disagree?

A lot of role-players don't even acknowledge that system is different than written rules.

So people say "system doesn't matter" and "programming language doesn't matter" because they can't be bothered to think about complicated things with many subtle factors. Both of these are attractive because they're easy answers.

I don't know if it's on topic, but there's a certain assumption here about system does matter and roleplay games always refering to something like a programming language.

It's something I was getting at here: Complete games and unguided resource assignment

In terms of this thread, there are two different types of 'system does matter'

One is in the programming language sense: Every programing language is at least slightly biased in it's design toward some sort of particular program type. Since the system does matter is for designers to listen to, here it means designers should create a language that has the bias they want it to have.

The other, which this thread isn't really refering to, is a complete game: It's been compiled and no more code is added at all. Here 'system does matter' means to not just create a language, but make a game program with it. In fact, one which does what you want your game to do.

Currently the roleplaying community at large (including the forge) confuses the two, not drawing a line between them. I can see the confusion when reading game texts here. There are breakpoints, where there are rules and then suddenly they just stop and it's really just advice for someone to program in their own rules here (ie, come to an often unwritten agreement with friends on how to handle the next bit).

Personally I see it as a massive lapse of the 'system does matter' philosophy - the designer isn't trying to forfil the idea of SDM, when he hand waves sections and leaves it up to the end user to finish the design themselves. That's making the end user a co-designer and delegating work to them.

On the other hand, it's been the most recurring technique of introducing the SIS into the systems rules. It's a particularly raw technique, like leaving parts out of an Ikea furniture kit, so the end result MUST consist partially of the users imagination. It's also gets to be a bit of an ego stroke for end users, their whim becoming reality, but being able to use the above confusion in design to say 'that's how the game works'. Despite how I put it, that's often quite functional...but still an ego stroke (certainly inspires a type of investment). Much like having a combat system in a game has become a tradition, so have these break points, even at the forge.

If it were a computer game, it would be like confusing the difference between A: pushing the control stick forward and B: entering code that increments your X co-ords by ten units, when the control stick is pushed forward.

I'd say the analogy helps clarify how system matters in a different way, if your writing a programming language, than if your writing a complete game. When your writing a programming language, your leaving it partly up to someone else to make system matter as well. That's a pretty big difference, since your acknowleding that system does matter, but also conciously deciding to wash your hands of the process at point X and delegating it to the end user.