it-swarm-es.com

¿Los lenguajes mecanografiados dinámicos merecen todas las críticas?

He leído algunos artículos en Internet sobre la elección del lenguaje de programación en la empresa. Recientemente, muchos lenguajes mecanografiados dinámicos han sido populares, es decir, Ruby, Python, PHP y Erlang. Pero muchas empresas aún se quedan con lenguajes mecanografiados estáticos como C, C++, C # y Java.

Y sí, uno de los beneficios de los lenguajes de tipo estático es que los errores de programación se detectan antes, en tiempo de compilación, en lugar de en tiempo de ejecución. Pero también hay ventajas con los lenguajes de tipo dinámico. ( más en Wikipedia )

La razón principal por la cual las empresas no comienzan a usar lenguajes como Erlang, Ruby y Python, parece ser el hecho de que son de tipo dinámico. Esa también parece ser la razón principal por la cual las personas usan StackOverflow decide contra Erlang. Vea ¿Por qué decidió "contra" Erlang .

Sin embargo, parece haber una fuerte crítica contra la escritura dinámica en las empresas, pero realmente no entiendo por qué es que fuerte.

Realmente, ¿por qué hay tanta crítica contra la tipificación dinámica en las empresas? ¿Realmente afecta tanto el costo de los proyectos o qué? Pero tal vez me equivoque.

35
Jonas

Sí, creo que sí.

Hay algunas razones que deben considerarse en la selección de un idioma para un nuevo proyecto:

  • Velocidad de tiempo de ejecución. En comparación con C/C++/Fortran, Perl y Python son tan lentos que es divertido.
  • Velocidad de inicialización. En comparación con los lenguajes rápidos anteriores, Java se cae y llora mientras la JVM sigue cargando y cargando y ...while(1) .. ..
  • Capacidad de prototipo. Pasar exhaustivamente y realizar el trabajo de declaración/definición requerido para C++ o Java aumenta el LOC, que es la métrica conocida solo que se correlaciona de manera confiable con la cantidad de errores. También lleva mucho tiempo. También requiere pensar un poco más sobre los tipos y las conexiones.
  • Fiddlability interno. Jugar dinámicamente con sus componentes internos es excelente hasta que comience a depurar su código de auto-modificación . (Python, LISP, Perl)
  • Verificación de corrección. Un compilador puede proporcionar un paso rápido de semi-corrección de su código en C++, y esto puede ser realmente Agradable.
  • Detalles de análisis estático. C y Java tienen un análisis estático bastante bueno. Perl no es completamente analizable estáticamente a un nivel teórico (Posiblemente Python también). Estoy razonablemente seguro de que LISP tampoco.
  • Las plataformas extrañas solo toman C, en general.
  • Cadena de soporte. Si puede tener un contrato en el que revise y trabaje sus errores, eso es enorme .

Si puede presumir que la organización con la que está trabajando tiene un principio de "Avanzar" (Hay un término contable para esto), y no lo hará simplemente al azar decide no trabajar en el software, entonces tiene un caso mucho mejor para usar el software. Dado que no hay ventas comerciales importantes (lo que implica asumir la responsabilidad de mantenerlo) Python/Perl/$ dynamic_language, reduce considerablemente el riesgo.

En mi experiencia, los mantenedores de código abierto a menudo tienen un problema con asumir la responsabilidad total de las correcciones de errores y lanzar actualizaciones. "¡Es gratis, TÚ trabajas en ello!" es no una respuesta que es aceptable para la mayoría de las empresas (no sus competencias básicas, entre otras cosas).

Por supuesto, no estoy hablando del mundo de aplicaciones web/startup, que tiende a jugar con reglas de alto riesgo/alta recompensa y está muy abierto a quedarse en el borde de la tecnología.

46
Paul Nathan

Está dando demasiado crédito técnico a los responsables de la toma de decisiones empresariales. Hay un viejo dicho, "Nadie fue despedido por comprar IBM". Si tomas una ruta diferente y las cosas se ponen difíciles (siempre lo hacen), nadie quiere arriesgarse a ser culpado. Cumplir con los estándares y culpar a alguien más.

Hay muchas compañías más jóvenes que eventualmente se convertirán en las empresas del mañana y usarán esos idiomas.

¡Y no olvidemos las miles de líneas de código escritas en VBA!

24
JeffO

La razón por la cual las empresas usan C, C++, C # y Java no es porque estén tipadas estáticamente (al menos no directamente). Los tomadores de decisiones empresariales no están haciendo este tipo de elecciones sobre la base de Una comparación objetiva de los sistemas de tipos, te lo aseguro.

