LOL! Charles, Mark actually made you speechless at many points during the interview, including the very end. He's a real hard core technical dude to talk to, isn't he and I see you really respect him as do we all!
You're wearing microphones that actually work and whoever did the soundwork on this video actually knew what they were doing for a change (or read up on how to do it properly since the last video ). Congrats, I can finally hear you!
On a negative note, it's not nice to cut the guy off mid sentence, I mean going a few seconds over the buzzer with some closing words is OK - you guys don't have to take the time limit THAT literaly. So, some more constructive (I hope) criticism for you...
Why is the audio so quiet and distorted during various points? Come on guys either put microphones on or get a decent microphone to record the session. I have to turn the volume up to ungodly levels just to be able to make out what you are saying. Then,
after I do that, there's clipping going on during some of what you are saying...
What this example showed is that those same "subgroup of senior specialists" will be responsible for writing the bodies of the parallel for statements, to make sure that no race conditions sneak in. So, in the end, does this really solve the problem or just
make it easy for people who don't know how to write concurrent code think that it is now easy to do so (with parallel_for)?
Also, how will the PPL and all of the mumbo-jumbo (i.e., Concurrency Runtime) it sits on handle parellizing code in multiple concurrent processes? Or, are we supposed to, from now on, run only a single "parallelized" process on a multi-core host?