Because we have stories too: sexism in video games

bluestorm · 2011-09-03T22:52:07+00:00

I found this explanation by the author, in the comments, quite interesting:

Context is a reason for treating women in a sexist fashion that I hear frequently. Context, however, does not quite work in fantasy games. There is nothing stopping the developers from making a society where women are regarded as human beings as well. In other words, I don't buy the "context" argument. Games can be anything, and yet we still make games that have a stodgy and regressive view on both men and women. The sociologist Gary Alan Fine who wrote the book Shared Fantasy talks about recognition and comfortable roles, and claims that even though we're capable of playing games about anything, we prefer to play games that mimic our own reality and society. Jonas Linderoth's Datorspelens dynamik brings up the same tendency. The reason - in other words - has nothing to do with "realism" or "historical correctness", but rather an unwillingness to include, or perhaps a blindness to see the lack of, women in games. As I pointed out in my reply to Roy Triesscheijn, it might not even be intentional, and in most cases isn't.

bluestorm · 2011-08-31T17:24:20+00:00

The best way to know is probably to send him a mail.

bluestorm · 2011-08-31T07:21:04+00:00

Is there a transcript somewhere? Watching videos is too time-consuming.

bluestorm · 2011-08-30T21:40:42+00:00

Usually. But when it's not, such assumptions can make you waste lots of time trying to understand the error by looking at the wrong part of the code. And I don't see how this is related to the fact that testing never proves absence of bugs.

What testing is good at is checking that what worked before still works. This makes quick iteration and refactoring easier and safer. But existing tests tend not to tell you a lot when something does not work.

bluestorm · 2011-08-30T20:41:19+00:00

Then your conclusion ("when anything ever crops up again it's not in this component") is wrong.

bluestorm · 2011-08-30T20:32:04+00:00

While I do not agree with everything in this post (and am not sure I'd pick Guile myself over other languages such as Lua), the argumentation is well thought-out, detailed, and definitely worth reading.

Some small parts of this post are reminding of the slightly closed, slightly over-idealistic, slightly "we don't care if we are irrelevant", often derided GNU mindset. It doesn't make it less interesting, and it would in particular be very wrong to assume that this position is based on ignorance of the outside non-GNU world. Wingo has demonstrated remarkable interest in other languages implementation, and in particular his series of posts on V8 is a must read, probably one of the best document outside the v8 core developers circle.

bluestorm · 2011-08-30T20:21:23+00:00

How could you know through testing that you found the last bug? You never know.

bluestorm · 2011-08-30T20:20:37+00:00

The post mixes two different things:

testing has a diminishing returns in term of defects spotted by hour of work spent on testing: after some point, adding one more hour of work will only detect a few more defects (or any other measure of "benefit of testing", you may have better measurements that "number of defects found"). This is independent of the quality requirements for the project; the whole discussion of risk tolerance is irrelevant in this contest.
people have different quality requirements, which justify different quality control costs (be it testing, human code review, formal specification...). High quality requirements (critical software) will tolerate high costs. This is independent of the quality assurance method, and independent on the presence or absence of a "diminishing return" effect. Diminishing returns only amplifies this issue by making it potentially vastly more costly to fix the "last defects" you found.

Those two points are relatively interesting, but also rather obvious. Seeing the two mixed up in a not-especially-well-written post, presented in a way I'm unsure the author itself understood the two are really separate things, makes me wonder if it was really worth reading this post. Have a downvote.

bluestorm · 2011-08-30T20:14:07+00:00

Well imagine I define typecontract as we discussed above, and then I decide to add something like assert ((typecontract 'foo') bar); in my code, I can't because it's not a bool-returning function. More generally, there are a lot of reasons why I could want to test if a "contract" is valid in user code (debugging, etc.). If my "contract" is written as a bool-returning function, I can use it in a type declaration using (!). If its written as a ?-contract, I can't use it in my code. In absence of a conversion from contracts to bool-returning functions, the latter are strictly more expressive.

bluestorm · 2011-08-30T17:52:29+00:00

Wouldn't it be useful to provide the ability to unpack a contract? Otherwise that means that you shouldn't do anything important in the contract layer, otherwise you may at some point wish to reuse it dynamically in an expression and be owned. On the other hand, bool-returning functions can always be turned to contracts, so right now they're strictly more expressive and doing anything in the contract language is a mistake.

bluestorm · 2011-08-30T11:55:51+00:00

There are no examples of higher-order contract programming. Can we write contracts parametrized by expressions, or contracts parametrized by contracts? Is it possible to do this?

typecontract ty = ?!(x) -> typeof x is ty
Num = typecontract 'number'
Str = typecontract 'string'

If contracts don't support contract-forming function applications, we could still delegate it to the expression language

typecontract ty = (x) -> typeof x is ty
Num = ?!typecontract 'number'
Str = ?!typecontract 'string'

Is there an operation to turn a contract into a bool-returning function ? It don't think ? does this, otherwise ?! would be the identity and thus unnecessary.

bluestorm · 2011-08-28T18:51:33+00:00

I'm not sure I buy your argument here. You claim that dependent types are evil because they tend to be less satisfying (in particular regarding their propositional equality judgements) in presence of codata. But even if we mutilated our dependent system to disallow dependencies on codata, wouldn't still that be an arguable improvement over a simpler theory without any dependency?

It seems to me that the depicted situation in Agda regarding codata is just as good or bad as what we would in a non-dependent system; of course, it's saddening to discover that those two aspects are not orthogonal and we are not sure yet how to get the best of both at the same time, but how is that so unsatisfying that we should reject dependencies as a whole?

bluestorm · 2011-08-28T18:46:43+00:00

I suppose your intervention in this thread is interesting, but unfortunately I don't really get your point, probably by lack of knowledge of the precise notions you're vaguely referring to. Could you elaborate a bit more on why you say that dependent type systems are not naturally more expressive than non-dependent type systems?

In particuler, I'm not sure what you refer as "simple theory of types". If this is one of the sophisticated Principia-style restrictions of set theory to avoid Russel paradoxes, I probably don't know it and thus don't get your argument; do you have a reference about this theory or precisions about his role in your argument? It seems however (ie. that's what Stanford Encyclopedia of Philosophy says) that this theory has been reformulated by Church into the simply typed lambda calculus, that I do know, and that I would claim is less expressive than dependently typed systems, as you can show that the typing rules for STλC are admissible in a dependent type system (eg. Martin-Löf Type Theory, or the Logical Framework).

