Вышел Ruby 2.3.3

Если они минорные релизы делают с промежутком в 6 дней, то ты каждые 6 дней будешь тащить это сюда?

Нет, разработчики Ruby не из тех, кто делают релизи часто или через определённые промежутки времени. К счастью, ещё много, очень много софта с нормальным темпом разработки. И то, что разработчики внезапно могут что-то пофиксить выпустив релиз, этому не противоречит.

Релиз Ruby 2.3.1 был в конце апреля, а релиз 2.3.0 был в конце декабря прошлого года.

Мужики, а какая область применения у рубей? Где они хороши? А то везде питон да питон, изо всех щелей уже.

ЯП одного фреймворка же, подрастерявшего популярность. Еще можно замшелый перл заменить в нише одноразового кода.

Chef на рубях, где кроме него - хз

Это объектно-ориентированный скриптовый язык широкого применения. От прикладных задач в десятки строчек до дистрибутивных скриптов (как в Зюзе) и игр. Поддерживает и GUI тулкиты, но с Tk в последние годы стали возникать проблемы, и из ветки 2.4.x поддержку Tk, вроде как, выпилят совсем.

PS. Один из ряда скриптовых языков, которые продолжают знать про кодировку KOI8-R.

Ну, ты сюда постишь анонс минорного релиз, который от прошлого релиза отличается 2 коммитами. В этом топике уже текста больше, чем этот диф.

Событие планетарного масштаба.

Мужики, а какая область применения у рубей?

Регулярно ломать обратную совместимость.

А то везде питон да питон, изо всех щелей уже.

s/python/js

Не совсем так. Релиз 2.3.1 был 7 месяцев назад. Новость о релизе предыдущей версии 2.3.2 многие могли пропустить. А те, кто не пропустили, могут не ожидать сабжевого релиза 2.3.3. В любом случае для тех, кто следит за версиями, это может быть интересно.

Мужики, а какая область применения у рубей? Где они хороши? А то везде питон да питон, изо всех щелей уже.

Та же область, что и у Python, но Ruby удобен, а Python — не очень.

В Ruby обычно есть один очевидный способ сделать простую вещь, а в Python — их много и все как будто намеренно усложнены. Например, чтобы сделать слияние двух хэшмапов в Python есть с десяток способов и ни один из них не так очевиден как Hash#merge:

context = defaults.merge user

Та же область, что и у Python

С той лишь разницой, что Python входит в LSB и есть вообще везде, а что бы запустить какою-нибудь рибиновую хрень нужно на машину притащить RVM и 2-3 версии интерпретатора.

В Ruby обычно есть один очевидный способ сделать простую вещь, а в Python

Все с точностью до наоборот.

Например

Вот это как очевидный пример, что в Ruby принято обмазываться сахарком в 10 слоев регулярно при этом ломая обратную совместимость и собтсвенные же парадигмы языка.

А еще Ruby пожалуй единственный современный язык, который демонстрирует продолжительный и стабильный отток аудитории. Собственно, ничем кроме как пускалки рельсов стать ему не удалось и уже не удастся. Вангую, что через 7-10 лет он будет там, где сейчас Perl.

там, где сейчас Perl

Perl 5 живее всех живых. Активно развивается вместе с модулями. Perl 5.24 вышел в мае, параллельно стартанула тестинг ветка 5.25. В понедельник вышел Perl 5.25.7.

Отток наблюдается в сторону Node.js либо Elixir/Phoenix у которых ноги растут из RoR, но никак не в сторону Python который уже сам давно трупным душком пованивает, не говоря уже о Django, и у которого тоже наблюдается отток.

Про обратную совместимость - полная чушь. Серьёзный передел был в конце нулевых между 1.8 и 1.9, равно как и у Python с версиями 2 и 3, только лишь наоборот с той разницей, что поломали не так кардинально и про версию 1.8 уже забыли многие годы назад, а питонисты до сих пор 2.7 уплетают.

P.S. Python - норм. Лютый идеологический хейт из разряда «краем уха слышал» - не норм.

Отток наблюдается в сторону Node.js либо Elixir/Phoenix у которых ноги растут из RoR, но никак не в сторону Python

В отличии от ваших «предположений», я свои утверждения основываю на статистике гитхаба (с 2012 года). Особенно все это хорошо видно не в количественном, а как раз таки в процентном соотношении.

Про то что ноги Node растут из ROR ты это знатно меня повеселил.

С той лишь разницой, что Python входит в LSB и есть вообще везде, а что бы запустить какою-нибудь рибиновую хрень нужно на машину притащить RVM и 2-3 версии интерпретатора.

