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


BitFlipper BitFlipper
  • Do you find the Win 10 build 10122 "Hoth" theme to your liking?

    First they remove the borders and only the active window has a drop shadow. Then suddenly all windows have a drop shadow and the active window has a more pronounced drop shadow (btw why add them back at all? Drop shadows are skeumorphic - blasphemy. Maybe they realized some of it actually had a real purpose - surprise!). Now we discover drop shadows alone are useless when you have a dark background. Oops, back to the drawing board...

    This is what you get when you have UI designers that no longer have a clue what they are doing. I've seen so many iterations of them trying to make a mobile UI work on the desktop that it is clear they are completely directionless. At this point it has degenerated into simply throwing spaghetti at the wall to see if anything works.

    Did anyone really complain about the Win 7 UI, which itself is a product of ~25 years of careful UI refinement. Enough complaining that we instead needed to end up with this disaster?

    Seriously, these are not the kinds of discussions we should be having with a desktop OS that has already been hugely successful over a long period of time.

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

    , PerfectPhase wrote


    Yep, they said while you should use the aync methods as a default, they are putting back no-async methods to make porting easier.  Same with Ex methods, they're adding non-Ex versions back for back compat.

    I watched the video and it is good news that they are putting non-async methods back.

    However I don't buy the part that it was done to help with backwards compatibility. That is just BS. You can convert any async/await into a sync function by simply adding ".Result" to the end. Much more likely is that someone woke up and noticed the significant overhead it adds.

  • Windows 10 (metro?) is butt-ugly

    , Jim Young wrote


    ^^ This

    Wow, do you people really think the amount of complaining and backlash is par for the course? WAKE UP!

  • Windows 10 (metro?) is butt-ugly

    , kettch wrote

    Who wants to start a pool on what the next gripe thread will be? We've covered updates and icons. I'll go for the default desktop background next.

    I'm not going to start a thread myself, but I'd imagine it would be about something else that is now broken/fubarred/uglified/dumbed down in Windows. Some people work all day in Windows, so this is important for those people.

    It's interesting how some people just want to stick their fingers in their ears and ignore negative feedback. Negative feedback is still feedback, and if the negative feedback keeps growing and it keeps being ignored then this can't possibly end well for anyone. Believe it or not, I think most of the people complaining want Windows to succeed.

    But OK fine, let's all sing along now... "lalalalala...."

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

    Async/await is definitely a nice construct, but it really shouldn't be forced into everything. It solves UI/web/database problems for people that don't know how to code, but causes other problems if forced into places it should not be in.

    Briefly, the problem I have is that it was forced into the storage APIs for WinRT, meaning there is no non-async/await way to read a file. You have StorageFile.ReadAsync, but not StorageFile.Read. As my performance tests clearly show, this has a huge impact on IO performance.

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

    , wkempf wrote


    I'm suspicious of claims that async/await slows your application down....

    You no longer need to be suspicious: Here, starting around page 4, I posted benchmark code that shows how async/await kills performance. You are more than welcome to run the code yourself and then either explain how those benchmarks are flawed, or accept that async/await has a significant effect on performance.

    "Async all the way down" is only best practice if all your application does is some UI updating, not if you actually want to do something that requires real performance.

  • Windows 10 (metro?) is butt-ugly


    I guess complaining about something you used to love that is now degrading into a cringeworthy pile of bile qualifies as trolling these days.

  • Windows 10 (metro?) is butt-ugly

    I think in 20 years from now we will point and laugh at this failed experiment. Kinda like we do with MS BoB. One of two things would have happened by then:

    1. MS became irrelevant and another company is ruling the desktop.
    2. Someone with enough power at MS got a clue and replaced whatever there is now with some real leaders.
  • Google Surface

    The YouTube link seems to be broken.

  • Why can you do this with Java but not with C#?

    You might be able to do this with a VS plugin. The plugin would do something like this:

    1. Detect when the user wants to compile new changes (maybe via a special "Compile" button that the plugin provides).
    2. Put a temporary breakpoint at the 1st line that was modified (it keeps track of changes in documents).
    3. Once stopped in the debugger, remove the temp breakpoint and issue a Run, which will use E&C to compile and then run the program again.

    The biggest problem, which may not be surmountable, would be to allow edits to be made while the application is running. VS prevents edits from being made while running, but maybe there is a way for the plugin to make the current document editable, not sure.

    Of course the other problem is that E&C doesn't support 64 bit code, not sure when/if that will be fixed.