¿Qué le atrae a la gente de los lenguajes dinámicos? [cerrado]

Parece que todos se están subiendo al tren dinámico y no compilado últimamente. En su mayoría, solo he trabajado en lenguajes compilados de tipo estático (C, Java, .Net). La experiencia que tengo con lenguajes dinámicos es cosas como ASP (Vb Script), JavaScript y PHP. Utilizar estas tecnologías me ha dejado mal sabor de boca a la hora de pensar en lenguajes dinámicos. Las cosas que normalmente el compilador habría detectado, como los nombres de variable mal escritos y la asignación de un valor del tipo incorrecto a una variable, no ocurren hasta el tiempo de ejecución. E incluso entonces, es posible que no note un error, ya que simplemente crea una nueva variable y asigna un valor predeterminado. Tampoco he visto nunca intellisense funcionar bien en un lenguaje dinámico, ya que, bueno, las variables no tienen ningún tipo explícito.

Lo que quiero saber es, ¿qué encuentra la gente tan atractiva sobre los lenguajes dinámicos? ¿Cuáles son las principales ventajas en términos de cosas que los lenguajes dinámicos le permiten hacer que no se pueden hacer o que son difíciles de hacer en lenguajes compilados? Me parece que decidimos hace mucho tiempo que cosas como páginas asp no compiladas que arrojan excepciones en tiempo de ejecución eran una mala idea. ¿Por qué hay un resurgimiento de este tipo de código? ¿Y por qué me parece, al menos, que Ruby on Rails realmente no se parece a nada que no pudieras haber hecho con ASP hace 10 años?

Creo que la razón es que la gente está acostumbrada a lenguajes de tipo estático que tienen sistemas de tipos muy limitados e inexpresivos. Estos son lenguajes como Java, C ++, Pascal, etc. En lugar de ir en la dirección de sistemas de tipos más expresivos y mejores inferencias de tipos (como en Haskell, por ejemplo, e incluso SQL hasta cierto punto), a algunas personas les gusta simplemente mantener toda la información de "tipo" en su cabeza (y en sus pruebas) y eliminar por completo la verificación de tipo estática.

Lo que esto te compra al final no está claro. Hay muchas nociones erróneas sobre la verificación de tipos, las que encuentro con más frecuencia son estas dos.

Falacia: los lenguajes dinámicos son menos prolijos. La idea errónea es que la información de tipo es igual a la anotación de tipo. Esto es totalmente falso. Todos sabemos que la anotación de tipo es molesta. La máquina debería poder resolver esas cosas. Y de hecho, lo hace en compiladores modernos. Aquí hay un QuickSort escrito estáticamente en dos líneas de Haskell (de haskell.org ):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Y aquí hay un QuickSort escrito dinámicamente en LISP (de swisspig.net ):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

El ejemplo de Haskell falsifica la hipótesis tipificada estáticamente, por lo tanto, detallada . El ejemplo LISP falsifica la hipótesis detallada, por lo tanto, estátipada estáticamente . No hay ninguna implicación en ninguna dirección entre la escritura y la verbosidad. Puede dejar eso fuera de su mente con seguridad.

Falacia: Los lenguajes tipados estáticamente deben compilarse, no interpretarse. De nuevo, no es cierto. Muchos lenguajes de escritura estática tienen intérpretes. Está el intérprete de Scala, los intérpretes de GHCi y Hugs para Haskell y, por supuesto, SQL se ha escrito e interpretado de forma estática durante más tiempo del que he estado vivo.

Ya sabes, tal vez la multitud dinámica solo quiere libertad para no tener que pensar tan cuidadosamente en lo que están haciendo. Es posible que el software no sea correcto o sólido, pero tal vez no tenga que serlo.

Personalmente, creo que aquellos que renunciarían a la seguridad tipográfica para comprar un poco de libertad temporal, no merecen ni libertad ni seguridad tipográfica.

No olvide que necesita escribir una cobertura de código 10x en pruebas unitarias para reemplazar lo que hace su compilador: D

He estado allí, he hecho eso con lenguajes dinámicos y no veo absolutamente ninguna ventaja.

