C# for Technical Programming: Should I Learn?

[dimensionless]

and if yes, are you using for technical programming? I was considering learning some C#, so my programming skills don't become obsolete, but I'm not so sure that everything in scientific programming will go the C# direction.

 

[shoehorn]

Not for technical or scientific programming, no. It is quite a useful skill, but it's pretty much a non-starter in terms of serious, technical applications at the moment because:

• The CIL/CLI layer puts yet another level between you and the bare metal; for HPC applications, this is not what you want.
• Despite what the Mono people will tell you, it's essentially Windows-only at this stage.
• There are vast amounts of perfectly good C/C++ code out there for scientific and technical computing. Don't expect to see this code supplanted in favour of C# any time soon.
• C++0x, which is now essentially finalized, is beautiful. In the long run, being competent with the new specification will be more useful to those looking to program for scientific applications than knowing C#.
• Being an excellent C++ programmer is a significantly more lucrative skill than being an excellent C# programmer.

 

[-Job-]

Shoehorn, you're obviously talking about client based applications, for server-based applications C# or even Java is much more popular than C++.

Since there's a clear shift in the industry underway for moving to server-based applications and cloud computing with thin clients, personally i wouldn't pick C++ over Java or C#.

 

[CRGreathouse]

I like C# a lot, and it's certainly growing in popularity. I use it more than C (or C++). But I agree with shoehorn: it's not really for scientific computing. I downloaded a port of a CNF solver in C#,and the documentation mentioned that it runs about 4 times slower than the native C++ version. With careful C# optimization I imagine it could be made to run only 3 times slower, but probably not as fast as twice as slow. I think this is typical for high-performance computing.

 

[Hurkyl]

Also, for interfacing with high performance code, you can use a language like python in which programming is much simplier. Python itself is a slow language, but you won't be using it for anything that needs to be fast -- the heavy lifting would be done through interfacing with libraries like numpy or sage... or through its C/C++ interfaces.

 

[shoehorn]

Shoehorn, you're obviously talking about client based applications, for server-based applications C# or even Java is much more popular than C++.

I'm talking about scientific/technical computing, which is what the question was really about.

Since there's a clear shift in the industry underway for moving to server-based applications and cloud computing with thin clients, personally i wouldn't pick C++ over Java or C#.

Well, I'm not sure how this is related to scientific/technical programming that we're talking about in this thread but let me say this: "cloud computing" is, at this stage, nothing more than marketing hype. And to be frank, I don't see that changing any time soon.

 

[CRGreathouse]

Well, I'm not sure how this is related to scientific/technical programming that we're talking about in this thread but let me say this: "cloud computing" is, at this stage, nothing more than marketing hype. And to be frank, I don't see that changing any time soon.

I don't agree with that at all. Google has been using cloud computing (internally) since before the term, to great effect. And Amazon monetized it fairly effectively.

But then I don't really think of C# as a major cloud computing language, so I suppose we agree that the use of C# in the cloud is not a major factor at the moment or in the near future.

 

[-Job-]

Shoehorn, i saw your points 2 and 5 and saw it as an argument for why C++ "is better than" C#, i should have read the whole thread, my bad.

In any case, just because you're using Java and C# doesn't mean that you can't make use of C++ libraries (same as in Python).

And i don't understand why you're calling Cloud Computing "marketing hype".

 

[-Job-]

But then I don't really think of C# as a major cloud computing language, so I suppose we agree that the use of C# in the cloud is not a major factor at the moment or in the near future.

