Usando diferentes idiomas en un proyecto

Question

Hace poco escuché sobre el uso de varios idiomas en un proyecto (grande), también leí acerca de servicios famosos como Twitter usando Rails como frontend, mezclado con algunos otros idiomas, y Scala creo fue como back-end.

• ¿Es esta la práctica habitual? ¿Quién hace eso?

• Estoy seguro de que esto tiene desventajas. Creo que tendrá problemas con los diferentes intérpretes/compiladores y conectará sin problemas los diferentes idiomas. ¿Es esto cierto?

• ¿Por qué se hace esto realmente? Para el rendimiento?

Answer 1

Creo que en el caso de Twitter estuvo relacionado con el rendimiento; Scala es bastante más rápido que Ruby, y lo usan para alimentar sus sistemas de cola.

Además de los problemas de mantenimiento, el uso de varios idiomas juntos puede ayudar a compensar las desventajas en cada idioma. Con Twitter, Ruby (on Rails) es ideal para ejecutar la interfaz de su sitio, pero tiene más sentido utilizar un lenguaje más rápido para procesar las tareas secundarias. La integración entre los idiomas no es difícil cuando se trata de sistemas de colas, ya que pueden estar completamente separados de la aplicación en sí y aún así realizar sus tareas correctamente.

Answer 2

La pregunta se reduce esencialmente a los idiomas específicos del dominio (DSL). A veces, un idioma es más adecuado para una parte del programa y otro para otro. Los beneficios (velocidad de ejecución o facilidad de desarrollo) a menudo superan los inconvenientes de mezclar múltiples idiomas.

• ¿Es esta la práctica habitual? ¿Quién hace eso?

muy común; Yo diría que casi todas las aplicaciones grandes están escritas en más de un idioma.

Considere el ejemplo de un juego. El motor central generalmente se escribe en C o C++ para la velocidad y el acceso de hardware de bajo nivel, pero el comportamiento de los objetos y los caracteres está escrito en un lenguaje de nivel superior como Lua.

• estoy seguro de que hay desventajas a esto. Creo que tendrá problemas con los diferentes intérpretes/compiladores y conectará sin problemas los diferentes idiomas. ¿Es esto cierto?

Sí, hay una cierta cantidad de sobrecarga para permitir scripts para acceder a los objetos del juego y tal.

• ¿Por qué se hace esto realmente? Para el rendimiento?

Sí y no. Si el rendimiento no fuera un problema, todo el juego podría escribirse en un lenguaje de scripting.Algunas otras razones son:

• Velocidad de desarrollo; imagina la sobrecarga si todos los pequeños objetos y personajes en un juego como World of Warcraft fueron escritos en C++. El programa debería compilarse y reiniciarse para cada pequeño cambio.

• Modularidad; los objetos nuevos se pueden descargar, agregar y eliminar fácilmente en tiempo de ejecución, y los usuarios inteligentes incluso pueden modificarlos.

• Portabilidad; los mismos scripts se ejecutarán sin modificaciones en diferentes plataformas.

Answer 3

Tengo varios proyectos con lenguajes mixtos

En un caso tengo algunas F # mezclados con C#, porque f # me permitió codificar un problema más fácil (y era un desafío)

otros casos haría estar mezclando Silverlight y .net en el mismo proyecto - utilizan diferentes CLR

en otros casos tengo vb.net yC# cuando las empresas tenían programadores que usan múltiples idiomas - la mayoría de las personas con las que trabajo no pueden leer c .. . Cualquier código hecho en eso probablemente no sería n los mejores intereses del empleador.

La principal desventaja es que todos los que trabajan en el código deben conocer todos los idiomas.

No es algo que hago a menudo, pero realmente se trata de las herramientas para el trabajo imo.

No diría que está hecho para el rendimiento por lo general ... aunque he vinculado a C++ dll cuando necesito algo muy rápido (algoritmos gráficos antes de que pudiera hacer cualquier cosa) ... las decisiones el rendimiento circundante es mayor que el tiempo de cálculo. Todos los gastos generales habituales, como la escalabilidad, la facilidad de lectura todavía entran en juego. Es decir, creo que se puede decir que es sobre el rendimiento, siempre y cuando usted no limitar el rendimiento en el sentido de la ejecución de programas f En la velocidad o

Answer 4

En una típica aplicación embebida que escribo para el 8051, he participado varios idiomas:

• C: la mayor parte de la aplicación está en C, ya que es mucho más rápida de escribir, pero es fácil de producir código ajustado que se ajusta a 64k (o menos) de espacio de código.
• Lenguaje ensamblador: a veces no se puede salir con el código generado por el compilador. Cuando cada byte cuenta, las reglas del lenguaje ensamblador.
• Perl - Varias de mis herramientas de compilación están escritas en Perl. Un lenguaje poderoso, flexible y dinámico como Perl hace que sea fácil trabajar con imágenes ROM y manejar muchos aspectos del proceso de compilación.
• GNU make - ¿Huh? Sí, hacer es un lenguaje. Es un lenguaje declarativo (que es otra categoría de lenguaje a la par con "orientado a objetos", "funcional" e "imperativo"). Make es la base de mi sistema de compilación.

