Es difícil pensar en tipos de generales aplicaciones que Python no sería adecuada, pero hay varios tipos, donde, al igual que casi todos los lenguajes de alto nivel afín, es decir, que podría ser considerado una opción peculiar y probablemente inferiores .
En aplicaciones "duras en tiempo real", todas las asignaciones y liberaciones dinámicas de memoria, y especialmente recolección de basura, son comprensiblemente mal vistas; esto descarta casi todos los lenguajes modernos (incluyendo Python, pero también Java, C#, etc, etc.), ya que casi todos ellos confían en el manejo dinámico de la memoria y la recolección de basura de algún tipo.
Si está programando para un "dispositivo integrado" que espera ser producido y vendido en grandes cantidades, cada bit de ROM puede agregar mensurablemente a los costos generales, por lo que desea un lenguaje centrado en exprimir la aplicación hasta el último bit posible: cualquier lenguaje que dependa de un entorno de tiempo de ejecución enriquecido o sistema operativo (incluyendo Python, y, nuevamente, también Java, C#, etc.) lo obligaría a gastar más en muchos más bits de ROM (tenga en cuenta los lenguajes de interpretación con subprocesos como el antiguo Forth: pueden hacer que el código de una aplicación sustancial sea sensiblemente más compacto que el código de máquina directo).
Hay muchos otros nichos que comparten restricciones similares (mayormente enfocados en MEMORIA: concéntrese en usar la menor cantidad de bits posible y/o limitar estrictamente la ejecución dentro de límites predefinidos - sin dinamismo, sin asignación, sin recolección de basura, etc. , etc.), y básicamente el caso volvería a inclinarse de manera similar (por ejemplo, hay aplicaciones de servidor, destinadas a ejecutarse en innumerables servidores, que pueden ahorrar muchos megabytes por servidor si están codificados en C++ [especialmente si no hay "supuestamente- smart "punteros ;-)] en lugar de Java, Python, C#, y así sucesivamente).
Por supuesto que hay excelentes razones para que la mayoría de los lenguajes modernos (Python, Java, C#, etc.) elijan asignación dinámica de memoria, recolección de basura, etc., a pesar de la importancia de los nichos de aplicación donde esas técnicas son negativas: Básicamente, si puede permitirse un buen manejo de la memoria, escribir aplicaciones se convierte en MUCHA, MUCHO más fácil, y toda una clase de problemas y fallas conectadas con la necesidad de administrar la memoria cuidadosamente si le falta dicho soporte puede desaparecer, la productividad del programador realmente aumenta ... si la recolección de basura y similares pueden ser permitidas en absoluto, eso es. Por ejemplo, si una aplicación fuera a ejecutarse en algunos cientos o miles de servidores, probablemente no me molestaría en codificarla en C++ con la administración manual de la memoria para ahorrar memoria; es solo en decenas y cientos de miles de servidores, que la economía de todos esos megabytes adicionales realmente entra en juego.
Tenga en cuenta que, a pesar de la idea errónea de que los "lenguajes interpretados" (aquellos con un tiempo de ejecución subyacente o VM, como Java, C#, Python, etc.) "son lentos", de hecho para la mayoría de las aplicaciones intensivas en CPU (como computación científica), Python es perfectamente adecuado, siempre que el "entorno de tiempo de ejecución enriquecido" (por ejemplo, numpy
) se tenga en cuenta Entonces, eso no es realmente un factor, aunque el consumo de memoria y la recolección de basura PUEDE ser, en algunos nichos.
@Stackoverflow Lectores: Gracias a todos por proporcionar pro mpt responde a mi consulta. – Rachel