user-interface - haskell functional programming

Escribir GUI en un idioma y la aplicación principal en otro. (6)

Digamos que escribo una aplicación en Haskell o Erlang (o cualquier otra, no importa) y quiero que funcione con mi gui en un lenguaje más amigable para los gui (mi opinión), digamos Python. ¿Cómo pegar esos dos? ¿Cómo se comunicaría entre esas dos partes de la aplicación? ¿Haciendo algún tipo de servidor o algo? ¿Es este tipo de solución popular? He visto cosas como SMplayer, que es un gui para mplayer y funciona bastante bien. ¿Qué piensas sobre este tipo de diseño?

Dependerá del idioma exacto que desee utilizar tanto para la GUI como para la lógica. Como respondió David, básicamente solo tienes esas dos opciones, y ambas tienen ventajas y desventajas:

Poner todo en una sola aplicación es lo mejor en cuanto a rendimiento, ya que cuando realice las llamadas al otro idioma, no esperará hasta que el otro proceso obtenga el control, y luego no esperará a que el proceso vuelva a tener el control para Recibe la respuesta. Esta es también la solución más fácil si puede incrustar un idioma en otro idioma, entonces, por definición, se ejecutarán en el mismo proceso.

Usar diferentes procesos puede ser bueno si siempre estás haciendo muchas cosas en el proceso "lógico", pero quieres que la interfaz de usuario siga respondiendo. (aunque esto también podría lograrse con hilos, en un solo proceso). Además, si no puede incrustar los idiomas, esta será la solución más sencilla. (por ejemplo, el uso de sockets simples para IPC, que existen en casi todos los idiomas y son verdaderamente portátiles. (lo que no es tan cierto para cosas como tuberías o memoria compartida)

Así que realmente depende de los idiomas que elijas.

He escrito aplicaciones en Haskell usando ambos métodos (cliente / servidor, nativo) y ambos vienen con sus ventajas {dis}. Me doy cuenta de que esto es más de lo que pidió, pero he documentado las ventajas y desventajas de ambos enfoques con la esperanza de que le ayuden a tomar una decisión más informada.

Más específicamente los enfoques que utilicé fueron:

Aplicaciones web que usan Haskell como backend y Javascript / HTML para el frontend. La comunicación se realizó únicamente utilizando JSON. No se generó HTML o Javascript en el backend.
De forma nativa en Haskell puro utilizando GTK2HS.

Las ventajas del primer enfoque son:

Me vi obligado a separar el código GUI de la lógica de back-end. Definitivamente hecho para un diseño más limpio.
Haskell ahora tiene servidores web de alto rendimiento [4,5]. También tiene una gran compatibilidad con CGI / FastCGI y bases de datos si desea escribir scripts de estilo PHP en servidores web de terceros. Utilicé este último enfoque y funcionó bastante bien.
Las bibliotecas de IU son lo suficientemente buenas ahora, donde construir una interfaz de usuario en Javascript es una experiencia agradable. Estoy muy contento con Qooxdoo [2] pero hay varias opciones (jQuery, ExtJS ...)
La memoria transaccional de software [3] hace que sea trivial almacenar el estado al que se accede simultáneamente en el lado del servidor. STM es la principal razón por la que este enfoque es viable y divertido.
Me gustó que la interfaz de usuario fuera coherente y fácil de implementar en cualquier plataforma que pudiera ejecutar un navegador web. Si su aplicación tiene que ejecutarse en Mac, así como en Windows y Linux, sigo pensando que esta es la mejor manera de hacerlo (más abajo).

Las desventajas del primer enfoque son:

Tuve que lidiar con la autenticación y las sesiones, incluso cuando sabía que se trataba de una aplicación de usuario único. Ahora hay marcos (Yesod, Happstack ...) que ayudan con esto, pero creo que es una complejidad accidental que puede evitarse escribiendo una aplicación nativa.
Tuve que pasar mi propio protocolo de comunicación cliente / servidor. Extender el protocolo y asegurarse de que era correcto fue doloroso en el extremo de Javascript, pero fue una alegría absoluta en el extremo de Haskell. Sospecho que este será el caso de cualquier combinación de lenguaje amigable con GUI / Haskell que elija.
Una buena parte de mi código acabó de agrupar y desordenar los datos JSON. Este es un problema menor ahora porque creo que hay una serie de librerías de Haskell en esa afirmación para automatizar esto [1].
La mayoría de los hosts no admiten aplicaciones Haskell.

Las ventajas del segundo enfoque son:

todo su desarrollo está en el mismo idioma y, por lo tanto, es más fácil de probar.
Glade es ideal para la construcción visual de GUI y la integración de Haskell es extremadamente buena.
El despliegue en Windows y Linux es fácil.
GTK2HS es muy bueno, completo y bien documentado.
Los enlaces también intentan reflejar la estructura OO de GTK. Esto tiene sus inconvenientes (ver a continuación), pero la gran ventaja es que pude usar la documentación de otros enlaces de idiomas para llenar los vacíos de documentación. Cuando desarrollé me refería constantemente a los excelentes documentos GTK de Python.

Las desventajas del segundo enfoque son:

desplegar una aplicación GTK2HS en una Mac es terrible y parece feo arrancar.
La instalación de GTK2HS en Windows no es trivial, en Mac es un problema de investigación abierta.
GTK2HS requiere que escribas Haskell muy unidiomático. Hay un estado mutable en todo el lugar y la falta de objetos significa que básicamente está escribiendo código de procedimiento.

Espero que esto no fuera TMI.

-deec

[1] http://www.google.co.uk/search?hl=en&as_sitesearch=hackage.haskell.org%2Fpackage&as_q=json

[2] http://www.qooxdoo.org

[3] http://www.haskell.org/haskellwiki/Software_transactional_memory

[4] http://hackage.haskell.org/package/warp-0.3.2.3

[5] http://snapframework.com/

Podrías hacer esto:

el programa principal en Haskell o Erlang se puede ejecutar solo en la línea de comandos, con un indicador de consola, etc.
la GUI en cualquier idioma inicia el programa central y lo dirige a través de la entrada y salida estándar del núcleo.

Este enfoque es utilizado por gdb (core) / ddd (GUI). Esto le permite depurar fácilmente el núcleo en la línea de comando. Con este enfoque, también puede hacer fácilmente scripts por lotes utilizando el núcleo, pruebas de unidad, etc.

Si por lenguaje amigable con la interfaz de usuario quiere decir tener el Diseñador visual de GUI, entonces aún puede hacerlo en haskell. 2 marcos principales de GUI de Linux, GTK y QT tienen diseñadores visuales y puedes usar los archivos de GUI que producen a partir de haskell.

Echa un vistazo a las bibliotecas gtk2hs o qthaskell.

Tienes dos opciones obvias:

Ponga toda la aplicación dentro de un solo proceso. Por lo general, esto involucraría algo como las DLL de Windows (nativas, COM, ensamblados administrados, etc.) o objetos compartidos de Unix.
Comunícate entre las dos partes de la aplicación usando mecanismos de IPC.

En general, la opción 1 es preferible si los idiomas en cuestión son susceptibles.

Thrift soporta Haskell, Erlang y Python:

Thrift es un marco de software para el desarrollo de servicios escalables en varios idiomas. Combina una pila de software con un motor de generación de código para crear servicios que funcionan de manera eficiente y perfecta entre C ++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Cocoa, JavaScript, Node.js, Smalltalk y OCaml.