Comments 26
Так у меня на сименсе спошная функциональщина, да еще и реалтайм!
Первый пример показателен тем, что в нём первая императивная реализация читается легче, чем "улучшенная" функциональная.
Главная заповедь, которую следует помнить функциональному программисту: "Программы делаются только и исключительно ради побочных эффектов".
В своё время точно так же носились с ООП, как единственно правильным стилем, а до него еще что-нибудь было и лет через 10 будет (а может вернутся к нему, зумеры снова переоткроют что-то с умным видом. Это всё замануха для нового, неискушённого знанием истории поколения.
Ну так и расклад тот же, что с ООП: если ты его освоил и разумно используешь – ты можешь писать программы проще и надёжнее. А если поверил, что это silver bullet и стал пихать во все дыры – твой код может превратиться в тыкву.
Да и функциональная парадигма даже старше, чем ООП...
Сначала придумали функциональный подход и только потом, что-то в нем не устроило и пришлось до ООП расширяться...
Кстати, ООП не отрицает функциональной парадигмы. Все так же можно создавать объекты, объединяющие данные и функции вместе, при этом функции в таких объектах будут pure, объекты не будут иметь сайд-эффектов и состояния и т.д.
Вот тут подробнее.
Не знаком со свифтом, но ежели в нем условный .map() или .filter() не написан через хвостовую рекурсию с возвратом значения, то скорее всего он написан через for, который таки имеет состояние, к тому же мутируемое. Функции-то конечно скорее чистые, чем нет, однако же функциональная парадигма это в первую очередь про отказ от состояния и мутаций.
Хотя судя по тексту автор за разумное использование функционального программирования, так что с этим можно жить.
А если написан через хвостовую рекурсию, но компилятор её оптимизировал в цикл – это всё равно неправославно?
Не знаю, не мне судить. Я адепт быдлокода. Это было скорее про то, кто и насколько привержен трушности парадигмы.
Как по мне это будет очень показательно указывать на то, что ни объектно-ориентированная, ни функциональная парадигмы в чистом виде не жизнеспособны.
P. S. По моему скромному опыту ни разу не встречался с тем, чтобы компилятор оптимизировал хвостовую рекурсию, да и вообще любую рекурсию в цикл и, честно говоря, даже не подозревал о подобных кейсах. Видимо по причине того, что я не часто использую рекурсии и не знаю ASM и машинный код, чтобы увидеть, что же там в итоге получится. Пойду почитаю что ль, спасибо, что подтолкнули.
Перевод на человеческий:
- map: обработай каждую штуку;
- filter: убери лишнее;
- reduce: собери все в одну кучу.
Принципиальная ошибка.
Следует читать так:
Перевод на человеческий:- map: каждая штука рбработанна
- filter: убрано лишнее;- reduce: собрано в одну кучу.
Зачем здесь эта GPTщина? Автор, самостоятельно написать статью, в своём стиле, - слабО?
Если в Интернете любят обсирать, то на хабре любят обсирать с умным видом :)
Статья в 2-х словах рассказывает начинающим, что такой стиль вообще есть. В ней нет пропаганды этого стиля, нет сравнения с другими, нигде не написано, что его нельзя применять с ООП и т.д. Нравится такой подход, он применим к твоему проекту - используй.
Местами мне кажется, что ИТ сообщество хуже ворчливых бабок на лавке...
Перевод на человеческий:- map: обработай каждую штуку;- filter: убери лишнее;- reduce: собери все в одну кучу.
так map, filter, reduce это же просто функции, их кто-то должен написать... то есть ФП это программирование для тех, для кого написание функций map, filter, reduce это магия, получается. Получается ФП это такая мечта о программировании без программирования, получается - как бы ничего нового! В самом начале были мечты о том что физики будут писать программы каким-то своим особенным способом не вспоминая про адреса в памяти, про различия типов памяти как памяти программной и памяти области данных, про адреса, указатели, ссылки, загрузки-передачи данных, ...
Все эти попытки использовать в статье сленг, примитивные сравнения с бытом, постоянные обращения на "ты" выглядят жутко кринжово и выдают GPT
Это все хорошо, но проблема в том, что программы делаются только и исключительно для того, чтобы изменять данные. А еще создавать новые копии так то не дешево.
Впрочем ознакомиться, почему такой подход удобен, для каких задач хорошо подходит, какие проблемы решает конечно стоит.
Имеется ввиду неизменение исходных данных. То есть когда надо делать многочисленные выборки (filter), обсчитывать их (map, reduce) и выдать результат.
Это никак не противоречит моему комментарию. Я понимаю, почему неизменные данные хорошо работают. Но программы делаются ради измененных данных (как в прямом, так и в переносном смыслах)
Я понимаю, что функциональное программирование не меняет данные, а создает новые. Про это и речь.
Да, простите, возможно мой комментарий был недостаточно понятен.
Мы говорим о разных вещах.
Программы, в конечном итоге, это изменение ноликов и единичек в памяти компьютера (потом эту память так же сохраняют на диски и выводят на экран).
Программы по определению стейтфул.
Но, в практическом смысле, мы изобрели большое количество инструментов и абстракций, которые значительно улучшают качество программ.
Например, уменьшают количество ошибок за счет того, что данные выполняются только в определенных, ограниченных местах и определенным образом.
То есть функциональных ЯП.
И это работает, программы получаются проще и элегантнее и это работает как будто мы не меняем данные.
Но всегда следует помнить - это не константа абсолюта и хорошо работает не везде и не всегда, у этого есть недостатки и границы применимости.
Например, это хорошо работает на серверах, где значительная часть логики - запрос/ответ и программа может быть stateless. И это плохо работает, например, в играх, где концептуальное состояние мира большое и комплексное и системы должны взаимодействовать друг с другом для создания интересной игры (даже если это создает головную боль разработчикам)
В конечном итоге, за это еще и надо платить - дублирование данных вместо перезаписи может немало стоить.
Вот про это мой комментарий.
А чистые функции безусловно хорошо работают много где.
А почему пример randomize так уж плох? Имя функции соответствует поведению, делает всё то же что и функция выше, ничего не меняет)
Статью можно разбирать на перлы:
Тезис 1: все через map, filter, reduce
Меньше циклов, меньше багов, больше кайфа.
... кроме вышеупомянутых функций есть forEach, который не просто использует for loop - это фактически он и есть. Запрещаете им пользоваться?
Тезис 2: let - это любовь
Если ты все еще на var, как на сигаретах - пора бросать.
let - твой друг. var - бывший, которого пора отпустить.
у вас там дальше пачка функций в одной. Запретите создать var переменную и разбить это на части?let result = { double(increment($0)) }
func randomize(_ x: Int) -> Int { x * Int.random(in: 1...10) }
Это уже мутный тип. Как начальник, который обещал повышение.
а ничего, что реализация системной функции random работает схожим образом?
Тезис 4: Функции как значения (Higher-order functions)
func add(_ a: Int, _ b: Int) -> Int
let operation: (Int, Int) -> Int = add
как можно перевести вместо "функции как значения" вместо "функции высшего порядка"? И пример такой же - мимо.
Когда ты работаешь со struct (а не с class), ты меньше паришься, кто где что поменял. Каждое изменение - новая копия. Никто не ломает твою память.
специально для вас есть отдельная статья и даже на русском:
https://apptractor.ru/info/articles/struct.html
да и структуры тоже могут содержать функции
и т.д.
Функциональный стиль: объясняю как другу