Al leer las respuestas de otras personas, parece que hay más o menos tres argumentos para los lenguajes dinámicos:

1) El código es menos detallado. No encuentro esto válido. Algunos lenguajes dinámicos son menos detallados que algunos estáticos. Pero F # se escribe estáticamente, pero la escritura estática no agrega mucho código, si es que lo hay. Sin embargo, está escrito implícitamente, pero eso es algo diferente.

2) "Mi lenguaje dinámico favorito X tiene mi característica funcional favorita Y, por lo tanto, dinámico es mejor". No mezcle lo funcional y lo dinámico (no puedo entender por qué hay que decir esto).

3) En lenguajes dinámicos puedes ver tus resultados inmediatamente. Noticias: También puede hacer eso con C # en Visual Studio (desde 2005). Simplemente establezca un punto de interrupción, ejecute el programa en el depurador y modifique el programa mientras depura. Hago esto todo el tiempo y funciona perfectamente.

Yo mismo soy un firme defensor de la escritura estática, por una razón principal: mantenibilidad. Tengo un sistema con un par de 10k líneas de JavaScript en él, y cualquier refactorización que quiera hacer tomará como medio día ya que el compilador (inexistente) no me dirá qué es lo que arruinó el cambio de nombre de la variable. Y ese es el código que escribí yo mismo, en mi opinión también bien estructurado. No quisiera la tarea de estar a cargo de un sistema dinámico equivalente que alguien más escribió.

Supongo que recibiré una votación negativa por esto, pero me arriesgaré.

VBScript apesta, a menos que lo esté comparando con otra versión de VB. PHP está bien, siempre que tenga en cuenta que es un lenguaje de plantillas demasiado grande. El Javascript moderno es genial. De Verdad. Toneladas de diversión. Simplemente manténgase alejado de cualquier script etiquetado como "DHTML".

Nunca he usado un lenguaje que no permitiera errores en tiempo de ejecución. En mi humilde opinión, eso es en gran medida una pista falsa: los compiladores no detectan todos los errores tipográficos, ni validan la intención. La escritura explícita es excelente cuando necesita tipos explícitos, pero la mayoría de las veces no los necesita. Busque las preguntas aquí genericso sobre si el uso de tipos sin firmar fue una buena opción para las variables de índice; la mayor parte del tiempo, estas cosas simplemente se interponen en el camino y le dan a las personas perillas para jugar cuando tienen tiempo en sus manos. .

Pero, realmente no he respondido a tu pregunta. ¿Por qué son atractivos los lenguajes dinámicos? Porque después de un tiempo, la escritura de código se vuelve aburrida y solo desea implementar el algoritmo. Ya se sentó y lo resolvió todo con lápiz, hizo un diagrama de escenarios de problemas potenciales y demostró que se pueden resolver, y lo único que queda por hacer es codificar las veinte líneas de implementación ... y doscientas líneas de repetición para que se compile . Entonces te das cuenta de que el sistema de tipos con el que trabajas no refleja lo que estás haciendo en realidad, sino la idea ultra abstracta de otra persona de lo que podrías estar haciendo, y hace mucho que abandonaste la programación por una vida de ajustes de adornos, así que obsesivo-compulsivo que avergonzaría incluso al detective ficticio Adrian Monk.

Ahí es cuando vas a empezar a mirar seriamente los lenguajes dinámicos.

Soy un programador de .Net de tiempo completo totalmente arraigado en la agonía de C # de tipo estático. Sin embargo, me encanta el JavaScript moderno.

En términos generales, creo que los lenguajes dinámicos le permiten expresar su intención de manera más sucinta que los lenguajes de tipado estático, ya que dedica menos tiempo y espacio a definir cuáles son los componentes básicos de lo que está tratando de expresar cuando en muchos casos son evidentes.

Creo que también hay varias clases de lenguajes dinámicos. No tengo ningún deseo de volver a escribir páginas ASP clásicas en VBScript. Para que sea útil, creo que un lenguaje dinámico debe admitir algún tipo de colección, lista o construcción asociativa en su núcleo para que los objetos (o lo que pasa por objetos) se puedan expresar y le permitan construir construcciones más complejas. (Tal vez todos deberíamos codificar en LISP ... es una broma ...)

