Related
I've had a look at the article http://slodge.blogspot.co.uk/2013/06/ioc-and-servicelocation-in-v3-brain-dump.html about "IoC and ServiceLocation in v3".
Everything's clear there. However, what's about this logic performance?
As usually Reflection is used for such types of stuff (I assume MvvmCross does it as well). And everyone (at least, more or less experienced developer) knows that reflection is performance's "evil".
So, as I understand, the framework goes through all the classes in app (probably, Core assemply only) and finds the ones which need to be injected etc, right?
I am sure that that's ok in small projects and also is not sufficient for such projects like web ones (long time on startup), but what's about Mobile applications (which usually has much more limited processor power and the startup time is critical for users)? Have you had any thoughts on that? How do you evaluate relationship between "convenience of development" and "first time performance reduction" in that meaning?
Thank you.
General answer
The MvvmCross philosophy on performance is:
we make development more convenient so that developers can make more delightful apps
we're aware that parts of the platform do add a level of overhead - but we've worked hard to make sure it isn't a large one
we give the developers tools to build decoupled views, viewmodels and components - we think this allows the developers to write more efficient and more robust components
because we allow the developers to build decoupled components, then if/when they hit performance problems, then we believe this makes them much more able to optimise where and when they need to.
because we provide a platform for reuse, we believe developers will be more able to develop and use better components - e.g. because developers can reuse our table/list adapters they don't have to fix and optimise new table/list adapters in every single app
we've worked hard to make sure almost everything can be overridden in the platform so that you can optimise later if you need to - if your app wants to hand-tune IoC registration it can - your app doesn't have to use reflection.
we think that .Net (both Microsoft and Mono versions) also helps with making apps more performant through:
efficient memory management
libraries like linq and the TPL
the TPL coupled with compiler tools like await/async
providing native access via PInvoke when needed
Of course, if you absolutely need to hit some <200kB package size limit you won't be able to use MvvmCross; and, of course, even with the best tools in the world, developers can still make badly-performing apps... but we position MvvmCross to help good developers make delightful cross-platform apps.
Technical points
limited processor power
A modern mobile platform has:
2 to 8 CPU cores, each running at > 1GHz
1+GB of fast RAM
16+GB of very fast storage (Flash)
This is hardly limited - it's faster and more powerful than PCs were 10 years ago.
everyone ... knows reflection is performance's "evil"
Sorry - I don't think you are correct.
The people I work with are aware that Reflection introduces a small overhead, but it doesn't dominate our performance considerations.
I agree more with Donald Knuth who said:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"
From http://en.wikipedia.org/wiki/Program_optimization
This is especially the case in apps/projects/products which have many releases - in tightly coupled projects small optimisations created for v1 can often cause serious performance issues by the time you reach v10 or v11 where changes in the platform cause the 'old code' to be executed in 'new patterns'.
If anyone is really into micro-optimisation, then it's also worth noting that MvvmCross uses things like lots of methods marked virtual, lots of small interfaces/objects and string formatting using "{0}{1}" type patterns - all of which could be optimised if anyone really wanted to.
Ok. After some discussion I guess there is a sense to summarize.
I consider the answer as:
There are no any problems with performance when using MvvmCross in usual apps development, however, due to mentioned above technologies used in the framework building and because of the first aim of that framework was development process convenience, there is a chance that applications structure growing can influence their performance (rather speaking of the app launching).
In this cases there is an ability to override some logic with using own optimized approaches to solve possible problems.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Over the last few years F# has evolved into one of Microsoft's fully supported languages employing many ideas incubated in OCaml, ML and Haskell.
Over the last several years C# has extended its general purpose features by introducing more and more functional language features: LINQ (list comprehension), Lambdas, Closures, Anonymous Delegates and more...
Given C#'s adoption of these functional features and F#'s taxonomy as an impure functional language (it allows YOU to access framework libraries or change shared state when a function is called if you want to) there is a strong similarity between the two languages although each has its own polar opposite primary emphasis.
I'm interested in any successful models employing these two languages in your production polyglot programs and also the areas within production software (web apps, client apps, server apps) you have written in F# in the past year or so that you would previously have written in C#.
I have written an application to balance the national power generation schedule for a portfolio of power stations to a trading position for an energy company. The client and server components were in C# but the calculation engine was written in F#.
The use of F# to address the complexity at the heart of this application clearly demonstrates a sweet spot for the language within enterprise software, namely algorithmically complex analysis of large data sets. My experience has been a very positive one. In particular:
Units of measure The industry I work in is littered with units. The equations I implemented (often of a geometric nature) dealt with units of time, power and energy. Having the type system verify the correctness of the units of the inputs and outputs of functions is a huge time saver, both in terms of testing and reading/understanding the code. It eradicates a whole class of errors that previous systems were prone to.
Exploratory programming Working with script files and the REPL (F# Interactive) allowed me to explore the solution space more effectively before committing to an implementation than the more traditional edit/compile/run/test loop. It is a very natural way for a programmer to build their understanding of the problem and the design tensions in play.
Unit testing Code written using non-side effecting functions and immutable data structures is a joy to test. There are no complex time-dependent interactions to screw things up or large sets of dependencies to be mocked.
Interoperation I defined the interface to the calculation engine in C# and implemented the calculation in F#. The calculation engine could then be injected into any C# module that needed to use it without any concerns at all about interoperability. Seamless. The C# programmer need never know.
Code reduction Much of the data fed into the calculation engine was in the form of vectors and matrices. Higher order functions eat these for breakfast with minimal fuss, minimal code. Beautiful.
Lack of bugs Functional programming can feel strange. I can be working on an algorithm, trying hard to get the code to pass the type checker but once the type checker is satisfied thats it, it works. Its almost binary, either it wont compile or its correct. Weird edge case errors are minimised, recursion and higher order functions remove a lot of book-keeping code that introduces edge case errors.
Parallelism The functional purity of the resulting implementation makes it ripe for exploiting the inherent parallelism in processing vectors of data. Maybe this is where I will go next now that .NET 4 is out.
During my internship at Microsoft Research, I worked on some parts of Visual Studio IntelliSense for F# (which is itself written in F#). I already had some experience with IntelliSense from earlier C# projects, so I think I can compare the two.
Visual Studio Extensibility is still based on COM, so you need to deal with objects that are not very nice .NET objects (and definitely not functional), but I don't feel there is any major difference between C# and F# (it works smoothly from F#)
The data structures used to represent program code in F# are mostly discriminated unions (which are not supported in C# in any reasonable way) and this makes a huge difference for this kind of application (where you need to process tree structures, such as program code). Discriminated unions and pattern matching allows you to structure the code better (keep related functionality in one place rather than having it all over the place in virtual methods)
Earlier, I also worked on CodeDOM provider for F# (also written in F#). I actually did first experiments in C#, but then converted the code to F#.
CodeDOM provider needs to traverse some structure represented using .NET objects, so there isn't much space for inventing your own representations of data (which is the area where F# can offer nice benefits).
However, there were many small F# features that made the task easier. Since you need to produce a string, I defined custom operators for building strings (using StringBuilder) and implemented the code using them and higher-order functions (e.g. to format list of objects separated using the specified string etc.), which removed a lot of repetition (and tedious foreach loops).
These are two relatively specific examples, but both of them are related to working with representations of programs, or expressions, or more generally, complex tree-like data structures. I think that in this area, F# is definitely a good choice (regardless of the functional features in C#).
We shipped the world's first commercial product written in F# (F# for Visualization) and the second (F# for Numerics) as well as the first commercial literature on F# (The F#.NET Journal) and wrote and publish the only book about the current version of F# (Visual F# 2010 for Technical Computing).
We had been shipping products along similar lines written in C# (e.g. this) but we also had a strong background in the commercial use of OCaml. We were enthusiastic early adopters of F# when it was still a research prototype back in 2006 because we recognised the potential of having a decent modern OCaml-like language on the industrial-strength .NET platform and, consequently, we pushed to have it productized. The result has been an incredible success and F# has far exceeded our lofty expectations.
For us, F# has many different advantages and we use it for a wide variety of applications. We have hundreds of thousands of lines of F# code in production. We now use F# for all of our LOB apps: our credit card transactions are processed using F# code, our product notifications are sent using F# code, our subscriptions are handled using F# code, our accounts are done using F# code and so on. Perhaps the main language feature that pays dividends here is pattern matching. We even used F# to color syntax highlight our latest book...
Our visualization library is a big seller and its functionality centers on F# interactive running in Visual Studio. Our library augments this with the ability to spawn interactive 2D and 3D visualizations with minimal effort (e.g. just Plot([Function sin], (-6., 6.)) to plot a sine wave). In particular, all threading issues are completely automated so users do not have to worry about UI threads and dispatch. First-class functions and laziness were extremely valuable when writing this part of the library and algebraic datatypes were used extensively elsewhere. Predictable performance also proved to be valuable here when our customers hit performance bugs in WPF's hit testing and were easily able to reimplement the relevant code in F# for a 10,000× performance improvement. Due to the free-form nature of this product's GUI, the GUI designer and C# would not have been beneficial.
Much of our work revolves around numerical methods, including both our commercial libraries and books. F# is much stronger in this area than C# because it offers high-level abstractions (e.g. higher-order functions) with minimal performance penalties. Our most compelling result in this context was the creation of a simple but generalized implementation of QR decomposition from linear algebra that was 20× shorter than the Fortran code from the reference implementation of LAPACK, up to 3× faster than the vendor-tuned Intel Math Kernel Library and more generic because our code can handle matrices of any type, even symbolic matrices!
We are currently developing WPF/Silverlight components in a mix of F# (for the guts) and C# (for the shim), building WPF apps to act as interactive manuals for our software products and I am writing a new book, Multicore F#, that will be the definitive guide to shared-memory parallel programming on .NET.
Over the last 6 or so months, I've been working on a Vim emulation layer for Visual Studio 2010. It's a free product with all of the source it's freely available on github
GitHub: http://github.com/jaredpar/VsVim
VsVim on Visual Studio Gallery
The project is divide into 3 DLL's representing a distinct layer. Each layer has a corresponding unit test dll.
Vim Engine: F#
WPF layer for adornments and editor integration: C#
Visual Studio Integration layer: C#
This is the first major project I've ever done with F# and I have to say I love the language. In many ways I used this project as a method of learning F# (and this learning curve is very much evident if you look through the history of the project).
What I find the most amazing about F# is just how concise of a language it is. The Vim engine comprises the bulk of the logic yet it only comprises 30% of the overall code base.
A lot of the unit tests for the F# Visual Studio components are written in F#. They run outside VS, mocking the various Visual Studio bits. The ability to cons up anonymous objects that implement interfaces is useful in place of a mocking framework/tool. I can just write
let owpe : string list ref = ref []
let vsOutputWindowPane =
{ new IVsOutputWindowPane with
member this.Activate () = err(__LINE__)
member this.Clear () = owpe := []; 0
member this.FlushToTaskList () = VSConstants.S_OK
member this.GetName(pbstrPaneName) = err(__LINE__)
member this.Hide () = err(__LINE__)
member this.OutputString(pszOutputString) = owpe := pszOutputString :: !owpe ; 0
member this.OutputStringThreadSafe(pszOutputString) = owpe := pszOutputString :: !owpe ; 0
member this.OutputTaskItemString(pszOutputString, nPriority, nCategory, pszSubcategory, nBitmap, pszFilename, nLineNum, pszTaskItemText) = err(__LINE__)
member this.OutputTaskItemStringEx(pszOutputString, nPriority, nCategory, pszSubcategory, nBitmap, pszFilename, nLineNum, pszTaskItemText, pszLookupKwd) = err(__LINE__)
member this.SetName(pszPaneName) = err(__LINE__)
}
DoSomethingThatNeedsA(vsOutputWindowPane)
assert( !owpe = expectedOutputStringList )
when I need an instance of e.g. an IVsOutputWindowPane to pass to some other component that will eventually be calling OutputString and Clear, and then inspect the string list ref object at the end of the test to see if the expected output was written.
We wrote a custom rules engine language using the Lex-Yacc implementation in F#
EDIT to include comment reply
There was no lex/yacc implementation in C#. (as far as we were aware, and the F# one was)
It would have been possible, but a downright pain to build the parsing ourselves.
This topic shows some other suggestions, such as external libraries, but our lead architect is an old hand at functional languages, so the choice to use F# was a no-brainer.
I'm currently working on a compile for a programming language. The compiler is written entirely in F#. The compiler (aside from the lex and parser build with lex/yacc) is basically build as a lot of transformation of a complex tree like structure.
As noted by others discriminate unions and pattern matching makes working with this kind of data structure a lot easier than dumping the code in virtual methods "all over the place"
I hadn't done any F# work before I started working on the compiler (I had however buld compilers in another OCaml variant called MoscowML) and just as Jared states it's visible from the code what parts I did first but in general I found F# easy to learn getting in to the FP mind set again after coding mainly OO for a decade will take a bit longer though.
working with trees aside I find the ability to write declarative code the main benefit of FP (F# included) having code that describes the algorithm Im trying to implement in contrast to C# describing how I've implemented the algortihm is a huge advantage.
Not personal experience, but you can listen to an episode of DNR (I think it's this one) where they talk to Microsoft folk about F#. They wrote most of Xbox Live scoring system, which was far from trivial, using F#. The system scaled massively across hundreds of machines and they were very satisfied with it.
I don't know if it's in production, but the AI for "The Path of Go" was written in F#:
http://research.microsoft.com/en-us/events/techvista2010/demolist.aspx#ThePathofGo
The Path of Go: A Microsoft Research
Game for Xbox 360
This demo showcases an Xbox 360 game,
based on the game of Go, produced
in-house at Microsoft Research
Cambridge. Go is one of the most
famous board games in East Asia, it
originated in China 4000 years ago.
Behind the deceptive simplicity of the
game hides great complexity. It only
takes minutes to learn, but it takes a
lifetime to master. Although computers
have surpassed human skills at Chess,
implementing a competitive AI for Go
remains a research challenge. The game
is powered by three technologies
developed at Microsoft Research
Cambridge: an AI capable of playing
Go, the F# language, and TrueSkill™ to
match online players. The AI is
implemented in F# and meets the
challenge of running efficiently in
the .net compact framework on Xbox
360. This game places you in a number of visually stunning 3D scenes. It was
fully developed in managed code using
the XNA environment.
(Someone else mentioned "TrueSkill" already.)
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.
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/
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
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.
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.
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)
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.
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.
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
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
As I posted earlier here I've decided to try my hand at one of these, but given my interests as a web developer, I'd like to know the difference between them in their real-world applications.
Edit Note:
While I'm a web developer, please don't let that limit your answer. I'm 30...I've got years of career changing ahead of me.
Bear in mind that I speak ASFAC++B. :) I've put the most important differentiating factor first.
Garbage Collection
Garbage Collection (GC) is the single most important factor in differentiating between these languages.
While C and C++ can be used with GC, it is a bolted-on afterthought and cannot be made to work as well (the best known is here) - it has to be "conservative" which means that it cannot collect all unused memory.
C# is designed from the ground up to work on a GC platform, with standard libraries also designed that way. It makes an absolutely fundamental difference to developer productivity that has to be experienced to be believed.
There is a belief widespread among C/C++ users that GC equates with "bad performance". But this is out-of-date folklore (even the Boehm collector on C/C++ performs much better than most people expect it to). The typical fear is of "long pauses" where the program stops so the GC can do some work. But in reality these long pauses happen with non-GC programs, because they run on top of a virtual memory system, which occasionally interrupts to move data between physical memory and disk.
There is also widespread belief that GC can be replaced with shared_ptr, but it can't; the irony is that in a multi-threaded program, shared_ptr is slower than a GC-based system.
There are environments that are so frugal that GC isn't practical - but these are increasingly rare. Cell phones typically have GC. The CLR's GC that C# typically runs on appears to be state-of-the-art.
Since adopting C# about 18 months ago I've gone through several phases of pure performance tuning with a profiler, and the GC is so efficient that it is practically invisible during the operation of the program.
GC is not a panacea, it doesn't solve all programming problems, it only really cleans up memory allocation, if you're allocating very large memory blocks then you will still need to take some care, and it is still possible to have what amounts to a memory leak in a sufficiently complex program - and yet, the effect of GC on productivity makes it a pretty close approximation to a panacea!
Undefined Behaviour
C++ is founded on the notion of undefined behaviour. That is, the language specification defines the outcome of certain narrowly defined usages of language features, and describes all other usages as causing undefined behaviour, meaning in principle that the operation could have any outcome at all (in practice this means hard-to-diagnose bugs involving apparently non-deterministic corruption of data).
Almost everything about C++ touches on undefined behaviour. Even very nice forthcoming features like lambda expressions can easily be used as convenient way to corrupt the stack (capture a local by reference, allow the lambda instance to outlive the local).
C# is founded on the principle that all possible operations should have defined behaviour. The worst that can happen is an exception is thrown. This completely changes the experience of software construction.
(There's unsafe mode, which has pointers and therefore undefined behaviour, but that is strongly discouraged for general use - think of it as analogous to embedded assembly language.)
Complexity
In terms of complexity, C++ has to be singled out, especially if we consider the very-soon-to-be standardized new version. C++ does absolutely everything it can to make itself effective, short of assuming GC, and as a result it has an awesome learning curve. The language designers excuse much of this by saying "Those features are only for library authors, not ordinary users" - but to be truly effective in any language, you need to build your code as reusable libraries. So you can't escape.
On the positive side, C++ is so complex, it's like a playground for nerds! I can assure you that you would have a lot of fun learning how it all fits together. But I can't seriously recommend it as a basis for productive new work (oh, the wasted years...) on mainstream platforms.
C keeps the language simple (simple in the sense of "the compiler is easy to write"), but this makes the coding techniques more arcane.
Note that not all new language features equate with added complexity. Some language features are described as "syntactic sugar", because they are shorthand that the compiler expands for you. This is a good way to think of a great deal of the enhancements to C# over recent years. The language standard even specifies some features by giving the translation to longhand, e.g. using statement expands into try/finally.
At one point, it was possible to think of C++ templates in the same way. But they've since become so powerful that they are now form the basis of a whole separate dimension of the language, with its own enthusiastic user communities and idioms.
Libraries
The strangest thing about C and C++ is that they don't have a standard interchangeable form of pre-compiled library. Integrating someone else's code into your project is always a little fiddly, with obscure decisions to be made about how you'll be linking to it.
Also, the standard library is extremely basic - C++ has a complete set of data structures and a way of representing strings (std::string), but that's still minimal. Is there a standard way of finding a list of files in a directory? Amazingly, no! Is there standard library support for parsing or generating XML? No. What about accessing databases? Be serious! Writing a web site back-end? Are you crazy? etc.
So you have to go hunting further afield. For XML, try Xerces. But does it use std::string to represent strings? Of course not!
And do all these third-party libraries have their own bizarre customs for naming classes and functions? You betcha!
The situation in C# couldn't be more different; the fundamentals were in place from the start, so everything inter-operates beautifully (and because the fundamentals are supplied by the CLR, there is cross-language support).
It's not all perfect; generics should have been in place from the start but wasn't, which does leave a visible scar on some older libraries; but it is usually trivial to fix this externally. Also a number of popular libraries are ported from Java, which isn't as good a fit as it first appears.
Closures (Anonymous Methods with Local Variable Capture)
Java and C are practically the last remaining mainstream languages to lack closures, and libraries can be designed and used much more neatly with them than without (this is one reason why ported Java libraries sometimes seem clunky to a C# user).
The amusing thing about C++ is that its standard library was designed as if closures were available in the language (container types, <algorithm>, <functional>). Then ten years went by, and now they're finally being added! They will have a huge impact (although, as noted above, they leak underfined behaviour).
C# and JavaScript are the most widely used languages in which closures are "idiomatically established". (The major difference between those languages being that C# is statically typed while JavaScript is dynamically typed).
Platform Support
I've put this last only because it doesn't appear to differentiate these languages as much as you might think. All these languages can run on multiple OSes and machine architectures. C is the most widely-supported, then C++, and finally C# (although C# can be used on most major platforms thanks to an open source implementation called Mono).
My experience of porting C++ programs between Windows and various Unix flavours was unpleasant. I've never tried porting anything very complex in C# to Mono, so I can't comment on that.
Both C and C++ give you a lower level of abstraction that, with increased complexity, provides a breadth of access to underlying machine functionality that are not necessarily exposed with other languages. Compared to C, C++ adds the convenience of a fully object oriented language(reduced development time) which can, potentially, add an additional performance cost. In terms of real world applications, I see these languages applied in the following domains:
C
Kernel level software.
Hardware device drivers
Applications where access to old, stable code is required.
C,C++
Application or Server development where memory management needs to be fine tuned (and can't be left to generic garbage collection solutions).
Development environments that require access to libraries that do not interface well with more modern managed languages.
Although managed C++ can be used to access the .NET framework, it is not a seamless transition.
C# provides a managed memory model that adds a higher level of abstraction again. This level of abstraction adds convenience and improves development times, but complicates access to lower level APIs and makes specialized performance requirements problematic.
It is certainly possible to implement extremely high performance software in a managed memory environment, but awareness of the implications is essential.
The syntax of C# is certainly less demanding (and error prone) than C/C++ and has, for the initiated programmer, a shallower learning curve.
C#
Rapid client application development.
High performance Server development (StackOverflow for example) that benefits from the .NET framework.
Applications that require the benefits of the .NET framework in the language it was designed for.
Johannes Rössel makes the valid point that the use C# Pointers, Unsafe and Unchecked keywords break through the layer of abstraction upon which C# is built. I would emphasize that type of programming is the exception to most C# development scenarios and not a fundamental part of the language (as is the case with C/C++).
C is the bare-bones, simple, clean language that makes you do everything yourself. It doesn't hold your hand, it doesn't stop you from shooting yourself in the foot. But it has everything you need to do what you want.
C++ is C with classes added, and then a whole bunch of other things, and then some more stuff. It doesn't hold your hand, but it'll let you hold your own hand, with add-on GC, or RAII and smart-pointers. If there's something you want to accomplish, chances are there's a way to abuse the template system to give you a relatively easy syntax for it. (moreso with C++0x). This complexity also gives you the power to accidentally create a dozen instances of yourself and shoot them all in the foot.
C# is Microsoft's stab at improving on C++ and Java. Tons of syntactical features, but no where near the complexity of C++. It runs in a full managed environment, so memory management is done for you. It does let you "get dirty" and use unsafe code if you need to, but it's not the default, and you have to do some work to shoot yourself.
My opinion is C# and ASP.NET would be the best of the three for development that is web biased.
I doubt anyone writes new web apps in C or C++ anymore. It was done 10 years ago, and there's likely a lot of legacy code still in use, but they're not particularly well suited, there doesn't appear to be as much (ongoing) tool support, and they probably have a small active community that does web development (except perhaps for web server development). I wrote many website C++ COM objects back in the day, but C# is far more productive that there's no compelling reason to code C or C++ (in this context) unless you need to.
I do still write C++ if necessary, but it's typically for a small problem domain. e.g. communicating from C# via P/Invoke to old C-style dll's - doing some things that are downright clumsy in C# were a breeze to create a C++ COM object as a bridge.
The nice thing with C# is that you can also easily transfer into writing Windows and Console apps and stay in C#. With Mono you're also not limited to Windows (although you may be limited to which libraries you use).
Anyways this is all from a web-biased perspective. If you asked about embedded devices I'd say C or C++. You could argue none of these are suited for web development, but C#/ASP.NET is pretty slick, it works well, there are heaps of online resources, a huge community, and free dev tools.
So from a real-world perspective, picking only one of C#, C++ and C as requested, as a general rule, you're better to stick with C#.
C - an older programming language that is described as Hands-on. As the programmer you must tell the program to do everything. Also this language will let you do almost anything. It does not support object orriented code. Thus no classes.
C++ - an extention language per se of C. In C code ++ means increment 1. Thus C++ is better than C. It allows for highly controlled object orriented code. Once again a very hands on language that goes into MUCH detail.
C# - Full object orriented code resembling the style of C/C++ code. This is really closer to JAVA. C# is the latest version of the C style languages and is very good for developing web applications.
From your other posts, I guess you want to learn a new language to get new skills. My advice is that the language is not really important, what is important is the quality of its community (advice, but also existing code you can read and learn from) and the available libraries/frameworks. In this respect, I think the "C family" is not the best choice for you: web libraries and frameworks are few, not portable and not great, and coding style of code you can study varies a lot and may confuse you a lot (although C is my favorite language).
I would advise to just learn C, and try to really understand the concept of pointers, then move to other languages more adapted to the web (Python or JavaScript comes to mind - or even Java). Also, in the C family, Objective-C has the best mix of power and simplicity in my opinion, but is a niche player.
C is the core language that most closely resembles and directly translates into CPU machine code. CPUs follow instructions that move, add, logically combine, compare, jump, push and pop. C does exactly this using much easier syntax. If you study the disassembly, you can learn to write C code that is just as fast and compact as assembly. It is my preferred language on 8 bit micro controllers with limited memory. If you write a large PC program in C you will get into trouble because of its limited organization. That is where object oriented programming becomes powerful. The ability of C++ and C# classes to contain data and functions together enforces organization which in turn allows more complex operability over C. C++ was essential for quick processing in the past when CPUs only had one core. I am beginning to learn C# now. Its class only structure appears to enforce a higher degree of organization than C++ which should ultimately lead to faster development and promote code sharing. C# is not interpreted like VB. It is partially compiled at development time and then further translated at run time to become more platform friendly.
For raw speed, use C. For power, use C++. For .NET compatibility, use C#.
They're all pretty complex as languages go; C through decades of gradual accretion, C++ through years of more rapid enhancement, and C# through the power of Microsoft.
I was just wondering what language would be a good choice for developing a game server to support a large (thousands) number of users? I dabbled in python, but realized that it would just be too much trouble since it doesn't spawn threads across cores (meaning an 8 core server=1 core server). I also didn't really like the language (that "self" stuff grossed me out).
I know that C++ is the language for the job in terms of performance, but I hate it. I don't want to deal with its sloppy syntax and I like my hand to be held by managed languages. This brings me to C# and Java, but I am open to other languages. I love the simplicity of .NET, but I was wondering if, speed wise, this would be good for the job. Keep in mind since this will be deployed on a Linux server, it would be running on the Mono framework - not sure if that matters. I know that Java is syntax-wise very similar to .Net, but my experience with it is limited. Are there any frameworks out there for it or anthing to ease in the development?
Please help me and my picky self arrive on a solution.
UPDATE: I didn't mean to sound so picky, and I really don't think I was. The only language I really excluded was C++, Python I don't like because of the scalability problem. I know that there are ways of communicating between processes, but if I have an 8 core server, why should I need to make 8 processes? Is there a more elegant solution?
I hate to say it, and I know I'm risking a down mod here, but it doesn't sound like there's a language out there for you. All programming languages have their quirks and programmers simply have to adapt to them. It's completely possible to write a working server in Python without classes (eliminating the "self" variable class references) and likewise just as easy to write C++ with clean syntax.
If you're looking to deploy cross-platform and want to develop cross-platform as well, your best bet would probably be Java. It shorter development cycles than compiled languages like C and C++, but is higher performance (arguable, but I've always been anti-Java =P) than interpreted languages like Python and Perl and you don't have to work with unofficial implementations like Mono that may from time to time not support all of a language's features.
I might be going slightly off-topic here, but the topic interests me as I have (hobby-wise) worked on quite a few game servers (MMORPG servers) - on others' code as well as mine. There is literature out there that will be of interest to you, drop me a note if you want some references.
One thing that strikes me in your question is the want to serve a thousand users off a multithreaded application. From my humble experience, that does not work too well. :-)
When you serve thousands of users you want a design that is as modular as possible, because one of your primary goals will be to keep the service as a whole up and running. Game servers tend to be rather complex, so there will be quite a few show-stopping bugs. Don't make your life miserable with a single point of failure (one application!).
Instead, try to build multiple processes that can run on a multitude of hosts. My humble suggestion is the following:
Make them independent, so a failing process will be irrelevant to the service.
Make them small, so that the different parts of the service and how they interact are easy to grasp.
Don't let users communicate with the gamelogic OR DB directly. Write a proxy - network stacks can and will show odd behaviour on different architectures when you have a multitude of users. Also make sure that you can later "clean"/filter what the proxies forward.
Have a process that will only monitor other processes to see if they are still working properly, with the ability to restart parts.
Make them distributable. Coordinate processes via TCP from the start or you will run into scalability problems.
If you have large landscapes, consider means to dynamically divide load by dividing servers by geography. Don't have every backend process hold all the data in memory.
I have ported a few such engines written in C++ and C# for hosts operating on Linux, FreeBSD and also Solaris (on an old UltraSparc IIi - yes, mono still runs there :). From my experience, C# is well fast enough, considering on what ancient hardware it operates on that sparc machine.
The industry (as far as I know) tends to use a lot of C++ for the serving work and embeds scripting languages for the actual game logic. Ah, written too much already - way cool topic.
Erlang is a language which is designed around concurrency and distribution over several servers, which is perfect for server software. Some links about Erlang and game-servers:
http://www.devmaster.net/articles/mmo-scalable-server/
http://www.erlang-consulting.com/euc2005/mmog/mmog_in_erlang.htm
I'm thinking of writing a game-server in Erlang myself.
Speaking of pure performance, if you can run Java 6 you get about 1:1 performance when compared to optimized C++ (special cases notwithstanding, sometimes Java is faster, sometimes C++), the only problem you will have is of course stuff like database libraries, interconnectivity, scalability and such. I believe there's a variety of good to great solutions available to each of these problems but you won't find one language which would solve everything for you so I have to give you the age old advice: Choose the language you like and use that one.
Oh, you're still reading this? :) Well, here's some extra pointers.
EVE Online uses Python for its client and server side code and it's both bug-ridden and laggy as something I don't think I should write here so that'd be an example of how Python can be extended to (poorly) serve vast amounts of users.
While Java has some good to great solutions to various related problems, it's really not the best language out there for vast amount of users; it doesn't scale well to extremes without tuning. However there's multi-VM solutions to this which somewhat fix the issue, for example Terracotta is said to do the job well.
While C++ is rather cumbersome, it allows for such a low-level interaction with the system that you may actually find yourself doing things you thought you couldn't do. I'm thinking of something like dynamic per-core microclustering of runtime code blocks for "filling" every possible clock cycle of the processor as efficiently as possible for maximum performance and things like that.
Mono is far behind the .NET VM/equivalent on Windows platforms so you wouldn't be able to use the latest and fanciest features of C#. However Windows XP (x64) OEM licenses are so laughably cheap at the moment that with small investment you could get a bunch of those and you could then run your code on the platform it was meant to be. And don't fall into the Linux hype, Linux is your saviour only if you really know how to use it and especially XP is pretty damn fast and stable nowadays.
What kind of performance do you need?
twisted is great for servers that need lots of concurrency, as is erlang. Either supports massive concurrency easily and has facilities for distributed computing.
If you want to span more than one core in a python app, do the same thing you'd do if you wanted to span more than one machine — run more than one process.
More details about this game server might help folks better answer your question. Is this a game server in the sense of something like a Counter Strike dedicated server which sits in the background and hosts multiplayer interactions or are you writing something which will be hosted on an HTTP webserver?
Personally, if it were me, I'd be considering Java or C++. My personal preference and skill set would probably lead me towards C++ because I find Java clumsy to work with on both platforms (moreso on Linux) and don't have the confidence that C# is ready for prime-time in Linux yet.
That said, you also need to have a pretty significant community hammering on said server before performance of your language is going to be so problematic. My advise would be to write it in whatever language you can at the moment and if your game grows to be of sufficient size, invest in a rewrite at that time.
You could as well use Java and compile the code using GCC to a native executable.
That way you don't get the performance hit of the bytecode engine (Yes, I know - Java out of the box is as fast as C++. It must be just me who always measures a factor 5 performance difference). The drawback is that the GCC Java-frontend does not support all of the Java 1.6 language features.
Another choice would be to use your language of choice, get the code working first and then move the performance critical stuff into native code. Nearly all languages support binding to compiled libraries.
That does not solve your "python does not multithread well"-problem, but it gives you more choices.
The obvious candidates are Java and Erlang:
Pro Java:
ease of development
good development environments
stability, good stack traces
well-known (easy to find experienced programmers, lots of libraries, books, ...)
quite fast, mature VM
Pro Erlang:
proven in systems that need >99.9% uptime
ability to have software updates without downtime
scalable (not only multi-core, but also multi-machine)
Contra Erlang:
unfamiliar syntax and programming paradigm
not so well known; hard to get experienced programmers for
VM is not nearly as fast as java
If your game server mainly works as a event dispatcher (with a bit of a database tucked on), Erlang's message-driven paradigm should be a good match.
In this day and age, I would not consider using an unmanaged language (like C or C++); the marginal performance benefits simply aren't worth the hassle.
It may depend a lot on what language your "game logic" (you may know this term as "business logic") is best expressed in. For example, if the game logic is best expressed in Python (or any other particular language) it might be best to just write it in Python and deal with the performance issues the hard way with either multi-threading or clustering. Even though it may cost you a lot of time to get the performance you want out of Python it will be less that the time it will take you to express "player A now casts a level 70 Spell of darkness in the radius of 7 units effecting all units that have spoken with player B and .... " in C++.
Something else to consider is what protocol you will be using to communicate with the clients. If you have a complex binary protocol C++ may be easier (esp. if you already had experience doing it before) while a JSON (or similar) may be easier to parse in Python. Yes, i know C++ and python aren't languages you are limited to (or even considering) but i'm refer to them generally here.
Probably comes down to what language you are the best at. A poorly written program which you hated writing will be worse that one written in a language you know and enjoy, even if the poorly written program was in an arguable more powerful language.
You could also look at jRuby. It comes with lots of the benefits of Java and lots of the benefits of Ruby in one neat package. You'll have access to huge libraries from both languages.
What are your objectives? Not the creation of the game itself, but why are you creating it?
If you're doing it to learn a new language, then pick the one that seems the most interesting to you (i.e., the one you most want to learn).
If it is for any other reason, then the best language will be the one that you already know best and enjoy using most. This will allow you to focus on working out the game logic and getting something up and running so that you can see progress and remain motivated to continue, rather than getting bogged down in details of the language you're using and losing interest.
If your favorite language proves inadequate in some ways (too slow, not expressive enough, whatever), then you can rewrite the problem sections in a more suitable language when issues come up - and you won't know the best language to address the specific problems until you know what the problems end up being. Even if your chosen language proves entirely unsuitable for final production use and the whole thing has to be rewritten, it will give you a working prototype with tested game logic, which will make dealing with the new language far easier.
You could take a look at Stackless Python. It's an alternative Python interpreter that provides greater support for concurrency. Both EVE Online's server and client software use Stackless Python.
Disclaimer: I haven't used Stackless Python extensively myself, so I can't provide any first-hand accounts of its effectiveness.
There is a pretty cool framework in development that addresses all your needs:
Project Darkstar from Sun. So I'd say Java seems to be a good language for game server development :-)
I know facebook uses a combination of Erlang and C++ for their chat engine.
Whatever you decide, if you choose a combination of languages, check out facebook's thrift framework for cross language services deployment. They open sourced it about a year+ back:
http://incubator.apache.org/thrift/
C++ and Java are quite slow compared to C. The language should be a tool but not a crutch.