Aaron Stainback

Back to Profile: AceHack


  • Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask)

    More like this please. Smiley  Carl Hewitt is brilliant!!  Also thanks so much Clemens for the summation at the end, it was very helpful.  And always Erik was great; I had many of the same thoughts like tail recursion and event loops basically being the same thing.  I would love to see some specific examples of where these break down as compared to the actor model.  I still don't 100% understand the distinction in my head.  Thanks guys.

  • Using the Kinect to model your world with ​Reconstruct​Me

    Great Post!!!!! This will work great with robotics studio simulation environment!! Smiley

  • Lang.NEXT 2012 Expert Panel: Native Languages

    @dot_tom with the recent release of iOS 5 and auto ref counting by the compiler, (I'm not talking about smart pointers) Apple has a really nice story around memory management in my opinion. Even before the auto ref counting having nicely named functions to denote ownership was really nice.  I'm glad to hear I'm not the only one who really loves Microsoft but also has a fond place for Apple.  I almost felt like a traitor.  Smiley

  • Lang.NEXT 2012 Expert Panel: Native Languages

    I would like to see someone from Apple on these native talks speaking about Objective-C or any one of the native languages on the Mac.  Being a Mac and Windows developer I would love to hear about API design decisions and much of the thought process behind both Mac and Windows languages in one session.  In many ways I see Mac as being ahead on a native front and Windows being ahead on a managed front but I am by no means an expert.  I would love to see this explored further.  Thanks.


  • Lang.NEXT 2012 Expert Panel: Web and Cloud Programming (and more)

    So worth the wait.  I vote best video of channel 9 all time.  Wish there was a 10 star button.

  • Language Support for Asynchronous Programming

    I'm glad to see so many questions about async\await.  Hopefully a similar pattern will show up in other languages... hint, hint, C++ Smiley  Keep up the amazing work!!!

  • Lang.NEXT 2012 Expert Panel: Native Languages

    Yes I would love to see this video!! Smiley

  • Lang.NEXT 2012 Expert Panel: Web and Cloud Programming (and more)

    My eardrums can take it, please post Smiley

  • Windows 8 & C++

    @freefly Sorry but I disagree.  I really enjoyed this video and found his explanation of why using ^ instead of * was a very good one.  * is reserved for real pointers (which should only be used in special circumstances in "modern" C++ 11 style coding).  ^ is reserved for auto ref counted handles (or garbage collected objects in the case of C++\CLI or maybe in the future of C++\CX).  Great job and thanks for this video.

  • Mads Torgersen, Donna Malayeri and Erik Meijer: ​(Re)​Introducing Lang.NEXT

    Hey can't wait for Lang.NEXT, it's going to be great!!

  • Checking In: Larry Osterman - 26 Years of Programming at Microsoft and Counting

    , felix9 wrote

    HEROS ! Cool


    I 2nd that!

  • GoingNative 3: The C++/CX Episode with Marian Luparu

    As someone who started with VB, then C#, and then moved to C++, I can say the Managed Extensions and C++\CLI extensions were great at bridging the learning curve gap between C# and C++.  I was really writing C++ that looked almost exactly like C# at first.  Then I was able to play and learn more "unsafe" C++ features one at a time and learn the advantages and disadvantages of each in isolation while still being productive.

    After getting very familiar with the amazing optimizations available in C++ it was disappointing that the CLI extensions compiled to the slower managed code.  So I did my best efforts to only use CLI at the boundary but in conjunction with WPF and a MVVM pattern this option ran into performance issues with huge amounts of data and it was tedious to keep all the boundary code in sync with the real code.

    That is why I am very excited to see C++\CX.  Since it compiles to native code many of the performance issues will now be eliminated.  I am very excited to see that as I considered that a minor drawback of C++\CLI.  The reason I didn't consider it a major drawback was because in most LOB apps I've worked on the amount of data on the screen at once is not a lot but it really affected scientific data visualization.  The Boundary layer was slow for huge amounts of data unless extreme optimizations were done that really obscured the code and took much time.  The other part of C++\CLI and still C++\CX I still consider a minor drawback is the lack of a built convention based model like the Entity Framework code first approach.

    EF uses certain "strategies" to map object concepts to DB table "resources", using a similar approach I created T4 templates that used the C++ ISO standard API as the code first for auto generating the wrapper non ISO C++\CLI classes.  This did require that I map basically the "resource" allocation "strategies" (implicit ownership rules) of the existing ISO API so the T4 templates could be generated off convention and this declarative "resource" strategy mapping.  I'm sure this is a na├»ve approach and would not work in all situation's but I've hacked together several T4s that basically describe the implicit "strategies" behind a few specific open source C++ projects so I would not have to keep the boundary layer in sync by hand.   So when the ISO API changes so does the C++\CLI Boundary layer automatically.  I took this approach specifically in a molecular biology software project that ran both on the Mac and Windows and used several cross platform C++ open source APIs for the back end while having a WPF front end on Windows and a Cocoa front end on the Mac.

    Overall I am very excited to see C++\CX and I think it will be warmly welcomed for the design goals it was intended to serve.  It would be nice to see some additional features that built upon C++\CX like the EF\T4 "resource" strategy mapping approach.  My templates are really hacked together but their do seem to be common strategies among C\C++ API open source projects that allow for code generation based off some common generic strategies.  I'm sure a more seasoned C++ could speak more on this subject.  Anyways thanks for all the hard work, VS11 is very exciting to me.