Creo que en los círculos .Net, los lenguajes dinámicos tienen mala reputación porque están asociados con VBScript y / o JavaScript. VBScript es simplemente recordado como una pesadilla por muchas de las razones por las que Kibbee declaró: cualquiera recuerda haber aplicado el tipo en VBScript usando CLng para asegurarse de tener suficientes bits para un entero de 32 bits. Además, creo que JavaScript todavía se ve como el idioma del navegador para los menús desplegables que está escrito de una manera diferente para todos los navegadores. En ese caso, el problema no es el idioma, sino los distintos modelos de objetos del navegador. Lo interesante es que cuanto más madura C #, más dinámico comienza a verse. Me encantan las expresiones Lambda, los objetos anónimos y la inferencia de tipos. Cada día se parece más a JavaScript.

Aquí hay un QuickSort escrito estáticamente en dos líneas de Haskell (de haskell.org):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Y aquí hay un QuickSort escrito dinámicamente en LISP (de swisspig.net):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Creo que estás sesgando las cosas con tu elección de idioma aquí. Lisp es notoriamente pesado por los padres. Un equivalente más cercano a Haskell sería Python.

if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

Código Python desde aquí

Para mí, la ventaja de los lenguajes dinámicos es que el código se vuelve mucho más legible debido a menos código y técnicas funcionales como el bloque de Ruby y la comprensión de listas de Python.

Pero luego echo de menos la verificación del tiempo de compilación (si ocurre un error tipográfico) y el autocompletado del IDE. En general, la menor cantidad de código y legibilidad vale la pena para mí.

Otra ventaja es la naturaleza normalmente interpretada / no compilada del lenguaje. Cambie algún código y vea el resultado de inmediato. Realmente es un ahorro de tiempo durante el desarrollo.

Por último, pero no menos importante, me gusta el hecho de que puedes encender una consola y probar algo de lo que no estás seguro, como una clase o método que nunca antes has usado y ver cómo se comporta. Hay muchos usos para la consola y lo dejo para que lo averigües.

Tus argumentos contra los lenguajes dinámicos son perfectamente válidos. Sin embargo, considere lo siguiente:

1. Los lenguajes dinámicos no necesitan compilarse : simplemente ejecútelos. Incluso puede volver a cargar los archivos en tiempo de ejecución sin reiniciar la aplicación en la mayoría de los casos.
2. Los lenguajes dinámicos son generalmente menos detallados y más legibles : ¿alguna vez ha mirado un algoritmo o programa dado implementado en un lenguaje estático y luego lo ha comparado con el equivalente de Ruby o Python? En general, lo que busca es una reducción en las líneas de código en un factor de 3. Una gran cantidad de código de andamiaje es innecesario en lenguajes dinámicos, y eso significa que el resultado final es más legible y más enfocado en el problema real en cuestión.
3. No se preocupe por los problemas de escritura : el enfoque general cuando se programa en lenguajes dinámicos es no preocuparse por la escritura: la mayoría de las veces, se pasará el tipo correcto de argumento a sus métodos. Y de vez en cuando, alguien puede usar un tipo diferente de argumento que resulta que también funciona. Cuando las cosas van mal, es posible que su programa se detenga, pero esto rara vez sucede si ha realizado algunas pruebas.

A mí también me dio un poco de miedo alejarme del mundo seguro de la escritura estática al principio, pero para mí las ventajas superan con creces las desventajas, y nunca miré hacia atrás.

Creo que el "nuevo amor descubierto" por los lenguajes de tipado dinámico tiene menos que ver con si los lenguajes de tipado estático son mejores o peores, en el sentido absoluto, que el aumento de la popularidad de ciertos lenguajes dinámicos. Ruby on Rails fue, obviamente, un gran fenómeno que provocó el resurgimiento de los lenguajes dinámicos. Lo que hizo que los rieles fueran tan populares y creó tantos conversos desde el campo estático fue principalmente: un código y configuración muy concisos y DRY. Esto es especialmente cierto en comparación con los marcos web de Java que requerían montañas de configuración XML. Muchos programadores de Java, también inteligentes, se convirtieron, y algunos incluso evangelizaron ruby ​​y otros lenguajes dinámicos. Para mí, tres características distintas permiten que los lenguajes dinámicos como Ruby o Python sean más concisos:

1. Sintaxis minimalista: la más importante es que no se requieren anotaciones de tipo, pero también el diseñador del lenguaje diseñó el lenguaje desde el principio para que sea conciso.
2. sintaxis de funciones en línea (o lambda): la capacidad de escribir funciones en línea y pasarlas como variables hace que muchos tipos de código sean más breves. En particular, esto es cierto para las operaciones de lista / matriz. Las raíces de estas ideas fueron obviamente - LISP.
3. Metaprogramación: la metaprogramación es una gran parte de lo que hace que los rieles funcionen. Dio lugar a una nueva forma de refactorizar código que permitió que el código cliente de su biblioteca fuera mucho más conciso. Esto también se origina en LISP.

Estas tres características no son exclusivas de los lenguajes dinámicos, pero ciertamente no están presentes en los lenguajes estáticos populares de hoy: Java y C #. Podría argumentar que C # tiene el número 2 en delegados, pero yo diría que no se usa ampliamente, como con las operaciones de lista.

En cuanto a lenguajes estáticos más avanzados ... Haskell es un lenguaje maravilloso, tiene # 1 y # 2, y aunque no tiene # 3, su sistema de tipos es tan flexible que probablemente no encontrará la falta de meta para ser limitante. Creo que puede hacer metaprogramación en OCaml en tiempo de compilación con una extensión de idioma. Scala es una incorporación muy reciente y muy prometedora. F # para el campamento .NET. Pero, los usuarios de estos lenguajes son una minoría, por lo que no contribuyeron realmente a este cambio en el panorama de los lenguajes de programación. De hecho, creo firmemente que la popularidad de Ruby afectó la popularidad de lenguajes como Haskell, OCaml, Scala y F # de forma positiva, además de los otros lenguajes dinámicos.

Personalmente, creo que es solo que la mayoría de los lenguajes "dinámicos" que ha utilizado resultan ser malos ejemplos de lenguajes en general.

Soy mucho más productivo en Python que en C o Java, y no solo porque tienes que hacer el baile de editar-compilar-enlazar-ejecutar. Me estoy volviendo más productivo en Objective-C, pero probablemente eso se deba más al marco.

No hace falta decir que soy más productivo en cualquiera de estos lenguajes que PHP. Demonios, prefiero codificar en Scheme o Prolog que en PHP. (Pero últimamente he estado haciendo más Prolog que cualquier otra cosa, ¡así que tómatelo con un grano de sal!)

Mi apreciación por los lenguajes dinámicos está muy ligada a lo funcionales que son. Las listas por comprensión de Python, los cierres de Ruby y los objetos prototipados de JavaScript son facetas muy atractivas de esos lenguajes. Todos también cuentan con funciones de primera clase, algo que no puedo ver sin vivir nunca más.

No categorizaría PHP y VB (script) de la misma manera. Para mí, esos son en su mayoría lenguajes imperativos con todos los inconvenientes de tipado dinámico que sugieres.

Claro, no obtiene el mismo nivel de comprobaciones en tiempo de compilación (ya que no hay tiempo de compilación), pero esperaría que las herramientas de comprobación de sintaxis estática evolucionen con el tiempo para abordar al menos parcialmente ese problema.

Una de las ventajas señaladas para los lenguajes dinámicos es simplemente poder cambiar el código y continuar ejecutándose. No es necesario volver a compilar. En VS.Net 2008, al depurar, puede cambiar el código y continuar ejecutándose sin una recompilación. Con los avances en compiladores e IDE, es posible que esta y otras ventajas de usar lenguajes dinámicos desaparezcan.

Ah, no vi este tema cuando publiqué una pregunta similar

Aparte de las buenas características que el resto de la gente menciona aquí sobre los lenguajes dinámicos, creo que todos se olvidan de una, la más básica: la metaprogramación.

Programando el programa.