I don't mean that C# or Java or even Python are Cloud Computing languages, except that some of the disadvantages associated with these languages can be reduced in server environments. You can compile natively and in the case of C# also don't have to worry about portability (while enjoying the benefits of Java, C# or Python).

 

[CaptainQuasar]

I'm an experienced C# developer, but I don't have experience in scientific computing applications. I think everything everyone's said here about C# is true except for this one:

Despite what the Mono people will tell you, it's essentially Windows-only at this stage.

Some of the fancy stuff like Mono's version of Silverlight for web applications or really Windows-specific things like the interfaces to Windows Performance counters that tell you how many threads are running, etc. aren't finished (so in Unix you have to parse the /proc/meminfo device file as though you're writing a Unix app normally), and you usually need to start developing on Mono to make sure that you don't accidentally use any proprietary Microsoft libraries that aren't part of the C# spec (which Visual Studio wizards love to stick in) but the core language itself and well over 90% of the System namespace libraries are implemented through version 2 of the language (which is all I really use, I know they've put a lot of work into C# 3 but I don't keep tabs on that.)

So far I think every time I've swiped a sample written in Windows off of a developer website the code itself has compiled and run on Linux unmodified. (The IDE is another story; their project file converter doesn't work sometimes and you have to create a new project from scratch and add the source files manually. But I like MonoDevelop, it has all of the features I ever actually use in VS and it runs a heck of a lot faster than Visual Studio or something like Eclipse.) The binaries the Mono compiler produces are cross-platform; I can write an application on my Windows machine and FTP it up to a Linux server and it runs there.

It's certainly not as mature as Java (decrepit, perhaps? :*) Just kidding, I wish I had many of the things available for Java in Mono) but it's definitely cross-platform.

⚛​

 

[shoehorn]

I don't agree with that at all. Google has been using cloud computing (internally) since before the term, to great effect. And Amazon monetized it fairly effectively.

My apologies, I should have clarified what I meant. Firstly, everything I've said in the thread to this point has been on the understanding that we're talking specifically about those areas of scientific/technical computing that the OP was interested in.

Secondly, the point I should have made is that there is a difference between a product or strategy being ready to be implemented by companies that have hundreds/thousands of developers and massively liquid capital (not to mention the ability to allocate that capital in innovative ways), and a product that can be implemented or used by "everyone." While Google, Amazon, and others have focused impressive amounts of resources towards cloud computing, there are many, many areas where I think it's a non-starter.

For instance, most of my development experience is in the hedge fund/banking industry. While there are obviously ways in which the financial industry can (and do) make use of cloud computing, the "nuts-n-bolts" stuff is totally unsuited to that approach. Unfortunately, this doesn't seem to be understood by those companies who used regularly contact me to tell me how cloud computing could be used to great effect in our hedge fund.

Again, apologies if anyone took this as a slight on the model itself; I'm simply trying to limit the discussion to the scientific/technical computing areas that the OP was interested in.

Some of the fancy stuff like Mono's version of Silverlight for web applications or really Windows-specific things like the interfaces to Windows Performance counters that tell you how many threads are running, etc. aren't finished, and you usually need to start developing on Mono to make sure that you don't accidentally use any proprietary Microsoft libraries that aren't part of the C# spec (which Visual Studio wizards love to stick in) but the core language itself and well over 90% of the System namespace libraries are implemented through version 2 of the language (which is all I really use, I know they've put a lot of work into C# 3 but I don't keep tabs on that.)

This is why I said it's "essentially" Windows-only at the moment. Portability of code is all well and good in theory, but my experience is that when people are in making money from their code portability rapidly disappears as a design goal. Unfortunately, this often results in the use of Microsoft components that aren't available to developers on other platforms.

I do, however, take the broader point that Mono has made great progress over the last couple of years.

 

[CaptainQuasar]

This is why I said it's "essentially" Windows-only at the moment. Portability of code is all well and good in theory, but my experience is that when people are in making money from their code portability rapidly disappears as a design goal. Unfortunately, this often results in the use of Microsoft components that aren't available to developers on other platforms.

But if you access one of those proprietary Microsoft libraries through any language, including Java, your code is going to be Windows-only. It's definitely possible to make stupid or short-sighted choices that impede portability in Java and makes an app Unix-only or Windows-only, too - I've worked at companies that have done exactly that.

And what you highlighted above is something the IDE does, anyways - that doesn't have anything to do with the language or the VM that runs the code. Java developers only wish they had just one standardized IDE they could use to make excuses.

I do, however, take the broader point that Mono has made great progress over the last couple of years.

Oh, yeah. If your last experience with Mono was two years ago, it's radically different now.

⚛​

 

[CRGreathouse]

My apologies, I should have clarified what I meant. Firstly, everything I've said in the thread to this point has been on the understanding that we're talking specifically about those areas of scientific/technical computing that the OP was interested in.

Secondly, the point I should have made is that there is a difference between a product or strategy being ready to be implemented by companies that have hundreds/thousands of developers and massively liquid capital (not to mention the ability to allocate that capital in innovative ways), and a product that can be implemented or used by "everyone." While Google, Amazon, and others have focused impressive amounts of resources towards cloud computing, there are many, many areas where I think it's a non-starter.

Ah. Then I totally agree with you. I will make one minor point, though: cloud computing isn't all about the big guys. I used Google as an example of a big company approach (use cloud computing to do amazing things for your company), while Amazon's model is an example of how little companies can use cloud computing (buy some time on Amazon's machines).

 

[-Job-]

Google has recently introduced AppEngine for scalable server-based apps. It's free with a paying option that offers more guarantees (it's basically a typical web host, except that it uses a non-relational database, only supports python apps, and scales well).
This is pretty much their cloud computing service.

I have a very general view of cloud computing that encompasses any software-as-a-service application, independently of how it's implemented, and there's lots of SaaS providers emerging (SalesForce leading this).

 

[CRGreathouse]

Google has recently introduced AppEngine for scalable server-based apps. It's free with a paying option that offers more guarantees (it's basically a typical web host, except that it uses a non-relational database, only supports python apps, and scales well).

