Hacen dinámicos lenguajes de tipo merecen toda la crítica? [cerrado]

Question

He leído algunos artículos sobre Internet sobre la programación de la elección del idioma en la empresa. Recientemente, muchos lenguajes dinámicos escrito han sido populares, es decir, Ruby, Python, PHP y Erlang. Sin embargo, muchas empresas todavía permanecen con lenguajes estáticos escrito como C, C ++, C # y Java.

Y sí, una de las ventajas de los lenguajes estáticos escrito es que los errores de programación son capturados antes, en tiempo de compilación, en lugar de en tiempo de ejecución. Pero también hay ventajas con lenguajes dinámicos mecanografiado. ( más en Wikipedia )

La razón principal por la que las empresas no empiezan a utilizar lenguajes como Erlang, Ruby y Python, parece ser el hecho de que son mecanografiada dinámico. Esto también parece ser la razón principal por la gente en StackOverflow deciden en contra de Erlang. Ver ¿Por qué decidió "contra" Erlang .

Sin embargo, parece que hay una fuerte crítica contra el tipado dinámico en las empresas, pero en realidad no lo entiendo por qué es que fuerte.

En serio, ¿por qué hay tantas críticas contra el tipado dinámico en las empresas? Es lo que realmente afecta el costo de los proyectos que mucho, o qué? Pero tal vez me equivoque.

Answer 1

Sí, creo que lo hacen.

Hay algunas razones por las que deben tenerse en cuenta en la selección de un idioma para un nuevo proyecto:

• Velocidad en tiempo de ejecución. En comparación con C / C ++ / Fortran, Perl y Python son tan lentos que es divertido.
velocidad
• inicialización. En comparación con el anterior lenguas rápidas, Java se cae y llora como la JVM mantiene la carga y carga y ... while(1) ....
• Prototipo-capacidad. Exhaustivamente pasando y haciendo el trabajo de declaración / definición requerida para C ++ o Java aumenta el COL, que es el solamente sabe que la métrica fiable correlaciona con bugcounts. También lleva mucho tiempo. También se requiere un poco más de pensar en los tipos y las conexiones.
• fiddlability interna. Dinámicamente jugar un poco con sus partes internas es grande hasta que comience a depurar su código mutante . (Python, Lisp, Perl)
• verificación de la corrección. Un compilador puede proporcionar una rápida una vez más pasar de semi-corrección de su código en C ++, y esto puede ser realmente agradable.
Detalles del análisis
• estáticas. C y Java tienen muy buen análisis estático. Perl no es completamente estática analizables en un nivel teórica (Posiblemente Python también). Estoy razonablemente seguro de Lisp no es tampoco.
• plataformas extraños sólo toman C, en general.
• cadena de soporte. Si usted puede tener un contrato que surtir sus errores mirado y trabajado, que de enorme .

Si se puede suponer que la organización que está trabajando tiene un principio de "En el futuro" (No es un término contable para esto), y no simplemente decidir aleatoriamente a no trabajar en el software, entonces usted tiene una mejor caso por utilizar el software. Dado que no hay negocio importante venta (llevando implicación de asumir la responsabilidad de su mantenimiento) Python / Perl / $ dynamic_language, se reduce considerablemente el riesgo.

En mi experiencia, los mantenedores de código abierto a menudo tienen un problema con la toma plenamente la responsabilidad de corrección de errores y la liberación de actualizaciones. "Es gratis, trabaja en él!" es no una respuesta que es aceptable para la mayoría de las empresas (no sus compentencies básicos, entre otras cosas).

Por supuesto, no estoy hablando de la / el mundo webapp de inicio, que tiende a jugar por el alto riesgo / alta recompensa reglas y ser muy abierto a permanecer en el borde de formación de espuma de la tecnología.

Answer 2

Usted le está dando demasiado crédito técnica a los tomadores de decisiones de la empresa. Hay un viejo dicho, "nadie fue despedido por comprar IBM". Si vas a una ruta diferente y las cosas se ponen rocosa (siempre lo hacen), nadie quiere arriesgarse a ser culpado. Se adhieren a las normas y culpar a alguien más.

Hay muchas empresas más jóvenes que con el tiempo se convertirán en las empresas del mañana y que se usen dichas lenguas.

Y no nos olvidemos de las líneas buggillion de código escrito en VBA!

Answer 3

La razón por empresas utilizan C, C ++, C # y Java no se debe a que se escriben de forma estática (al menos directamente). tomadores de decisiones de la empresa no están haciendo este tipo de decisiones sobre la base de una comparación objetiva de los sistemas de tipo, se lo aseguro.

Empresas lo cuidado acerca de:

