2008-09-26 8 views
10

Estoy considerando crear una aplicación que sea una combinación de un lenguaje dinámico (python o ruby) y un lenguaje compilado, y necesito ayuda para convencerme de que esta es una buena idea.Programación Polyglot: ¿Es una buena práctica construir aplicaciones con múltiples idiomas?

Mi idea es que puedo usar un lenguaje dinámico para obtener una gran cantidad de código escrito rápidamente, y luego pasar a un lenguaje compilado como c/C++ para implementar código de rendimiento crítico.

puedo ver una gran cantidad de beneficios de este enfoque:

  1. Aumento de la productividad mediante la codificación principalmente en el lenguaje dinámico
  2. disponibilidad de las bibliotecas de ambos idiomas

Pero hay también algunos son desventajas:

  1. Mantenimiento de un puente entre los dos idiomas
  2. La dependencia de las dos lenguas y los insectos de la lengua/biblioteca en lugar de uno

¿Cuáles son las otras ventajas/desventajas de este enfoque? ¿Alguien sabe acerca de los recursos y/o mejores prácticas en torno a esto?

Respuesta

12

Creo que su enfoque es muy sensato. La forma de abordar las desventajas es averiguar con anticipación qué tan fácil es interactuar el lenguaje dinámico con C o C++ antes de decidir si usarlo o no para su proyecto.

Además, debe pensar si desea que su aplicación sea multiplataforma. Un lenguaje dinámico es mucho menos dependiente de la plataforma que un compilado. Ese puede ser un factor para decidir qué partes de la aplicación se deben hacer en C o C++.

3

Sí. Muchos programas son una combinación de un lenguaje de alto nivel, como Python o Ruby, y un lenguaje de bajo nivel como C. Obtienes los beneficios de la lógica de codificación en un lenguaje OO recolectado en la basura y aún puedes administrar registros manualmente dentro de circuitos internos ajustados .

1

Creo que esta es una buena idea.

Dado que la mayoría de los sistemas operativos (¿casi todos?) Están escritos en C o C++, cada lenguaje dinámico o interpretado se encuentra en algún momento retrocediendo a un lenguaje compilado y optimizado para cosas de bajo nivel.

5

Ja, bien sur, mein freund. Es un'idea meravigliosa de hecho. Boa sorte.

Estoy bromeando, por supuesto. Un desarrollador web hace eso todos los días sin siquiera darse cuenta: Java, JSP, EL/OGNL, HTML, CSS, Javascript, hormiga, XML, XSLT ...

Creo que la programación de políglota es natural, potente, eficiente y más que nada guay. Tiene que ser utilizado de la manera correcta, por supuesto, para aprovechar la potencia máxima de cada idioma y para no confundir a las otras personas en su equipo.

+0

Exactamente, la mayoría de las cosas que estoy escribiendo están en PHP, XML, XSLT, CSS, HTML y JS. El desarrollo web utiliza la mejor herramienta para el trabajo en varios lugares todo el tiempo. –

+0

XSLT? Es como el griego para mí. Sin embargo, olvidó SQL en esa lista. –

+0

@Christopher Mahan: ¡Sí! Exactamente, como dije, "sin siquiera darme cuenta" :) –

2

Es posible que no necesite implementar ningún elemento crítico para el rendimiento hasta más adelante. Por lo tanto, lucharía mucho contra la entrada de uno de estos cambios importantes críticos para el rendimiento hasta que esté realmente seguro de que debe hacerlo.

De lo contrario, simplemente elija un idioma raíz, perl y ruby ​​use c, por lo que su incorporación es bastante simple. También podría ejecutar python (jython) o ruby ​​(jrunby) en una máquina virtual Java, lo que le daría java como back-end. Aunque podría proporcionar algunos otros problemas, ya que no estoy familiarizado con el desarrollo en contra de esas versiones de los respectivos idiomas.

no todos los problemas de rendimiento requerirán que baje a un lenguaje de bajo nivel, así que intente abordarlo primero en una languga, antes de saltar rápidamente a otra.

Buena suerte,

2

