There's an interesting division between what happens on MU*s IC (in character) and what happens OOC (out of character). Think about it this way: if you were roleplaying with a group of people face to face (pencil and paper), and two characters flirt, would you consider this cheating? Even if the people playing don't hold any attraction for each other? I doubt it. But if you go to get a drink after the game and continue to flirt, then it's a cause for concern.
The rule of thumb is: what's done IC is no more cheating than acting in a play or writing in a book. If it crosses into OOC, it's you talking, not your character.
One of the great features of Java (and other dynamic languages) is that the compiler is generally laid back about typing. You can put a circle in a list of polygons (objects) if you want. No hassle. Why shouldn't you be able to? instanceof allows you to check what type of object you have when you pull one off the list. You get a classcast exception if it's an unexpected type at runtime; you can catch the exception and recover. No worrying about RTTI overhead, either.
Laid-back languages allow programmers to make mistakes they wouldn't otherwise, but it also provides an ease-of-use sorely missing from C.
For instance: Java: at runtime you cast an Object to a circle. A catchable exception results before you can do anything dangerous. C/C++: at runtime you cast a void* to a circle*. nothing happens. you write to a field in the circle and... buh. Potential memory overwrite.
This could go a long way towards reducing voting confusion (ala butterfly ballots). You could have a well-layed-out touch screen rather than being limited to the size of a paper ballot. Voting in an elderly county which has a lot of with people poor eyesight? Increase the font size.
At the end of the session, after people have picked their candidates, you can present the information to them again and ask them to verify that the choices are correct. No dimpled chads, no half-punched holes, no double votes. It won't eliminate problems, mistakes, or complaints entirely, but it allows options which are unavailable on paper.
So the system may be buggy at first: treat it as a critical systems project (life support, chemotherapy machines). The best part of all -- instant and accurate tallies, where the numbers stay the same no matter how many times you add up the votes!
The rule of thumb is: what's done IC is no more cheating than acting in a play or writing in a book. If it crosses into OOC, it's you talking, not your character.
Laid-back languages allow programmers to make mistakes they wouldn't otherwise, but it also provides an ease-of-use sorely missing from C.
For instance:
Java: at runtime you cast an Object to a circle. A catchable exception results before you can do anything dangerous.
C/C++: at runtime you cast a void* to a circle*. nothing happens. you write to a field in the circle and... buh. Potential memory overwrite.
At the end of the session, after people have picked their candidates, you can present the information to them again and ask them to verify that the choices are correct. No dimpled chads, no half-punched holes, no double votes. It won't eliminate problems, mistakes, or complaints entirely, but it allows options which are unavailable on paper.
So the system may be buggy at first: treat it as a critical systems project (life support, chemotherapy machines). The best part of all -- instant and accurate tallies, where the numbers stay the same no matter how many times you add up the votes!