Я не использую RVM, и ruby-build с chruby тоже давно перестал использовать(потому что в этом нет необходимости). Использую последнюю стабильную версию из репозиториев Arch, Ubuntu, и docker-контейнеры на базе alpine.

Какая программа не работает на последней стабильной версии(мне правда интересно)? Для какой программы вам потребовалось «притащить RVM и 2-3 версии интерпретатора»?

Создается впечатление, что то, что вы пишете, скорее основано на болезненном опыте с Python 2 и 3.

Вот это как очевидный пример, что в Ruby принято обмазываться сахарком в 10 слоев

Как, по вашему мнению, следовало бы правильно решать эту задачу?

Про то что ноги Node растут из ROR ты это знатно меня повеселил.

Речь была про Elixir/Phoenix, это же очевидно и не нуждается в пояснениях любому разбирающемуся в теме человеку. Мнение о Ruby того, кто слышит это сочетание в первый раз очень авторитетно, да :)

Создается впечатление, что то, что вы пишете, скорее основано на болезненном опыте с Python 2 и 3.

Да так оно и есть. Плач Ярославны джангиста и личные фантомные боли и кошмары.

на болезненном опыте с Python 2 и 3.

В чем заключается болезненность опыта с Python 2 и 3?

Вы не поверите, но версии Forthan и Cobol тоже до сих пор выходят.

В чем заключается болезненность опыта с Python 2 и 3?
регулярно при этом ломая обратную совместимость и собтсвенные же парадигмы языка.

Оно еще живо?

Например, чтобы сделать слияние двух хэшмапов в Python есть с десяток способов и ни один из них не так очевиден как Hash#merge

Прошу прощения, мне неочевидно, почему merge существующего defaults с user дает внезапно новый хэшмап. Это как если бы слияние основной ветки репозитория DVS с побочной создавало отдельную третью ветку. Но нет, в реальном мире слияние ничего нового не создает. По логике, defaults.merge в Руби должен действовать как defaults.update в Питоне.

Вы не поверите, но версии Forthan и Cobol тоже до сих пор выходят.

Не просто поверю, а знаю. Потому, что практически без них никак. Весь серьёзный математический код написан на Fortran'е. Без Fortran'а нет ни scipy, ни octave,... На Cobol'е тоже полно рабочих и практически использующихся программ.

Можно глянуть как ломается msf.

Стандарты с(++) тоже выходят до сих пор.

Так я только за. В отличии от динозавров C/C++ по-мнению некоторых от которых тоже может «попахивать» с них народ не валит толпами, собственно то, о чем я и говорю.

мне неочевидно

Человек как раз таки не догонят, что есть жесткая парадигма - явное лучше неявного. И приведенные им же примеры, где две структуры данных в явном виде объединяются в третью это наглядно демонстрируют, но радуется что ему дали сахарку записать это в одну строчку.

Можно глянуть как ломается msf.

А как он ломается?

➜  ~ msfconsole -v
Framework Version: 4.13.0-dev
➜  ~ ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux]

Интересно, как бы вы назвали статью «The Idiomatic Way to Merge Dictionaries in Python», следуя своей логике.

Ты просто не знаком с Ruby.
Для меня, например, очевидно, что метод merge вернет новый объект, в то время как merge! - изменит существующий объект.

очевиден как Hash#merge:

Нет, сахар как раз-таки != очевидность. Сахар (с этим еще можно поспорить) == упрощение конкретных операций в пользу _восприятия_, а-ля @запомни, что _arr1 --> _arr2 --> _arr3 ... --> _arrN даст пересечение массивов _arr1 ... _arrN@ Мб поэтому все «старики», которых я знаю, не ведутся на него от слова совсем.

Очевидность, это когда (по примеру выше) – нет стандартной intersection -> ищем+тянем либу -> нет либы -> пишем реализацию. Вот и вся очевидность. Меньше сахара -> меньше мусора в голове.

Вышел Ruby 2.3.3 (комментарий)

Для меня, например, очевидно, что метод merge вернет новый объект

merge -> слияние/соединение
Я думаю определения в русском словаре сам найдешь. Не представляю, где ты здесь увидел _очевидность_.

P.S.:

Ты просто не знаком с Ruby.

Я надеюсь ты под _работой программиста_ не подразумеваешь _зубрежку сахара_ (не знаком с Ruby)? Если так, у меня для тебя плохие новости.

Ты хочешь мне доказать, что метод merge не делает `слияние/соединение`?

