Прошла онлайн Ruby-конференция: https://noruko.org/ (доступ разрешили без регистрации).

В докладе Матца (создателя Ruby) были все обычные заявления: добавим type annotations, нужно больше сторонних инструментов (линтеров, тайп чекеров), интерпретатор будет быстрее, улучшим JIT, думаем над созданием некоего супербыстрого "микроруби" (интерпретатора, реализующего подмножество Ruby).

Мне лично интересно было глянуть на три нововведения в синтаксисе языка (собственно, той части, которая на виду у пользователя):

1. Pattern matching

case JSON.parse(json, symbolize_names: true)
in {name: "Alice", children: [*, {name: "Bob", age: age}, *]}
  p age
in _
  p "no Alice"
end

- В целом, мне нравится, как реализован этот оператор case... in
- Не понятно, почему в качестве плейсхолдера "что угодно" используется *, а не _
- Удручает, что нет планов распространения паттерн матчинга на сигнатуры метода в стиле Elixir или JS (декомпозиция аргументов метода прямо в его сигнатуре + возможность определить/"перегрузить" одноимённые методы с разной сигнатурой)

2. Оператор "правого присвоения" (right assignment).

# было
top_five =
  (1..100)
  .map{|x| rand(x)}
  .sort
  .reverse
  .take(5)

# стало
(1..100)
  .map{|x| rand(x)}
  .sort
  .reverse
  .take(5) => top_five

- Мне нравится, как Матц не ставит пробелы перед и после фигурных скобок блока - такое написание удобней и практичней традиционного по "западному" кодстайлу
- Пример не убедительный - следовательно, убедительного примера, где бы правое присвоение могло быть удобным придумать сходу Матцу не удалось

3. Порядковые аргументы блока

# умножить каждый элемент на 2
[1, 2, 3].map{_1 * 2}

- Идея мне нравится - такая возможность была бы весьма востребована
- Выбор имён _1, _2, ... выглядит как-то несовременно

Общее резюме, цитируя-перефразируя Матца: Ruby будет становиться лучше (если американцы традиционно помогут японцам сделать из их кулибинских идей красивый коммерческий продукт), и вы тоже :)

#programming #ruby

"Функциональное программирование" (ФП) - модный термин.

Автор имеет опыт разработки веб-приложений на Elixir-е (с использованием фреймворка Phoenix). Можно ли Elixir считать функциональным языком? Большинство отвечают, мол, конечно, это один из референтных представителей группы. Тот же JavaScript или Ruby могут назвать "языком с *элементами* ФП", но никому не придёт в голову назвать "полноценным" "функциональным языком".

Мне кажется, точно также, как отсутствие диплома о техническом образовании не делает человека гуманитарием (впрочем, верно и обратное), также и отсутствие на уровне базовых конструкций языка "экземпляров классов" не делает язык "функциональным". В случае Elixir, отсутствие "экземпляров" не делает даже язык "не объектно-ориентированным".

В самом деле, ООП (объектно-ориентированный подход/программирование) зиждется на следующей формуле: "состояние" + "поведение". У нас есть некие автономные чёрные ящики (объекты), у которых в каждый момент времени есть некое внутреннее (не видимое снаружи) состояние и есть возможность получать сообщения.

Сейчас обычно говорят не "получать сообщения", а "вызывать метод". Впрочем, обратите внимание, что в Ruby проверка на то, существует ли у объекта метод, делается с помощью метода `respond_to?`— "отвечает ли?". Наследие Smalltalk, где объекты таки посылали друг другу именно "сообщения". В каком-нибудь Objective C (базовом языке для разработки под iOS) до сих пор официально "посылают сообщения".

Но, простите, а что наши разработанные на Elixir "процессы" делают, когда работают в экосистеме Erlang-а? Посылают друг другу сообщения. И так, Elixir-овский "процесс":
— имеет внутреннее состояние (минимальное разнообразие типовых способов работы с состоянием заложено в стандартную библиотеку, называющуюся OTP);
— отвечают на "сообщения".

QED, господа — Elixir это объектно-ориентированный язык (где роль "классов" играют "модули", роль "объектов" — "процессы", роль "методов" — сообщения и функции).

Отличие Elixir в том, что, когда вы пишете код, язык вас вынуждает явно себе представлять, как ваши объекты "раскладываются" по процессам (параллельным потокам выполнения) — какой объект живёт в каком "домике"-процессе на каком "островке"-сетевом узле. Традиционный объектно-ориентированный язык позволяет инкапсулировать даже сетевой вызов к REST-ресурсу, избаловывая программиста этими непрозрачными стенками абстракций.

