Ну, крайность, не крайность. А в принципе это глобальное состояние системы, и именно из него она восстановится после жёсткого перезапуска. Просто мы тут о другом состоянии говорим, о том которое находится в ОЗУ и доступно на протяжении процесса обработки запроса.
Например, k(x) может обращаться к БД и извлекать оттуда данные (params[:id]), h — как-то обрадабывать эти данные, например, преобразовать их в список чисел, следующая функция может возвести их в квадрат.
Ну вот, Вы сами описали как функции, одна за другой меняют состояние, которое передаётся по цепочке.
Состояние на уровне отдельной функции тоже можно рассматривать, так сказать, мгновенное состояние… но набор локальных «переменных» нас слабо волнует, интерес представляет только то состояние, которое передаётся по цепочке функций. По поводу всего остального мы просто ожидаем, что половину из этого компилятор нафиг уберёт, а остальное подчистит сборщик мусора )
Функция — просто правило, по которому элементы одного множества сопоставляются другому. О каком состоянии может быть речь?
Состояние — это один из аргументов функции, например, в той же хвостовой рекурсии при вычислении факториала начальное состояние будет = 1, а итоговое — результат. Просто Вы это называете не состоянием, а вычисляемым значением, хотя, строго говоря, вычисляемое значение — это только конечное состояние.
Когда мы говорим, что данные неизменяемые, мы не лукавим, т.к. они физически не меняются в ОЗУ, в отличии от императивных языков. Насколько я понимаю, именно это помешало распространению ФП в прошлом веке, т.к. программы работали медленнее из-за неизменяемости данных, но со временем это оптимизировали. И теперь людей больше интересует как запустить сотни потоков и не получить ни race condition от доступа к изменяемым данным, ни геммороя с блокировками.
Я предполагаю, что в данном контексте состоянием является некоторый переменный(upd.) набор данных, принадлеащий системе.
В таком определении у Вас состояние — это вся база данных + redis + ещё что-то. Слишком глобально и внешне к самому приложению.
Давайте возьмём для примера веб-приложение, оно обрабатывает входящие HTTP-запросы. Задача приложения обработать запрос и выдать HTTP-ответ. Для простоты рассмотрим один поток выполнения. Получив запрос, приложение создаёт некоторую структуру данных, описывающую запрос. Теперь эта структура данных и есть состояние. Дальше оно передаётся от функции к функции, сначала проходит через middleware-функции, потом в роутинг-функцию, потом в action-функцию контролера и т.д. пока эта структура-состояние не станет ответом.
Подождите, а как ЯП может запретить писать в каком-то стиле? Я всегда был уверен, что язык может только повысить удобство практического применения какой-то парадигмы, но запретить при этом все остальные… такого как-то не встречал.
Можете пример такого языка привести?
А где вы вообще вычитали про неизменяемое состояние в ФП? В ФП есть неизменяемость данных, но причём тут состояние?
Любая функция, если она что-то делает изменяет состояние, это вроде очевидный факт касаемо ФП.
Даже чисто математические функции изменяют состояние:
y(x) = x*x
y(5) => 25 // было состояние: 5, стало: 25.
Разница в том, что в ФП это состояние передаётся в качестве аргумента функции, а в ООП состояние — это отдельная «сущность», на которую 2 метода могут влиять параллельно.
Зачем править, когда есть monkey-patching :-D
А если серьёзно, то всё-таки ситуация получше, каждый первый точно править не надо. В основном в допилке нуждаются не особо популярные гемы типа интеграций со всякими сервисами. Случаи, когда нужно влезть в исходники того же Arel или kaminari, не так уж часто встречаются.
Если коротко, то состояние передаётся от функции к функции. Каждая функция его меняет (или не меняет, если надо пропустить шаг обработки) и передаёт следующей.
Вы маленько путаете… Программы, полезные с практической точки зрения, действительно содержат сайд-эффекты, такие как запись в БД. Но из популярных нынче ФП, насколько мне известно, только Haskell радеет за чистоту в этом смысле.
Остальные относятся к этому проще, представляя программу как своеобразный конвеер, у которого на входе — запрос, на выходе — ответ. А внутри цепочка функций, шаг за шагом преобразующих то самое состояние. Некоторые из этих функций могут иметь побочный эффект в виде записи в персистентное хранилище.
Ну а то, что пишут в императивном стиле и в нечитабельной форме, то это ведь не проблема ФП, это проблема с ригидностью мышления автора конкретного кода. ФП — не самоцель, а один из удобных инструментов, если уметь им пользоваться.
Более подходящее выражение: выход из зоны комфорта. Если для Rails у Вас уже есть набор привычных гемов. То тут придётся этот набор заново подбирать и возможно что-то самому писать. Я просто застал время, когда и используя Rails надо было самому писать гемы. Поэтому не вижу в этом ничего страшного :-)
Да не, эта идиома переводится именно так: пруф. Другое дело, что дословный перевод был в чём-то яснее, т.к. выражение «из коробки» уже устоялось в IT и понятно о какой «коробке» идёт речь.
приученность к императивной парадигме (если заставить школьника, который писал на паскале, писать на лиспе, то он будет писать на нем точно так же, как на паскале, просто со скобочками)
Вот в этом основная проблема «моды на ФП», по сути то это просто ещё 1 инструмент и надо понимать как им пользоваться. Вот неплохая статья на эту тему: http://degoes.net/articles/fp-is-not-the-answer
По Rails/Django/etc можно найти ответ практически на любой вопрос на SO, документация в рельсах достаточно неплоха (т.к. проект опенсорсный и при этом популярный, то понятное дело, что она постоянно улучшается), количество плагинов/гемов/модулей просто зашкаливает. Может этим похвастаться Haskell/Elixir?
Те, кто помнят экосистему Rails и Django времён 2008-2010 годов, могут оценить, что в том же Elixir ситуация с экосистемой уже гораздо лучше. Конечно по кол-ву пакетов/гемов обогнать Ruby не просто, но нет каких-то прям стоп-факторов от использования. Про экосистему Haskell я не в теме, честно говоря.
Но ведь все те недостатки, которые перечисляют авторы подобных статей, существовали в нынешних подходах и раньше. Это как «разоблачение», что АНБ следит за людьми.
Так он и пишет, что 6 лет уже об этих недостатках говорят и пытаются исправить. Но раз Core Team против таких исправлений, то можно уже и закрыть тему.
По-моему это более эмоциональный перевод, а по сути то же самое. Хотя все по-разному воспринимают… не исключаю, что кто-то мог «Пришло время попрощаться с Rails» воспринять как «Прекратите использовать Rails!», несмотря на то, что в заголовке никакого призыва нет и посыл другой.
В каком интересно? Тот же Rails выходит уже в 5-й мажорной версии. IT всё ещё неустоявшаяся отрасль, поэтому тут неизбежно постоянное развитие и изменения на уровне технологий. Стабильными пока остаются только теория и фундаментальные принципы. Назовите хотя бы парочку технологий, которые остановились в развитии, скажем, в 2014 году или раньше и до сих пор актуальны?
Уповая на чудо-технологии все больше появляется недопрограммистов неспособных самостоятельно писать хорошие программы.
Статья отчасти и посвящена тому, что появляется много таких Rails-программистов, которые даже на Ruby в отсутствии Rails не могут программировать.
Вообще раньше моветоном было указывать даже язык программирования перед понятием программист, а теперь везде и всюду НазваниеФреймворка-программист (AngularJS Developer, Magento Developer, Rails Developer). Являются ли люди, которые так себя позиционируют вообще программистами? На мой вгляд, нет. Они — пользователи фреймворков и даже гордятся этим. Для них переключиться и сделать новый проект на другом фреймворке — это целая смена Вселенной, хотя по меркам программирования — это пустяковая задача. Это не хорошо и не плохо, это просто факт. К тому же такие люди тоже нужны отрасли, т.к. программистов на все компании тупо не хватит.
Не путайте понятия! Те, кто пытаются что-то изменить и улучшить заслуживают уважения, являются двигателями прогресса! Те, же, кто уповают только на смену технологий в надежде на чудесные изменения…
Похоже Вы сами запутались… Автор статьи совсем не школьник, который не осилил Rails и ищет замену. В его профессионализме сомневаться не приходится, так же как в профессионализме Steve Klabnik, José Valim и многих других. Все они вполне осознанно переходят на другие технологии, потому что пришло время. Профессионалам не нужно надеяться на чудесные изменения, они сами меняют то, что их не устраивает.
P.S. И, кстати, с чего Вы взяли, что у Ruby высокий порог входа?
Я, правда, Вам ещё один ответ написал и только потом это сообщение увидел )))
Спасибо за дискуссию.
Ну вот, Вы сами описали как функции, одна за другой меняют состояние, которое передаётся по цепочке.
Состояние на уровне отдельной функции тоже можно рассматривать, так сказать, мгновенное состояние… но набор локальных «переменных» нас слабо волнует, интерес представляет только то состояние, которое передаётся по цепочке функций. По поводу всего остального мы просто ожидаем, что половину из этого компилятор нафиг уберёт, а остальное подчистит сборщик мусора )
Когда мы говорим, что данные неизменяемые, мы не лукавим, т.к. они физически не меняются в ОЗУ, в отличии от императивных языков. Насколько я понимаю, именно это помешало распространению ФП в прошлом веке, т.к. программы работали медленнее из-за неизменяемости данных, но со временем это оптимизировали. И теперь людей больше интересует как запустить сотни потоков и не получить ни race condition от доступа к изменяемым данным, ни геммороя с блокировками.
Давайте возьмём для примера веб-приложение, оно обрабатывает входящие HTTP-запросы. Задача приложения обработать запрос и выдать HTTP-ответ. Для простоты рассмотрим один поток выполнения. Получив запрос, приложение создаёт некоторую структуру данных, описывающую запрос. Теперь эта структура данных и есть состояние. Дальше оно передаётся от функции к функции, сначала проходит через middleware-функции, потом в роутинг-функцию, потом в action-функцию контролера и т.д. пока эта структура-состояние не станет ответом.
Можете пример такого языка привести?
Любая функция, если она что-то делает изменяет состояние, это вроде очевидный факт касаемо ФП.
Даже чисто математические функции изменяют состояние:
y(x) = x*x
y(5) => 25 // было состояние: 5, стало: 25.
Разница в том, что в ФП это состояние передаётся в качестве аргумента функции, а в ООП состояние — это отдельная «сущность», на которую 2 метода могут влиять параллельно.
А если серьёзно, то всё-таки ситуация получше, каждый первый точно править не надо. В основном в допилке нуждаются не особо популярные гемы типа интеграций со всякими сервисами. Случаи, когда нужно влезть в исходники того же Arel или kaminari, не так уж часто встречаются.
Остальные относятся к этому проще, представляя программу как своеобразный конвеер, у которого на входе — запрос, на выходе — ответ. А внутри цепочка функций, шаг за шагом преобразующих то самое состояние. Некоторые из этих функций могут иметь побочный эффект в виде записи в персистентное хранилище.
Ну а то, что пишут в императивном стиле и в нечитабельной форме, то это ведь не проблема ФП, это проблема с ригидностью мышления автора конкретного кода. ФП — не самоцель, а один из удобных инструментов, если уметь им пользоваться.
Те, кто помнят экосистему Rails и Django времён 2008-2010 годов, могут оценить, что в том же Elixir ситуация с экосистемой уже гораздо лучше. Конечно по кол-ву пакетов/гемов обогнать Ruby не просто, но нет каких-то прям стоп-факторов от использования. Про экосистему Haskell я не в теме, честно говоря.
Статья отчасти и посвящена тому, что появляется много таких Rails-программистов, которые даже на Ruby в отсутствии Rails не могут программировать.
Вообще раньше моветоном было указывать даже язык программирования перед понятием программист, а теперь везде и всюду НазваниеФреймворка-программист (AngularJS Developer, Magento Developer, Rails Developer). Являются ли люди, которые так себя позиционируют вообще программистами? На мой вгляд, нет. Они — пользователи фреймворков и даже гордятся этим. Для них переключиться и сделать новый проект на другом фреймворке — это целая смена Вселенной, хотя по меркам программирования — это пустяковая задача. Это не хорошо и не плохо, это просто факт. К тому же такие люди тоже нужны отрасли, т.к. программистов на все компании тупо не хватит.
Похоже Вы сами запутались… Автор статьи совсем не школьник, который не осилил Rails и ищет замену. В его профессионализме сомневаться не приходится, так же как в профессионализме Steve Klabnik, José Valim и многих других. Все они вполне осознанно переходят на другие технологии, потому что пришло время. Профессионалам не нужно надеяться на чудесные изменения, они сами меняют то, что их не устраивает.
P.S. И, кстати, с чего Вы взяли, что у Ruby высокий порог входа?