переосмысление колес: Узел. JS/Event-driven, программирующий v.s. Функциональное программирование?

На самом деле это не «изобретение велосипеда заново». Javascript на самом деле не является функциональным языком как таковым, но он был основан на Lisp, и именно для этого он был разработан. На мой взгляд, Javascript действительно сильнее как Lisp-подобный функциональный язык, чем как объектно-ориентированный язык. Вот почему фреймворки с сильно функциональным * дизайном, такие как jQuery, так хорошо подходят этому языку.

(* Примечание: очевидно, не чисто, но функционально во многом так же, как Scheme.)

Я действительно не знаю о Node.JS тоже, но я действительно не вижу поразительного сходства между ним (из вашего описания) и функциональным программированием. Судя по вашему описанию, Node.JS, похоже, нацелен на помощь асинхронному программированию - поскольку вы заявляете, что «вам не нужно ждать шаг за шагом последовательно», вы можете выполнять другие задачи, как одна длительная задача делает свое.

Функциональное программирование полностью ортогонально этому - то есть на самом деле оно не имеет никакой связи с асинхронностью. Вы можете иметь одно без другого, или оба вместе, или ни один из них. Функциональное программирование - это устранение побочных эффектов в ваших программах и возможность манипулировать функциями как первоклассными членами языка и составлять их так же, как и другие значения.

Ключевая роль Javascript в узле как веб-сервере заключается в том, что он в значительной степени управляется событиями.

Я считаю, что функциональное программирование имеет преимущества для параллелизма, в том числе благодаря неизменяемости.

не уверен, насколько другие функциональные языки управляются событиями, просто хотел выделить это как часть преимуществ узла.

Прочитав документацию Node.JS (и красивую презентацию ), я думаю, что в других ответах здесь нет смысла об этом: Node.JS основан на идее, что стиль написания программ, где мы ожидаем, что они будут блокироваться при вводе-выводе, неправильный, и что вместо этого мы должны инициировать ввод-вывод (например, чтение базы данных или чтение сокета). ) и передать функцию для обработки результата ввода-вывода вместе с запросом.

Вместо того, чтобы делать это:

var result = db.query("select.."); // blocking
// use result

Node.JS основан на идее делать это:

db.query("select..", function (result) {
    // use result
});

Авторы (Node.JS) отмечают, что этот способ программирования очень неудобен во многих системах, поскольку языки не имеют закрытий или анонимных функций, а библиотеки в основном блокируют ввод-вывод. Однако Javascript предоставляет первое (и программисты привыкли к нему, учитывая, как JS используется в браузере в событийной манере), а Node.JS заменяет последнее: будучи полностью управляемой событиями библиотекой ввода-вывода без каких-либо блокирующих вызовов.

Как это связано с функциональным программированием? Все функциональные языки программирования предоставляют закрывающие конструкции, достаточно мощные, чтобы делать то, что Node.JS пытается сделать с Javascript. Большинство из них еще больше упрощают кодирование, поскольку передача замыканий обычно является фундаментальной для языка.

Что касается Haskell, используя монады, такие вещи можно было бы очень легко построить. Например:

doQuery :: DBConnection -> IO ()
doQuery db = do
    rows <- query db "select..."
    doSomething rows
    doSomethingElse rows

Эти очень последовательные императивные строки кода на самом деле представляют собой последовательность замыканий под управлением монады IO . Это как если бы на JavaScript вы написали:

db.query("select...", function (rows) {
    doSomething(rows, function () {
        doSomethingElse(rows, function () { /* done */ })
    })
})

По сути, при написании монадического кода на функциональном языке вы уже пишете его в форме, которую авторы Node.JS хотят, чтобы мы написали: Где каждый шаг последовательного вычисления передается как закрытие предыдущего. Однако посмотрите, насколько лучше этот код выглядит в Haskell!

Кроме того, вы можете легко использовать параллельные функции Haskell, чтобы легко достичь этой неблокирующей операции:

forkQuery :: DBConnection -> IO ThreadId
forkQuery db = forkIO $ do
    rows <- query db "select..."
    doSomething rows
    doSomethingElse rows

Не путайте этот forkIO с дорогостоящим форком процесса, к которому вы привыкли, или даже с ОС технологические потоки. По сути, это тот же легкий поток выполнения, который использует Node.JS (только с несколько более богатой семантикой). У вас может быть 1000 штук, как и стремится Node.JS.

Вкратце - я думаю, что Node.JS строится на средствах, существующих в JavaScript, но это гораздо более естественно для функциональных языков. Кроме того, я думаю, что все элементы, которые есть в Node.JS, уже существуют в Haskell и его пакетах, а затем и в некоторых.Для меня я бы просто использовал Haskell!

Я еще не использовал node.js, но я определенно заинтересован в нем и скоро попробую. Здесь уже есть много отличных ответов о функциональном программировании и тому подобном, поэтому я не буду вдаваться в подробности.

Вы спрашиваете, почему бы не использовать на сервере какой-нибудь другой язык, такой как haskell, Closure и т. Д. Для меня node.js привлекает больше других в том, что он ЯВЛЯЕТСЯ javascript. В моих приложениях на клиенте уже много javascript, поэтому это означает, что я могу работать на одном языке как на сервере, так и на клиенте.

Я надеюсь, что это упростит и упростит разработку, потому что мне не нужно будет так резко переключать контексты. Может даже быть некоторое сокращение работы, если некоторая логика, которая используется как на клиенте, так и на сервере, может быть совместно использована (возможно, форма кода проверки и т.п.).

Одним из основных преимуществ сокращения разрыва между клиентом и сервером является возможность повторного использования кода на клиенте и сервере. Например, если вы хотите иметь многофункциональный и динамический веб-сайт AJAX для современных браузеров и урезанную версию для старых браузеров, вы можете использовать один и тот же код отображения для форматирования входящих данных как на клиенте, так и на сервере.

Другие преимущества этого включают возможность HTML5 / Google Gears / Adobe Air иметь локальную базу данных хранилища и сервер для запуска веб-приложений в автономном режиме, вы можете иметь код, который традиционно будет на сервере и храниться локально, когда сервер не работает. доступный.