architecture - hashtags - Programación de Polyglot: ¿Es una buena práctica construir aplicaciones con múltiples idiomas?

architecture hashtags instagram (11)

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.

Mi pensamiento es que puedo usar un lenguaje dinámico para escribir un montón de código rápidamente, y luego pasar a un lenguaje compilado como c / c ++ para implementar código de rendimiento crítico.

Puedo ver muchos beneficios de este enfoque:

Mayor productividad al codificar principalmente en el lenguaje dinámico
Disponibilidad de bibliotecas de ambos idiomas

Pero también hay algunos inconvenientes:

Mantener un puente entre los dos idiomas
Dependencia de dos idiomas y errores de lenguaje / biblioteca en lugar de uno

¿Cuáles son los otros pros / contras de este enfoque? ¿Alguien sabe acerca de los recursos y / o mejores prácticas en torno a esto?

Acabo de volver a leer su pregunta: su propuesta de usar 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 e intente hacerlo.

Creo que 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 cierto modo retrocediendo a un lenguaje compilado y optimizado para cosas de bajo nivel.

Creo que tu 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 ++.

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 los geeks de rendimiento están trabajando en un lenguaje que les gusta y que les da el control de bajo nivel que necesitan, mientras que los diseñadores de niveles pueden trabajar en un lenguaje de nivel superior donde no necesitan preocuparse por administrar la memoria y demás.

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 usan 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,

Estoy a favor de usar 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?

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, Ant, XML, XSLT ...

Creo que la programación políglota es natural, poderosa, eficiente y más que genial. 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.

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 .

Algunas personas argumentan que los programadores debemos dominar demasiados idiomas. 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 pesado: 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.

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

@ Zorkerman

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

Debo decir que son plataformas geniales, y se obtiene el enorme beneficio de los lenguajes dinámicos, MÁS la gran compatibilidad con bibliotecas de terceros y de primera clase de Java, además de un lenguaje compilado base independiente de la plataforma, MÁS recolección de basura en ambos idiomas (es importante entender 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 de kernel, o cosas que necesitan cada onza de rendimiento que puedas reunir).

Solo quiero dar una breve anécdota. 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 que elija, y la plataforma Java tiene tanto que ofrecer (y ha recorrido un largo camino desde los primeros días cuando la gente lo criticaba como mucho más lento 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 fluida (desde el lado JRuby al Java de todos modos), por lo que mantener un puente no es un problema. Jython, creo que es lo mismo, pero de nuevo mi experiencia con él es mucho menos.