Back to Profile: sylvan


  • E3 2010: Highlight Reel from The Microsoft Press Briefing

    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.).

  • Inside SPUR - A Trace-Based JIT Compiler for CIL

    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.

  • CES 2010: NUI with Bill Buxton

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

  • E2E2E: Meijer, Rys and Vick - Programming Data

    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.

  • Nick Baker: Xbox Architecture

    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:  and

  • C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 9 of 13

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

  • C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 7 of 13

    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




  • Rico Mariani: Inside Visual Studio Beta 2 - Performance and Reliability

    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.

  • C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 4 of 13

    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!

  • C9 Lectures: Dr. Erik Meijer - Functional Programming ​Fundamental​s, Chapter 3 of 13

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


    Prelude> :t zip

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


  • Expert to Expert: Harry Shum - General Purpose Search, Decision Engines and Bing

    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 Sad

    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.

  • VC 10: Stephan T. Lavavej and Damien Watkins - Inside STL

    Or as my mother used to say "When your hammer is C++, everything starts looking like a thumb" Smiley