A las empresas les importa :

  • Costos de mantenimiento a largo plazo: ¿puede esperar razonablemente que las cosas sigan funcionando bien en 10 años? En realidad, es bueno que la evolución del lenguaje sea conservadora y compatible con versiones anteriores (como con Java). La escritura estática es útil aquí porque detecta un tipo importante de errores en tiempo de compilación antes de que entren en sus sistemas de producción .....
  • Disponibilidad de talento - ¿podrás encontrar desarrolladores para mantener tu nuevo y brillante sistema? ¿Qué pasa si el desarrollador original se va, todos los demás entenderán el código? Esto plantea un 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, soporte operativo, etc.) Esto ofrece enormes ventajas a los lenguajes que se usan ampliamente (C, C++, C # y Java)
  • Costos de integración: ¿es fácil conectarse/integrarse con otras tecnologías que ya tiene implementadas o que es probable que adquiera? Si ya tiene una pila de sistemas J2EE heredados, entonces necesita integrarse con ellos. Es probable que una nueva solución Java EE) sea mucho más práctica para esto que, por ejemplo, Python.
  • Previsibilidad/bajo riesgo: ¿está probada la plataforma/lenguaje y puedo estar seguro de que funcionará? Esto suele ser más importante que la simple productividad. Es mucho más fácil para un gerente persuadir a su jefe para que le dé un gran presupuesto de mano de obra para construir un nuevo sistema que para él regresar más tarde y decir que no ha funcionado .....
  • Enterprise Backing/support - ¿Las principales organizaciones internacionales están comprometidas a apoyar el lenguaje y la plataforma? ¿Firmarán un contrato para apoyarme para que pueda llamar a alguien si las cosas salen mal?
  • neutralidad del proveedor/independencia de la plataforma - ¿Me voy a encerrar en un solo proveedor? ¿O tengo una amplia gama de opciones de proveedores futuros/rutas de transición disponibles? No querrás estar atrapado en un callejón sin salida arquitectónico, incapaz de avanzar mientras tus competidores almuerzan. Si está haciendo su trabajo correctamente como arquitecto empresarial, debe pensar con al menos 5-10 años de anticipación en estas cosas.

Personalmente, creo que si desea utilizar lenguajes dinámicos en la empresa, su mejor oportunidad es utilizar algo que se apoye en un ecosistema empresarial existente. Los más notables son los nuevos lenguajes dinámicos de JVM: p. JRuby, Groovy, Clojure. En lo que respecta a la gestión de TI, estas son opciones de lenguaje dinámico "seguras" porque operan dentro y juegan muy bien con el resto del ecosistema empresarial Java).

18
mikera

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

Creo que esta es solo su principal excusa. La verdadera razón es que las empresas realmente no los toman tan en serio y sienten que tal vez son demasiado aficionados. Java y .NET son "nombres de grandes empresas", tienen buen marketing comercial, atención al cliente comercial y, por lo tanto, se los toma muy en serio.

Es desafortunado que prácticamente no haya un lenguaje de tipo estático que sea tan popular como los nombres de las grandes empresas. ¿Por qué los entornos de programación de código abierto/software libre casi siempre se escriben dinámicamente? Esto podría indicar que un lenguaje de tipo estático en realidad no es tan fácil de hacer, y que el tipeo dinámico es un "truco de hombre vago". Si ese es el caso, las empresas que deciden en contra de los idiomas de tipo dinámico podrían realmente tener un punto.

11
Timwi
  • Los idiomas de tipo dinámico tienden a ser más lentos que sus primos de tipo estático.
  • Los errores son más difíciles de detectar y pueden ser más difíciles de depurar
  • El compilador/intérprete tiende a ser mucho menos exigente con lo que puede y no puede hacer. es decir, solo detecta errores de sintaxis en la etapa de compilación
  • Si no tiene mucho cuidado con el diseño de un lenguaje de tipo dinámico, termina con Javascript, que es el idioma de los olores de código

EDIT: Debo mencionar que mi lenguaje de programación principal en este momento es Python, que se escribe dinámicamente. Personalmente, me encanta la libertad que viene de no tener que pre-declarar variables, pero a veces, sería Sería bueno especificar (por ejemplo) qué tipo de parámetros que toma una función para detectar errores antes que tarde.

9
Chinmay Kanchi