Es bastante difícil de hacer en lenguajes compilados, por lo general, tome .Net. Para que funcione tienes que hacer todo tipo de mambo jumbo y normalmente termina con un código que corre unas 100 veces más lento.

La mayoría de los lenguajes dinámicos tienen una forma de hacer metaprogramación y eso es algo que me mantiene ahí: la capacidad de crear cualquier tipo de código en la memoria e integrarlo perfectamente en mi aplicación.

Por ejemplo, para crear una calculadora en Lua, todo lo que tengo que hacer es:

print( loadstring( "return " .. io.read() )() )

Ahora, intente hacer eso en .Net.

Mi principal razón para que me gusten los lenguajes dinámicos (mecanografiados, ya que ese parece ser el foco del hilo) es que los que he usado (en un entorno de trabajo) son muy superiores a los lenguajes no dinámicos que he usado. C, C ++, Java, etc ... son todos lenguajes horribles para realizar el trabajo real. Me encantaría ver un lenguaje tipado implícitamente que sea tan natural para programar en tantos de los tipeados dinámicamente.

Dicho esto, hay ciertas construcciones que son simplemente increíbles en los lenguajes tipados dinámicamente. Por ejemplo, en Tcl

 lindex $mylist end-2

El hecho de que pase "end-2" para indicar el índice que desea es increíblemente conciso y obvio para el lector. Todavía tengo que ver un lenguaje escrito estáticamente que logre eso.

Creo que este tipo de argumento es un poco estúpido: "Las cosas que normalmente el compilador habría detectado, como los nombres de variable mal escritos y la asignación de un valor del tipo incorrecto a una variable, no ocurren hasta el tiempo de ejecución" sí, eso es correcto como Desarrollador de PHP No veo cosas como variables mal escritas hasta el tiempo de ejecución, PERO el tiempo de ejecución es el paso 2 para mí, en C ++ (que es el único lenguaje compilado con el que tengo experiencia) es el paso 3, después de vincular y compilar.

Sin mencionar que se necesitan unos pocos segundos después de presionar guardar hasta que mi código está listo para ejecutarse, a diferencia de los lenguajes compilados, donde puede llevar literalmente horas. Lo siento si esto suena un poco enojado, pero estoy un poco cansado de que la gente me trate como un programador de segunda porque no tengo que compilar mi código.

El argumento es más complejo que esto (lea el artículo de Yegge "Is Weak Typing Strong Strong" para una descripción interesante).

Los lenguajes dinámicos tampoco carecen necesariamente de comprobación de errores; la inferencia de tipo de C # es posiblemente un ejemplo. De la misma manera, C y C ++ tienen controles de compilación terribles y están tipados estáticamente.

Las principales ventajas de los lenguajes dinámicos son a) la capacidad (que no necesariamente tiene que usarse todo el tiempo) yb) la ley de iteración de Boyd .

La última razón es enorme.

Aunque todavía no soy un gran admirador de Ruby, encuentro que los lenguajes dinámicos son herramientas realmente maravillosas y poderosas.

La idea de que no hay verificación de tipos y declaración de variables no es un problema demasiado grande. Es cierto que no puede detectar estos errores hasta el momento de la ejecución, pero para los desarrolladores experimentados esto no es realmente un problema, y ​​cuando comete errores, generalmente se solucionan fácilmente.

También obliga a los principiantes a leer con más atención lo que escriben. Sé que aprender PHP me enseñó a estar más atento a lo que estaba escribiendo, lo que ha mejorado mi programación incluso en lenguajes compilados.

Los buenos IDE le darán suficiente intellisense para que sepa si una variable ha sido "declarada" y también intentan hacer alguna inferencia de tipo por usted para que pueda saber qué es una variable.

El poder de lo que se puede hacer con lenguajes dinámicos es realmente lo que hace que trabajar con ellos sea tan divertido en mi opinión. Claro, podría hacer lo mismo en un lenguaje compilado, pero necesitaría más código. Los lenguajes como Python y PHP le permiten desarrollar en menos tiempo y obtener una base de código funcional más rápido la mayor parte del tiempo.