Я надеюсь ты под _работой программиста_ не подразумеваешь _зубрежку сахара_?

В стандартной библиотеке Ruby принято соглашение об именовании методов, поищи и почитай.

Я надеюсь ты под _работой программиста_ не подразумеваешь _зубрежку сахара_?

В стандартной библиотеке Ruby принято соглашение об именовании методов, поищи и почитай.

Я задал тебе вопрос, ты ушел от ответа. Типичный показатель.

Симметрично :D

Ты хочешь мне доказать, что метод merge не делает `слияние/соединение`?

Создавая новый объект? Со своей функцией он справляется, кто ж спорит, но только для меня более _очевидно_, когда под слиянием подразумевается _поглощение_ одного объекта другим.

Симметрично :D

Что симметрично, погромист? Ты на вопрос-то ответь, а то красиво уходить мы все умеем.

Ты только «за» что? А то так сразу и не понятно: осуждаешь ты перл или хвалишь, и за что?

Можно его запустить версией 1.9.3?

Можно его запустить версией 1.9.3?

Наверное, нет. А зачем?

Поддержка 1.9 завершилась. Не вижу причины, по которой разработчики msf могли бы отказаться от фич, которые появились в более новых версиях.

А dict.update — это «сахар» или нет?

Поддержка 1.9 завершилась. Не вижу причины, по которой разработчики msf могли бы отказаться от фич, которые появились в более новых версиях.

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

if {$tcl_version == 8.5} {
  proc lmap {...}
}

Конкретно этот метод – нет. Объясню.

Во-первых, что касается «сахара». Понятно, что это личная терминология, не имеющая отношения к syntactic sugar, надеюсь это понятно. Сахаром я это назвал чисто автоматически, т.к. кем-то уже было сказано в этой ветке. Хотя я называю это просто «избыточное ненужно». Если это было не понятно сразу – мой косяк, не спорю.

Во-вторых, я не подразумевал непосредственно _рабочее назначение_ метода, со своей функцией он справляется и я об этом уже писал. Мне не ясно, как для вас очевидно, что merge == NEW_OBJECT, а merge! == CURRENT_OBJECT. Я понимаю, что есть правило наименования, но это как раз и не о _очевидности_, а о _зубрежке_.

В-третьих, лично для себя я определяю «избыточное ненужно» примерно так: если для работы с методом/функцией/etc как с черным ящиком мне приходится держать в уме какие-либо знания о подводных камнях (а-ля ! после названия) (а иногда даже постоянно лезть в доку, если долго не работал с вызываемым), то для меня это уже _аналог_ синтаксического сахарка, ага.

Подытожу: метод update для работы со словарем для меня абсолютно прозрачен. По логике вещей он должен обновить словарь (done), обновить значения существующих ключей (done), не возвращать ничего (а с чего бы ему что-либо возвращать?) (done). Прозрачность на лицо, поэтому пусть будет, фиг с ним (хотя я вообще python юзаю только как скриптовый язычок для решения быстрых «наколенных» задач, а ruby не юзаю вообще).

Интересно, как бы вы назвали статью «The Idiomatic Way to Merge Dictionaries in Python», следуя своей логике.

Для меня совершенно очевидно, что рубишный метод Hash#merge является аналогом гипотетической искомой функции merge_dicts из статьи:

context = merge_dicts(default, user) # magical merge function

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

~ >>> python
Python 2.7.12 (default, Jul  1 2016, 15:12:24) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import antigravity
>>> 

В любом случае, у тикля есть на вики куски кода, которые позволяют писать в стиле

Вместо того, чтобы тратить на это время, проще просто требовать последнюю стабильную версию. Если обратную совместимость не ломали существенно, пользователей не затруднит начать ее использовать.

Подытожу: метод update для работы со словарем для меня абсолютно прозрачен.
По логике вещей
Прозрачность на лицо

А что такое «прозрачность»? Может быть, вам нужно каждый раз, когда возникает позыв написать dict.update(other_dict), писать

for key, value in other_dict.items():
    dict[key] = value

Очевидность, это когда (по примеру выше) – нет стандартной intersection -> ищем+тянем либу -> нет либы -> пишем реализацию. Вот и вся очевидность. Меньше сахара -> меньше мусора в голове.

Вместо того, чтобы тратить на это время, проще просто требовать последнюю стабильную версию.

LTS дистры с поддержкой 5-7 лет не нужны, так понимаю?

Ну так не секрет, что Руби более выразителен, чем Питон.

Они одинаково выразительны. Просто Ruby удобнее.