@Bass:Can you point to a dynamically typed native language out there? Note, dynamically typed, not dynamic.
It's kind of difficult to devise any actionable plans with something as generic as that, clearly everything isn't broken. Is there anything I can do on my end to experience the behaviors you're seeing? Which language and editor is it? What stops working? It would help a lot with a set of minimal reproducible steps, Connect is also a great place to leave feedback or bugs.
Just venting here BTW.
Ever sense i first used VS 4, well VB4 at the time, up until Visual Studio 2010. Things have been getting better, things just work.
But with VS 2012 this thing a joke, its buggy and slow. But i guess that's what happens when a dev team focuses on changing colors and icons instead of working on real features.
Intellisense stops working, auto formatting stops, things that worked before just stop working out of the blue and new things like search stops being clickable.
Maybe its just me but this lately all of Microsoft's major products just feel like there getting worse not better.
Based on research made by folk at the LLVM, it seems that the include system is the main offender, with modules they proved the the compilation time can be greatly reduced. The include system is flexible, and for any project you could probably find the optimal structure that yields the optimal compilation times, but not without sacrificing maintainability and readability.
There are several reasons for this. Most importantly, C++ is a far more complex language (grammar wise) than C# so it takes longer to parse (particularly thanks to templates, which are a Turing-complete compile-time language), and the C++ compiler performs far more extensive optimizations (in the .Net world, most optimizations are performed by the JIT, so the work of the C# compiler is relatively light).
sure, but C++ is also one of its kind with the not paying for what you don't use philosophy, being native doesn't necessarily mean control or speed given high enough abstractions
I can send an IP packet to Europe faster than I can send a pixel to the screen. How f'd up is that?
"I will not sacrifice the Enterprise. We've made too many compromises already; too many retreats. They invade our space and we fall back. They assimilate entire worlds and we fall back. Not again. The line must be drawn here! This far, no further! And *I* will make them pay for what they've done."
+1 exactly this, friend
That's a bit unfair. The Win32 apis were built with needing to propagate errors across different language barriers (i.e. so you could create MyAwesomeProgram in VB or Pascal or Fortran rather than being forced to use C/C++ in order to interoperate with the Microsoft libraries written in C/C++).
You can't unwind an exception over someone else's code (because you don't know how they are compiled), so you can't use exceptions, heap-pointer based exceptions (like C++) are also bad because it restricts what you can throw (i.e. you can't throw an out-of-memory exception if you'd need to allocate an OOM exception to throw one)
You also can't intern stuff like Java and C# because you don't have a common runtime (because some of the code in the process is Win32 C/C++, some is MyAwesomeProgram.vb and a third party component it is using is in delphi pascal, all interacting with a lovely frontend written in flash).
So sadly Microsoft only has one thing left: A global enum of all possible errors, i.e. HRESULTs.
Basically what I'm saying is that HRESULTs are dirty, but that's because they're intended for crossing language or API boundaries. Microsoft never intended or expected you to use them internally. They expected you to write code like this:
MyAwesomeVoid MyAwesomeFunc(AwesomeParam1 awesomeParams...)
And your runtime would do something like:
void CallOut( std::vector<AwesomeStuff> awesomes )
IEnumerable<void*> nativePtrs = map(awesomes => native);
HRESULT hr = Win32Api(nativePtrs);
if(hr != S_OK)
In fact, that is pretty much exactly what C#/VB.Net is doing under the hood.
It's not the fault of HRESULTs that they are crappy. It's the fault of developers for daring to attempt writing code in anything other than the glorious language of C/C++. If all developers could agree to only ever use C++, I'm sure Microsoft would be happy to dump HRESULTs and move to std::exceptions