Как стать автором
Обновить

Комментарии 35

Так как Flux — просто набор основных элементов (магазины, действия...

Я думаю, что stores правильнее перевести все же как «хранилища», а не «магазины»
Чёрт, а я уже половину гадов прочитал в надежде посмотреть, что за фрейворк, где магазин основной элемент.
Заодно и «редьюсеры» вместо «редукторов».
Я не уверен, что подразумевает «звание общепризнанного», но Haskell, один из популярнейших функциональных языков, не упомянут :)

И коль упомянут Python — я бы назвал Haskell как раз статически типизированным питоном.
Не надо называть Haskell «статически типизированным питоном», не оскорбляйте его.
Не имел таких намерений. Просто в беседе с людьми, не знающими о предмете разговора, лучше всего применять аналогии — а питон довольно популярен, был упомянут в статье, и ближе всего по синтаксису (хотя, конечно, не по мышлению).
Преимущества функционального программирования давно признаны широкой общественностью.

А ещё больше признаны недостатки этого подхода, из-за чего нету и не предвидится его доминирование.
Надеюсь Вы правы и доминирования не произойдет =) Лично я, когда вижу лапшекод из функций, не понимаю, как некоторым такой код кажется проще декларативного подхода. Это все возможно субъективщина, но лично я нагромождение функций воспринимаю плохо.
Вы что-то путаете, функциональное программирование — это и есть декларативный подход.
Пардон муар, императивный =)
Что-то какая-то сумбурная статья получилась: всё в кучу намешано. Про какие-то войны корпораций с их фреймворками, которые бьются за мифическое место под солнцем, вытесняя друг друга. Остаться должен только один? Непонятно какой бум ознаменовал Ангулар? Знаю, jQuery ознаменовал клиентский бум, NodeJS — серверный. Ангулар — хоть и был значителен, но был лишь одним из. Был и backbone, был и ember, и knockout, и многое другое.
Ну и не сказал бы, что React весь пронизан функциональщиной. Требование иммутабельности — это так, стечение обстоятельств по большей части. Redux — да, но это лишь один Абрамов, в нужное время в нужном месте. Так что по-моему автор тут скорее выдает желаемое за действительное.
Ну а функциональщина это такой себе общий тренд на сегодня для многих языков в отрасли, и я не удивлюсь, что просто временно модный.
Ангулар произвел бум маркетинговый бул, прежде всего в аутсорсе, но не только.
НЛО прилетело и опубликовало эту надпись здесь
Ну по вашей логике, тогда и математика отчасти императивная. Ведь a / b != b / a. И порядок действий в просчетах тоже важен. Так что я пожалуй с этим аргументом не согласен. Избегать зависимости от очередности выполнения нужно только в тех случаях, где это необходимо.

Так же тут не fluent interface, а pipeline, по очередное выполнение операций на новых данных, каждый метод возвращает новый instance данных. Fluent interface работает с одним объектом.

У Haskell похожее можно достичь с помощью functional composition (filter length. concat list2. concat list1. take index). Что по вашему здесь тоже императивное программирование?

Не важно как записано, по сути это и есть описанный вами вывод на основе математических функций.

НЛО прилетело и опубликовало эту надпись здесь
Для pipeline'ов используются сегодня не столько коллекции, сколько стримы.
НЛО прилетело и опубликовало эту надпись здесь
То, что это можно было делать за царя гороха в Smalltalk(ООП язык типа да) — не значит, что это не функциональные фишки. Одно другое не исключает. И идеи довольно просты, полезны и очевидны, тут согласен, что многие из них делают слишком много шума(мода, что тут сказать)

Функциональное программирование вообще то самая древняя парадигма, появилась раньше ООП, так что тут кто у кого заимствовал еще(если речь об этом конечно). В целом есть такая тенденция, что его хотят запихнуть везде, где нужно и не нужно, но от этого оно хуже не становиться, главное рационально понимать его применение и проблемы, которое оно может решить эффективней того же ООП.
Одно из важных достоинств ООП — это возможность эмуляции некоторых частей функционального программирования путём использования «паттерна Стратегия» через механизмы наследования или имплементации, когда функцию оборачивают в «объект первого класса», фактически синглетон. Собственно, большая часть классических «шаблонов проектирования» — именно про это.
НЛО прилетело и опубликовало эту надпись здесь
Сейчас даже в php есть генераторы, а значит можно накостылять какой-нибудь пайп-механизм. Прям не знаю, нужно ли делать целый язык под это дело
Такие гибриды коллекций с итераторами как односвязные списки в качестве одного из базовых типов данных появились ещё задолго до ООП в родоначальнике функционального программирования (и вообще втором по счёту языке программирования высокого уровня после Фортрана) языке LISP. Односвязных списков вполне достаточно для маппинга, фильтрации и редьюсинга. Односвязный список — вполне себе такой «сам себе стрим/однонаправленный итератор», ибо у него есть только «голова»==текущий элемент и ссылка на следующий элемент, дополнительным плюсом от чего являются возможность приделать несколько «голов» к одному и тому же «хвосту» и возможность создавать «ленивые списки», в которых хвост генерируется «на лету» только при обращении.
Судя по всему, в примере не просто fluent interface, а методы, применяемые к allAliases и дальше, не изменяют объект, а создают новый, возможно, «ленивый».
Сейчас мы работаем над созданием мобильного приложения на React/Redux, и вот как выглядит код, который я пишу:
Вы сейчас почти дословный аналог куска шарпокода с активным использованием LINQ показали. Что забавно, LINQ в шарпе появился в год выпуска Clojure.
Скорее не забавно, а закономерно. Функциональные фичи активно внедряются в императивные мэйнстрим языки.
С копипастой-переводом уже разговариваем, да? :)
Обижаешь, разговор с копипастой — старая традиция хабра.
Один из авторов linq в одной из лекций по функциональному программированию говорил, что при создании linq они черпали вдохновление из haskell.
Языки программирования развиваются. Что объектные языки получают удобные функциональные вещи, так и рассмотренный в статье «функциональный» JS получает элементы ООП. Во многих языках — мультипарадигма.
Наша задача — писать эффективно эффективный код, а не проводить время в вечных спорах)
НЛО прилетело и опубликовало эту надпись здесь
Архаичным – это которым? Что именно делает их архаичными? И почему именно Python?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Добрый день, у вас в переводе неточность.
для создания схемы браузера

Здесь автор имел ввиду создание языка программирования scheme для браузера.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий