После десяти месяцев разработки представлен (https://www.ruby-lang.org/en/news/2013/12/25/ruby-2-1-0-is-r.../) релиз языка программирования Ruby 2.1 (http://www.ruby-lang.org). Ruby - мощный и динамический объектно-ориентированный язык программирования, отличающийся высокой эффективностью разработки программ и вобравший в себя лучшие черты Perl, Java, Python, Smalltalk, Eiffel, Ada и Lisp. Код проекта распространяется под лицензиями BSD ("2-clause BSDL") и "Ruby", которая ссылается на последний вариант лицензии GPL и полностью совместима с GPLv3. Ruby 2.1 продолжает развитие ветки 2.0 при сохранении полной обратной совместимости.
Основные (http://www.atdot.net/~ko1/activities/RubyKaigi2013-ko1.pdf) изменения (https://github.com/ruby/ruby/blob/v2_1_0/NEWS):
- Поддержка кэширования методов в VM;
- Новый сборщик мусора RGenGC;
- Расширение (https://bugs.ruby-lang.org/issues/8481) возможностей (https://bugs.ruby-lang.org/issues/8571) конструкции "Refinements" ( Module#refine) для повышения безопасности внесения изменений в код на лету;
- Поддержка нового синтаксиса комплексных литералов (1 // 2 == Rational(1, 2);
- Изменено (https://bugs.ruby-lang.org/issues/3753) значение, возвращаемое по умолчанию для конструкций "def";
- Для ускорения вычислений с данными типа Bignum задействована (https://bugs.ruby-lang.org/issues/8796) библиотека GMP (http://gmplib.org/);
- Новые методы String#scrub и String#scrub! для проверки и исправления некорректной строковой последовательности;
- Новый метод Socket.getifaddrs, ассоциированный с функцией getifaddrs();
- Обновление RDoc 4.1.0 и RubyGems 2.2.0;
- Оптимизация (https://bugs.ruby-lang.org/issues/9042) строк "литерал".freeze на уровне VM;- Поддержка (https://bugs.ruby-lang.org/issues/8257) выражения Exception#cause;
- Обновление библиотек BigDecimal, JSON, NKF, Rake, RubyGems и RDoc;
- Удаление curses из стандартного набора библиотек (библиотека curses вынесена в отдельный curses.gem (https://github.com/shugo/curses)).URL: https://www.ruby-lang.org/en/news/2013/12/25/ruby-2-1-0-is-r.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=38732
Ни разу не руби-программист, потому такой вопрос к спецам:
portupgrade во фре, работает до жути медленней чем portmaster, это связано с архитектурными различиями этих прог или влияет скорость работы ПО написанном на том или ином языке?
И то и то.
Ruby язык для програмирования програмистами, а не чтобы оно потом быстро работало и память не ело. Железо сейчас стоит копейки относительно цены времени программеров.
А зачем оптимизировать код, когда можно просто повысить процессу приоритет? ©
Это не ваше? :))
Хелловорд программист втреде. Догадайся, почему кроме какого-то го..на на руби и гвидобейсике больше ничего нет?
)))))))))))))))))))))))) kopeyki
> )))))))))))))))))))))))) kopeykiЗа трепание языком? Безусловно.
То есть умножению вас в школе так и не научили? Ведь если умножить дополнительные затраты на количество запусков, а потом еще и на количество машин, то копейками окажутся как раз затраты на программистов.
Где там «до жути медленней», когда, скажем, 99,99999999999999999% времени занимает, собственно, GCC ??? :)
Это как бы не отменяет того факта, что писанина на всяких "гвидобейсиках" таки тормозная сама по себе.:) Для примера: http://hackie.blog.tut.by/2009/04/25/vyshel-fquery-021-bystr.../
> 25.04.2009Оно живое вообще?
> Оно живое вообще?А чего бы и нет?:) http://gpo.zugaina.org/app-portage/fquery/ChangeLog
Просто не все согласны с тем, что версия софта должна увеличиваться на единицу каждое рождество, иногда он просто работает.
>Автор проекта gentoo больше не использует и перешел на slackwareБггг)
P.S. Просто гвидобэйсик прост и понятен. Скорость не первостепенная задача, для этого есть другие инструменты. А хаскель - это звиздец. Выбирать его ради скорости тоже неадекватно. Тогда уж c/cpp/pascal.
Поддерживаю, хаскель используют только из желания щас мы в бою попробуем этот модный тренд..
portmaster - набор sh-скриптов, а ruby - тормоз, да.
В 2.1.0 они перешли на что-то похожее на semantic versioning. Какой-то он у них больно странный.
Version Schema:
MAJOR: Reserved for special events
MINOR: increased every christmas, may be API incompatible
TEENY: security or bug fix which maintains API compatibility
PATCH: number of commits since last MINOR releaseИм там вторым же комментом заявили, что в MINOR ломать API нельзя, но им все рано :(
Ну и где API поломали? Что def теперь возвращает Symbol? С 1.8 на 1.9 и то больше сломали.
Ну да. А какая скриптятина и где от этого сломалась - юзеры на себе узнают. Но апи совместимый, совмесимый, совместимый. А то что существующие программы могут сломаться от смены поведения - фича, не баг.
идеала не существует, в гвидобейсике с этим вообще ужос-ужос
примеры-примеры!
> примеры-примеры!Ты
Разница между ruby 1.8/1.9(2.0) в разы больше чем между python 2/3, плюс каждая версия ломает обратную совместимость.
Переход с 1.8 на 1.9 тяжелый из-за Unicode и только в части работы со строками. В остальном - легко исправимые мелочи.Переход с 1.9 на 2.0 не заметен. Больше проблем при переходе на JRuby.
Для сохранения обратной совместимости просто не надо использовать то, что появилось в 2.0 или 2.1. Версия 1.8 уже не поддерживается. Для разработки она совершенно не интересна.
>Переход с 1.8 на 1.9 тяжелый из-за Unicode и только в части работы со строками. В остальном - легко исправимые мелочи.Забыли про кучу всего, например потоки которых не было.
>Переход с 1.9 на 2.0 не заметен.
Большей частью да.
>Для сохранения обратной совместимости просто не надо использовать то, что появилось в 2.0 или 2.1
Обратная совместимость, она ОБРАТНАЯ, то есть если код из 2.0 будет работать в 2.1 он обратно совместим, а не наоборот. Вот только в минорных версиях ломать эту совместимость зачем?
> Версия 1.8 уже не поддерживается. Для разработки она совершенно не интересна.
Спасибо Кэп!
И конечно мы забыли про тесты?
Тесты не в счёт. Они, конечно, во многом помогут, но вообще-то они для выявления ошибок авторов программы, а не ловли изменений в среде исполнения. Некрасиво это.
> Тесты не в счёт. Они, конечно, во многом помогут, но вообще-то они
> для выявления ошибок авторов программы, а не ловли изменений в среде
> исполнения. Некрасиво это.Если изменился язык, то это не ошибки автора программы, это ошибки в проектировании языка.
Ты совсем дурак?
> Ты совсем дурак?Только в нижней части.
Как ломаются, так и чинятся. Это не C-экстеншн переписать под новое API. У меня на Rails-апе (12 KLOC код, 26 KLOC тесты) при переходе с 1.9 на 2.0 сломались только тесты -- связка webmock и vcr глюканула, обновил -- работает дальше. А то разведут истерику, из-за пары ±методов.
> при переходе с 1.9 на 2.0А слабо с 1.8 на 1.9? Между 1.9 и 2.0 разница действительна мала.
Ну так, с тестами все было бы ок :) Тем более, есть тонна софта для анализа кода на рубях, всякие там rubocop, reek, flay, flog, churn, metric_fu и т.д. Были даже скриптики (sed, awk) которые занимались «портированием» с 1.8 на 1.9. Я по прежнему считаю, что эту проблему высасывают из пальца всякие диванные проггеры.
>Ну так, с тестами все было бы ок :)Если код покрыт тестами, то переписывать код резко становится не нужно?
Давай конкретно, во-первых при изменении синтаксиса языка и методов библиотек придется переписывать тесты, во-вторых придется переписывать код, на проект из 10k строк кода уйдет минимум неделя работы команды, а теперь прикинь что ты собственник этого кода, давай посчитай сколько это стоит.
>Я по прежнему считаю, что эту проблему высасывают из пальца всякие диванные проггеры.
Проблема описана прямо в новости, критика идет от всего сообщества ruby.
> Ну и где API поломали? Что def теперь возвращает Symbol? С 1.8
> на 1.9 и то больше сломали.Так о том и речь, что при смене минорного номера, как в вашем примере, e более привычной схеме нумерации ломать API не принято. Не знаю сломалось ли оно при переходе с 1.8 на 1.9, но описанная тредстартером схема это допускает.
> Не знаю сломалось ли оно при переходе с 1.8 на 1.9,О... Сломалось это слишком мягкое выражение, это два разных языка, с похожим синтаксисом.
> О... Сломалось это слишком мягкое выражение, это два разных языка, с похожим
> синтаксисом.Перед тем как это заявлять, приведите несколько выражений из 1.8, которые не поймёт 1.9. А то, что методы некоторые переименовали или изменили число параметров - это не такая уж и проблема.
> Перед тем как это заявлять, приведите несколько выражений из 1.8, которые не
> поймёт 1.9. А то, что методы некоторые переименовали или изменили число
> параметров - это не такая уж и проблема.Навскидку:
$ rvm use 1.8 && echo "puts [].uniq.join(" ").any?" | ruby
false
$ rvm use 1.9 && echo "puts [].uniq.join(" ").any?" | ruby
-:1:in `<main>': undefined method `any?' for "":String (NoMethodError)
$И не спрашивайте зачем так делалось. Факт -- есть факт.:)
> Навскидку:
> $ rvm use 1.8 && echo "puts [].uniq.join(" ").any?" | ruby
> false
> $ rvm use 1.9 && echo "puts [].uniq.join(" ").any?" | ruby
> -:1:in `<main>': undefined method `any?' for "":String (NoMethodError)
> $
> И не спрашивайте зачем так делалось. Факт -- есть факт.:)Убрали метод any? для строки. Вполне в духе приближения к естественному английскому, поскольку смысла от такого метода здесь нет.
Ну а изменения языка то в чём?
>> Навскидку:
>> $ rvm use 1.8 && echo "puts [].uniq.join(" ").any?" | ruby
>> false
>> $ rvm use 1.9 && echo "puts [].uniq.join(" ").any?" | ruby
>> -:1:in `<main>': undefined method `any?' for "":String (NoMethodError)
>> $
>> И не спрашивайте зачем так делалось. Факт -- есть факт.:)
> Убрали метод any? для строки. Вполне в духе приближения к естественному английскому,
> поскольку смысла от такого метода здесь нет.
> Ну а изменения языка то в чём?Задолбал: http://stackoverflow.com/questions/21574/what-is-the-differe...
> Задолбал: http://stackoverflow.com/questions/21574/what-is-the-differe...Ну и где? Единственное различие - 1.9 больше не поддерживает {"a","b"} - No Longer Supported
Чего кричать о другом языке, если старый код всё равно будет работать?
>> Задолбал: http://stackoverflow.com/questions/21574/what-is-the-differe...
> Ну и где? Единственное различие - 1.9 больше не поддерживает {"a","b"} -
> No Longer Supported
> Чего кричать о другом языке, если старый код всё равно будет работать?Каким образом? Работа со строками и массивами поломана.
> Каким образом? Работа со строками и массивами поломана.Был бы использован метод empty?, который для строки явно логичнее, проблемы бы не было.
В том, что касается работы со строками - надо действительно местами убрать force_encoding, местами вписать кодировку при открытии файлов. Однако в целом программа остаётся без изменений. На этом переписывание ограничивается.
>> Каким образом? Работа со строками и массивами поломана.
> Был бы использован метод empty?, который для строки явно логичнее, проблемы бы
> не было.Ты из более чем 20 изменений методов языка увидел один? Ну это к окулисту.
Библиотеки не совместимы, сам язык другой, совсем другой, другая модель работы с памятью, с потоками, другие методы типов.> В том, что касается работы со строками - надо действительно местами убрать
> force_encoding, местами вписать кодировку при открытии файлов. Однако в целом программа
> остаётся без изменений. На этом переписывание ограничивается.Покажи средний проектик, скажем, хотя бы в 5000 строк, который без труда будет работать в 1.8 и 1.9, вот тогда поговорим.
> Убрали метод any? для строки. Вполне в духе приближения к естественному английскому, поскольку смысла от такого метода здесь нет.Ну да, в духе. А типа вот от этого, смысла сразу поприбавилось?
> $ rvm use 1.9 && echo 'p "".lines.any?' | ruby
> falseтут уже линия, а не строка...:)
PS. Это всё "динамическиеопердени" виноваты, ибо тип у "any" должен быть:
Prelude> :t any
any :: (a -> Bool) -> [a] -> Bool
и никак иначе.:)
> $ rvm use 1.8 && echo "puts [].uniq.join(" ").any?" | ruby
> false
> $ rvm use 1.9 && echo "puts [].uniq.join(" ").any?" | ruby
> -:1:in `<main>': undefined method `any?' for "":String (NoMethodError):))))
А "стринга".any? слабо? Зачем было лиспятину воротить для примера, чтоб показать, что знаешь тему? В стандартной библиотеке и так много мусора, типа keep_if. Вроде как синоним для select, а по факту это select!, только портит читаемость и вносит баги. Я бы с радостью повыбрасывал эти keep_if, inject и прочую смолтокщину и оставил бы лиспятину. Все равно количество смолток проггеров со времени релиза руби только падает, не вижу смысла им помогать мигрировать. А лисп вечен и прекрасен.
> А "стринга".any? слабо? Зачем было лиспятину воротить для примера, чтоб показать, что
> знаешь тему?Та не. Просто из переписки скопипастил.:) Такая конструкция в реальном коде была, просто список пожат до финального состояния, которое было в рантайме.
>> О... Сломалось это слишком мягкое выражение, это два разных языка, с похожим
>> синтаксисом.
> Перед тем как это заявлять, приведите несколько выражений из 1.8, которые не
> поймёт 1.9.Я бы написал, конечно, но после:
> А то, что методы некоторые переименовали или изменили число
> параметров - это не такая уж и проблема.уже и сказать нечего.
>> А то, что методы некоторые переименовали или изменили число
>> параметров - это не такая уж и проблема.
> уже и сказать нечего.Сложно понять, что язык и библиотеки - это не одно и то же?
>>> А то, что методы некоторые переименовали или изменили число
>>> параметров - это не такая уж и проблема.
>> уже и сказать нечего.
> Сложно понять, что язык и библиотеки - это не одно и то
> же?То есть мы можем эти библиотеки запросто могу использовать в других языках?
Или как?
> О... Сломалось это слишком мягкое выражение, это два разных языка, с похожим синтаксисом.Язык остался тем же с минимальным изменением синтаксиса.
> То есть мы можем эти библиотеки запросто могу использовать в других языках?
> Или как?Нет, потому, что библиотеки написаны под этот язык. Тем не менее, часть, которая написана на Ruby, может быть перенесена на другие версии, хотя довольно много методов там написано на C.
Как бы то ни было, изменения в 1.9 по сравнению с 1.8 довольно логичные и в случае возникновения несовместимости в своих программах, опытный программист может исправить довольно быстро.
или держать две версии программ, для 1.8 и для 1.9. И для 2.0, и для 2.1.
> или держать две версии программ, для 1.8 и для 1.9. И для
> 2.0, и для 2.1.Если очень надо обеспечить работу одновременно в 1.8 и в новых, то можно вставить в код проверку версии. Но зачем, учитывая, что 1.8 осталась только в старых дистрибутивах?
>> или держать две версии программ, для 1.8 и для 1.9. И для
>> 2.0, и для 2.1.
> Если очень надо обеспечить работу одновременно в 1.8 и в новых, то
> можно вставить в код проверку версии. Но зачем, учитывая, что 1.8
> осталась только в старых дистрибутивах?ты видел сколько методов изменили? Писать обёртки для каждого? 1.9.2 имеет отличия даже от 1.9.3, не говоря уж о 2.0 и 2.1. Руби классный язык, только разработчики подхватили рефакторинг. Краем уха я где-то слышал что так бывает при ооп головного мозга, но это всё слухи наверное, хотя глядя в сравнении с питоном и перлом.
>> О... Сломалось это слишком мягкое выражение, это два разных языка, с похожим синтаксисом.
> Язык остался тем же с минимальным изменением синтаксиса.Ага, ага. Только программы написанные под 1.8 не работают под 1.9.
>> То есть мы можем эти библиотеки запросто использовать в других языках?
>> Или как?
> Нет, потому, что библиотеки написаны под этот язык.Тогда какого ты их отделяешь от языка?
> Как бы то ни было, изменения в 1.9 по сравнению с 1.8
> довольно логичные и в случае возникновения несовместимости в своих программах, опытный
> программист может исправить довольно быстро.А теперь представь, что ты пишешь не хелловорлд в 100 строк, а большой проект в десятки и сотни тысяч строк кода. Слабо после каждого минорного обновления всю команду переводить, на фиксинг несовместимости, сколько времени это займет, сколько будет в деньгах стоить, подумай над этим.
> Ага, ага. Только программы написанные под 1.8 не работают под 1.9.Ничего, что про планируемый сбор несовместимостей на переход к 2.0 был известен оочень давно, если не ещё раньше? ;)
Плохо здесь то, что на 1.9 начали переезжать деятели, не понимающие разницы между разработкой и деплойментом -- ну и смазали нормальную работу, превратив её в достраивание самолёта в воздухе. Матцу стоило таким внятно настучать по головам и рукам в стиле Линуса, IMHO.
А других таких случаев не припоминаю. Между 1.6 и 1.8 вообще был сделан shim -- подключаешь и заводишь код для 1.6 на 1.8 без изменений.
>> Ага, ага. Только программы написанные под 1.8 не работают под 1.9.
> Ничего, что про планируемый сбор несовместимостей на переход к 2.0 был известен
> оочень давно, если не ещё раньше? ;)Особенно учитывая ломку совместимости в минорных версиях, "оочень давно" еще в процессе.
> Плохо здесь то, что на 1.9 начали переезжать деятели, не понимающие разницы
> между разработкой и деплойментом -- ну и смазали нормальную работу, превратив
> её в достраивание самолёта в воздухе. Матцу стоило таким внятно
> настучать по головам и рукам в стиле Линуса, IMHO.Я ему про Фому, а он про Ерему. Изначальный топик был о том, что разница между ruby 1.8 и ruby 1.9 в разы больше чем между python 2/3, а он про деятелей.
> А других таких случаев не припоминаю. Между 1.6 и 1.8 вообще
> был сделан shim -- подключаешь и заводишь код для 1.6 на
> 1.8 без изменений.Собственно я про это же.
> Особенно учитывая ломку совместимости в минорных версиях [...]
> [...] разница между ruby 1.8 и ruby 1.9 в разы больше чем между python 2/3Устойчивое ощущение, что если бы Вы толком портировали код между python 2.x/2.y/3.x и ruby 1.8/1.9(2.x), причём не три строчки, а в случае питона что-нить вроде zope -- то мы бы здесь не видели вышепроцитированного, по крайней мере в таком виде. :)
>Устойчивое ощущение, что если бы Вы толком портировали код между python 2.x/2.y/3.x и ruby 1.8/1.9(2.x), причём не три строчки, а в случае питона что-нить вроде zope -- то мы бы здесь не видели вышепроцитированного, по крайней мере в таком виде. :)Да, да кругом школата, один Мишка умный, может уже хватит? Существует куча программ работающих на python2.7/3.2/3.3 одновременно, не существует ни одной, кроме самых тривиальных, работающих на ruby 1.8/1.9. Zope? Вы вообще в теме? Его еще кто использует? Назовите хоть один известный проект на нем за последние 5 лет.
> Да, да кругом школата, один Мишка умный, может уже хватит?Сами себе ник выбирали, никто за язык не тянул.
> Существует куча программ работающих на python2.7/3.2/3.3 одновременно,
> не существует ни одной, кроме самых тривиальных, работающих на ruby 1.8/1.9.http://www.devalot.com/articles/2012/03/ror-compatibility
http://oreilly.com/ruby/excerpts/ruby-best-practices/writing...Поздравляю соврамши.
> Zope? Вы вообще в теме? Его еще кто использует? Назовите хоть
> один известный проект на нем за последние 5 лет.Да понятно, что после рельс у питонятников зазудело и начались догоняйки во фреймворки в другую сторону -- я из темы уже несколько лет как изрядно выпал (и впадать особо не намерен), но те же плонеры помирать явно не собираются.
Речь была о том, что перепирание нетривиального проекта между python 2.x было адским трудом. Это не опровергает "кучи программ", а дополняет картинку, если вдруг не поняли.
И позиции у Гвидо и Матца по части обратной совместимости весьма различны.
какая разница где ломать API? главное знать где и когда оно буде сломано. и сколько будет поддерживаться старая версия.
А у меня большее недоумение вызывает "increased every christmas". Как-то нелогично менять номер версии просто потому, что год прошёл. Если с предыдущего раза ни чего существенного допилить не успели, а дедлайн наступил, они вкорячивают любую неотлаженную и несущественную фичу лишь бы циферку подкрутить, так что ли?
>Как-то нелогично менять номер версии просто потому, что год прошёл.А почему бы нет. Номер версии это всего лишь номер версии, он не на что не влияет.
Тут с semantic versioning мало чего общего. "special events" - слабо определённое нечто, "every chritsmas" пообще полный бред ради увеличения номера версии без повода, teeny - то что в semver называется patch, patch - бесполезное ни о чём не говорящее большое число.В то время как semver чёткая схема, major.minor.patch, где major увеличивается на поломках API совместимости, minor - на новых фичах, сохраняющих совместимость и patch на остальных совместимых в обе стороны изменениях.
Со своей идиoтской схемой они могут ломать API как хотят, хуже от этого не станет.
GMP -- эт правильно.
Да давно уже пора было.
>Удаление curses из стандартного набора библиотек (библиотека curses вынесена в отдельный curses.gem).Зачем?