Потому что типичный АПИ — «вот тебе запрос, обработай его, дай ответ». Это как раз очень хорошо ложится на определение функции:
res = handle(req)
Я пытаюсь, сказать, что все, что происходит — это трансформация данных перед\после тем\того как положить\достать их в\из хранилища.
объекты бизнес-логики
Объекты никуда не деваются и в ФП. Только вместо классов появляются типы, вместо интерфейсов — тайпклассы и т.д…
«ну есть юзеры, группы, роли, проекты, и все это связано кучей зависимостей»
Это все прекрасно описывается теорией категорий. (И да — ее не обязательно знать, достаточно понимать довольно небольшое кол-во базовых понятий). Оперируя продуктами\ко-продуктами можно добиться выдающихся результатов, при этом получая мощные гарантии. А ООП код не дает никаких гарантий. Наследуясь от базового класса — можно переопределить его поведение до неузнаваемости. И программисту, который, скажем, рефакторит такой код чтобы быть уверенным, что он ничего не поломал необходимо изучить всю иерархию классов… если обобщить, то ты не знаешь что делает программа, пока не прочитаешь ее полностью (в худшем случае). Если брать ФП, то там программа сводится к значению. Т.е. это просто функция, а что бы понять что делает функция — достаточно взглянуть на ее сигнатуру. И если вам когда либо приходилось рефакторить код на Java (ООП) и Scala (ФП), то очевидно, что последнее требовало на порядки меньше трудозатрат.
Как-то так.
т.е. какая-то там часть функциональщины может там работать под капотом в виде всяких акторов
Часто как раз таки поступают наоборот. Возвращаясь к скале — рантайм JVM очевидно более заточен под Java, поэтому в скале даже в чисто функциональных частях кода используют ООП под капотом, чтобы добиться оптимальной производительности.
Пример: Map — если конструировать ее из списка, то под капотом создается MutableBuilder, который собирает структуру данных, а на выход она уже возвращается как immutable.Map. Это не ломает никаких абстракций, но прокачивает производительность в реалиях JVM.
Возьмем, к примеру, классические rest-API: если рассуждать с точки зрения программирования в большинстве случаев там ООП ну никак не заходит, единственная причина, по которой оно (ООП) занимает нишу — «ну, так все делают!».
На моей практике, университетов в России которые нормально преподают ФП, (5 лет назад), было очень мало, по сравнению с университетами где хоть как-то преподавали программирование. Но ООП есть везде. Вкупе с тем, что концепции довольно сильно отличаются, мы получаем эффект, что на выходе разработчики не могут «с ходу» понять абстракции ФП и не спешат развиваться в эту сторону.
Очень хорошая статья, спасибо большое!
Я в этой теме разбираюсь чуть меньше, чем никак… но что если под крипту адаптировать структуру, которую использует пейпал? То есть Эстонская (зарубежная) компания, в рамках которой происходит покупка крипты, а есть ее «филиал» в России, который может выдавать деньги (исключительно в рублях) на предварительно привязанный банковский счет.
Зачем двойной трафик? Если вы используете редакс — нужно загрузить все данные на сервере, потом отправить заполненный стор на клиент (как часть HTML-страницы). Затем, на клиенте, можно легко проверить, что данные уже есть в сторе и ничего не загружать
В этом нет ничего удивительного, сделать эффективное приложение на чистом яваскрипте крайне сложно.
Сложно\не сложно — вопрос не в этом. Как может быть фреймворк, написанный на JS, который решает широкий круг задач, быстрее чем код, написанный на JS, который решает одну конкретную задачу. Это просто чушь. В худшем случае можно замерить десяток фреймворков, выбрать лучший и вырезать из него необходимый код, удалив все лишнее. Во всех тестах ванильный JS нужно принимать за точку отсчета… быстрее него фреймворк быть не может (максимум одинаково). Ознакомьтесь со статьей, на которую есть ссылка из бенчмарка, который я приводил выше: http://www.stefankrause.net/wp/?p=316. Автор там пишет такую вещь:
Inferno is crazy fast. It’s only 7% slower and I had to add some tricks for vanillajs to match inferno.
Архитектурные решения не нужны в приложении для бенчмарка: оно может быть нечитаемо, скорей всего его не возможно поддерживать и так далее, но оно должно быть максимально оптимизировано. И фреймворка там никак не выйдет.
Ну и еще один аргумент в пользу нерепрезентативности приведенного вами теста: если добавить TypeScript к реакту — это волшебным образом ускорит его в 3 раза (приблизительно)…
Вот более серьезный бенч: да, последняя версия Vue по-шустрее в целом, но реакт не так сильно отстает, как в тесте по вашей ссылке. Мнение автора vuejs на эту тему:
Due to internal implementation differences, frameworks that uses async rendering (e.g. Vue, Om, Mercury) gains the advantage by skipping part of the calculations that happened in the same event loop. The real world user experience doesn’t demonstrate such dramatic difference.
То бишь: с асинхронным рендером на одном синтетическом todo-mvc тесте результаты не дают представления о реальной производительности.
1) Если на рынке легко заработать, как говорят об этом брокеры, почему же они просто не торгуют сами?
Брокерам действительно легко заработать на рынке… а вот трейдерам — отнюдь. Торговать самому — это риск. Круче, когда у тебя торгуют другие, а ты просто берешь комиссию (ну и кладешь себе в карман по «копеечке» с каждой сделки… все равно никто не заметит).
2) Зачем кому-то, кто разработал свою уникальную систему торговли, которая приносит стабильный доход, делиться ею с другими?
3) Зачем людям, написавшим успешного помощника, приносящего 1000% в месяц, выкладывать его в сеть? Ведь ты уже миллионер, зачем создавать конкуренцию?
За копейки продают только чушь. А в целом — любая система работает только ограниченный промежуток времени: рынок все время меняется, ее нужно постоянно развивать. Так что, если продать за хорошие деньги несколько сотен копий советника, который отработает с месяц — отличная прибыль и никакого риска.
4) Зачем человек, считающий себя профи и успешно торгующий много лет, пишет на форумах вопросы «Ну что куда рынок пойдет? Какие прогнозы?».
Этого никто не будет делать. Вы торгуете не столько с брокером, сколько с другими трейдерами. Внутри каждого брокера есть биржевой стакан и mathcing engine, которые закрывают транзакции.
Конечно, брокеры бывают разные… но если брать топ 50-100, то там все более-менее цивильно. Я к тому, что если на двух аккаунтах будут разные котировки и это всплывет — прощай дядя брокер. Без вариантов. А если учесть, что у форекс-брокеров есть еще и регуляторы — то все еще лучше.
Потому что типичный АПИ — «вот тебе запрос, обработай его, дай ответ». Это как раз очень хорошо ложится на определение функции:
res = handle(req)
Я пытаюсь, сказать, что все, что происходит — это трансформация данных перед\после тем\того как положить\достать их в\из хранилища.
Объекты никуда не деваются и в ФП. Только вместо классов появляются типы, вместо интерфейсов — тайпклассы и т.д…
Это все прекрасно описывается теорией категорий. (И да — ее не обязательно знать, достаточно понимать довольно небольшое кол-во базовых понятий). Оперируя продуктами\ко-продуктами можно добиться выдающихся результатов, при этом получая мощные гарантии. А ООП код не дает никаких гарантий. Наследуясь от базового класса — можно переопределить его поведение до неузнаваемости. И программисту, который, скажем, рефакторит такой код чтобы быть уверенным, что он ничего не поломал необходимо изучить всю иерархию классов… если обобщить, то ты не знаешь что делает программа, пока не прочитаешь ее полностью (в худшем случае). Если брать ФП, то там программа сводится к значению. Т.е. это просто функция, а что бы понять что делает функция — достаточно взглянуть на ее сигнатуру. И если вам когда либо приходилось рефакторить код на Java (ООП) и Scala (ФП), то очевидно, что последнее требовало на порядки меньше трудозатрат.
Как-то так.
Часто как раз таки поступают наоборот. Возвращаясь к скале — рантайм JVM очевидно более заточен под Java, поэтому в скале даже в чисто функциональных частях кода используют ООП под капотом, чтобы добиться оптимальной производительности.
Пример: Map — если конструировать ее из списка, то под капотом создается MutableBuilder, который собирает структуру данных, а на выход она уже возвращается как immutable.Map. Это не ломает никаких абстракций, но прокачивает производительность в реалиях JVM.
На моей практике, университетов в России которые нормально преподают ФП, (5 лет назад), было очень мало, по сравнению с университетами где хоть как-то преподавали программирование. Но ООП есть везде. Вкупе с тем, что концепции довольно сильно отличаются, мы получаем эффект, что на выходе разработчики не могут «с ходу» понять абстракции ФП и не спешат развиваться в эту сторону.
Я в этой теме разбираюсь чуть меньше, чем никак… но что если под крипту адаптировать структуру, которую использует пейпал? То есть Эстонская (зарубежная) компания, в рамках которой происходит покупка крипты, а есть ее «филиал» в России, который может выдавать деньги (исключительно в рублях) на предварительно привязанный банковский счет.
Сложно\не сложно — вопрос не в этом. Как может быть фреймворк, написанный на JS, который решает широкий круг задач, быстрее чем код, написанный на JS, который решает одну конкретную задачу. Это просто чушь. В худшем случае можно замерить десяток фреймворков, выбрать лучший и вырезать из него необходимый код, удалив все лишнее. Во всех тестах ванильный JS нужно принимать за точку отсчета… быстрее него фреймворк быть не может (максимум одинаково). Ознакомьтесь со статьей, на которую есть ссылка из бенчмарка, который я приводил выше: http://www.stefankrause.net/wp/?p=316. Автор там пишет такую вещь:
Архитектурные решения не нужны в приложении для бенчмарка: оно может быть нечитаемо, скорей всего его не возможно поддерживать и так далее, но оно должно быть максимально оптимизировано. И фреймворка там никак не выйдет.
Ну и еще один аргумент в пользу нерепрезентативности приведенного вами теста: если добавить TypeScript к реакту — это волшебным образом ускорит его в 3 раза (приблизительно)…
То бишь: с асинхронным рендером на одном синтетическом todo-mvc тесте результаты не дают представления о реальной производительности.
Брокерам действительно легко заработать на рынке… а вот трейдерам — отнюдь. Торговать самому — это риск. Круче, когда у тебя торгуют другие, а ты просто берешь комиссию (ну и кладешь себе в карман по «копеечке» с каждой сделки… все равно никто не заметит).
За копейки продают только чушь. А в целом — любая система работает только ограниченный промежуток времени: рынок все время меняется, ее нужно постоянно развивать. Так что, если продать за хорошие деньги несколько сотен копий советника, который отработает с месяц — отличная прибыль и никакого риска.
Это очень умный бот с ИИ /sarcasm
Конечно, брокеры бывают разные… но если брать топ 50-100, то там все более-менее цивильно. Я к тому, что если на двух аккаунтах будут разные котировки и это всплывет — прощай дядя брокер. Без вариантов. А если учесть, что у форекс-брокеров есть еще и регуляторы — то все еще лучше.