estoy a favor de utilizar la mejor herramienta para el trabajo. En el caso de la ingeniería de software eso significa ser políglota. Nunca esperarías que un carpintero use solo un martillo, sin importar lo que esté construyendo. ¿Por qué debería ser diferente para nosotros?

0

Es bastante común, pero asegúrese de saber por qué lo está diseñando de la manera en que lo hace.

Un ejemplo es en la programación de juegos. En muchos juegos, el motor de juego crítico para el rendimiento está escrito en C, mientras que las secuencias de comandos de nivel se hacen en Python, Scheme, un lenguaje nacional o lo que sea.

Esto significa que el rendimiento de los frikis están trabajando en un idioma que les gusta y lo que les da el control de bajo nivel que necesitan, mientras que los diseñadores de niveles pueden trabajar en un lenguaje de alto nivel en el que no tiene que preocuparse por la gestión de la memoria y etcétera.

2

@Zorkerman

Tengo experiencia tanto con Jython y JRuby ... mucho más con JRuby.

Debo decir que son excelentes plataformas, y se obtiene el enorme beneficio de los lenguajes dinámicos, ADEMÁS de la gran compatibilidad con bibliotecas de terceros y de primera clase de Java, además de un lenguaje compilado base independiente, además de recolección de basura en ambos idiomas (es importante entender la administración de la memoria, pero soy del campo en el que es mejor que lo evites a menos que realmente lo necesites, como si estuvieras haciendo controladores o cosas a nivel del núcleo, o cosas que necesitan cada onza de rendimiento que puedas reunir)

Solo quiero dar una anécdota rápida. Hace poco estaba construyendo un script de ruby ​​para indexar una instancia de Solr, y necesitaba acceder a una base de datos DB2 (la fuente de nuestros datos para indexar). Straight Ruby falló miserablemente ... tiene una compatibilidad horrible con DB2, que requiere una instalación completa de DB2 express edition ... que aún no funcionaba como se anunciaba (no pude compilar los controladores Ruby una vez que terminé la instalación). La solución fue simplemente cambiar a JRuby y usar JDBC desde el lado de Ruby, usando un par de tarros fáciles de instalar (y mucho MUCHO más pequeños que la instalación de DB2).

Definitivamente recomendaría altamente considerar JRuby o Jython en lugar de utilizar C como su back-end ... He descubierto que el algoritmo y el rendimiento de los recursos generalmente tienen un impacto mucho mayor en el rendimiento de la aplicación que el idioma elegido, y la plataforma Java tiene mucho que ofrecer (y ha recorrido un largo camino desde los primeros días en que las personas decían que era mucho más lenta que C/C++). A menos que esté haciendo cálculos muy intensivos que no se pueden refactorizar algorítmicamente, lo más probable es que no tenga que bajar al idioma compilado, independientemente de su elección.


PS La integración con Java en JRuby es muy transparente (desde el lado JRuby a Java de todos modos), por lo que el mantenimiento de un puente no es un problema. Jython, creo que es lo mismo, pero de nuevo mi experiencia con él es mucho menos.

6

Acabo de volver a leer su pregunta: su propuesta de utilizar C para el código de rendimiento crítico. Cualquier lenguaje dinámico que valga la pena tiene herramientas para permitirle acceder al código nativo de manera eficiente. Así que comience escribiendo todo en el lenguaje dinámico. Después de todo, puede descubrir que no necesita C.

Pero si lo hace, establezca un generador de perfiles, elija cuidadosamente algo para optimizar y listo.

2

Vale la pena señalar que Gambit Scheme y pollo (y algunas otras implementaciones para el caso) se ejecutan en un modo interpretado, y luego se puede compilar a C.

1

Algunas personas argumentan que nosotros, los programadores deben dominar demasiado muchos lenguajes. Ellos argumentan que agregar un idioma es A Bad Thing.

Todo el acceso a los datos en SQL, la presentación en HTML/CSS parece ser irreversible.

Lo XML es un poco molesto: algunas personas intentan hacer todo en XML, como si XML tuviera poderes mágicos para mejorar el software.

Además, hay una buena cantidad de redundancia debido a los múltiples idiomas. Todas las vinculaciones entre idiomas significan que las cosas se escriben dos veces, una vez en cada idioma.

Cuestiones relacionadas