Actually, the fact that Google's service doesn't support anything but python was one of the reasons that I suggested C# wasn't a major player in cloud computing.

 

[-Job-]

Actually, the fact that Google's service doesn't support anything but python was one of the reasons that I suggested C# wasn't a major player in cloud computing.

Ok, but two points on that:
1. The fact that python (which is not the best performing language) is being used in Cloud Computing implementations shows why, in the future, you may not find yourself doing a lot of C++, and this is why i would pick Java or C# to learn (over C++).
2. Cloud computing is not really associated with one language or another, but in the same way that Python's disadvantages can be minimized in a server environment, so can C# and Java, which makes them, in my opinion, more viable than C++. Not that i see them as Cloud Computing languages. In fact i heard Microsoft is introducing a functional language to .Net, called F#, which i suspect might be sold as "better suited" for Cloud Computing apps.

 

[Coin]

A note on portability: It is true that it is very rarely that portability is ever truly a requirement for any given application, no matter how philosophically nice the idea may seem. However, portability is an issue which is larger than just whether you can port your application. Think about, for example, the portability of your skill set. A big problem with a platform-locked language like C# is that as you gain expertise and background in the language, you are learning things whose future is in a certain way shut off. C# skills will be transferable, but only to things within the Microsoft sandbox; the more you use something like C#, the harder it will be to later switch back to using other things. A related problem is that of code reuse. You are unlikely to port most apps to another operating system or language, but what if you want to take just this one useful routine and reuse it in a later program? Well, that later program had better be running somewhere where hooking into the CLR is not a problem...

-- -- --- -- --

I would like also to make a note about the use of C# for high-performance programs. Although I would agree that you will eventually find yourself unhappy if you try to start a high-performance program in C#, it is worth noting that C# has an actually very nice interoperability layer that allows you to link native C++ code into your C#/CLR program. I do not remember exactly what this is called but I believe the most recent version of this goes under the name "Interop" or "InteropServices". You can put the C++ code into a DLL and then simply call your DLL's functions and classes from inside the C# program. So something that would be possible and very likely even desirable (if you are writing a windows application) is to write a program whose GUI is written in C# and whose "guts", whose inner loops, are written in C++. At this point you are basically doing what Hurkyl suggests, only using C# as your high-level language which interfaces with the low-level C++.

