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.
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
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.
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.
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!
I tried bing, set it as my default search provider when it came out. Switched back to google a few days ago. I really wanted it to be good, but the fact is that it just doesn't provide nearly as relevant search results for my usage.
It pained me to have to admit it, but using Bing for a few weeks I frequently had to go to google's home page to try my search terms again after Bing failed to provide anything relevant and it almost always produced better results so eventually I just had
to admit that Bing, even though it may have a bunch of extra fancy stuff that google doesn't, simply doesn't stack up for plain old search so there was no point in making my life harder by not having google as the main search provider
If bing, which is beta, had a "these result suck" link that you could click to easily report crappy results I'm sure you could learn a lot.