Lo hago porque me gusta usar la herramienta adecuada para cada trabajo. Debo usar C y ensamblador para el pequeño micro de 8 bits. Uso C tanto como sea posible porque hago más trabajo. Uso Perl para manejar tareas complejas relacionadas con la compilación, porque es más productivo que C y más potente y portátil que bash.Utilizo GNU make como la base de mi compilación porque está muy bien adaptada para manejar las relaciones de dependencia y hace que sea más fácil crear y mantener estos metadatos y aplicarlos al proceso de creación de mi proyecto; en otras palabras, productividad.

La gran desventaja de este enfoque es obvia: entender mi aplicación requiere que un ingeniero entienda C, lenguaje ensamblador, Perl y make.

Answer 5

Lotes de proyectos son lenguaje mixto. Uno de los lenguajes más comúnmente mezclados es SQL, y muestra una característica clave de los proyectos de lenguaje mixto: cada idioma se centra en las partes del problema en las que es bueno y compensa las debilidades del otro (s). En el caso de SQL, maneja el acceso a la base de datos relacional, dejando otras cosas (ya sea la GUI o el servicio web o ...) a otros lenguajes que sean mejores para ellos. Me atrevería a decir que usar un solo idioma es casi como usar un martillo para hacer una casa; sí, necesitas un martillo, pero también necesitas muchas otras herramientas.

Conozco proyectos que usan una mezcla de jQuery, Tcl, C, Fortran y SQL en el único proyecto. (Es una aplicación web, impulsado por un servidor web escrito en Tcl, con componentes computacionales en C y Fortran y una base de datos accesible a través de SQL.)

Answer 6

Considere el proyecto web promedio, y el número de idiomas que implica:

HTML, CSS, JavaScript/JQuery, Java, SQL/HSQL.

Cuando cada idioma es mucho más adecuado para el dominio de los idiomas que ya se está utilizando, tirar en otro idioma.

También he tenido los datos-pesados ​​programas con un frente de cliente web escrito en Java , pero un back-end (para realmente crujir números) escrito en C, alojado en diferentes servidores, y así sucesivamente.

Y tengo que decir, no modelar fuera de Twitter. Es poco probable que tenga una idea de que toneladas de personas quieren tanto, que no tiene una rentabilidad integrada, que los inversores lo llenan de dinero. También son absolutamente terribles en el ajuste y acabado en los lugares; si alguna vez ingresas tu contraseña de Gmail, es probable que se haya transmitido sin errores, por ejemplo, y durante al menos dos años, podrías hacer amistad con personas sin su permiso a través de la interfaz de mensajes de texto. (Gah.)

Answer 7

¿Es esta práctica común? ¿Por qué se hace esto realmente? Para el rendimiento?

Sí. Las personas que lo hacen generalmente intentan reutilizar el software existente (que notará que está escrito en varios idiomas) o intentan usar varios idiomas diferentes, cada uno de los cuales es bueno para ellos.

El rendimiento a veces puede estar relacionado; por ejemplo, puede que desee utilizar Lua por sus capacidades de prototipado rápido, pero conectarlo a un correo electrónico analizador de gran rendimiento escrita en C.

creo que va a tener problemas con los intérpretes diferentes/compiladores y sin problemas de conexión los diferentes idiomas ¿Es esto cierto?

A veces. El estado de la práctica en varios idiomas es más o menos que si un idioma habla con otra cosa que no sea ella misma, hablará con C. Por lo tanto, a menudo es posible hacer que las cosas funcionen juntas a través de algún tipo de interfaz tipo C.

De lo contrario, los primeros problemas suelen aparecer en la gestión de la memoria o en una capa de VM, que podríamos considerar ejemplos de "código administrado". Por ejemplo, es muy difícil obtener un programa Haskell para intercambiar objetos asignados en el montón con una JVM. Una solución típica es tratar este tipo de llamadas, como llamadas a procedimientos remotos, como si los programas se ejecutaran en procesos diferentes o incluso en máquinas diferentes. Tales llamadas pueden implicar una sobrecarga sustancial, a menudo haciendo que sea prohibitivamente costoso para dos idiomas diferentes compartir objetos mutables, por ejemplo. Sin embargo, si no tienes que mutar cosas, los gastos generales no son tan malos.

Resumen: hay razones de peso para usar diferentes idiomas para resolver diferentes problemas, y sería sorprendente que un sistema de software grande hizo no utilizar varios idiomas (excepto tal vez en silos de un solo idioma como Squeak Smalltalk, que simplemente no hablan con el resto del mundo). Ciertamente hay dificultades con la interoperabilidad, pero el problema es antiguo y se conocen soluciones temporales.