Entries:
Comments:
Posts:

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

Discussions

William Kempf wkempf
  • Error : Inconsistent ​accessibili​ty

    This should be obvious from the error message. Look at the Album class definition. It has to be public, because it's part of the public interface on the Artist class.

  • VS2015 RC download link is broken

    Works for me.

  • Reverse porting of the ios/ android to windows

    I *think* the question he's asking is if he can use Windows and Visual Studio to develop "native" Android or iOS applications.

  • When will surface pro 4 be released

    @spivonious: That's the best guess, but it's only a guess. As dahat said, those who know cannot say. Sorry SP4, you're not going to get an answer here.

  • Android Apps to run on Windows Phone

    @Bas: No, it's seemed to have been mostly the opposite. His tweets during the presentations were almost over the top positive... even during the Andriod/iOS reveals.

  • Best of //build/

    @ScanIAm: It's a little heavy weight for replacing Notepad++ for me, but yes, it's an interesting additional tool.

  • Best of //build/

    @bondsbw: I seem to recall him saying, specifically, they'd have access to Cortana. I know they mentioned access to "universal APIs", and Cortana should be one of those, so I'm fairly confident in answering yes.

    @spivonious: It's more than Android apps. It's also iOS apps... though the story is different for both. Android apps run in "subsystems" which I assume is a "container" model. The iOS apps are compiled for Windows. Take your existing iOS code, create a Visual Studio project for it, compile. Yeah, lots of details missing for both, but still exciting. What blew my mind is that many of us have been running an iOS app for about a year now, and didn't know. Candy Crush was put onto Windows Phone using this new system. Crazy, huh? How the hell did they keep that secret for so long?

  • Too much gloom here lately, even for my taste ;-)

    , swheaties wrote

    I didnt say they contradict.  They are not relevent.

    "Task objects via continuations is confusing for some, and the resultant code is "inside out", making it hard to reason about the behavior. THAT is what async/await solves."

    No its not.  Async await is not a different syntax for TPL or a different way of reasoning about it  (which is arguably why it is as confusing as it is).  I think continuation syntax is very sensible but thats my opinion.  Substituing await then having the compiler wrap the code in a continuation is far less intuitive - again my opinion.
    Async does not guarantee you parallelism.  Async requires you to return tasks (or awaitables - but not what you would natively return).  It requires (best practice, at least) async all the way down, and also different constructors if you want to implement the pattern completely.  Its all busy work if you ask me. My highly unscientific testing shows it slows my app down.
    Where you get the benfit if any is on your dbservice/http calls.   So why not wrap those calls in a task and just be done with it.

    No one said async/await was "a different syntax for TPL". You can think that continuation syntax is "sensible" all you want... the reality is that many (most?) developers find it confusing, and even for those that don't, when the logic is inverted it's harder to read and understand. It makes it very difficult to see the structure of the algorithm. If you disagree, that's fine, but that's purely one person's opinion... many others don't agree with you.

    No one said async guarantees you parallelism. Even threads don't guarantee you that, and async is NOT a threading concept. I find it very interesting that you argue against async because it requires you to return Tasks (awaitables, as you admit) but then argue in favor of the TPL. "Async all the way down" is best practice, yes. It's best practice whether or not you're using async/await. So, that's a red herring. Not sure what "different constructors" you're referring to... but I'm willing to bet, like async all the way down, it's not something unique to async/await. I'm suspicious of claims that async/await slows your application down. Just as I'm suspicious of people who think multithreading will speed their application up. Nothing is that simple.

  • Too much gloom here lately, even for my taste ;-)

    Those two comments are not in contradiction. If you think they are, then I'd say you don't understand async/await. As for the usefulness of async/await, I did state what it was. "Task objects via continuations is confusing for some, and the resultant code is "inside out", making it hard to reason about the behavior. THAT is what async/await solves." Not that you ever asked what the usefulness was. You just made confusing statements that you've still not explained. I can't help you if I don't understand what you're saying.

  • Too much gloom here lately, even for my taste ;-)

    @spivonious: Not exactly. The TPL doesn't have to be used at all with async/await. All that's needed is an "awaitable", which is a pattern, not a concrete interface. That said, the vast majority of the time when you use async/await today, it will be with a Task. The only exception I'm aware of is IObservable with Rx and custom awaitables that individual applications may have used... though most people aren't aware you can even do this, so there's few of those in the wild.