Discussions

@Bass:Can you point to a dynamically typed native language out there? Note, dynamically typed, not dynamic.

Oct 28, 2012 at 2:17 PM, wsdotnet wrote

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.

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.

2 days ago, Sven Groot wrote

*snip*

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).

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.

1 day ago, blowdart wrote

*snip*

 

Oh tosh. You could make that claim of anything that compiles to native. Speed is dependant on the compiler, the runtime, and how crappy the user's code is.

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

"How long?"
"Question of my life. If the question is when will this station be back online, two weeks, earliest. This is plasma damage. All major uplink components are fried."

13 hours ago, ZippyV wrote

https://twitter.com/id_aa_carmack/status/193480622533120001

I can send an IP packet to Europe faster than I can send a pixel to the screen. How f'd up is that?

http://superuser.com/questions/419070/transatlantic-ping-faster-than-sending-a-pixel-to-the-screen

on that hardware everything will fly, 32GB of RAM? the sweet spot for me is 16, can't stand less

"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."

18 hours ago, evildictait​or wrote

*snip*

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...)
{

  SuperDoubleAwesomePinvoke(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)
    AwesomeThrow( HRToAwesomeException(hr));
}

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

+1 exactly this, friend

weak type systems, non-optional-GC, error codes