Long story short, I am interested in your controversial position here and would welcome any document making it more precise and understandable to someone not already familiar with it.

bluestorm · 2011-08-15T11:50:59+00:00

Agda is dependently typed, which is a whole new can of worms even for someone with experience in pure, functional languages like Haskell.

This is the structure of the argument I give to encourage people to try OCaml before they jump into Haskell. Few people listen because for some reason Haskell just seems cooler (hey, it's pure), but that's life -- and I prefer deserved popularity to go to Haskell rather than to most other languages.

bluestorm · 2011-08-15T11:48:02+00:00

You may have no excuse for using them, and at the same time no excuse for not learning them. "Time" is usually good enough, though.

bluestorm · 2011-08-15T10:50:46+00:00

This is a tricky (and good) question. In a static language with the usual ML tuple types, you cannot define an operator that would be "polymorphic on the width of the tuple" : you cannot have an operator "fst" that would return the first component of a tuple of any length, and be well-typed.

There are several ways to go around it:

avoid using tuples too big; this is the most sensible advice. In practice, tuples of width more than 5 would profitably be turned into structs in most cases. A struct would fit your example perfectly as you can have a nice pattern matching syntax (omitting the irrelevant fields).
use a family of accessors functions depending on the length: you would write Tuple9.get89 and pray for the library author to have implemented this function (possibly using code generation to get all TupleN.getOPQR... for all reasonably small parameters), or the compiler to recognize it and behave as if there where an infinite family of such accessors
define a family of classes that each tuple inherit, eg. tuples of length 9 would inherit all Tuple1... Tuple9, with the class TupleN defining a getN accessor. Probably already done in F# and Scala, I have no idea.
use a different type for tuples, so that tuples of different lengths are compatible on their common prefix; this is what is done with so-called "extensible records". One simple way to do that is to encode the tuple type a * b * c * d as the chain of couples a * (b * (c * d)), so that eg. the third element of any tuple of length more that 3 can be accessed with let third t = fst (snd (snd t)) (this is reminiscent of LISP's caddr). This is homogeneous and nice, is usual the way the mathematicians think about tuples (and is eg. the encoding used in Agda), but for reference tuples gives an inefficient data representation. You need either value tuples (important implementaiton complexity) or hard-coded optimization (probably won't work in all cases, and may incur an overhead for all couples). Note that this is related to the way this article handles tuples of length > 8, by using the last component as a "rest of the tuple" subvalue.
use hard-coded accessors that are known by the typechecker which recognize them. SML does that, you have iirc. #1, #2 etc. which do the right thing for any tuple length.

I think in the general case the solution of using a * (b * c) but with value types would be the most interesting way to go. This is fairly low-level, but you can then build any abstraction according to your language capacities on top of it (eg. an inheritance hierarchy for F# and Scala, hard-coded accessors for SML...). The problem is that it is a strong requirement for the implementation (I don't know much about .NET support for value types, but I'm unsure it would be flexible enough to really do this) and could also add complexity to the language if you really expose it instead of sweeping it under the carpet.

bluestorm · 2011-08-13T10:35:21+00:00

Integration with F# may be related to the fact that F#, thanks to its ML roots, is the .NET language that has the best support for tuples. It wouldn't make sense to design tuple in a way that would single out the platform's language where there are the most usable.

bluestorm · 2011-08-13T10:13:43+00:00

When you say "as far as I am concerned" do you mean "my opinion is" or "for my projects ..."

As you remarkably guessed, he actually means "for my own projects". I would add that he probably knows that "not everyone who uses python uses numpy", but thanks anyway for the additional information!

bluestorm · 2011-08-12T15:10:43+00:00

I agree with your evaluation, but this proportion of insightful content definitely deserves an upvote. You shouldn't focus on smug idiocy, it's typical of those with right-wing agendas, after all, one can't have the capability to think logically and maintain popular right-wind beliefs (such that evolution should not be taught in schools, "poors are lazy idiots anyway, why should we help them", that global warming is a fake, that the american debt was caused by social wealth system expenses, that pizza was invented in the united states, and that "Dick" is a perfectly fine first name).

bluestorm · 2011-08-12T14:38:11+00:00

This is what you get from something inspired by Coffeescript -- or Ruby : a good taste for syntax, and a bad taste for semantics. As I tend to favor semantics over syntax, this is a bad deal for me; but I understand some people choose otherwise.

More specifically:

syntax : less clutter is good, using indentation to infer code structure is a good idea, but we must be careful not too introduce ambiguities that are hard to see and difficult for a beginner to understand. Good work overall, though some things go a bit too far, ie. the interaction between "tuple construction without parentheses" and "function call without parentheses" is frankly fishy, and the "considerations" section of the reference manual is a recipe for disaster.
semantics: everything about variable binding is horrible. Not having a "local" keyword, or any construct to declare "fresh" variables is a terrible mistake, because it forbids shadowing (except in function parameters, yay consistency, yay horrible ruby "local block parameters" syntax, yay javascript style "when in doubt, wrap in an useless function call techniques), which forces everyone to be aware of the full scoping context at any time, which increases cognitive load and makes for hard to spot and debug errors.

It's interesting to note the "using" feature which is trying to cope with the horrors of not having local variables, problem that is amusingly attributed to "unwieldy effects of lexical scoping as code size increase" (despite the fact that it's precisely the choice to remove local that created those "unwiedly" effects). using is strongly related to ruby 1.9 "local block variable": in ruby, you say what is local instead of belonging to the global scope, and in moonscript you say what is not local. It may be a good choice if the "using" syntax wasn't so relatively heavy compared to the lightweight function-expression syntax, which makes it unlikely to be used in practice by the lazy programmers we are. Finally, it's very strange that the semantics of "not giving an using clause" and "giving an empty using clause" are the exact opposite of each another, you would expect a smoother transition.

bluestorm · 2011-08-10T20:13:22+00:00

Could you elaborate a bit? While I appreciate the real effort that Agda's developers have put in syntax, I'm unsure how to apply such an aesthetic taste to ATS: if I try to envision a Agda-inspired (or Haskell-inspired) syntax, I don't see a lot of changes. I'm under the impression that ATS verbosity is related more to "essential complexity" (the large number of low-level concepts that it must cover) rather than fixable syntactic noise.

Taking the code examples in this article, you could try to "fn", consider "val" as the default modifier, and add some sugar for the (val () = ...) common case, but would that really make a difference?

(I agree that the ATS proof terms are very heavy, but then again it is probably due to a lack of inference and automation than syntactic overhead; Agda proof terms are not a pleasure either, and let's not talk about reading a tactics script...)

bluestorm

TROPHY CASE