приученность к императивной парадигме (если заставить школьника, который писал на паскале, писать на лиспе, то он будет писать на нем точно так же, как на паскале, просто со скобочками)
Вот в этом основная проблема «моды на ФП», по сути то это просто ещё 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-функцию тоже не прокатывало.
Начали и начали. От ещё одного проекта на Rails никому хуже не станет )))
А на будущее посмотрите ещё и в сторону Elixir+Phoenix. Конфет много не бывает xD
Я так понял, главная проблема автора не столько в самом Rails, сколько в сообществе.
Автор хочет привлечь внимание сообщества к тому, что есть жизнь за пределами Rails. Как на Ruby, так и на других языках. В частности он является автором более чем десятка полезных гемов для Ruby.
Очень бы хотелось обсудить предыдущую статью автора, в которой он осуждает monkey patching: если не ActiveSupport, то как?
Нет ничего плохого в отдельных модулях для подобных методов, не обязательно их добавлять к базовым классам. По началу это даёт определённый вау-эффект, но не даёт реальных преимуществ, а вот весёлый дебаг временами обеспечивает.
Хаха, а я застал «краешком»… серьёзные проекты на WebForms я не делал, но там реально была жесть, он генерировал совершенно дикий HTML, а AJAX работал через UpdatePanel, т.е. тупо обновлял практически всю страницу… Так что да, ASP.NET MVC в сравнении с WebForms был крут уже с первой версии.
Про это ещё Фаулер писал в EAA Patterns писал… Если вкратце, то AR — это одновременно и паттерн и антипаттерн, так как совершенно внаглую нарушает SRP.
Вариант хорош. Но никто и не говорит, что невозможно использовать обычные Ruby-классы совместно с Rails. Автор статьи прекрасно об этом осведомлён, просто устал бороться с тем, что генеральная линия Rails Core Team идёт совсем в другом направлении.
Ох, не напоминайте мне про Arel. Надо было мне как-то раз его подружить с PG-функциями без скобок, типа current_date.
Для тех, кто не знает, у Arel есть возможность вызывать SQL-функции, но только со скобками
Account.where{created_at == :now.func()} # работает
Account.where{created_at == :current_date.func()} # не работает
В общем, пока я воркэраунд писал, достаточно ознакомился с его исходниками. Мягко говоря, там реальный треш. Если не согласны, попробуйте решить вышеописанную задачу. У меня на тот момент была версия arel-4.0.2.
Те, кто помнят экосистему 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-функцию тоже не прокатывало.
А на будущее посмотрите ещё и в сторону Elixir+Phoenix. Конфет много не бывает xD
Автор хочет привлечь внимание сообщества к тому, что есть жизнь за пределами Rails. Как на Ruby, так и на других языках. В частности он является автором более чем десятка полезных гемов для Ruby.
Для тех, кто не знает, у Arel есть возможность вызывать SQL-функции, но только со скобками
В общем, пока я воркэраунд писал, достаточно ознакомился с его исходниками. Мягко говоря, там реальный треш. Если не согласны, попробуйте решить вышеописанную задачу. У меня на тот момент была версия arel-4.0.2.