Is such a thing even possible? Let's find out.

Last time I tried to talk about .Net, certain somebodies felt the urge to bring up how things "didn't look native" when running .Net apps in Linux and shit, then kept focusing on that.

So let's limit ourselves to the internal parts. The .Net runtime, or very adequate alternative implementations (it IS a published and standardized thing after all) can run on a reasonable amount of different machines. Perhaps not so much as its older sister Java, but plenty.

Which, just as an aside, brings me to mention that Java's Swing doesn't look native either, so if you're gonna whine about Winforms anyway, take it both ways please.

At any rate, let's talk about the CLI, shall we? Or, if you prefer, other systems like it, such as Java, or dare I suggest, SCI.

That quote is truth.

But hey, you could write .Net code in raw assembly if you wanted to. It's just, the important thing to remember is that it's stack-based.

add eax, edx ldloc.0 ldloc.1 add stloc.0

One is x86. The other is CIL. As far as this specific example goes, it's still pretty straightforward, and the CIL is usually converted to the target platform anyway at runtime, block by block, so you end up with the x86 line after all.

I certainly found removing the Corruption from my copy of Terraria easy enough.

Edit: oh and there's a tool to compile the whole damn thing directly to the target platform, makes it go faster in the long run.

Well, then you should also be able to use C#. They all share the same base class library, except VB.NET has some extra things like "My" I think, and IMHO, it's closer to C# than it is to VB Classic.

Are there any other reasons to call it "convenient"?

Stupid arguments are exactly what I wanted to avoid in this thread so I'm pleased to hear that.

And yes, C++/CLI is just odd.

See, I could go into how actually using the actual native controls is the only way to get an actually native look and feel, but that's exactly what this is not supposed to be about. So thank you, Niko, for that.


Now, let's try to fix this. VB.Net had optional parameters (you all know what those are, right?) but C# didn't until version 4. According to the developers' blogs, this was because they needed time to properly define the behavior of that functionality, which sounds like a pretty good reason for delay to me. There are simple usage cases where the "correct" behavior is blatantly obvious, but then there's also complicated scenarios. And those are the cause of the delay.

Because on the CIL level, there's no such thing -- C# 4.0's optional parameters are filled in at compile time:

void MyFunction(int i, int j = 4) { ... }

MyFunction(2, 3);
MyFunction(2); //compiles as MyFunction(2, 4)

And that's why you can use the 4.0 compiler, set to target the 2.0 runtime, and still use things like var and optional parameters.

Ain't that a cool thing.

Basically, they probably do. It's just, VB Classic already had it so they were pretty much forced to do it from day one.

It could've been a CIL-level function, but that would just open a whole 'nother can of worms.

You guys seriously gonna persist on the whole native looks bullshit?