#programming #fp #ruby #javascript #elixir

Элементы ФП в императивных языках

Мода на "функциональное программирование" задаётся, несомненно, как раз привнесением в более распространённые императивные языки пресловутых "элементов ФП".

Среди всех таких элементов можно (условно — реальная "генеалогия" чуть сложнее) выделить два класса:

1) Элемент LISP: лямбда-функции. В Ruby "лямбды" изначально были заложены в язык в виде "блоков кода" (конечно, в оригинальном LISP это сделано несколько более органично). Вслед за взрывным ростом популярности Ruby и большим признанием удобства использования "лямбд" со стороны прикладных программистов, стали потихоньку добавлять их и в другие языки: кажется, первым среди невымирающих динозавров была Java 8. Ну а теперь даже в C++ вы можете встретить нечто похожее.

2) Элемент LISP: итераторы. Аналогично с итераторами: map, select, reduce, zip, и т. д. и т. п. можно найти в любом уважающем себя современном языке. Популяризирует их в наше время JavaScript, в очередной ревизии которого они наконец появились, чтобы язык не выглядел совсем уж позорно на фоне любительской поделки фанатиков Rails — CoffeScript-а (как раз после появления "лямбд" и итераторов в JS "коффискрипт" и умер).

3) Элемент Haskell: "монады". Мало кто, в сущности, знает хоть что-то о системе категорий, но антураж "матана" привлекает неуверенных в себе программистов. Точно также, как психолог в связи с массовостью профессии и отсутствием профессиональных стандартов считается неполноценным психиатром, и программист на заре развития программирования мог бы считаться неполноценным математиком. В какой-то мере сохраняется подобное смутное чувство и сегодня. Из всего Haskell-а (этакого "языка программирования от математиков") выдёргивают обычно так называемые "монады". Элементарная, в сущности, концепция, которая на языке ООП описывалась бы простым интерфейсом контейнера с 3-8 методами, превращается в жупел, которым неполноценные математики, так и не сумевшие стать программистами, формируют неуверенность в своём интеллекте у программистов, которые не желают становиться математиками.

4) Элемент Haskell: pattern matching. Опять же, JavaScript популяризирует концепцию в наше время, переназвав её как "destructuring". На мой взгляд, впрочем, в таком терминологическом изменении нет ничего страшного: надо быть ближе к народу. Destructuring позволяет, например, прямо в сигнатуре функции (в перечислении аргументов) "выдернуть" ключ хеша или элемент массива из входящего параметра (таким образом "сопоставив", match, входящую структуру некоему "образцу", pattern). Ruby идёт с отставанием: на коленке сделанный case... in в свежей версии это хорошо, но мало: даёшь "перегрузку" функций в зависимости от структуры аргумента, как в том же Elixir.

А кроме этих четырёх пунктов, что-то больше ничего и не приходит на ум.

А вам каких "элементов ФП" не хватает в любимых языках?

#programming #fp #ruby #javascript #elixir

Хроники смерти Ruby: первоисточник (1/6)

Сейчас можно считать сложившимся мнением среди настоящих софтверных инженеров, привыкших получать информацию из третьих рук и доверять экспертному мнению профессиональных IT-журналистов, что Ruby умирает (вариант: уже умер).

Интересно проследить историческую перспективу развития вопроса.

Впервые поднял тему, взявши сразу быка за рога, некий Jeff Cogswell в статье от 2014 года с недвусмысленным названием "5 языков программирования, назначенных умереть" ("5 Programming Languages Marked for Death").

Раздел про Ruby начинается с предложения, пытающегося подчеркнуть для читателей, насколько автор в теме: "всего десять лет назад, Руби был на пике моды [по Руби все сходили с ума]". Напомню, десять лет назад от момента написания статьи был 2004 год. Два года до выхода первой версии Ruby on Rails. Ruby вообще никто не знал, это был хоббийный проект нескольких неизвестных японских разработчиков из академических кругов.

Но всё же за что Джефф приговорил Ruby?

Утверждает, что, мол, "мы, люди, которые выросли на С-подобном синтаксисе, путаемся и спотыкаемся при изучении того, как работает Ruby". Дальше приводит два примера, в чём профессиональные С-программисты путаются: "hello, world" и функция для вычисления факториала:

