The cover of MSDN Magazine this month carries the main headline: “Asynchronous programming.” Inside you will find three articles about these new proposed features that will make it easier to write code that will help to create efficiencies in Visual Studio applications for asynchronous programming.
The entire article is about how it will be possible in the future to write code that does what the Magic application platform has been doing automatically for its programmers for more than 10 years. Visual Basic and C# don’t have these capabilities yet, but they will in the future the articles proclaim, but it will still require the developer to add special code and the creators of these languages are so far away from a solution that they are using the magazine to solicit feedback on the idea. Wow.
I think it is easy for those of us familiar with uniPaaS seamless efficiency through multithreaded concurrent architecture to forget that other developers must tell their programs how to handle concurrency of task execution. I remember being very impressed with the initial analogy used to explain the Magic engine and the Magic broker: the example used was that of a restaurant with many waiters and a short order cook or cooks who were working on many meals in parallel, breaking down the meal preparation into discrete steps and jumping back and forth between tasks.
At Magic Software, we talk a lot about how our advantage is a metadata driven architecture, but when you read the articles in this month’s MSDN Magazine it crystallizes some of the low-level nonsense that other developers put up with every single day without realizing that it Is a complete waste of time for them to be creating business applications in those languages (and don’t get me wrong, Java is no better). The sad thing for these developers is that they have to add lots of instructions to their code to tell the program how to process tasks concurrently. Really, in 2011 programmer drones are paid six figure salaries and still writing the same code concepts over and over again?
Thankfully, there is a smarter way to do asynchronous programming and achieve highly efficient applications without giving it a second thought. That approach is found in Magic Software’s uniPaaS application platform. Even after Microsoft finishes its "enhancements" to C# and Visual Basic (tough luck if you're using a different Microsoft language) you will still have to manually add "await" instructions to your code. And since there was no thought put into forward-migration and everyone handled concurrency differently, you will have to manually strip out all the old concurrency code. Yuck! The three articles were nice, very enlightening as to the tedium on the other side of the fence, but as for me: here’s three cheers for uniPaaS!