dynamic-languages - type - dynamic vs static languages
¿Cómo se programa de manera diferente en los lenguajes dinámicos? (15)
Creo que la diferencia más dramática en la elección de las estructuras de datos.
En Java o CI define estructuras o clases muy estrictamente. Si necesito agregar una propiedad, retrocedo y cambio la definición.
En Perl usaré un hash e ''inventaré'' claves como código.
¿Cómo podría alguien que realmente sabe cómo aprovechar los lenguajes de programación dinámica acercarse a la programación de forma diferente que alguien que trabaja en un lenguaje estático?
Estoy familiarizado con todo el debate sobre la tipificación estática frente a la dinámica, pero no es a eso a lo que me refiero. Me gustaría analizar las técnicas de resolución de problemas que son prácticas en lenguajes dinámicos pero no en lenguajes estáticos.
La mayor parte del código que he visto escrito en lenguajes de programación dinámicos no es muy diferente al código escrito en lenguajes de programación estáticos. Como dice el refrán, puedes escribir FORTRAN en cualquier idioma, y muchas personas lo hacen. Pero algunas personas usan lenguajes de programación dinámicos para resolver problemas de una manera que no se traduciría fácilmente en, por ejemplo, C ++. ¿Cuáles son algunas de sus técnicas?
¿Cuáles son algunos buenos recursos que discuten cómo usar lenguajes de programación dinámicos? No libros sobre sintaxis de lenguaje o referencia de API, sino recursos sobre enfoques de resolución de problemas que aprovechan las capacidades dinámicas del lenguaje.
EDITAR (1/5/2009): Agradezco las respuestas a continuación, pero no parecen dar cuenta de los enormes aumentos de productividad que los defensores dinámicos del lenguaje dicen que experimentan.
En lenguajes dinámicos, soy más experimental. Es más fácil cambiar las cosas sobre la marcha, por lo que puedo explorar soluciones más rápido.
Si sé lo que quiero hacer y, en general, cómo hacerlo, me gusta C ++. Si no sé cómo hacer lo que quiero hacer, y probablemente no estoy completamente seguro de lo que quiero hacer, prefiero Lisp.
Los lenguajes dinámicos son capaces de ejecutar código que se creó en tiempo de ejecución. Esto es muy peligroso si se inyecta un código malicioso. Pero muy poderoso si puedes desinfectar el medio ambiente.
Creo que las personas de Javascript hacen esto al ejecutar archivos JSON.
Una forma en que normalmente me encuentro aprovechando los lenguajes de programación dinámicos es simplificando y aclarando la sintaxis. Si represento una base de datos, por ejemplo, la sintaxis que uso para interactuar con ella puede ser mucho más clara si puedo cargar dinámicamente propiedades y métodos en el objeto de base de datos para sus tablas, las tablas y filas para sus columnas, etc. . La diferencia puede ser entre:
$row = $db->getTable(''user'')->getRow(27);
$row->setValue(''name'', ''Bob'');
y
$row = $db->user->getRow(27);
$row->name = ''Bob'';
El ''ahorro de ruido visual'' de la segunda forma realmente comienza a sumarse cuando estás haciendo cosas complejas.
Las iteraciones rápidas hacen a los programadores más felices, y no vienen más rápido que un intérprete interactivo. Una buena explotación de intérpretes le proporciona un entorno de pruebas, pruebas y creación de prototipos al mismo tiempo.
Sin embargo, tenga cuidado con la programación por permutación. Mi regla personal es que es porque funciona no significa que esté listo, cuando puedes explicar por qué funciona, está listo.
Más bibliotecas y bibliotecas más útiles y más importantes.
Mi suposición es que el "Duck Typing" generalmente asociado con lenguajes dinámicos ayuda a simplificar el código significativamente y hace que escribir código genérico sea mucho más fácil. No está limitado por una estricta jerarquía de clases y, por lo tanto, puede componer más fácilmente componentes de diferentes bibliotecas.
Mis mayores ganancias están en el mapeo entre bases de datos y objetos (ORM).
Si no hay concepto de un tipo, es muy fácil decir asignar cada columna en una fila a un valor en un objeto. Por supuesto, la compensación es que puede haber un desajuste entre el tipo de valor que cree que existe y el tipo de computadora.
Los idiomas dinámicos pueden cambiar el objeto en tiempo de ejecución, puede agregar métodos, propiedades ...
Un buen ejemplo de la magia de Dynamic Languages es este fragmento de código Groovy que llama a un método en un servicio web en solo dos líneas de código:
def proxy = new SoapClient("http://localhost:6980/MathServiceInterface?wsdl");
def result = proxy.add(1.0, 2.0);
Este es otro fragmento de Groovy que extrae datos de XML:
def contacts = new XmlParser().parseText("<contacts><name>Bahaa Zaid</name></contacts>");
def myName = contacts.name[0].text();
No puedes hacer esto en Idiomas Estáticos. El lenguaje dinámico puede cambiar los objetos para reflejar la condición real de tiempo de ejecución.
John, basado en tu edición de actualización del 1/5/09, es posible que AMOP sea una lectura interesante y más en la línea en la que estás pensando. Es bastante ceceo-céntrico, pero después de todo muchas de las buenas ideas dinámicas comenzaron allí. Entonces, si puedes disfrutar (o superar) ese aspecto, los autores discuten los aspectos dinámicos necesarios y se usan para hacer algo como esto. Es algo bastante poderoso.
Me gusta la respuesta de Slim. Paso una gran cantidad de tiempo en Java y C ++ creando estructuras de datos personalizadas que son gratuitas en Python / Ruby. Y crear funciones especializadas para procesar estas estructuras de datos personalizadas. Sí, en C ++, STL es realmente agradable. Sí, los genéricos en Java son agradables. Ayudan a crear estructuras de datos personalizadas mucho más rápido, sin embargo, todavía requieren una gran cantidad de reflexión y consideración.
Sin embargo, hay una razón más fundamental por la cual los lenguajes dinámicos son más fáciles de trabajar. Es una idea profunda que se llama tipa de pato. Algunos de los comentarios anteriores se refieren a la mecanografía de pato, pero tómese un momento para reflexionar sobre qué tipo de pato es. Es una forma fundamentalmente diferente de ver el mundo. Una vista que es incompatible con lenguajes como Java y C ++.
Duck typing significa que no pierdes tiempo definiendo qué es un pato. Al no tener que definir formalmente sus objetos, ahorra mucho tiempo y energía. Obtener las definiciones correctas es difícil. Eche un vistazo a esta publicación de mi blog donde doy ejemplos: las definiciones formales son menos útiles de lo que cree
Duck typing ha demostrado ser extremadamente útil. El principio "Debe Ignorar" en XML es lo que ha hecho que XML sea tan significativo y útil en la web. Pero eso es solo una instancia de mecanografía pato.
Otra forma de expresar el tipado de pato es mediante el mantra de la web "Sé estricto con lo que envías, generoso con lo que aceptas". Esa es también una idea muy fundamental.
Finalmente, es posible que desee volver a una publicación de blog larga mía donde explico la tipificación de pato y cómo se relaciona con cosas como la IA y el modelado: Duck Typing, Artificial Intelligence and Philosophy
No tengo una respuesta específica, solo una sugerencia: eche un vistazo al libro " Patrones de diseño en Ruby ": repasa la mayoría de los patrones de diseño clásicos (a la Gamma et al., Y más) y los expresa, bastante sucintamente, en Ruby :)
Se trata de una de mis proporciones favoritas: cuánto tiempo paso pensando en resolver un problema, cuánto tiempo paso pensando en la herramienta que estoy usando para resolver el problema. Piense que es equivalente a las relaciones S / N.
Con los lenguajes de pato-mecanografía (que considero que es el factor que más me ayuda con la productividad), simplemente puedo dedicar más tiempo a pensar en mi problema y su solución (y escribir un código que los aborde específicamente), y gasto menos tiempo manteniendo los artefactos del lenguaje en línea recta.
Luego hay un montón de código que simplemente no escribo, que involucra declaraciones y especialmente cambios de tipos.
Pero principalmente mantiene mi enfoque en el punto óptimo.
No puedo citar esto ahora (mi memoria me está fallando), pero he escuchado algo como:
Lo más cerca que la industria de la programación ha llegado a una solución mágica son los lenguajes administrados, liberando al programador de tener que preocuparse por los detalles de la administración de la memoria y dejándolos concentrar más energía en la solución del problema en cuestión.
Entonces, me atrevería a adivinar y decir que no es tanto que programes de forma diferente , sino que puedes dedicar más de tu cerebro a "resolver el problema" en lugar de a los detalles de implementación de la solución.
Para mí, es la velocidad de respuesta. Los idiomas dinámicos que uso (Python y un poco de JavaScript en este momento) se interpretan. Esto significa que puedo probar cosas sobre la marcha. Si quiero ver cómo se comporta un poco de la API, puedo piratear al intérprete por un par de minutos.
Si quisiera hacer lo mismo en un lenguaje como C #, tendría que arrancar VS, hacer un proyecto y luego compilarlo. Si quiero probar una parte de un software más grande en el que estoy trabajando, probablemente tenga que compilar eso, lo que puede llevar años. Afortunadamente en .Net puedo cargar ensambles del gran proyecto en IronPython y obtener algunos de los mismos beneficios (es decir, probando rápidamente diferentes partes de la API) de idiomas interpretados.
Lea "Higher Order Perl" por Mark Jason Dominus. Solo trata sobre Perl pero proporciona técnicas que son naturales para Perl que serían menos naturales en la mayoría de los lenguajes estáticos.
All languages obviously have their strengths and weaknesses and dymanic vs static
es solo una de las muchas maneras de clasificar un idioma. No argumentaría que los lenguajes dinámicos como un todo son mejores o peores que los lenguajes estáticos. Pero sí creo que este libro es muy bueno para mostrar diferentes maneras de abordar problemas usando Perl que sería más difícil o imposible en la mayoría de los lenguajes estáticos.