puts 'Bye bye, Miss American Ruby! Drove my Chevy to the Levie…'

puts '2011 was the day that Ruby died, yeah…'

def fact(n)
  if n == 0
    1
  else
    n * fact(n-1)
  end
end

puts fact(ARGV[0].to_i)

Текст примеров понятен даже человеку, который вообще не умеет программировать.

Дальше в статье приводится типовой аргумент "про Твиттер": "все любят язык, а вот Твиттер переписал весь проект с Ruby, т.к. не хватило производительности".

Для динамического языка, вообще говоря, нет ничего позорного в эволюции проекта вида "быстро написали, потом переписали на статическом языке". Это нормальное и даже целевое применение технологии. Благодаря этому Твиттер смог получить первых пользователей и, не застряв в болоте Java-разработки, заработать денег на дальнейшее развитие. Закономерный ход типовой эволюции стартапа. Но примечательно здесь то, что второго примера, кроме Твиттера, такой эволюции для Ruby никогда не приводят. Проектов на Rails сколько угодно любых размеров, а вот примеров отказа от технологии единицы. То есть в плане производительности Ruby/Rails всех, по большому счёту, устраивает.

Итак, Джефф пишет, с лёгкой иронией и играя словами, что в 2011 году Ruby уже, в мыслях автора, умер. В тот же год в реальном мире разработчик языка, Юкихиро Матсумото, был принят на руководящую техническую позицию в Heroku, недавно закрывшего сделку по продаже компании (2010) за $200 млн.

Heroku начал свой путь как система развёртывания и хостинга Ruby-приложений. Так сказать, от Ruby-разработчиков для Ruby-разработчиков. И так лихо сделал и реализовал ставку на умирающий язык, что за три года из "гаражного стартапа" превратился в одного из лидеров начавшейся индустрии "контейнерных-облачных хостингов".

В то время крупнейшие компании практически одновременно начали "гонку вооружений" за раздел только начавшего появляться (но уже заранее понятно, что сулящего огромные прибыли) рынка "цифровых облаков". Amazon запускает AWS (2006); Google – Cloud Platform (2008); Microsoft, спохватившись позднее всех, Azure (2010). В разгар битвы слона, кита и бегемота без лишнего шума и пыли откусывает значительную часть пирога Heroku (2007-2010), который практически сразу выкупает разработчик CRM-систем Salesforce (2010). Актив не совсем профильный, но Salesforce верно рассчитала, что дело того стоит, да и цена сделки, в масштабе разворачивающихся событий, копеечная. Благодаря своей прозорливости Salesforce до сих пор борется с "облачными конкурентами" более чем на равных. Heroku остаётся обособленным подразделением, продолжающим развивать платформу под крылом материнской компании.

#programming #ruby

Ну а Джефф к моменту написания статьи уже сильно отошёл от программирования ("разработку на jQuery" за программирование считать не будем). Зато всерьёз занялся набравшим популярность devops-ом. На наборе технологий прямого конкурента Heroku – AWS. Через год после написания статьи его собственный бизнес на данную хайповую тему "не пошёл" и был "приостановлен на неопределённое время", но, к счастью, ниша для "консультанта по облакам" с опытом С++ и без понимания потребностей стартапов находится. Джефф в конечном итоге оседает "AWS-консультантом" в крошечном провинциальном провайдере услуг телефонии и интернета. Что ж, дело полезное: как минимум, кто-то должен объяснять, в чём именно польза от освоения средств на "облачную инфраструктуру" (для телефонной компании).

Инженер, списавший Ruby в устаревшие языки, был списан как устаревший программист и бизнесмен. Диалектика.

#programming #ruby

Хроники смерти Ruby: круги на воде (2/6)

Посредественная статья от "учителя, автора книг, С++-разработчика, AWS-консультанта" (см. прыдудщие посты), опубликованная в довольно крупном онлайн-издании, породила круги на воде. Люди начали задавать вопросы, ставить промблемы.

"Рубисты", конечно, в основном продолжали заниматься своим делом и вообще были не в курсе происходящего. Я сам в 2014 взялся за очередной проект, стейкхолдеры которого (не будучи программистами) выбрали Rails за его рентабельность для бизнеса. И так, как-то по инерции, переходя раз в год-два на очередной новый проект с очередным рутинным повышением зарплаты, узнал о том, что Ruby умер, году в 2019-м. Узнал случайно, поскольку тема начала подниматься в кругах потенциальных клиентов Rails-курса, где я преподаю.

