Where/When do C# and the .NET Framework fail to be the right tool?

Question

In my non-programming life, I always attempt to use the appropriate tool for the job, and I feel that I do the same in my programming life, but I find that I am choosing C# and .NET for almost everything. I'm finding it hard to come up with (realistic business) needs that cannot be met by .NET and C#.

Obviously embedded systems might require something less bloated than the .NET Micro Framework, but I'm really looking for line of business type situations where .NET is not the best tool.

I'm primarly a C# and .NET guy since its what I'm the most comfortable in, but I know a fair amount of C++, php, VB, PowerShell, batch files, and Java, as well as being versed in the web technologes (JavaScript, HTML, and CSS). But I'm open minded about it my skill set and I'm looking for cases where C# and .NET are not the right tool for the job.

I choose .NET and C# because I'm comfortable with it, but I'm looking for cases where it isn't appropriate.

Answer 1

I've recently watched an InfoQ presentation where Neil Ford presents a Thoughtworks project that chose Ruby on Rails over .NET because of the alleged better flexibility of Rails and Ruby. Take a look there at their take on the subject.

Answer 2

I would not use C# for application that make heavy use of resources and need close acces to hardware, ie high profile computer games.

Real time applications (lets say some app that monitors the temperature in a nuclear plant, unless of course Homer simpson in runnig it) have been mentioned, but not games.

World class 3D intensive, IA Intensive games are best server by C++ (at leats the core of them), because you need to be close to the procedural paradigm and hardware, and you need to tell the computer what to do and how to do it, without anything in the middle (the CLR)

Answer 3

you've asked an interesting question.

I'll rephrase it: Why Object Oriented? And why .NET? And when not?

I suppose the thing to keep in mind is why OO is so popular. In the modern world, much of the demand for programs is essentially for business. This is why object oriented paradigms are so popular; it is often the most straightforward way to turn a business problem into a program. You basically take a look at a business, break down what the interacting parts (people, machines, places, etc) are, and write something that mimics it in code. So OO is popular because it allows you to mimic many real world situations.

.NET I suspect is popular because it seems so comprehensive. You get loads of components with it, and all you're really doing is mimicking a business issue by writing some connective tissue between these components. Add to that the fact that there's a huge community of people using it already, and the network effect speaks in .NETs favour.

Finally, when would you NOT use .NET?

If your problem is not a business problem, ie isn't merely an issue of connecting some premade components, you might need something different. For instance, if you're writing a driver for a new piece of hardware, that driver is really a layer below the business layer, because

1) It needs to work regardless of what the composition of components is used for 2) The business layer doesn't really care how it works

There's plenty of programming problems where you wouldn't use an OO model, but I suspect OO is useful because it connects all the parts (which aren't OO, like databases and drivers) to create a whole.

Answer 4

There isn't, really, all that much difference between the problem domains served by different programming languages. Rather, the choice usually comes down to

• What languages do you/your team already know you can be productive in?
• What is available in the libraries (built-in or available from elsewhere) for the language?

The answer to this question will therefore depend on you. For example, if I personally was doing a quick text processing task I'd whip it up in Perl, because I know Perl well and can do that sort of task efficiently: if you asked me to do it in C# I'd say that was the wrong tool for me, because I can do it quicker in Perl.

If you are looking to learn and diversify your programming toolbox -- which is a good idea -- then rather than asking where C# is the wrong tool, you need to ask which language is most appropriate for each task, and make an effort to learn that language better. Otherwise C# will always be the best tool for all jobs, for you.

Answer 5

London Stock Exchange was originally written in .NET http://blogs.computerworld.com/london_stock_exchange_suffers_net_crash

You can gain some insightful insights about why using .NET and any non-deterministic memory releasing apps(aka garbage collection) for that matter, does make things like real-time systems not amenable on .NET, see the following link. Humor is bonus http://tech.slashdot.org/tech/08/09/08/185238.shtml

And they ditch .NET, and chooses MilleniumIT which uses C++ http://linux.slashdot.org/story/09/10/06/1742203/London-Stock-Exchange-Rejects-NET-For-Open-Source?from=rss

For anything like volume money transactions and life matter(embedded device for car engine), you cannot let just garbage collection kicks-in randomly and incessantly

[EDIT]

Why the downvote, are there any Microsoft shills here? I just talk in general terms in which the underlying paradigm .NET was architectured in (managed and garbage collected). Perhaps if I just say that the only instances where .NET are not to be used are in car engines and machines that are connected to humans (e.g. heart pacemaker, dialysis machine), I would not get downvoted

Answer 6

C# and .NET are not the right solution if you work in a heterogeneous environment with many platforms. For all practical purposes .NET is a Microsoft-only solution (yes, I know about Mono and I stand by my statement) that locks you in to one vendor and hardware architecture. If your workplace has Macs and Linux boxes and SPARC servers and PowerPC blade servers, etc. etc. etc. then C#/.NET is not going to do you a whole lot of good.

You also have the problem of vendor lock-in. Let's say you write a server application in C# and .NET. Now let's say ARM's recent foray into server-grade components pans out and ARM-equipped server kit hits the market like a thunderbolt. If you use C#/.NET for your app you're hosed until Microsoft ports their stuff over to the ARM-based architectures (if ever -- NT once supported many more architectures than it does now: the trend is toward shrinking the Windows ecosphere, not expanding it). By locking yourself in to one vendor-specific technology you've made yourself less able to survive market shifts.

Answer 7

C# might not be a good choice for complex algorithms, especially those benefitting from parallelism, that would be better expressed using a functional language like F#.

See: https://stackoverflow.com/questions/141985/why-should-a-net-developer-learn-f

Answer 8

They move the programming paradigm away from small interoperating tools to large monolithic applications, due to the fact that their load times, minimum worknig sets and interactions with the file system are much higher than those written in compiled-to-host languages.

That's not always a bad thing, but it does mean that the highly efficient (albeit high learning curve) command-line based programming models - a la UNIX - become less used, which is a shame in my opinion.

Answer 9

C# and the .NET Framework might not be the best choice for a hard real-time application. Your application will hose on the first garbage collection, and real-time systems often have memory constraints that make the full-blown .NET framework unsuitable.

That said, there are ways around these problems, see here: http://www.windowsfordevices.com/c/a/Windows-For-Devices-Articles/Adding-Realtime-to-Windows-Embedded/