Я хотел бы знать, как реактивное программирование привязано к функционально-программированию.Является ли реактивное программирование ограниченным функциональным программированием?
Большинство документов ссылаются на «Реактивное программирование» как «Функциональное реактивное программирование».
Может ли реактивное программирование работать вне функционального программирования?
Легче ли написать реактивные программы с функциональным языком?
Я использую то, что я бы назвал реактивным программированием, или SEDA (Staged Event Driven Architecture), но я мало использую способ функционального программирования. http://www.slideshare.net/PeterLawrey/writing-and-testing-high-frequency-trading-engines-in-java
Хотя легче писать реактивные программы функционально, их проще выполнять быстрее, используя функциональное программирование. Повторное использование изменяемого состояния часто на 2-5 раз быстрее, чем создание новых неизменяемых объектов. Поэтому, если вы используете реактивное программирование для повышения производительности, я бы не использовал функциональное программирование.
Часто разработчики считают, что им приходится использовать несколько потоков или ядер, потому что они есть. Это похоже на то, что вам нужно использовать 100% дискового пространства или тратить его впустую.
IMHO вы должны только добавить сложность нескольких потоков, если это повышает производительность, и это самый простой способ добиться этого улучшения. То, что часто забывается в обсуждении упрощения параллелизма, заключается в том, что самым простым решением является использование одного потока, и, если вы не доказали, что ваше решение быстрее, вы не убедили меня в том, что использование нескольких потоков было когда-либо полезным.
Не использовать ресурсы, выделенные ресурсами *, это их тратить. –
@RandallSchulz правда, но приложить дополнительные усилия, чтобы использовать все ресурсы и быть хуже, тратит больше. –
@Peter, спасибо за ваш ответ. Я согласился с вами, что иногда вам просто не нужно использовать parelallel programming. Но я хотел бы узнать больше о принципах реактивного программирования и о том, как он влияет на дизайн, как мы это делаем сегодня в O.O. программирование. Я читаю статью Одерского о том, что он «устарел» от шаблона наблюдателя, и он заявил, что наблюдатель олицетворяет некоторые принципы разработки программного обеспечения. Нужно ли нам думать о функциональном программировании, чтобы сделать реактивные приложения? – edubriguenti
Я предполагаю, что вы проводите курс реактивного программирования Одерским/Мейер/Куном? Затем вы увидите интерпретацию Мартина Одерского в первом сеансе: он использует очень широкое описание из словаря, в котором реактивные средства «легко реагируют на стимул». Таким образом, речь идет о программе, наблюдающей и ожидающей некоторого стимула, на который она реагирует.
Итак, с этой точки зрения реакции являются прежде всего чем-то вроде функций, вызванных наблюдением. Когда вы можете составить их, например. вы сопоставляете события или переменные потока данных, вы, вероятно, называете это «функциональным» в том смысле, что набор будущих значений объявляется как функция значений, инициированных событиями.
Функциональное реактивное программирование или FRP, с другой стороны, это термин, придуманный Коналом Эллиоттом и Полом Худаком (первоначально: функциональная реактивная анимация, поскольку речь шла о графических интерфейсах). Он тесно связан с их работой и языком программирования Haskell.
Многие библиотеки, которые реализуют реактивные идеи (см., Например, статью WP по реактивному программированию), разделяют аспект композиции события с FRP, в то время как они не обязательно распространяются на аналитические/непрерывные сигналы или «поведение» FRP, которые дополняют Мероприятия.
Вы обнаружите, что некоторые люди утверждают, что реактивное программирование без присоединения к каноническому FRP-к примеру. при использовании актеров или каналов - это «красть» термин от «истинных носителей» этого названия. Таким образом, это обсуждение может легко стать идеологическим. С другой стороны идеологического, вы обнаружите, что реактивный часто (ab) используется в качестве нового слова. «Реактивный манифест» (манифест ... действительно !? вы можете даже знак этот материал ...), вероятно, будет примером этой стороны.
Хорошая точка. Я читаю статью Одерского о том, что он «устарел» от шаблона наблюдателя, и он заявил, что наблюдатель олицетворяет некоторые принципы разработки программного обеспечения. Этот документ, IMHO, показывает, что будущее является функциональным программированием, потому что эта парадигма затрагивает большинство проблем в реактивном программировании. Здесь ссылка на эту статью [link] http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf – edubriguenti
Не все может быть красиво составлено, поэтому идея о том, что функционал является единственным средством защиты, не выполняется. Примером являются представления коллекции: представление показывает список элементов, а некоторые связанные с ним представления должны реагировать на добавление или удаление элементов из базовой модели. Это тривиально со стандартным MVC, но как вы определяете это чисто функциональное? Каким должен быть тип, 'Seq [A]'? Это может стать очень неэффективным, когда вы действительно хотите узнать, какой элемент был добавлен/удален. Функциональность хороша для выражений, вещей, которые оценивают индивидууму, но для коллекций он менее подходит. –
Возможно, вам будет интересно взглянуть на Reactive Manifesto.
Я думаю, что можно писать реактивные приложения с языком OO (например, Java как веб-сервер NIO2 и Netty), но гораздо удобнее использовать функциональный язык.
Я зарегистрируюсь. Я считаю, что принципы и атрибуты качества, которые они представляют, являются ключами к реактивному программированию, действительны. Моя основная забота заключается в том, что для достижения такого уровня сопротивления, а также паралеллизма и отказоустойчивости «единственный» способ заключается в функциональном программировании. – edubriguenti
Для меня этот «реактивный манифест» - просто модное слово. Эрланг реализует все это с 80-х бесплатно и тихо.
Я бы сказал, что в функциональном программировании легче придерживаться реактивных принципов, поскольку FP обычно охватывает неизменные состояния и функции свободных побочных эффектов. Это означает, что его легче реализовать параллельно, и parallel системы.
Удачи в реализации «реактивной» системы, использующей общие состояния, потоки, блокировки, семафоры ... И знаете, они говорят, что только два человека могут получить правильную параллельную систему Java, Дуг Ли и Брайан Гетц.
Нет, они не являются независимыми парадигмами программирования, реактивным потоковым подходом и функциональностью, основанной на философии чистых функций для всех.
Ваши вопросы могут быть лучше подобраны для этого сайта: http://programmers.stackexchange.com/ – mwhs
Существует одна википедия для реактивного программирования и другая для функционального реактивного программирования. Я бы начал там. – keyser
Если вы посмотрите на определение реактивного программирования, вы увидите, что концепция, стоящая за ней, может быть достигнута с помощью любой парадигмы, которая поддерживает идею события или сигнализации. Это означает, что он очень параллелен. И функциональные языки очень хорошо поддерживают параллелизм (по расчету/исчислению лам). То есть все – mwhs