Si te encuentras con alguna parte que te causa duda puedes comentarlo y te ayudaremos rápidamente.
Solución:
“.NET” no es un lenguaje. Tal vez sea Python vs. C# o Python/Django vs C#/ASP.NET (o elija cualquier “trabajo web” que desee; hay muchas, muchas soluciones diferentes tanto para Python como para “.NET” y elegir Django o MVC2 del bate podría limitando severamente mejores opciones viables). Como contrapartida a Python vs. “.NET”: existe IronPython (Python “en .NET”)
Yo consideraría: Comodidad del desarrollador con un lenguaje y, si son iguales en Python y “.NET”, entonces consideraría los tiempos de respuesta para el desarrollo y elegiría el lenguaje/”trabajo web” que minimice esto (nuevamente, no es necesario que sean restricciones previas).
Si bien las pruebas unitarias/de integración son imprescindibles para cualquier [sizable] proyecto, encuentro que un lenguaje escrito estáticamente (C#/F#) puede reducir en gran medida el número de “errores estúpidos” relacionados con los tipos.
Abre el campo de juego 🙂
Editar para comentar:
Entonces solo estás comparando idiomas.
En cuyo caso, C# es un lenguaje imperativo tipado estáticamente muy aburrido con OO basado en clase de herencia única/interfaz (pero algunos trucos más ingeniosos que Java, que es francamente de la edad de piedra). Esto es el mismo tipo básico de OO que tiene Python y excluyendo el static/ bit dinámico, ambos idiomas están fuertemente tipados (la mecánica es diferente, pero el resultado final es bastante similar en el espectro del lenguaje). En realidad, python tiene MI, pero eso parece menos aceptado en python como el uso de la palabra clave ‘lambda’ y dado que python se escribe dinámicamente, no hay soporte en tiempo de compilación para determinar contratos de tipo/interfaz (hay, sin embargo, algunos módulos que tratar de proporcionar esto).
Si puede aprender/conocer Python, entonces puede aprender/conocer C#. No es un cambio de paradigma. Algunas palabras clave aquí, llaves allá, necesitan decir a qué tipo te refieres allí, una biblioteca base diferente… un entorno diferente (tienes que luchar contra algunas para llegar a un REPL, pero es factible en VS). Cómo les gusta/aprende/a los desarrolladores usarlo es otra historia. Si bien antes llamé a C# imperativo, es bueno ver la adición de algunas funciones “similares a las funcionales”, como las extensiones LINQ/IEnumerable y los cierres sin delegados, incluso si la sintaxis básica de C# es muy procedimental — una vez más, bastante muy parecido a python (for-expresiones, funciones anidadas, división declaración/expresión).
Si bien la nueva ‘dinámica’ desdibuja la línea (muy rara vez tiene un buen uso, casi en los mismos lugares uno podría haber tenido que recurrir a la reflexión en versiones anteriores de C#), esto no es true, pero el punto es que generalmente es “de la manera incorrecta”, excepto en los pocos casos en que resulta ser “la mejor/única manera”), ‘var’ no lo es. Es decir, el tipo de una variable ‘var’ es conocido en tiempo de compilación y no tiene nada que ver con la escritura dinámica; es todo tipo de inferencia. Algunos lenguajes como F#/SML y Haskell tienen una inferencia de tipos mucho, mucho más potente, eliminando la necesidad de “todas esas declaraciones de tipos desagradables” (aunque anotar explícitamente los tipos o conjuntos de tipos permitidos puede aclarar la intención) al tiempo que conserva static mecanografía.
Personalmente, todo lo demás a un lado, usaría un lenguaje escrito estáticamente. No estoy diciendo C# (¡y definitivamente no estoy diciendo Java!), pero Los lenguajes escritos estáticamente pueden empujar los errores de tipo a la parte superior y requieren contratos explícitos por adelantado. (Esta es una gran, gran victoria para mí). Si bien te pierdes algunos trucos dinámicos ingeniosos, casi siempre hay una mejor manera de realizar la misma acción en el idioma de destino: solo tienes que pensar en términos de ese idioma y usar un destornillador para un tornillo y un martillo para una uña. Por ejemplo, no espere traer el código de Python basándose en el (ab) uso de local() o global() en C# tal como está.
En el “lado negativo”, la mayoría de los lenguajes tipificados estáticamente (C # aquí) requieren una compilación explícita primero (pero esto no es tan malo ya que hace ensamblajes bonitos) y herramientas como “REPL” no se toman como primero. ciudadanos de primera clase (es un ciudadano de primera clase en F#/VS2010). Además, si tiene una biblioteca esencial para Python/C# (y no está disponible en el otro idioma), ese puede ser un factor decisivo para elegir un idioma en lugar de otro.
Escribí una respuesta muy completa en Quora sobre esto: ¿Cómo se compara Python con C#?
TL;RD
La respuesta es enorme, pero (con suerte) bastante completa. Programé en C#/.NET durante casi 10 años, así que lo conozco muy bien. Y programo en Python en Quora desde hace ~ 7 meses, así que espero saberlo bastante bien.
Python es ganador en: facilidad de aprendizaje, desarrollo multiplataforma, disponibilidad de bibliotecas de código abierto
C# es ganador en: biblioteca estándar, características del lenguaje, proceso y herramientas de desarrollo, rendimiento, velocidad de evolución del lenguaje
Más o menos uniforme: sintaxis (Python es mejor en legibilidad, C# tiene una sintaxis más consistente), adopción.
También sugeriría que debemos comparar los tiempos de ejecución y no limitarnos a las características del idioma antes de realizar tales movimientos. Python se ejecuta a través del intérprete CPython, donde C# se ejecuta en CLR en sus implementaciones predeterminadas.
La multitarea es muy importante en cualquier proyecto a gran escala; .NET puede manejar esto fácilmente a través de subprocesos… y también puede beneficiarse de los procesos de trabajo en IIS (ASP.NET). CPython no ofrece true capacidades de subprocesamiento debido a GIL… un bloqueo que cada subproceso debe adquirir antes de ejecutar cualquier código, por true multitarea tienes que usar múltiples procesos.
Cuando alojamos la aplicación ASP.NET en IIS en un solo proceso de trabajo, ASP.NET aún puede aprovechar los subprocesos para atender múltiples solicitudes web simultáneamente en diferentes núcleos donde CPython depende de múltiples procesos de trabajo para lograr la computación paralela en diferentes núcleos.
Todo esto lleva a una gran pregunta, cómo vamos a alojar la aplicación Python/Django en Windows. Todos sabemos que el proceso de bifurcación en Windows es mucho más costoso que en Linux. Entonces, idealmente para alojar la aplicación Python/Django; el mejor entorno sería Linux en lugar de Windows.
Si elige Python, el entorno adecuado para desarrollar y alojar Python sería Linux… y si es como yo, que viene de Windows, elegir Python también introduciría una nueva curva de aprendizaje de Linux… aunque no es muy difícil en estos días. …
valoraciones y comentarios
Si para ti ha sido de ayuda nuestro post, sería de mucha ayuda si lo compartieras con otros seniors de esta forma nos ayudas a difundir esta información.