В инфополе, тем временем, в 2014-2015 году кто-то лениво отпинывался от статьи Джеффа, мягко намекая, что ставить в один ряд Perl, Delphi, VB.NET и Ruby это несколько перебор, в независимости от популярности последнего.

Кто-то закинул удочку прямо в мейлинг лист по Ruby, в обсуждение довольно мелкого, но всё же существенного рутинного технического вопроса (введения frozen string literals по умолчанию): один из разработчиков риторически спросил, не умирает ли Ruby потому, что другой разработчик настаивал на изменениях(!) языка в сторону упрощения(!) его применения конечными пользователями. Логика абсурдная, но вброс был сделан. "Внутренний круг разработчиков Ruby обсуждает, не умирает ли Ruby".

Кто-то начал использовать заданный тренд демагогии для оправдания недостатков конкурирующих платформ. Очередной PHP-разработчик пишет, что "преимущества Ruby пропали с появлением Laravel". Оцените накал пафоса: Laravel – это попытка прямо скопировать успех Rails на PHP. Попытка, в определённой степени, удачная, поскольку за PHP стоят бюджеты инертного Facebook-а, в своё время прогадавшего с выбором языка, да так и тянущего за собой грузило – бюджеты, гарантирующие определённую популярность. Проблема такой попытки в следующем: разработчик Ruby старался сделать язык, удобный для людей; а разработчик PHP слепил (по собственному его признанию) тяп-ляп, и когда ему указывают на большое количество накопившихся недоработок, то он с раздражением отвечает, что исправлять ничего не собирается, всё и так хорошо, поскольку язык вон видите какой популярный. Необразованный плагиатор и имитатор через губу бросил оригинальному автору замечание о том, что у последнего "уже нет преимуществ".

Адепты серверной разработки на Javascript (появление node.js во многом воспринималась как первоапрельская шутка, сделанная в неправильное время года – но ничего, сейчас попривыкли уже) зашли с другой стороны. Пользуясь своим профессиональным опытом, они сделали следующее предсказание: т.к. веб-фреймворки постоянно рождаются и умирают, то и Rails скоро умрёт. Проблема в том, что предсказание актуально для мира Javascript, но не для Rails.

Между Rails 3-й версии (2010) и 6-й (2019) различий в базовой функциональности так мало (с точки зрения пользователя – "внутренности" минимум дважды, конечно, переписали практически полностью), что переучиться можно, наверное, за пару дней (хотя, конечно, кое-что добавили, что придётся изучать дополнительно). В тот же временной период в JS изменился сам язык до почти полной неузнаваемости, а изменения первой цифры версий фреймворков (Angular 1 -> 2, React 3 -> 17 и др.) сопровождается, фактически, полным пересмотром всех основ – по сути созданием нового фреймворка. Тот критик несколько раз за прошедшее время становился полностью неактуальными и должен был начинать, фактически, с нуля (если смог).

Rails, напротив, это очень стабильная работа. Которая будет актуальна столько времени, сколько будет актуален современный интернет (пока все не перейдут, например, в VR, или не осядут по крупнейшим соцсетям с закрытием всех независимых сайтов).

#programming #ruby

Хроники смерти Ruby: старички на марше (3/6)

Переходим к 2016-2017 годам.

Очередной "консультант по облакам", рекламирующий себя на Quora как (не преувеличиваю, реально, так и пишет в своём профиле) "Задаватель Тяжёлых Вопросов" (ну, то есть, человек ставит промблемы-с), растекается мыслью по древу в 2016 году: Ruby плохой язык, так как обслуживает нужды Rails, а больше нигде и не используется.

Ну, во-первых, используется ещё в Devops.

Во-вторых, уважаемый, вы тему не меняйте. Речь шла про веб-разработку. С другими нишами компетентные люди разберутся, если будет время и деньги: не будите лихо. С этой уже разобрались так, что до сих пор все успокоиться не могут, так и норовят всё метку смерти налепить. Со всех сторон уже облепили, а языку хоть бы хны.