Y, para que conste, soy un desarrollador de .NET a tiempo completo y me encantan los lenguajes compilados. Solo uso lenguajes dinámicos en mi tiempo libre para aprender más sobre ellos y mejorar como desarrollador.

Creo que necesitamos los diferentes tipos de lenguajes en función de lo que estemos intentando conseguir, o solucionar con ellos. Si queremos una aplicación que cree, recupere, actualice y elimine registros de la base de datos a través de Internet, es mejor hacerlo con una línea de código ROR (usando el scaffold) que escribirlo desde cero en un lenguaje escrito estáticamente. El uso de lenguajes dinámicos libera las mentes de preguntarse sobre

• qué variable tiene qué tipo
• cómo hacer crecer una cadena dinámicamente según sea necesario
• cómo escribir código para que si cambio el tipo de una variable, no tenga que reescribir todas las funciones que interactúan con ella

a problemas más cercanos a las necesidades empresariales como

• los datos se guardan / actualizan, etc.en la base de datos, ¿cómo los uso para dirigir el tráfico a mi sitio?

De todos modos, una de las ventajas de los lenguajes de tipo flexible es que realmente no nos importa de qué tipo es, si se comporta como se supone que debe hacerlo. Esa es la razón por la que tenemos la escritura pato en lenguajes de escritura dinámica. es una gran característica y puedo usar los mismos nombres de variable para almacenar diferentes tipos de datos cuando surja la necesidad. Además, los lenguajes tipados estáticamente te obligan a pensar como una máquina (cómo interactúa el compilador con tu código, etc., etc.) mientras que los lenguajes tipados dinámicamente, especialmente ruby ​​/ ror, obligan a la máquina a pensar como un humano.

Estos son algunos de los argumentos que utilizo para justificar mi trabajo y experiencia en lenguajes dinámicos.

Creo que ambos estilos tienen sus puntos fuertes. En mi opinión, este pensamiento de uno u otro es paralizante para nuestra comunidad. He trabajado en arquitecturas que se escribieron estáticamente de arriba a abajo y estuvo bien. Mi arquitectura favorita es la de tipo dinámico en el nivel de la interfaz de usuario y de tipo estático en el nivel funcional. Esto también fomenta una barrera del idioma que refuerza la separación de la interfaz de usuario y la función.

Para ser cínico, puede ser simplemente que los lenguajes dinámicos permiten al desarrollador ser más perezoso y hacer las cosas sabiendo menos sobre los fundamentos de la informática. Si esto es bueno o malo, depende del lector :)

FWIW, la compilación en la mayoría de las aplicaciones no debería llevar horas. He trabajado con aplicaciones que tienen entre 200 y 500k líneas que tardan minutos en compilarse. Ciertamente no horas.

Yo mismo prefiero lenguajes compilados. Siento que las herramientas de depuración (en mi experiencia, lo que podría no ser cierto para todo) son mejores y las herramientas IDE son mejores.

Me gusta poder adjuntar mi Visual Studio a un proceso en ejecución. ¿Pueden otros IDE hacer eso? Tal vez, pero no los conozco. Últimamente he estado haciendo algunos trabajos de desarrollo de PHP y, para ser honesto, no es tan malo. Sin embargo, prefiero C # y VS IDE. Siento que trabajo más rápido y depuro problemas más rápido.

Entonces, ¿tal vez sea más una cuestión de conjunto de herramientas para mí que el problema del lenguaje dinámico / estático?

Un último comentario ... si está desarrollando con un servidor local, guardar es más rápido que compilar, pero muchas veces no tengo acceso a todo en mi máquina local. Las bases de datos y los archivos compartidos viven en otros lugares. Es más fácil enviar un FTP al servidor web y luego ejecutar mi código PHP solo para encontrar el error y tener que corregirlo y volver a ftp.

Productividad en un contexto determinado. Pero ese es solo un entorno que conozco, en comparación con otros que conozco o he visto utilizados.

Smalltalk en Squeak / Pharo con Seaside es una plataforma web mucho más efectiva y eficiente que ASP.Net (/ MVC), RoR o Wicket, para aplicaciones complejas. Hasta que necesite interactuar con algo que tenga bibliotecas en una de esas, pero no en smalltalk.