• costes de mantenimiento a largo plazo : se puede razonablemente esperar que las cosas siguen así el trabajo dentro de 10 años? Es realmente una buena cosa si la evolución del lenguaje es conservador y compatible hacia atrás (como en Java). La tipificación estática es útil en este caso, ya que atrapa un importante tipo de errores en tiempo de compilación antes de que lleguen a su sistemas de producción .....
• Talento disponibilidad - usted será capaz de encontrar a los desarrolladores para mantener su nuevo sistema brillante? ¿y si las hojas desarrollador original, tendrá todos los demás entender el código? Esto supone una gran obstáculo en la introducción de cualquier lenguaje "nuevo" (especialmente si también crea nuevos requisitos para la implementación, sistemas de construcción, apoyo operativo, etc.). Esto da una masiva ventajas a los idiomas que se utilizan ampliamente (C, C ++, C # y Java)
• costes de integración : se facilita la conexión / integrarse con otras tecnologías que ya tiene en su lugar o es probable que se adquieren? Si ya tiene una pila de sistemas heredados J2EE, entonces usted necesita para integrarse con ellos. Una nueva solución de Java EE es probable que sea mucho más práctico para esto que, por ejemplo, Python.
• Predicatbility / bajo riesgo : se ha demostrado la plataforma / lenguaje, y puede estar seguro de que va a trabajar? Esto es por lo general más importante que la simple productividad. Es mucho más fácil para un gerente para convencer a su jefe para darle un gran presupuesto de mano de obra para construir un nuevo sistema de lo que es para él para volver más tarde y decir que no ha trabajado .....
• Empresa Soporte / soporte - son las principales organizaciones internacionales ha comprometido a apoyar el idioma y la plataforma? Van a firmar un contrato para que me apoye de manera que tengo a alguien que llame sobre si las cosas van mal?
• Vendedor neutralidad / independencia de la plataforma - voy a quedar encerrado en un solo proveedor? O tengo una amplia gama de opciones de proveedores caminos futuro / de transición disponibles? Usted no quiere ser atrapado en un callejón sin salida arquitectónica, incapaz de progresar, mientras que sus competidores comen su almuerzo. Si usted está haciendo su trabajo correctamente como un arquitecto de la empresa, tiene que estar pensando en por lo menos 5-10 años por delante en esta materia.

En lo personal, creo que si desea utilizar lenguajes dinámicos en la empresa, entonces su mejor oportunidad, con mucho, es el uso de algo que Piggy-Back en un ecosistema empresarial existente. Los más notables son los nuevos lenguajes dinámicos de JVM: por ejemplo, JRuby, Groovy, Clojure. En lo que respecta a la gestión de TI, se trata de opciones de idioma dinámico "seguros" debido a que operan dentro y juegan muy bien con el resto del ecosistema de la empresa de Java.

Answer 4

La razón principal por la que las empresas no empiezan a utilizar lenguajes como Erlang, Ruby y Python, parece ser el hecho de que son mecanografiada dinámico.

creo que esto es sólo su excusa primaria. La verdadera razón es que las empresas realmente no todos ellos toman en serio y que sienten que son quizás un poco demasiado aficionado. Java y .NET son “grandes nombres comerciales”, tener un buen marketing comercial, atención al cliente comercial, y por tanto son ampliamente tomado muy en serio.

Es desafortunado que no hay prácticamente ningún lenguaje de tipo estático que es ni de lejos tan popular como los grandes nombres de empresas. ¿Por qué son de código abierto / entornos de programación de software libre casi siempre escriben de forma dinámica? Esto podría indicar que un lenguaje estáticamente mecanografiada no es realmente tan fácil de hacer, y que tipado dinámico es un “truco del hombre perezoso”. Si ese es el caso, las empresas que deciden en contra de idiomas de tipo dinámico podrían en realidad tienen un punto.

Answer 5

• tipos dinámicos lenguas tienden a ser más lento que sus primos de tipos estáticos.
• Los errores son más difíciles de atrapar y pueden ser más difíciles de depurar
• El compilador / intérprete tiende a ser mucho menos exigente en lo que puede y no puede hacer. es decir, que prácticamente sólo detectar errores de sintaxis en la fase de compilación
• Si usted no es muy cuidadoso con el diseño de un lenguaje de tipos dinámicos, usted termina con Javascript, que es la lenguaje de código olores

EDIT: Debo mencionar que mi lenguaje de programación principal en este momento es Python, que se escribe de forma dinámica. En lo personal, me encanta la libertad que viene con no tener que variables de declarar previamente, pero a veces, gustaría Hay que ser agradable para especificar (por ejemplo) qué tipo de parámetros de una función lleva a errores de captura temprana en lugar que tarde.

Answer 6

tipos dinámicos idiomas son percibidos (por algunos programadores / jefes) de código de producto que no funciona así. El hecho de que un programa de tipos dinámicos compila le dice muy poco acerca de su corrección. El hecho de que un lenguaje de tipos estáticos compila te dice mucho más. (Por otro lado, todavía hay un largo camino entre recopila y hace lo correcto, por lo que este podría ser menos significativa entonces parece)

tipos dinámicos idiomas son percibidos como lenguajes de script. Nunca iba a escribir una aplicación en bash o un archivo por lotes. Todos los idiomas tipos dinámicos tienden a ser colocado en esa categoría (injustamente).

tipos dinámicos idiomas son más lentos y luego lenguas tipos estáticos. (Pero vamos a ver qué tan bien el trabajo sobre los cambios que JIT)

Answer 7

Nota: esto es sobre todo subjetivo y basado en mis experiencias e impresiones

.

tipos dinámicos lenguas son muy diferentes de las lenguas tipos estáticos. Estas diferencias probablemente se vuelven más importantes en software empresarial peso pesado que en la mayoría de otras aplicaciones.

tipos estáticos idiomas tienden a ser muy prescriptivo. Un método sólo tomará la entrada que coincide exactamente con su firma. Los niveles de acceso tienden a ser muy importante y las interfaces se definen explícitamente, pero con verbosa restricciones inequívocas en lugar de hacer cumplir esas definiciones.

tipos dinámicos idiomas, por otro lado son muy pragmático. Conversiones de tipos suceden a menudo de manera implícita, las funciones pueden incluso jugar a lo largo de si se proporciona el tipo incorrecto de entrada siempre que se comporta suficientemente similares. En lenguajes como Python, aunque los niveles de acceso se basan en un contrato en lugar de restricciones técnicas (es decir, es sólo private porque se le dice que no lo uso y tiene un nombre gracioso).

Muchos programadores prefieren los lenguajes dinámicos, ya que (posiblemente) permiten la rápida creación de prototipos. El código menudo termina más corto (aunque sólo sea por la falta de declaraciones de tipo) y si quieres violar el protocolo adecuado porque se necesita una solución rápida y sucia o desea probar algo, que es fácilmente posible.

Ahora, la razón por la que las empresas "enterprisey" a menudo prefieren lenguajes de tipos estáticos es exactamente que son más restrictivos y más explícito acerca de esas restricciones. Aunque en la práctica incluso el código estático de tipos puede ser roto por idiotas con un compilador, muchos problemas serán mucho más visibles mucho antes en el proceso (es decir, antes del tiempo de ejecución). Esto significa que incluso si el código base es grande, monolítica y complejo, muchos errores se pueden coger fácilmente, sin tener que ejecutar el código o enviarlo al departamento de control de calidad.

La razón de que el beneficio no compensa las desventajas para muchos programadores fuera de ese entorno es que estos son los errores que a menudo se coge fácilmente mediante inspección minuciosa del código o incluso al intentar ejecutarlo. Especialmente cuando se sigue una metodología basado en pruebas, estos errores a menudo se vuelven triviales para atrapar y fácil de solucionar. También, con muchas de estas empresas tiene un ciclo de liberación mucho más corto, la productividad es a menudo más importante que la rigidez y una gran cantidad de pruebas (básica) que se está haciendo por los propios desarrolladores.

La otra razón por la que las empresas no utilizan enterprisey idiomas tipos dinámicos es mucho código heredado. Tan tonto como puede parecer a nosotros los nerds, las grandes empresas a menudo se adhieren a las soluciones que funcionan, incluso si están bien más allá de su vida útil. Esta es la razón por lo que muchas empresas grandes hacen cumplir Internet Explorer 6 y son tan lentos para actualizar sus sistemas operativos. Esta es la razón por la que a menudo se escribe código nuevo en "viejos" lenguas (por ejemplo, versiones antiguas de Java): es mucho más fácil añadir unas pocas líneas de código para una pieza sin vida del software de las que obtener la aprobación para una reescritura completa en una nueva idioma.

tl; dr:. lenguas estáticas sentirse más como la burocracia, así que los encargados enterprisey como ellos mejor

Answer 8

No, no creo idiomas tipos dinámicos merecen toda la crítica. (O, si lo prefiere, que se merecen tanto la crítica como lenguas tipos estáticos.)

En mi experiencia (y no hago ningún intento de tratar de generalizar esta declaración), los programadores que critican los lenguajes dinámicos no han utilizado ellos. La conversación va generalmente "pero con tipos estáticos las capturas compilador tantos errores!" y digo "bueno, eso no es sólo un problema, en mi experiencia". (Por lo general, el otro programador de de un Java, Delphi o antecedentes similares;. No sé ningún programadores de Haskell o ML)

La única cosa que realmente me pegas es cuando las reclamaciones alguien que la técnica no pueden Foo posiblemente pueden hacer (o podrían ser muy difícil de hacer) en un lenguaje de tipos dinámicos ... cuando esa técnica fue inventado en, por y para un lenguaje de tipos dinámicos. IDE? Charla. refactorización automática? Charla. Las personas que llaman-de / ejecutores de? Smalltalk.

Answer 9

Las empresas simplemente no están adoptando nuevos lenguajes y herramientas lo suficientemente rápido y hay buenas razones para ello. Pero, cuando una de las herramientas convencionales como C # implementar algunas de estas características, entonces van a obtener por goteo a la empresas de corriente ....