6
¿Qué factores indican que la solución de un proyecto no debe codificarse en un lenguaje dinámico?¿Bajo qué circunstancias los idiomas dinámicos no son apropiados?
A
Respuesta
0
La velocidad es generalmente la respuesta principal. Aunque esto se está convirtiendo en un problema menor en estos días.
0
cuando la velocidad es crucial. Los lenguajes dinámicos se están volviendo más rápidos, pero aún no están cerca del rendimiento de lo que es un lenguaje compilado.
3
Familiaridad y disposición de los programadores para trabajar con el idioma.
Tu lenguaje dinámico es probablemente mi lenguaje estático.
3
El desarrollo del nivel del sistema es un grupo clave de software que normalmente no debería estar en idiomas dinámicos. (controladores, cosas a nivel de kernel, etc.).
Básicamente todo lo que necesita tener cada onza de rendimiento o acceso a hardware de bajo nivel, debe estar en un lenguaje de nivel inferior.
Otro indicador es si se trata de un gran número de crujidos, como el crujido de números de datos científicos. Es decir, si necesita correr rápido y hacer números crujientes.
Creo que un tema común son los problemas intensivos del procesador ... en cuyo caso verá fácilmente las diferencias de rendimiento, y encontrará que el lenguaje dinámico simplemente no le puede dar el poder para usar el hardware de manera efectiva.
Dicho esto, si está haciendo un trabajo intensivo de procesador y no le importa el éxito en el rendimiento, entonces aún podría utilizar un lenguaje dinámico.
Actualización:
Tenga en cuenta que para el cálculo de números, me refiero a realmente larga cálculo de números en la arena científica donde el proceso se está ejecutando durante horas o días ... en este caso un aumento de 2 veces el rendimiento es GINORMOUS ... si se trata de una escala mucho más pequeña, los lenguajes dinámicos aún podrían ser útiles.
+1
Bueno, el cálculo numérico y los lenguajes dinámicos no son ortogonales, dadas las bibliotecas correctas. Piensa en Python y Numpy, o Star * P, etc. – tzot
-1
¿Qué tal interoperabilidad? ¿Es posible llamar a un componente COM de Ruby o Python?
+0
Prácticamente sin dolor. Ruby y, por lo que recuerdo, Python tiene ambos módulos Win32Ole para este propósito. La interoperabilidad de .Net también es posible, aunque creo que funciona mejor con las implementaciones IronRuby/IronPython. – JasonTrue
+0
Los idiomas dinámicos a menudo se sirven bajo la etiqueta "lenguajes adhesivos", así que la interoperabilidad está en la descripción del trabajo :) – tzot
0
Interop es absolutamente posible con los lenguajes dinámicos. (¿Recuerda el básico visual clásico, que tiene "enlace diferido"?) Requiere que el componente COM se compile con algunos extras para ayudar a las personas que llaman a llamar por su nombre.
No creo que el número de crujidos deba ser compilado estáticamente, la mayoría de las veces se trata de cómo resolverlo. Matlab es un buen ejemplo para el cálculo de números, y tiene un lenguaje no compilado. Matlab, sin embargo, tiene un tiempo de ejecución muy específico para números y matrices.
0
Creo que siempre debería optar por el lenguaje estático cuando sea posible. No digo que C# o Java tengan buenos sistemas estáticos, pero C# se está acercando. Bueno, type inference es la clave, ya que le brindará los beneficios que se ven en los lenguajes dinámicos a la vez que le brinda seguridad y características de los que tienen tics estáticos. Problema resuelto - no más flamewars.
+0
esto es muy subjetivo ... incluso la inferencia tipográfica no siempre puede hacer cosas que un lenguaje muy dinámico puede hacer, al menos no sin un montón de grandes cambios en el sistema de tipos ... –
+0
(Haskell fue un lenguaje divertido por cierto con inferencia de tipo fuerte, pero todavía prefiero los lenguajes más flexibles, dinámicos, orientados a objetos como Ruby) –
+0
Por supuesto, los lenguajes dinámicos siempre serán más flexible pero al costo de ciertas garantías. Creo que la flexibilidad de los lenguajes dinámicos está sobrevalorada. Ruby es un gran lenguaje, realmente lo es, pero la mayoría de sus características innovadoras ahora son posibles incluso en C# 3.0 sin perder el control estático durante la compilación –
0
Código de nivel del sistema para sistemas integrados. Un posible problema es que los lenguajes dinámicos a veces ocultan las implicaciones de rendimiento de una sola declaración sencilla.
Como dice esta declaración Perl:
@contents = <FILE>;
si el archivo está a unos pocos megabytes, entonces eso es una declaración que consume muchos recursos - es posible agotar su montón, o provocar un tiempo de espera de vigilancia, o en general más lento el respuesta del sistema integrado.
Si desea "programar más cerca del metal", probablemente desee utilizar un lenguaje estáticamente tipado y de "nivel medio".
1
controladores de dispositivos de tarjetas de vídeo
+0
aunque ... con las librerías adecuadas incluso eso es posible. solo mira a Numpy. –
2
En gran medida, lenguaje de programación es una elección de estilo. Utiliza el idioma que quieras usar y serás productivo y feliz al máximo. Si por alguna razón eso no es posible, entonces con suerte su decisión final se basará en algo significativo, como una plataforma contra la que deba competir o números reales de rendimiento empírico, en lugar de la elección de estilo arbitrario de otra persona.
Cuestiones relacionadas
- 1. ¿Bajo qué circunstancias son útiles las propiedades atómicas?
- 2. ¿Bajo qué circunstancias puede fallar ConcurrentBag.TryTake()?
- 3. ¿Qué son los idiomas ISO?
- 4. ¿Bajo qué circunstancias System.Collections.ArrayList.Add arroja IndexOutOfRangeException?
- 5. Bajo qué circunstancias [ClassCleanup] y [TestCleanup] no se ejecutan
- 6. ¿Bajo qué circunstancias se llama __rmul__?
- 7. ¿Bajo qué circunstancias caen los zócalos ZeroMQ o no entregan mensajes?
- 8. Bajo qué circunstancias, necesitamos llamar a GC.Colgar dos veces
- 9. En WPF, ¿bajo qué circunstancias Visual.PointFromScreen lanza InvalidOperationException?
- 10. ¿Bajo qué circunstancias finalizará la aplicación Log.wtf de Android?
- 11. Idiomas dinámicos compatibles con .NET 4.0 DLR
- 12. Contenedores Ioc e idiomas dinámicos (toma 2)
- 13. ¿Los árboles de expresión LINQ son árboles apropiados?
- 14. Funciones virtuales en constructores, ¿por qué los idiomas son diferentes?
- 15. ¿Puedes tener demasiado "dinámico" en idiomas dinámicos?
- 16. Los recursos dinámicos de nivel de aplicación no son dinámicos cuando se alojan en ElementHost
- 17. ¿Qué son los datos dinámicos de .net y por qué los usaría?
- 18. Excluir carpeta bajo enlaces dinámicos en Installshield
- 19. Mordisco alto y mordisco bajo ¿qué son?
- 20. ¿Bajo qué circunstancias el rendimiento de Javascript sería peor en IE8 que en IE7?
- 21. ¿Puede hacer un método para mejorar el rendimiento estático y bajo qué circunstancias?
- 22. ¿Bajo qué circunstancias mi navegador intentará reutilizar una conexión TCP para múltiples solicitudes?
- 23. jQuery.ajax no envía los encabezados ajax apropiados al usar HTTPS
- 24. ¿En qué circunstancias devuelve TextToSpeech.isSpeaking() verdadero?
- 25. ¿Bajo qué circunstancias se invocaría el operador de conversión de un tipo a sí mismo?
- 26. ¿Qué idiomas no tienen construcciones de bucle?
- 27. ¿Cuáles son los 5 idiomas principales para localizar una aplicación?
- 28. ¿Qué tan alto debe/van los idiomas de alto nivel?
- 29. ¿Qué idiomas son compatibles con la intercalación icu?
- 30. ¿Bajo qué circunstancias puede un puntero vtable ser nulo (o 0x1)?
La velocidad depende en gran medida de la calidad de la implementación y tiene muy poco que ver con si el lenguaje se tipea dinámicamente o estáticamente. Los buenos compiladores Common Lisp ciertamente pueden competir con C, los compiladores C malos pueden ser mucho más lentos que, por ejemplo, CPython. –