Имеет ли функциональное программирование отношение к веб-разработке?

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

сравните с настольными приложениями, где у нас обычно есть длительный процесс, пользовательский интерфейс с отслеживанием состояния и поток данных в нескольких направлениях. Это больше подходит для OO, который обеспокоен объектами с состоянием и передачей сообщений.

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

чисто функциональное программирование может не очень хорошо отображаться в среде веб-программирования. Но главным препятствием является именно отсутствие инфраструктуры (фреймворков и API). Это будет долгое время (вероятно, никогда, честно), прежде чем функциональный язык будет иметь такую богатую среду веб-программирования, как Java, Python или Ruby.

тем не менее, есть несколько вариантов.

• HAppS - веб-приложение Haskell сервер
• Страницы Сервера Haskell
• ссылки - функциональный язык веб-программирования
• mod_caml - модуль OCaml CGI для Apache
• Ocsigen / Eliom - веб-сервер OCaml / фреймворк программирования
• опа - a commercial Web application framework
• Yesod - веб-фреймворк для Haskell

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

Twitter переписал свой бэкэнд в Scala, язык JVM, который поддерживает как объектно-ориентированную, так и функциональную парадигмы.

и лифт веб-фреймворк написан на Scala.

для Clojure есть интересный запуск (TheDeadline), который разработан с использованием Clojure и Google App Engine. У них есть хороший ppt на Slideshare и интервью на InfoQ.

для хорошей дискуссии о развертывании Clojure с GAE: http://news.ycombinator.com/item?id=1239788

насколько я знаю, Clojure имеет несколько библиотек веб-разработки. Композиция Кольцо Колдовать

надеюсь, что это ответит на некоторые из ваших вопросов =) (я только начинаю тоже наружу..)

лучшие, Райан

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

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

проверить Ur / Web. Это очень быстро, и его система статического типа знает о таких вещах, как HTML и SQL, поэтому она может гарантировать всевозможные приятные вещи о безопасности.

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

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

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

идет довольно крутые вещи в Эдинбургском университете с функциональным программированием для web.

язык и парадигма не имеют значения для веб-приложений, они все одинаково хороши и плохи. Если вы ищете причину для изучения новой парадигмы, просто погрузитесь в нее. Мой совет будет анализировать проблему вы пытаетесь решить и выбрать соответствующий набор инструментов.

Javascript (язык части FE в интернете и все чаще BE) не является функциональным как таковым, но функции являются функциональными первого порядка

мы только запустили онлайн-таблицу, где бэкэнд полностью написан на Erlang.

http://hypernumbers.com

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

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

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

по крайней мере это моя причина.

еще один короткий ответ:http://www.mlstate.com -- Полная платформа веб-разработки, основанная на FP. Чистая семантика языка разрешить всевозможные автоматизированные безопасности и анализ безопасности, оптимизации и т. д.

внимание: я там работаю.

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

вы, вероятно, не будете использовать его и не должны использовать его, но когда вы говорите, что кто-то всегда найдет исключение из правила (Viaweb и т. д.). В принципе нет никакого "супер языка", есть только РАБОЧИЕ строки кода, обычно в " Blub."Даже Пол Грэм говорит, что главное (на самом деле только) преимущество Lisp-это способность быстро прототипировать.

также "Супер языки" обычно сталкиваются, а не увеличивают читаемость кода, что означает, что тот "гений", который его написал, должен сохраняйте его навсегда, так как никто другой не может понять его, тем более, что он, вероятно, напишет его на своем собственном измененном диалекте. Это уменьшает возможный объем любого проекта, что означает, что даже если новые, инновационные вещи могут быть сделаны, они не являются расширяемыми и поэтому остаются в относительно небольшом масштабе (например, Hacker News в Arc).

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

Что касается FP на JVM, есть ограниченные, но классные вещи. Хотя я лично использовал бы его только для прототипирования, возможно, у вас может быть прецедент (обычно что-то сделайте с многопоточностью), где это обеспечивает некоторое улучшение.