Después de leer los documentos de Node.JS (y el agradable slide deck), creo que las otras respuestas aquí carecen de sentido: Node.JS se basa en la idea de que el estilo de escritura de programas donde los esperamos bloquear en E/S es incorrecto, y que en su lugar debemos iniciar E/S (como leer una base de datos, o leer un socket) y pasar una función para manejar el resultado de la E/S junto con la solicitud.
Así que en lugar de hacer esto:
var result = db.query("select.."); // blocking
// use result
Node.JS se basa en la idea de hacer esto:
db.query("select..", function (result) {
// use result
});
Los autores (del nodo.JS) señalan que esta forma de programación es muy incómoda en muchos sistemas, ya que los idiomas no tienen cierres o funciones anónimas y las bibliotecas bloquean principalmente la E/S. Sin embargo, Javascript suministra lo primero (y los programadores están acostumbrados dado que JS se usa de forma similar en el navegador), y Node.JS completa lo posterior: se trata de una biblioteca de E/S totalmente controlada por eventos sin llamadas de bloqueo. en absoluto.
¿Cómo se relaciona esto con la programación funcional? Todos los lenguajes de programación funcionales proporcionan construcciones de cierre lo suficientemente potentes para hacer lo que Node.JS intenta hacer con Javascript. La mayoría hace que sea aún más fácil codificar, ya que los cierres pasados son generalmente fundamentales para el idioma.
En cuanto a Haskell, usando Mónadas, este tipo de cosas podría ser muy fácil de construir. Por ejemplo:
doQuery :: DBConnection -> IO()
doQuery db = do
rows <- query db "select..."
doSomething rows
doSomethingElse rows
éstas, las líneas imperativas muy secuenciales de código son realmente una secuencia de cierres bajo el control del IO mónada. Es como si en JavaScript que había escrito:
db.query("select...", function (rows) {
doSomething(rows, function() {
doSomethingElse(rows, function() { /* done */ })
})
})
En esencia, cuando se escribe código monádico en un lenguaje funcional, que ya está escribiendo en forma Node.js los autores quieren que escribamos: Donde cada paso del cálculo secuencial se pasa como un cierre al anterior. Sin embargo, ¡mira cuánto mejor se ve ese código en Haskell!
Además, puede utilizar fácilmente concurrente Haskell cuenta para lograr esta operación no bloqueante fácilmente:
forkQuery :: DBConnection -> IO ThreadId
forkQuery db = forkIO $ do
rows <- query db "select..."
doSomething rows
doSomethingElse rows
No se debe confundir con el que forkIO tenedor proceso costoso que estamos acostumbrados, o incluso proceso de OS trapos. Básicamente es el mismo hilo de ejecución ligero que Node.JS está utilizando (solo con semántica algo más rica). Puedes tener 1,000s 'em como Node.JS apunta a.
Así que, en resumen, creo que Node.JS se basa en una instalación que existe en JavaScript, pero que es mucho más natural en los lenguajes funcionales. Además, creo que todos los elementos que están en Node.JS ya existen en Haskell y sus paquetes, y algo más. ¡Para mí, usaría Haskell!
Bueno, para ser honestos, la programación funcional no implica un lenguaje puro. Haskell solo elige hacer esto. – codebliss
Tenga en cuenta que nunca dije que lo hizo. El estilo de programación, en sí mismo, es como lo definí. Poca controversia sobre eso. Existe un debate en curso sobre lo que se debería permitir llamar un "lenguaje de programación funcional": cualquier lenguaje que permita el estilo, cualquier idioma donde el enfoque principal apoye ese estilo, o solo los idiomas que no admitan otro estilo. Ese es un debate diferente. – harms