Los nombres de variable mal escritos están en rojo en el IDE, IntelliSense funciona pero no es tan específico. Los errores en tiempo de ejecución en las páginas web no son un problema sino una característica, un clic para abrir el depurador, un clic para mi IDE, corregir el error en el depurador, guardar, continuar. Para errores simples, el tiempo de ida y vuelta para este ciclo es menos de 20 segundos.

Los lenguajes dinámicos contraatacan

http://www.youtube.com/watch?v=tz-Bb-D6teE

Una charla sobre los lenguajes dinámicos, cuáles son algunos de los aspectos positivos y cuántos de los negativos no son realmente ciertos.

Porque considero estúpido tener que declarar el tipo de caja. El tipo permanece con la entidad, no con el contenedor. La escritura estática tenía sentido cuando el tipo de caja tenía una consecuencia directa sobre cómo se interpretaban los bits en la memoria.

Si echas un vistazo a los patrones de diseño en el GoF, te darás cuenta de que una buena parte de ellos están ahí solo para luchar con la naturaleza estática del lenguaje, y no tienen ninguna razón para existir en un lenguaje dinámico.

Además, estoy cansado de tener que escribir cosas como MyFancyObjectInterface f = new MyFancyObject (). ¿Principio SECO alguien?

Ponte en el lugar de un programador nuevo que selecciona un lenguaje para empezar, al que no le importa lo dinámico versus lo estático versus lambdas versus esto versus aquello, etc .; ¿Qué idioma elegirías?

C#

using System;
class MyProgram
{
    public static void Main(string[] args)
    {
        foreach (string s in args)
        {
            Console.WriteLine(s);
        }
    }
}

Lua:

function printStuff(args)
    for key,value in pairs(args) do
       print value .. " "
    end
end
strings = {
    "hello",
    "world",
    "from lua"
}
printStuff(strings)

Todo esto se reduce parcialmente a lo que es apropiado para los objetivos particulares y lo que es una preferencia personal común. (Por ejemplo, ¿va a ser una base de código enorme mantenida por más personas de las que pueden llevar a cabo una reunión razonable juntos? Quiere la verificación de tipos).

La parte personal se trata de intercambiar algunas comprobaciones y otros pasos por la velocidad de desarrollo y prueba (aunque es probable que se pierda algo de rendimiento de la CPU). Hay algunas personas para las que esto es liberador y un impulso de rendimiento, y hay algunas para las que esto es todo lo contrario, y sí, también depende del sabor particular de su idioma. Quiero decir que nadie aquí está diciendo que Java es genial para un desarrollo rápido y conciso, o que PHP es un lenguaje sólido en el que rara vez cometerá un error tipográfico difícil de detectar.

Me encantan los lenguajes estáticos y dinámicos. Cada proyecto en el que he estado involucrado desde aproximadamente 2002 ha sido una aplicación C / C ++ con una interpretación de Python incorporada. Esto me da lo mejor de ambos mundos:

1. Los componentes y marcos que componen la aplicación son, para una versión determinada de una aplicación, inmutables. También deben ser muy estables y, por lo tanto, bien probados. Un lenguaje escrito estáticamente es la elección correcta para construir estas piezas.
2. El cableado de los componentes, la carga de las DLL de los componentes, las ilustraciones, la mayor parte de la GUI, etc. pueden variar mucho (por ejemplo, para personalizar la aplicación para un cliente) sin necesidad de cambiar ningún marco o código de componentes. Un lenguaje dinámico es perfecto para esto.

Encuentro que la combinación de un lenguaje de tipo estático para construir el sistema y un lenguaje de tipo dinámico para configurarlo me da flexibilidad, estabilidad y productividad.

Para responder a la pregunta "¿Qué pasa con el amor por los lenguajes dinámicos?" Para mí, es la capacidad de volver a cablear completamente un sistema en tiempo de ejecución de cualquier forma imaginable. Veo el lenguaje de secuencias de comandos como "ejecutar el programa", por lo tanto, la aplicación en ejecución puede hacer lo que desee.

