Чего нам ждать от Ruby 2.1?

[dustalov]

Это уже упоминалось здесь в одном из подкастов, но я перевёл эту статью раньше, чем подкаст был анонсирован.

[dustalov]

Для меня лично особенно ценен новый метод String#scrub. В задачах NLP на входе может быть любой мусор и зачастую непросто добиться одинакового поведения на разных реализациях Ruby. Раньше для этого были собственные костыли, теперь есть родное решение.

[phoenixweiss]

Вы хотели сказать теперь есть родной костыль.
ИМХО конечно, но в Ruby-way это как-то не вписывается и воспринимается именно что костылем.

[dustalov]

Сам по себе метод нужный и не кажется мне костылём. Это всего лишь фильтрация данных.

Костыльность заключается в его вынужденной реализации с учётом особенностей JRuby, MRI, и других Ruby. Например, в какой-то версии MRI есть iconv в стандартной библиотеке, в какой-то новой версии его объявили устаревшим; в текущем JRuby 1.7.4 есть баг JRUBY-7007; в Rubinius также регулярно возникают проблемы с Unicode, и так далее.

Стандартизация метода и требуемого поведения — правильное решение.

[phoenixweiss]

Возможно, с этой точки зрения Вы и правы.

[cs0ip]

refinements очень напомнили implicit conversions из scala

[preprocessor]

Только они в скале резолвятся в компайл-тайме и вообще нормально задизайнены, в том плане, что всегда известно в каком окружении будет исполнен конкретный кусок кода. В руби это не так. Т.е. и производительность страдает (в руби!!) и дизайн языка.

Вообще с веткой 2+ в руби лично я решил, что эта школьная поделка ни к чему хорошему не придет.

[cs0ip]

Различия вы очень правильно описали. А я просто отметил схожесть идей.

[dustalov]

В целом, согласен. За последнее время возникает ощущение, что создатели языка Ruby схватились и начали запихивать в себя вещи, которые им приглянулись в дизайне других языков. Чем-то напоминает эволюцию C# от Microsoft, который также набрал в себя слишком многое.

[cs0ip]

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

[EvilShadow]

Т.е. и производительность страдает (в руби!!)

Вы так говорите, как будто от руби кто-то ожидает производительности. Его же любят и используют вовсе не из-за этого.

[preprocessor]

Вы так говорите, как будто это хорошо.

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

[EvilShadow]

Нет, я не говорил, что это хорошо. Я говорил, что если нужна высокая производительность, то руби — не самый подходящий выбор.
Что касается «замедлит в несколько раз» — без бенчмарков это беспредметный разговор.

[pechorin]

Блин, да самое важное — это новый GC. А вы все про работу со строками и манки-патчингом.

[dustalov]

Верное замечание. Андрей, вот тебе слайды Toward efficient Ruby 2.1 про RGenGC.

[preprocessor]

гц — это не язык. его можно хоть в патч-версиях имплементации менять. Так что если говорить про развитие языка, то гц вне темы.

[deilux]

Прикольно, узнал несколько фишек из языков а-ля C#

[SmartBye]

Может кто-то рассказать, какие конкретные проблемы решает #scrub? Из описания в исходниках не очень понятно, что такое invalid bytesequence.

[dustalov]

Я могу. Неправильная последовательность байт — это наличие в строке символов, не соответствующих её кодировке. Зачастую данные, приходящие в работающую программу извне могут быть некорректны — как заведомо, так и неосознанно. Лучше отфильтровать некорректные байты сразу, чем потом хвататься за голову при ошибках в боевых условиях.

Например, существует кодировка UTF-8. Строка "vit\xC3\xA6" является корректной записью слова vitæ и не содержит недопустимых символов. В свою очередь, строка "hello\x00\x20\uDC80there" некорректна. Благодаря методу String#scrub она превратится в безобидное hello there.

[SmartBye]

Ну об этом я догадывался, мне интересен пример, когда так происходит. Откуда могут взяться неверные байты, которые можно просто вырезать, что бы получилось хорошо? Ведь если они неправильные, то где-то в источнике проблема и нужно выяснять, почему они такие и как должно быть на самом деле, разве не так?

[dustalov]

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

Если совсем интересно, то могу поделиться опытом. У меня есть сервис извлечения ключевых слов. У сервиса есть API, им пользуются люди. Некоторое время назад в Squash начали появляться ошибки, связанные с некорректными байтами в строках. Я начал смотреть дампы параметров. Оказалось, что в некоторых входных текстах наряду с нормальными буквами присутствуют неюникодные символы, которые появились в результате: 1) парсинга Веб-сайтов; 2) какой-то кривой конвертации из офисных форматов. Удаление неправильных байт из текстов решило все подобные проблемы.