А где вы вообще вычитали про неизменяемое состояние в ФП? В ФП есть неизменяемость данных, но причём тут состояние?
Любая функция, если она что-то делает изменяет состояние, это вроде очевидный факт касаемо ФП.
Даже чисто математические функции изменяют состояние:
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 высокий порог входа?
Начнем с того, что я не занимаюсь проектированием и разработкой языков программирования, библиотек, фреймворков, а использую их в качестве инструментов. Улучшать их? Какой смысл?
Смысл есть, иначе бы развитие технологий совсем остановилось )))
А вот то, что Вы не занимаясь этим и даже не изучив код того же Rails, пытаетесь намекнуть на то, что люди, которые этим занимаются, не являются профессионалами — это как-то странно. Докатились… разработка фреймворков и библиотек — это по-вашему не дело, а метания в поисках истины. Вам самому не смешно?
Автор программировал на Ruby 9 лет. И что с того? Постоянно пытался изменить Ruby?
Автор вносил весьма значительный вклад в экосистему Ruby, если не 9 лет, то на протяжении 5 лет точно. Причём весьма активно.
Я бы не стал говорить о каком-то насыщении, если речь идет о притоке все новых начинающих программистов. Какое же тут насыщение?
Новички, как правило, просто используют то, что есть, и поэтому не добавляют никакой ценности в сообщество. Конечно, они могут со временем набрать квалификацию, выходя за рамки Rails. Но в целом на этой фазе развития идёт неизбежное понижение квалификации в среднем по сообществу.
Да и с чего бы профессионалам уходить куда-то, если их все устраивает.
С чего это Вы решили, что профессионалов всё устраивает?
По своему опыту скажу, что я менял технологии разработки только по мере того, как возникала необходимость переходить на какой-то новый качественный уровень, а предыдущие инструменты уже ну никак не подходили для реализации.
Ну вот, автор тоже перешёл на новый качественный уровень — к функциональному программированию.
Так почему же Вы ушли с предыдущих языков программирования, с предыдущих фреймворков, а не сделали их лучшими для себя?
Автор 9 лет программировал на Ruby — в каком месте тут «постоянные метания»?
И говорить о каком-то закате инструментария разработчика совершенно неуместно, пока этот инструмент востребован и прекрасно выполняет свои функции
Речь не о закате, а о насыщении. Все, кто хотел использовать Rails, — уже используют. Теперь добавляться будут только начинающие программисты. А профессионалы будут постепенно уходить в категории «Innovators» и «Early Adopters» других технологий. И это не тенденция последнего времени, так было всегда.
Если тот же Hanami наберёт популярность, то для Ruby никакого заката не будет, даже наоборот.
Ну, за 25 лет Вы явно успели попрограммировать не только на Ruby, не так ли? Т.е. причины со временем менять базис существуют в том числе и лично для Вас.
У любой технологии есть свой цикл развития:
Rails сейчас очевидно находится на этапе «Late Majority». И вполне объяснимо, что Пётр, как один из лидеров Ruby-сообщества, чувствует социальную ответственность и соответственно потребность описать свою точку зрения.
Хороший ответ. Akita справедливо отмечает, что у Rails есть своя сфера применения (Basecamp-like apps) и большинство веб-проектов в эту сферу попадают. Также как есть Wordpress для блогов.
И если вы пытаетесь сделать какой-то проект на инструменте, который для этого проекта не предназначен, например, магазин на Wordpress или веб-приложение, архитектурно не похожее на Basecamp, на Rails, то вы будете страдать. Однако, он забывает, что когда Rails только набирал обороты, многие говорили «Зачем нужен фреймворк, для большинства проектов достаточно CMS», «Зачем нужны Ruby и Python, большинство крупных проектов написаны на PHP». Так что текущая ситуация — просто очередной виток истории.
Также он отмечает, что слишком сильная дефрагментация сообщества, как у PHP и JS, — это ещё хуже, чем монополия. С этим я тоже согласен.
Я чуть выше описал зачем это было нужно. Именно как построитель запросов он и использовался, т.е. по самому прямому назначению.
не стоило тогда даже и рассматривать current_date как функцию?
Как не рассматривай, а как-то надо было её запихнуть в результирующий SQL и обойдясь при этом без raw SQL. Реальнее оказалось запихнуть как функцию )))
Ахах, ну видимо придётся контекст задачи описывать…
Нужно было предоставить пользователю возможность создавать сегменты по определённым моделям. Т.е. пользователь накидывает критерии в интерфейсе, а мы по этим критериям с помощью Arel генерируем SQL-запрос. Естественно давать пользователю вводить raw SQL в планы не входило. Переписывать без Arel было бы долго, потому что для заказчика это выглядило просто «а давайте добавим ещё 1 тип критериев в форму». При этом требования к скорости результирующего запроса были очень высокими, т.е. обернуть current_date в SQL-функцию тоже не прокатывало.
Любая функция, если она что-то делает изменяет состояние, это вроде очевидный факт касаемо ФП.
Даже чисто математические функции изменяют состояние:
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 высокий порог входа?
А вот то, что Вы не занимаясь этим и даже не изучив код того же Rails, пытаетесь намекнуть на то, что люди, которые этим занимаются, не являются профессионалами — это как-то странно. Докатились… разработка фреймворков и библиотек — это по-вашему не дело, а метания в поисках истины. Вам самому не смешно?
Автор вносил весьма значительный вклад в экосистему Ruby, если не 9 лет, то на протяжении 5 лет точно. Причём весьма активно.
Новички, как правило, просто используют то, что есть, и поэтому не добавляют никакой ценности в сообщество. Конечно, они могут со временем набрать квалификацию, выходя за рамки Rails. Но в целом на этой фазе развития идёт неизбежное понижение квалификации в среднем по сообществу.
С чего это Вы решили, что профессионалов всё устраивает?
Ну вот, автор тоже перешёл на новый качественный уровень — к функциональному программированию.
Автор 9 лет программировал на Ruby — в каком месте тут «постоянные метания»?
Речь не о закате, а о насыщении. Все, кто хотел использовать Rails, — уже используют. Теперь добавляться будут только начинающие программисты. А профессионалы будут постепенно уходить в категории «Innovators» и «Early Adopters» других технологий. И это не тенденция последнего времени, так было всегда.
Если тот же Hanami наберёт популярность, то для Ruby никакого заката не будет, даже наоборот.
У любой технологии есть свой цикл развития:
Rails сейчас очевидно находится на этапе «Late Majority». И вполне объяснимо, что Пётр, как один из лидеров Ruby-сообщества, чувствует социальную ответственность и соответственно потребность описать свою точку зрения.
И если вы пытаетесь сделать какой-то проект на инструменте, который для этого проекта не предназначен, например, магазин на Wordpress или веб-приложение, архитектурно не похожее на Basecamp, на Rails, то вы будете страдать. Однако, он забывает, что когда Rails только набирал обороты, многие говорили «Зачем нужен фреймворк, для большинства проектов достаточно CMS», «Зачем нужны Ruby и Python, большинство крупных проектов написаны на PHP». Так что текущая ситуация — просто очередной виток истории.
Также он отмечает, что слишком сильная дефрагментация сообщества, как у PHP и JS, — это ещё хуже, чем монополия. С этим я тоже согласен.
Как не рассматривай, а как-то надо было её запихнуть в результирующий SQL и обойдясь при этом без raw SQL. Реальнее оказалось запихнуть как функцию )))
Нужно было предоставить пользователю возможность создавать сегменты по определённым моделям. Т.е. пользователь накидывает критерии в интерфейсе, а мы по этим критериям с помощью Arel генерируем SQL-запрос. Естественно давать пользователю вводить raw SQL в планы не входило. Переписывать без Arel было бы долго, потому что для заказчика это выглядило просто «а давайте добавим ещё 1 тип критериев в форму». При этом требования к скорости результирующего запроса были очень высокими, т.е. обернуть current_date в SQL-функцию тоже не прокатывало.