No tengo mucha experiencia con lenguajes dinámicos en general, pero el único lenguaje dinámico que conozco, JavaScript (también conocido como ECMAScript), me encanta.

Bueno, espera, ¿cuál es la discusión aquí? ¿Compilación dinámica? ¿O mecanografía dinámica? JavaScript cubre ambas bases, así que supongo que hablaré de ambas:

Compilación dinámica :

Para empezar, se compilan los lenguajes dinámicos , la compilación simplemente se pospone para más adelante. Y Java y .NET realmente se compilan dos veces. Una vez a sus respectivos lenguajes intermedios, y de nuevo, dinámicamente, al código máquina.

Pero cuando la compilación se pospone, puede ver los resultados más rápido. Esa es una ventaja. Disfruto simplemente guardando el archivo y viendo mi programa en acción bastante rápido.

Otra ventaja es que puede escribir y compilar código en tiempo de ejecución . Si esto es posible en código compilado estáticamente, no lo sé. Me imagino que debe serlo, ya que todo lo que compila JavaScript es, en última instancia, código de máquina y compilado estáticamente. Pero en un lenguaje dinámico, esto es algo trivial. El código puede escribirse y ejecutarse solo. (Y estoy bastante seguro de que .NET puede hacer esto, pero el CIL en el que se compila .NET se compila dinámicamente sobre la marcha de todos modos, y no es tan trivial en C #)

Escritura dinámica :

Creo que la escritura dinámica es más expresiva que la estática. Tenga en cuenta que estoy usando el término expresivo de manera informal para decir que la escritura dinámica puede decir más con menos. Aquí hay un código JavaScript:

var Person = {};

¿Sabes qué persona es ahora? Es un diccionario genérico. Puedo hacer esto:

Persona ["First_Name"] = "Juan";
Persona ["Apellido"] = "Smith";

Pero también es un objeto. Podría referirme a cualquiera de esas "claves" así:

Person.First_Name

Y agregue cualquier método que considere necesario:

Person.changeFirstName = function (newName) {
  this.First_Name = newName;
};

Seguro, puede haber problemas si newName no es una cadena. No se detectará de inmediato, si es que alguna vez lo hará, pero puede comprobarlo usted mismo. Se trata de cambiar el poder expresivo y la flexibilidad por seguridad. No me importa agregar código para verificar tipos, etc., yo mismo, y todavía no me he encontrado con un error de tipo que me haya causado mucho dolor (y sé que eso no dice mucho. Podría ser cuestión de tiempo: )). Sin embargo, disfruto mucho esa capacidad de adaptarme sobre la marcha.

Buena publicación de blog sobre el mismo tema: Python me pone nervioso

Las firmas de métodos son prácticamente inútiles en Python. En Java, la escritura estática convierte la firma del método en una receta: es toda la mierda que necesita para que este método funcione. No es así en Python. Aquí, la firma de un método solo le dirá una cosa: cuántos argumentos necesita para que funcione. A veces, ni siquiera hará eso, si empiezas a joder con ** kwargs.

Porque es divertido, divertido, divertido. Es divertido no preocuparse por la asignación de memoria, por ejemplo. Es divertido no esperar la compilación. etc etc etc

Los lenguajes de escritura débil permiten flexibilidad en la forma de administrar sus datos.

Usé VHDL la primavera pasada para varias clases, y me gusta su método de representar bits / bytes, y cómo el compilador detecta errores si intenta asignar un bus de 6 bits a un bus de 9 bits. Intenté recrearlo en C ++, y estoy teniendo una lucha justa para lograr que la escritura funcione sin problemas con los tipos existentes. Creo que Steve Yegge hace un buen trabajo al describir los problemas relacionados con los sistemas de tipos fuertes.

Con respecto a la verbosidad: Encuentro que Java y C # son bastante detallados en general (no escojamos pequeños algoritmos para "probar" un punto). Y sí, he escrito en ambos. C ++ también tiene problemas en la misma área; VHDL sucumbe aquí.

La parsimonia parece ser una virtud de los lenguajes dinámicos en general (presento Perl y F # como ejemplos).