There are only two downsides to this approach. The first is that although the C#->C++ interop layer is extremely easy to use, it is also extremely slow and EXTREMELY difficult to optimize. If you are going to use C# interop you want to make absolutely certain (and the docs say as much) that interactions between C# and C++ are (a) not that frequent and (b) do not involve large data transfers between C# and C++ code. If you have a nice GUI written in C#, and your interactions with C++ code are limited to when you click a button it calls a C++ function and then a minute or so later the C++ code burps out the results of the computation for the C# code to display, then you will be very happy with the performance of this setup. But if the C++ code is continuously producing some sort of live data which the C# code that runs the GUI must graph 30 times a second, you will become very miserable very quickly.

The other downside to this approach is that it is not necessarily an argument in favor of C# specifically. "Interop" is essentially a feature of the CLR/.NET, not C#, and therefore any CLR/.NET language can use Interop too. This includes Python.NET, which runs inside the CLR alongside C# just as if it were C#. You could just as well write your .NET GUI in Python.NET and your inner loop / high performance code in C++, use Interop to communicate between the two, and there would be downside to this I am aware of as compared to having written in C# itself-- plus there would be the advantage that your python code and expertise would be (aside from direct calls to .NET API functions) portable outside of CLR/.NET, whereas C# code would not.

 

[-Job-]

Java also has interopterability capabilities provided by the Java Native Interface - allows you to mark methods as native and point them to C/C++ libraries for example. In Python you can actually write modules in C++.

By the way, i though this was cool, in GWT you can actually point Java native methods to javascript - by writing the native method declaration and following it with the javascript code in comments.

 

[CRGreathouse]

In fact i heard Microsoft is introducing a functional language to .Net, called F#, which i suspect might be sold as "better suited" for Cloud Computing apps.

Microsoft seems to be pushing F# pretty hard. I don't think it has legs.

 

[CaptainQuasar]

My note on portability: IKVM.net is an open source project that implements a Java Virtual Machine in .NET itself as well as an API for interfacing to a running Java application. So you can write Java apps, compile them to bytecode, and then compile those binaries into your .NET dlls.

Obviously that's not anything that's going to boost performance - but my point is that if you know what your options are and you've been careful in your architecture planning (or even sometimes if you haven't) you can get pretty far with code re-use. IKVM.net is just an open-source version of this too, which is tested and shipped with Mono as it happens; there are at least a couple of commercial products that work the same way.

Similarly there are all kinds of cross-compilers out there: to compile C# into JVM bytecode or conversely Java into MSIL for running on the CLR, like J# (though I understand that many of the commercial products out there are way better than J#, which is sort of a free afterthought from Microsoft.)

Another note - again I'm not experienced in HPC or the cloud-computing type stuff, but there do seem to be some relatively heavy-duty applications of .NET going on. http://tirania.org/blog/archive/2005/May-30.html" .)

Second Life, for another example, found three years ago that a port of their server-side scripting engine (which is used by the SL members or players or whatever; almost every object in the SL world has scripts attached to it) to Mono http://blog.secondlife.com/2005/11/15/mono-lsl2/".

Here's a http://tirania.org/blog//archive/2008/Aug.html" from Miguel de Icaza, who is sort of an open source demigod and who is one of the heavies on the Mono project who consulted for Second Life:

I find the SecondLife technology fascinating. Embedding Mono into SecondLife was not an ordinary task, it was not just a matter of linking with Mono and writing an LSL to CIL compiler.

SecondLife distributes the virtual world on hundreds of servers, and as visitors move through the virtual world, their inventory, character and scripts migrates from server to server.

This migration requires that running scripts be suspended, serialized to a database and their execution resumed on a different server. This means that all the state of a script, including the current location must be preserved while the user navigates across servers.

 

[mheslep]

Also, for interfacing with high performance code, you can use a language like python in which programming is much simplier. Python itself is a slow language, but you won't be using it for anything that needs to be fast -- the heavy lifting would be done through interfacing with libraries like numpy or sage... or through its C/C++ interfaces.

+1 python, numpy, scipy, matplotlib et al for almost any kind of scientific computation work.