По пунктам отвечать на очередное сравнение Ruby с VB и COBOL (последний разработан в 1959 году, ещё до Алгола, положившего начало всем современным процедурным языкам, и сейчас применяется в устаревшем на полвека софте американских банков), впрочем, не буду. Мне кажется, аватар очередного эксперта по веб-разработке говорит сам за себя: то есть понятно, что человек может порассуждать предметно о COBOL-е, но вот сам факт, что он его вспомнил и привёл в аргументе, уже является в полной мере самораскрывающим. "Дедушке пора на пенсию, заговаривается".

Ну а дальше пошла плясать губерния. Основной тон плясок примерно такой:

2014 – "Ruby умер"
2016 – "Ruby умирает и вот-вот умрёт"
2019 – "Ruby ещё держится, но вот-вот начнёт умирать"

К пляскам присоединились самые широкие массы трудящихся.

Евангелисты Go (языка, который разработала и поддерживает Google, крупнейшая IT-корпорация Земли) не посчитали выше своего достоинства присоединиться к общей демагогии. Мол, "руби умер, го писать на го". Предлагается писать на сравнительно неплохой вариации на тему языка Pascal (разработан в 1970), в которой разработчикам не удалось (в основном по организационно-политическим, а не техническим причинам) заимствовать многие полезные фичи из последователя паскаля, языка Oberon (разработан в 1986).

В чём замысел Go? Go – это язык, созданный стариками для студентов. Причём стариками, которые, в сущности, не любят студентов; мало того что не понимают их (это не грех, если разница в возрасте большая), но и не хотят понять; считают их чрезмерно амбиционзными дураками, которых надо приземлить. А Ruby – это язык, созданный взрослыми людьми для взрослых людей, чтобы дать им свободу и работающий инструмент самовыражения.

Не трудно заметить, что для того, чтобы полюбить Go-разработку (по принуждению и за хорошие деньги можно писать на чём угодно), мало быть студентом, надо ещё иметь низкую самооценку.

К пляскам на короткое время присоединяются сторонники Swift. Языка, разработанного в Apple для того, чтобы дать альтернативу к тому моменту уже совсем позорной неэстетичности Objective C. В сущности, Apple, выражаясь просторечно, прокинула пользователей Ruby. Малоизвестный факт: в Apple разрабатывалась, до какого-то момента, своя версия интерпретатора Ruby (MacRuby – 2007-2012), с компиляцией в низкоуровневый байткод LLVM, за счёт чего достагалсь производительность, сравнимая с компилируемыми языками. В конечном итоге Apple решила, в своей манере, не поддерживать общественный проект, а сделать свой уникальный продукт, выпустив Swift. Впрочем, macOS/iOS разработка это свой собственный мир, с веб-разработкой практически не пересекающийся, поэтому в данном разборе уделять ему внимания больше не будем. Реинкарнация идеи "компилируемого Ruby для маков" живёт в виде проекта Rubymotion, который пока только пытается нащупать целевую нишу.

Наконец, набирает популярность язык Elixir (2012). Язык создан "рубистом" (действующим членом команды разработки Rails) Хосе Валимом для платформы Erlang. Erlang (появился в 1980-х) – платформа для "старичков", занимающихся разработкой софта для телефонных сетей и коммутаторов, получает второе дыхание и выходит на оперативные просторы, становясь не просто "надёжной" или "зарекомендовавшей себя" технологией, а модной и приятной.

#programming #ruby

Хроники смерти Ruby: Ruby и Elixir (4/6)

Elixir, оттолкнувшись от рубишной базы энтузиастов и заимствовав некоторые элементы внешней эстетики языка Ruby, быстро уходит в свободное плавание. Социально активные рубисты, до которых спустя несколько лет наконец начали доходить слухи о скоропостижной кончине любимого языка, начинают давать восторженные отзывы Elixir-у. Пишутся статьи, переходят разработчики, выступают на Ruby-конференциях с обзором новой модной темы. Через пару лет возвращаются обратно на Ruby.

Elixir и Phoenix занимают свою, пока что ещё не до конца устоявшуюся, нишу в мире веб-разработки. Rails – это "через пять лет вырастем до 100 тыс. пользователей". Elixir – это "уже сейчас 1 млн. запросов в секунду". Это мир Discord-а, Whatsapp-а, некоторых подсистем серверов онлайн-игр и прочих распределённых приложений. Ниша пересекается с классическими веб-приложениями, но не сильно.

