Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


kasajian kasajian

Niner since 2005

  • The Future of Microsoft Tools and Services for the New Role of Developers

    very cool!

  • Introducing Visual Studio Dev Essentials


  • Rob Eisenberg on Aurelia

    Can't wait to use it!

  • Ask Anders Anything

    My favorite part:

    Q: C# started as an object-oriented, imparitive programming language, and has gained more functional programming concepts. Will this continue and where would you draw the line?

    A: "We're proving over the time that there isn't a line. No functional programming language is purely immutable because you have to produce output at some point. It's a question of how immutable you are. Functional languages tend to favor immutability heavily, whereas object-oriented languages tend to favor statefull and imperitive. We're all exploring the intersection between those."

    "The projects I've worked on recently, Roslyn and TypeScript, a lot of the techniques we used inside the compiler, for example, are functional programming techniques and a lot of immutable data structures."

    "Just because in this world of cmoputing that you have now you have mutable state, and you have multi-threading. You can have one or the other, but never do both. That would be a recipe for pain. If you want mutability, you have to be really careful with having threads modify your state. But if you're immutable, you can share with zero cost. You can had off a reference that's never changing. So you can have many threads *reading* the same data. That's always safe and is a liberating way to think about the problem. That's why I find immutability to be very attractive as programming tool."

  • Talkin' C++ with Alon, Marius, Bruno, and Jim

    @Charles:I wouldn't go as far as to say it's useless.  Most times when a consumer doesn't like a product, they don't tell advertiser.  This is a little similar to that.  So having a vote down button with no comment is definetely better than no vote down button at all.  That doesn't take away from the fact that if someone is going to vote down, it would be much more helpful if they also comment and explain why. 

  • Developing Applications for More Than 64 Logical Processors in Windows Server 2008 R2

    wow, the audio quality is so bad..  it just dies out and you hear nothing for 3 or 4 seconds at a time.

    It just seems odd that we're talking about great technolgoies, and we can't make a simple audio recording.  You can pick a tape recorder from Radio Shack for $20

  • E2E: Erik Meijer and Burton Smith - Concurrency, Parallelism and Programming

    I don't quite follow the reason on the white board that Erik wrote.


    He's saying that if you have a function

    [code] F( x ) { return 13; }[/code]

    (so basically, F always returns 13, regardless of what you pass in)


    and then you call F like so:

    F( E )

    would it retrun 13?  One would say, "sure, because it doesn't matter what you pass in"

    But his point is that, what if (for instance), the parameter E throws an exception.  That means F doesn't return 13 (or doesn't even get called)


    That means, you cannot replace an arbitrary instance of "F( E )" with "13".


    But I don't understand.   This is supposed to be purely-functional.  If I say that F returns 13 regardless of the parameter, I would want (and may be expect) that the compiler would not bother evaluating the parameter E to begin with.


    That is, even if I were to call F( 1/0 ), I could make the argument that 13 should be returned because ultimately, it's about evaulating F, not evaluating the the parameter to F, whose own evaluation is there solely for the purpose of being passed to F.




  • Anders Hejlsberg and Guy Steele: Concurrency and Language Design

    Assuming that someone writes software that super-concurrent, is there a way to verify that that is the case without actually trying it on a multi-processor computer?

    For instance, let's say that I have a quad core computer, and I write software that scales amazingly to 4 threads.  However, my intent was to actually scale to 8 or 16 or 32 threads, but I don't have the machine to test it.

    Is there some kind of execution path analysis tool (perhaps Intel can help with this), which analyzes the binary code (or may be source) and says, "yes, your code scales to 256 threads, with the following data set, but no more than that"

    Is there any research done in this area that anyone knows about?