Comments

The reason they made a separate hub is because it works better that way. Don't assume they're just bumbling idiots who haven't thought this through. It's done that way for a reason.

E3 isn't a consumer show at all. It's a press event. They're not selling it to the attendees at E3, they're selling it to soccer moms and six year olds, and are relying on journalists to do their jobs and report on it accurately even if they're not personally the target audience.

Wii sport wasn't a surprise. It was equally obvious. It's clear that physical gaming requires a sports title. We've certainly had arcade machines with sports titles for ages (golf, skiing etc.).

How does this relate to statically typed languages like C#? Does it improve upon the normal JIT for those too? Apologies if this is answered in the video. I'm bandwidth-limited at the moment so I'll have to watch it later.

You sure he's a principle researcher, and not a principal? 

Types are not just about ruling out invalid expressions, they also *add* information. The type of a variable can determine what piece of code to run in a given expression. This is type-based dispatch, as opposed to value based dispatch (vtables). 

Take a function like "read :: Read a => String ->a" in Haskell. It will parse any value of a type that's in the Read class. You don't nead a readInt, or readFloat etc., the type of the *result* of read is used to determine which specific parser to use. A dynamic language can't do that - it doesn't know the type of the result until after the function has executed, but it doesn't know which function to execute since it depends on the result type! 

That type is in turn determined from the context. This really starts shining when you compose it together, e.g. this function which reads a space separated list of values:

readSpaceSeparatedList :: (Read a) => String -> [a]

readSpaceSeparatedList xs = map read (words xs)

Now you can read a list of Ints, or Floats, or MyUserDefinedDataType using the same function. The specific expected type at the call site determines how the parsing happens. And indeed maybe the call site doesn't need to know what the specific type is:

sumSpaceSeparatedList :: (Num a, Read a) => String -> a

sumSpaceSeparatedList str = sum (readSpaceSeparatedList xs)

So again, we've written yet another layer of code and we *still* haven't had to decide exactly what parser to use to read the actual data from the string. We've only narrowed it down to something that's numeric (for the sum). Eventually something will force it to an Int or Float or something and then the compiler will figure out that it needs to use the Int or Float instance for Read.

Imagine how you'd write that in a dynamic language. You'd need a readInt, readFloat,etc, and similar for the two other functions. Or you'd need to wrap up the parser in an object and thread it through all the functions, but that's hideous (sort of like manual vtables to do OOP in C).

Anyway, this got longer than intended. The point is that a type system is not just about catching errors - types constitute extremely useful information that can actually be used by the compiler to make decisions, which can let you avoid writing ugly and boilerplate code.

Self-selected surveys are essentially useless. In fact, worse than useless, because people who don't know how proper statistical surveys work think it's representative of the real number, when in fact it's not.

See: http://en.wikipedia.org/wiki/Selection_bias  and http://en.wikipedia.org/wiki/Self-selection

I'm in the UK and I had major problems downloading PDC videos. This one seems fine though.

I don't think it's wrong at all. He hasn't flipped the arguments, he puts "ys" as the base case for the fold, meaning it will end up "to the right" (hence the "r" in foldr).

EDIT: Ah, I see what you mean, I thought you meant the first "=" sign. sorry about that, anyway. I'll keep this here because it's neat.

Put this in a Haskell file:

import Test.QuickCheck 
prop_Concat :: [Int] -> [Int] -> Bool 
prop_Concat xs ys = xs ++ ys == foldr (:) ys xs
 

This code defines a quickCheck property, which is a way of automatically generating tests in Haskell. You specify what you expect to be true for the inputs, and it generates tons of data for you and verifies that the property is indeed true.

Then open it in GHCi (or hugs, I think) and do:

*Main> quickCheck prop_Concat 
OK, passed 100 tests

Well, now that you mention it. It would be good if plugins were never allowed to block any UI. It appears that sometimes in VS2008 you click the "Tools" menu, or right-click a project, or something it takes many seconds (~2-10) to open. I suspect it's one of our plugins misbehaving for some reason, but it would be better if VS basically loaded any plugin UI asynchronously. So maybe that Incredibuild menu item isn't there initially if it's not fast enough (say, 50ms), that's better than its slowness getting in my way the 99% of the times when I'm not actually going for that menu item.

To be honest, people really don't use hugs/ghci for actually writing definitions. It's more for testing the definitions you have in a .hs file... Once you know more Haskell you'll understand better what the ghci prompt is (it's essentially right in the IO monad, hence the need for "let" etc. to declare things). 

Do yourself a favour and type your code in a .hs file, use ":r" to reload it each time and just use the interactive prompt to test the functions, it'll save you some head aches!

You can use ":t" to find the type of something:

Prelude> :t zip

zip :: [a] -> [b] -> [(a, b)]

Prelude>