Мир Elixir, по ряду причин, очень конгруентен миру Ruby. Elixir в использовании гораздо более сложный, чем Ruby (а Phoenix гораздо менее продуктивный в типовых случаях, чем Rails). Сложность окупается кратным ростом возможной производительности с тем же "железом". Из одной экосистемы в другую постоянно идёт взаимопроникновение идей и технологий. Phoenix списывает, творчески перерабатывая под функциональную парадигму (и постепенно в целом радикально переиначивая на свой лад), основную структуру Rails-приложения. Rails списывает экспериментальную и недоработанную идею LiveView (серверных обновлений клиентских событий) у Phoenix, доводит до ума на свой лад и тут же выпускает в production. Phoenix успевает только глазами хлопать. Короче, милые бранятся – только тешатся.

#programming #ruby

Хроники смерти Ruby: пик популярности (5/6)

К 2017-2018 годам, через 6 лет после даты смерти (2011) и через 3 года после её публичного объявления (2014), Ruby достигает невиданной популярности. До этой поры будучи в общем-то нишевым языком, "себе на уме", инструментом для сравнительно небольшой группы приверженцев (хоть и постоянно растущей), Ruby/Rails становится абсолютным мейнстримом.

Напомню, что создатель Ruby on Rails, Дэвид Хейнмайер Хэнсон, в своей книге "Getting real" (можно перевести как-то вроде "Становясь реалистичным") писал как владелец небольшой компании другим владельцам (и сотрудникам) небольших компаний: ребята, умерьте аппетиты. Не надо мегаломанских целей типа стать фейсбуком. Поставьте скромную цель. Например, миллион баксов в год. Чистыми.

Не надо стремиться к публикациям в больших журналах, типа Wall Street. Занимайтесь маркетингом в своей нише.

Не надо стремиться купить домен из одного словарного слова. Берите любой подходящий, добавьте "app" если надо. Первый домен для приложения компании: basecamphq.com

Спустя годы, конечно, компания-разработчик Rails покупает домен "basecamp.com".

А уже в наше время купила домен "hey.com" (2020) для своего нового email-сервиса (цена не разглашается; из общих соображений, от сотен тысяч до нескольких миллионов долларов).

Про ряд публикаций в Wall Street и выход книги-бестселлера Rework и не говорю.

В компании Basecamp скромно поясняют, мол, к такому успеху не стремились, но к нему пришли.

Следом за успехом материнской компании, получает свои 15 минут славы и разработанный ей (с участием открытого сообщества) фреймворк.

Зарплата Ruby on Rails разработчика выходит на первую строку таблицы зарплат веб-разработчиков.

Ruby заходит одной ногой в топ-10 популярных языков. В последующие годы рекорд не побит: болтается с 10 по 15 место.

Феноменальный успех для нишевого языка, который не поддерживает ни одна всемирная корпорация, и который находился под постоянным коллективным прессингом со стороны агитаторов всех конкурентов.

И вот с этого момента, наконец, можно считать Ruby состоявшимся языком, который хотя бы в теории может начать умирать. По-моему, плато действительно пройдено. Что же, C++ умирает 25 лет. Java умирает 20 лет. .NET умирает 15 лет. Ну и Ruby ещё покочевряжится немножко, как минимум пока нынешние первокурсники не станут шестидесятилетними старичками и не уйдут на пенсию. Не трудно заметить, что период умирания языка в несколько раз превышает период его бурной молодости, так что ждать придётся долго.

Внезапно став мейнстримом, Ruby, из-за своей специализированности и, в некоторой мере, "сиротства" (ни одна всемирная корпорация не поддерживает язык, в отличие от практически любого другого популярного), занял позиции позади навязываемых организационно-административными мерами C++, Go, PHP, Python и др. в индексе "народной популярности" Stackoverflow (последний стал использоваться в качестве основного демагогического аргумента "бесконечного умирания" Ruby).

Зацените накал полемики: Ruby только-только дорос, по масштабам внедрения и популярности, до целесообразности попытки штурма Топ-10 рейтинга Stackoverflow. А отношение такое, как будто он уже успел влезть на первое место и оттуда скатиться на десятое. Откуда такая паника-то? Спокойней надо относиться, ребята, сдержанней.

Объективно, у Ruby/Rails есть существенный недостаток. Если на C++, Java или КОБОЛе десять дедушек могут полтора года "строить архитектуру", "внедрять паттерны", "документировать и проектировать", вместо реализации бизнес-задач, то на Ruby два студента-старшекурсника за месяц делают MVP. Дедушке не хочется Ruby, ему хочется спокойной жизни. Дедушка напишет в блог, мол, я сорок лет в индустрии, пережил смерть алгола, кобола, эйпиэля, паскаля, ады и перла. И руби тоже туда отправится. Переживу.

