tags:

views:

530

answers:

8

Hi, when I first saw C#, I thought this must be some joke. I was starting with programming in C. But in C# you could just drag and drop objects, and just write event code to them. It was so simple.

Now, I still like C the most, becouse I am very attracted to the basic low level operations, and C is just next level of assembler, with few basic routines, so I like it very much. Even more becouse I write little apps for microcontrollers.

But yeasterday I wrote very simple control program for my microcontroller based LED cube in asm, and I needed some way to simply create animation sequences to the Cube. So, I remembered C#. I have practically NO C# skills, but still I created simple program to make animation sequences in about hour with GUI, just with help of google and help of the embeded function descriptions in C#.

So, to get to the point, is there some other reason then top speed, to use any other language than C#? I mean, it is so effective. I know that Java is a bit of similiar, but I expect C# to be more Windows effective since its directly from Microsoft.

The second question is, what is the advantage of compiling into CIL, and than run by CLR, than directly compile it into machine code? I know that portability is one, but since C# is mainly for Windows, wouldn´t it be more powerfull to just compile it directly? Thanks.

A: 

First answer: C# should be used by default for new projects. There are a few cases where it hasn't caught up yet to C++ (in terms of multi-paradign support), but it is heading in that direction.

Second answer: "portability" also includes x86 / x64 portability, which can be achieved by setting the platform to AnyCPU. Another (more theoretical at this point) advantage is that the JIT compiler can take advantage of the CPU-specific instruction set and thus optimize more effectively.

Stephen Cleary
I disagree with your first sentence, you're saying it far to generalized. There are reasons *not* to use C#, and it's completely project dependent.
Bobby
Right, but the default choice should be C#. Unless there is a project-specific reason not to. That's what I meant.
Stephen Cleary
No, not if you make product software, or web applications, or have a different target than a windows pc, or need to scale,...
Stephan Eggermont
All .NET languages are practically equivalent, with the exception of the dynamic languages. I have scalable solutions in C#, including web apps, mobile devices, and Silverlight. Given the op's prior experience (C and C#) and question (whether to default to C# or C), I believe I gave a good answer. I'm not saying that F# is evil; just probably more than the op wants to bite off for now.
Stephen Cleary
+10  A: 

1 - diff languages have their pros and cons. There are families of languages (functional, dynamic, static, etc.) which are better for specific problem domains. You'd need to learn one in each family to know when to choose which one. e.g. to write a simple script, I'd pick Ruby over C#

2 - Compiling it to CIL: Portability may not be a big deal.. but to be precise Mono has an implementation of the CLR on Linux. So there. Also CIL helps you to mix-and-match across languages that run on the CLR. e.g. IronRuby can access standard framework libraries written in C#. It also enables the CLR to leverage the actual hardware (e.g. turn on optimizations, use specific instructions) on which the program is run. The CLR on 2 machines would produce the best native code from the same IL for the respective machine.

Gishu
+2  A: 

I'm not sure that C# is more effective only because is a Microsoft product. If you use the Visual Studio, or other RAD, some of the code is auto-generated and sometimes is less efficient. Some years ago I was a dogmatic, thinking only C can response all our prayers :-P , but now I think virtual machines can help a lot in the way to optimize code before to execute it (like a RDBMS), storing in caché pieces of code to execute later, etc. Including the possibility to create "clusters" of virtual machines as Terracotta does. At least the benefits of having an extra abstraction layer are bigger that don't have it.

ocell
What's RDA? Rapid Development ? or?
kenny
@kenny LoL... excuse me! RAD (Rapid Application Development)
ocell
+5  A: 

Language and platform choice are a function of project goal. It sounds like you enjoy system level programming, which is one of the strong points of using C/C++. So, keep writing systems level code if that's what you enjoy.

Writing in C# is strong in rapid business application development where the goals are inherently different. Writing good working code faster is worth money in both man-hours and time to market. Microsoft does us a huge favor with providing an expressive language and a solid framework of functionality that prevents us from having to write low level code or tooling for 95% of business needs.

spoulson
+5  A: 

One important advantage of IL is language independance. You can define modules in project which should be done in C++, some in C# and some in VB.net. All these projects when compiled give respective assemblies(.dll/.exe). This you can use the assembly for C++ project in the c# one and vice versa. This is possible because.. no matter which language (.net supported) you choose.. all compile to the same IL code.

Chinjoo
+1  A: 

I agree with spoulson. C# is really good at solving business problems. You can very effective create a framework that models your business processes and solve many of those problems with object orientation and design patterns. In that respect it provides much of the nice object oriented capability that C++ has.

If you are concerned with speed, C is the route to go for the reasons that you stated.

David Robbins
+1  A: 

Further on the second question: you can run NGEN to generate a native image of the assembly, which can improve performance. Not quite machine code, but since it bypasses the JIT (just-in-time compile) phase, the app will tend to run much faster.

http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.

code4life
+1 I wasn't aware that this existed. Have you used this in production and what improvements did you see?
David Robbins
A: 

"is there some other reason then top speed, to use any other language than C#?"

I can think of at least four, all somewhat related:

  • I have a a large current investment in 'language X', and I don't have the time or money to switch to something else. (Port an existing code base, buy/acquire/port libraries, re-develop team skills in C#, learn different tools.)
  • An anticipated need to port the code to a platform where C# is not supported.
  • I need to use tools that are not available in C#, or are not as well supported. (IDE's, alternate compilers, code generators, libraries, the list goes on and on...)
  • I've found a language that's even more productive. ;-)

"what is the advantage of compiling into CIL, and than run by CLR, than directly compile it into machine code?"

It's all about giving the runtime environment more control over the way the code executes. If you compile to machien code, a lot becomes 'set in stone' at that time. Deferring compilation to machine code until you know more about the runtime environment lets you optimize in ways you might not be able to otherwise. Just a few off the top of my head:

  • Deferring compilation lets you select instructions that more closely match your host CPU. (To use 64-bit native instructions when you have them, or the latest SSE extensions.)
  • Deferring code lets you optimize in ways you might not be able to otherwise. (If you have only one class at runtime that's derived from a specific interface, you can start to inline even virtual methods, etc.)
  • Garbage collectors sometimes need to insert checkpoints into user code. Deferring compilation lets the GC have more control and flexibility over how that's done.
mschaef