Los lenguajes tipados dinámicamente son percibidos (por algunos programadores/jefes) para producir código que no funciona tan bien. El hecho de que un programa escrito dinámicamente compila le dice muy poco acerca de su corrección. El hecho de que un lenguaje estáticamente compilado te dice mucho más. (Por otro lado, todavía hay un largo camino entre las compilaciones y hace lo correcto, por lo que esto podría ser menos significativo de lo que parece)

Los lenguajes de tipo dinámico se perciben como lenguajes de secuencias de comandos. Nunca escribirías una aplicación en bash o un archivo por lotes. Todos los idiomas escritos dinámicamente tienden a agruparse en esa categoría (injustamente).

Los idiomas escritos dinámicamente son más lentos que los idiomas escritos estáticamente. (Pero veremos qué tan bien el trabajo en JIT cambia eso)

8
Winston Ewert

Nota: esto es principalmente subjetivo y se basa en mis experiencias e impresiones.

Los idiomas escritos dinámicamente son muy diferentes de los idiomas escritos estáticamente. Estas diferencias probablemente se vuelvan más importantes en el software empresarial pesado que en la mayoría de las otras aplicaciones.

Los lenguajes de tipo estático tienden a ser muy prescriptivos. Un método solo tomará datos que coincidan exactamente con su firma. Los niveles de acceso tienden a ser muy importantes y las interfaces se definen explícitamente, con restricciones detalladas pero inequívocas para aplicar esas definiciones.

Los lenguajes escritos dinámicamente, por otro lado, son muy pragmáticos. Las conversiones de tipos a menudo ocurren implícitamente, las funciones pueden incluso jugarse si proporciona el tipo de entrada incorrecto siempre que se comporte lo suficientemente similar. En lenguajes como Python, incluso los niveles de acceso se basarán en el contrato y no en restricciones técnicas (es decir, solo private porque se le dice que no lo use y tiene un nombre divertido).

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

Ahora, la razón por la que las empresas "empresariales" a menudo prefieren los idiomas de tipo estático es exactamente que son más restrictivas y más explícitas acerca de esas restricciones. Aunque en la práctica, incluso los códigos tipeados estáticamente pueden ser rotos 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 la base de código es grande, monolítica y compleja, se pueden detectar muchos errores 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 supere las desventajas para muchos programadores fuera de ese entorno es que estos son errores que a menudo se detectarán fácilmente mediante una inspección exhaustiva del código o incluso al intentar ejecutarlo. Especialmente cuando se sigue una metodología basada en pruebas, estos errores a menudo se vuelven triviales y fáciles de solucionar. Además, con muchas de estas compañías que tienen un ciclo de lanzamiento mucho más corto, la productividad es a menudo más importante que la rigidez y los desarrolladores mismos están realizando muchas pruebas (básicas).

La otra razón por la que las corporaciones empresariales no usan mucho los lenguajes escritos dinámicamente es el código heredado. Por tonto que nos parezca a los nerds, las grandes corporaciones a menudo se apegarán a soluciones que funcionen, incluso si ya han pasado su vida útil. Esta es la razón por la cual muchas compañías importantes aplican Internet Explorer 6 y son tan lentas para actualizar sus sistemas operativos. Esta es también la razón por la que a menudo escriben código nuevo en lenguajes "antiguos" (por ejemplo, versiones antiguas de Java): es mucho más fácil agregar algunas líneas de código a un software que no está vivo que obtener la aprobación para una reescritura completa en un nuevo idioma.

tl; dr: los lenguajes estáticos se parecen más a la burocracia, por lo que a los gerentes empresariales les gustan más.

8
Alan Plum

No, no creo que los lenguajes escritos dinámicamente merezcan todas las críticas. (O, si lo prefiere, se merecen tanta crítica como los lenguajes estáticamente escritos).

En mi experiencia (y no intento intentar generalizar esta afirmación), los programadores que critican los lenguajes dinámicos no los han usado. La conversación suele ser "pero con la escritura estática, el compilador detecta tantos errores". y digo "bueno, eso no es un problema, en mi experiencia". (Por lo general, el otro programador es de Java, Delphi o similar; no conozco a ningún programador de Haskell o ML).

Lo único que realmente me fastidia es cuando alguien afirma que la técnica Foo no puede posiblemente hacerse (o puede ser muy difícil de hacer) en un lenguaje de tipo dinámico ... cuando esa técnica se inventó en , por y para un lenguaje de tipo dinámico. IDEs? Charla. Refactorización automática? Charla. Llamadores de/implementadores de? Charla.

4
Frank Shearar

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 principales como C # implementa algunas de estas características, se introducirán en las empresas principales ...

0
aggietech