Может быть.

Но рассмотрим второй вариант: дедушку самого отправят на пенсию.

На что ставим?

#programming #ruby

Хроники умирания Ruby: 2020 и далее (6/6)

К 2020 году Ruby-сообщество окончательно пришло к выводу, что статус первоклассного языка, который был присвоен Ruby "явочным порядком" и без инициативы самого сообщества, накладывает некоторые обязательства, которые невольно надо пытаться выполнять. В частности, поддерживать градус ответной демагогии на должном уровне.

В прошлом году одна из крупнейших PHP-конференций не состоялась, потому что пару разработчиков-феминисток "выразили озабоченность" в связи с "недостаточным разнообразием [diversity]" спикеров. Организатор конференции, глупо хлопая глазами, оправдывался: "Да я... да вы что... да я же приглашал... да просто не было женщин желающих...". На что ему блюстители дайвёрсити строго, сдерживая справедливое раздражение, бросали: "Лучше искать надо было."

В этом плане у Ruby-сообщества несомненный бонус в виде создателя языка-японца и его коллег. Впрочем, как мы видим на примере Cyberpunk, даже при такой казалось бы железобетонной страховке, всерьёз начать докапываться всё равно могут. Но в ином случае было бы совсем плохо, с другой стороны.

Вообще, первая конференция по Ruby, на которую я пришёл, выглядела так: примерно десять человек в Москве встретились у метро. Списались через тематическую Google-группу. Один из участников заранее договорился со своим институтом (не первой величины), выделили кабинет, допустили на территорию. По очереди несколько человек о чём-то интересном рассказали, пиша мелом на доске. Про RSpec доклад был, про то, про сё. Поболтали душевно.

Одна из недавних конференций выглядела до локдауна вы сами знаете как. Официальные спонсоры. Огромная территория, снятая на несколько дней в пригороде. Тысячи участников. Докладчики первой величины со всего мира.

Попробуйте представить теперь, как я воспринимаю назойливо муссируемую идею о том, что Ruby, оказывается, умирает все эти годы. Моей первой реакцией является просто плюнуть и покрутить пальцем у виска: клинический неадекват. Но вот ради молодёжи (не в смысле возраста, а в смысле причастности к теме), которая не виновата в своей начальной неосведомлённости, решил расписать эту мысль чуть подробней.

Собственно, примерно такая же реакция у пока не до конца сориентировавшихся в "социальной реальности" зарубежных коллег. Пишутся статьи со сдержанным недоумением, мол, ребята, что вы нам сказки-то рассказываете: например, про низкую производительность Ruby/Rails? По сравнению с чем низкая? Уж не хуже, например, чем у Python/Django и PHP/Laravel.

"Не хуже" – это, конечно, вежливая сдержанность взрослого, чтобы не обидеть навязчивых подростков. Следующим бесхитростным ходом в борьбе инженеров с журналистами является такой: "А теперь Ruby стал в три раза быстрей. Третья версия." Мол, ну да, умираем, виноваты-с. Кочевряжимся вот как-то так, простите.

Ответным контр-ходом является вариация на тему "вы всё врёти", а именно мантра следующего сорта: "каждый инструмент подходит под свою задачу, нельзя однобоко смотреть на вещи, инженер должен уметь пользоваться чем дают, программист может изучить язык за две недели" и т.п.

На что инженер будет недоумённо хмуриться: мол, простите, а зачем мне кто-то будет рассказывать, что я должен говорить и даже думать(!), если я могу сам всё попробовать и объективно сравнить?

Сравнительный анализ инструментов для конкретной ниши разработки веб-приложений (в широком смысле) показывает, что Ruby/Rails – это самый технологичный инструмент на сегодняшний день. Вообще, на самом деле, рубисты плевать хотели и на Ruby, и на Rails, и не так уж сильно, открою секрет, любят эти технологии.

"Культ Rails" это "культ острых ножей для нарезания хлеба". "Почему ты острым ножом режешь, ведь есть десять тупых?" – "Ну дык, это, удобней ить" – "Ты, как инженер, должен уметь использовать разные инструменты, смотреть на технологии объективно, научиться пользоваться другим ножом можно за пару дней..." и пошло-поехало.

#programming #ruby