Python vs C#/.NET -- what are the key differences to consider for using one to develop a large web application?
My organization currently delivers a web application primarily based on a SQL Server 2005/2008 back end, a framework of Java models/controllers, and ColdFusion-based views. We have decided to transition to a newer framework and after internal explorations and mini projects have narrowed the choice down to between Python and C#/.NET.
Let me start off by saying that I realize either technology will work great, and am looking for the key differentiators (and associated pros and cons) These languages have a lot in common, and a lot not--I'm looking for your take on their key differences.
Example tradeoff/differentiator I am looking for:
While it seems you can accomplish more with less code and be more creative with Python, since .NET is more structured it may be easier to take over understanding and modifying code somebody else wrote.
Some extra information that may be useful:
Our engineering team is about 20 large and we work in small teams of 5-7 of which we rotate people in and out frequently. We work on code that somebody else wrote as much as we write new code.
With python we would go the Django route, and with .NET we would go with MVC2. Our servers are windows servers running IIS.
Some things we like about ColdFusion include that its very easy to work with queries and that we can "hot-deploy" fixes to our webservers without having to reboot them or interrupt anybody on them.
I've read some of the other X vs Y threads involving these two languages and found them very helpful, but would like to put Python head-to-head against .Net directly. Thanks in advance for letting me tap your experiences for this difficult question!
Answer
".NET" is not a language. Perhaps it's Python vs. C# or Python/Django vs C#/ASP.NET (or pick whatever "webwork" you want; there are many, many different solutions for both Python and ".NET" and picking Django or MVC2 of the bat might severely limiting better viable options). As a counter to the Python vs. ".NET": There is IronPython (Python "in .NET")
I would consider: Developer comfort with a language and, if they are equal in Python and ".NET", then I would consider turnaround times for development and choose the language/"webwork" that minimized this (again, it need not be previous constraints).
While unit/integration-testing is a must for any [sizable] project, I find that a statically typed language (C#/F#) can greatly reduce the number of "stupid bugs" relating to types.
Open up the playing field :-)
Edit for comment:
Then you're just comparing languages.
In which case, C# is a very boring imperative statically typed language with Single-Inheritance/Interface Class-Based OO (but a few more neat tricks than Java, which is just downright stone-age). This is the same basic type of OO as Python has and excluding the static/dynamic bit, both languages are strongly typed (the mechanics are different, but the end result is quite similar in the language spectrum). Actually, python has MI, but that seems less accepted in python as the use of the 'lambda' keyword and since python is dynamically typed there is no compile-time support for determining interface/type contracts (there are, however, some modules that try to provide this).
If you can learn/know Python, then you can learn/known C#. It's not a paradigm shift. Some keywords here, braces there, need to say what type you mean there, a different base library... different environment (you have to fight some to get to a REPL, but it's doable in VS.) How developers like/learn/use it is another story. While I did call C# imperative before, it's nice to see the addition of some "functional-like" features such as LINQ/IEnumerable extensions and closures-without-delegates, even if the basic C# syntax is very procedural -- once again, pretty much like python (for-expressions, nested functions, statement/expression divide).
While the new 'dynamic' does blur the line (there is very rarely a good use for it -- in about all the same places one might have had to fall back to reflection in prior C# versions -- this isn't true, but the point is it's generally "the wrong way", except in the few cases when it just happens to be "the best/only way"), 'var' does not. That is, the type of a 'var' variable is known at compile-time and has nothing to do with dynamic typing; it is all type inference. Some language like F#/SML and Haskell have much, much more powerful type inference removing the need for "all those ugly type declarations" (although explicitly annotating allowed types or set of types can make intent more clear) while preserving static typing.
Personally, everything else aside, I would use a statically typed language. I'm not saying C# (and I'm definitely not saying Java!), but statically typed languages can push type errors to the top and require up-front explicit contracts (this is a big, big win for me). While you do miss out on some neat dynamic tricks, there is almost always a better way to perform the same action in the target language -- you just have to think in terms of that language and use a screwdriver for a screw and a hammer for a nail. E.g. don't expect to bring Python code relying on the (ab)use of local() or global() into C# as-is.
On the "down-side", most statically typed languages (C# here) require an explicit compile-first (but this isn't so bad as it makes pretty assemblies) and tools like the "REPL" aren't taken as first-class citizens (it is a first-class citizen in F#/VS2010). Also, if you have an essential library for Python/C# (and it isn't available in the other language), that may be a deciding factor as to why to choose one language over the other.