Comments 21
Это уже упоминалось здесь в одном из подкастов, но я перевёл эту статью раньше, чем подкаст был анонсирован.
Для меня лично особенно ценен новый метод
String#scrub. В задачах NLP на входе может быть любой мусор и зачастую непросто добиться одинакового поведения на разных реализациях Ruby. Раньше для этого были собственные костыли, теперь есть родное решение.
Вы хотели сказать теперь есть родной костыль.
ИМХО конечно, но в Ruby-way это как-то не вписывается и воспринимается именно что костылем.
ИМХО конечно, но в Ruby-way это как-то не вписывается и воспринимается именно что костылем.
Сам по себе метод нужный и не кажется мне костылём. Это всего лишь фильтрация данных.
Костыльность заключается в его вынужденной реализации с учётом особенностей JRuby, MRI, и других Ruby. Например, в какой-то версии MRI есть iconv в стандартной библиотеке, в какой-то новой версии его объявили устаревшим; в текущем JRuby 1.7.4 есть баг JRUBY-7007; в Rubinius также регулярно возникают проблемы с Unicode, и так далее.
Стандартизация метода и требуемого поведения — правильное решение.
Костыльность заключается в его вынужденной реализации с учётом особенностей JRuby, MRI, и других Ruby. Например, в какой-то версии MRI есть iconv в стандартной библиотеке, в какой-то новой версии его объявили устаревшим; в текущем JRuby 1.7.4 есть баг JRUBY-7007; в Rubinius также регулярно возникают проблемы с Unicode, и так далее.
Стандартизация метода и требуемого поведения — правильное решение.
refinements очень напомнили implicit conversions из scala
Только они в скале резолвятся в компайл-тайме и вообще нормально задизайнены, в том плане, что всегда известно в каком окружении будет исполнен конкретный кусок кода. В руби это не так. Т.е. и производительность страдает (в руби!!) и дизайн языка.
Вообще с веткой 2+ в руби лично я решил, что эта школьная поделка ни к чему хорошему не придет.
Вообще с веткой 2+ в руби лично я решил, что эта школьная поделка ни к чему хорошему не придет.
Различия вы очень правильно описали. А я просто отметил схожесть идей.
В целом, согласен. За последнее время возникает ощущение, что создатели языка Ruby схватились и начали запихивать в себя вещи, которые им приглянулись в дизайне других языков. Чем-то напоминает эволюцию C# от Microsoft, который также набрал в себя слишком многое.
Вообще, как только язык перестает набирать в себя что-то новое, то он начинает умирать. Потому что концепции программирования меняются постоянно и люди ищут, что больше удовлетворит их здоровую лень. Однако в языке должна быть какая-то стержневая идеология, под которую адаптируются все новшества, а иначе может получиться язык в котором проще написать приложения с кучей скрытых ошибок, чем без них.
Это я сейчас не о руби, а так, пофилософствовать )
Это я сейчас не о руби, а так, пофилософствовать )
Т.е. и производительность страдает (в руби!!)
Вы так говорите, как будто от руби кто-то ожидает производительности. Его же любят и используют вовсе не из-за этого.
Блин, да самое важное — это новый GC. А вы все про работу со строками и манки-патчингом.
Верное замечание. Андрей, вот тебе слайды Toward efficient Ruby 2.1 про RGenGC.
гц — это не язык. его можно хоть в патч-версиях имплементации менять. Так что если говорить про развитие языка, то гц вне темы.
Прикольно, узнал несколько фишек из языков а-ля C#
Может кто-то рассказать, какие конкретные проблемы решает #scrub? Из описания в исходниках не очень понятно, что такое invalid bytesequence.
Я могу. Неправильная последовательность байт — это наличие в строке символов, не соответствующих её кодировке. Зачастую данные, приходящие в работающую программу извне могут быть некорректны — как заведомо, так и неосознанно. Лучше отфильтровать некорректные байты сразу, чем потом хвататься за голову при ошибках в боевых условиях.
Например, существует кодировка UTF-8. Строка
Например, существует кодировка UTF-8. Строка
"vit\xC3\xA6" является корректной записью слова vitæ и не содержит недопустимых символов. В свою очередь, строка "hello\x00\x20\uDC80there" некорректна. Благодаря методу String#scrub она превратится в безобидное hello there.Ну об этом я догадывался, мне интересен пример, когда так происходит. Откуда могут взяться неверные байты, которые можно просто вырезать, что бы получилось хорошо? Ведь если они неправильные, то где-то в источнике проблема и нужно выяснять, почему они такие и как должно быть на самом деле, разве не так?
Конечно нет, не так. Мы живём в неидеальном мире. Ни в коем случае нельзя забывать о человеческой невнимательности, которая может заключаться и в технической стороне дела. В реальном мире полно примеров, которые я привёл в предыдущем комментарии.
Если совсем интересно, то могу поделиться опытом. У меня есть сервис извлечения ключевых слов. У сервиса есть API, им пользуются люди. Некоторое время назад в Squash начали появляться ошибки, связанные с некорректными байтами в строках. Я начал смотреть дампы параметров. Оказалось, что в некоторых входных текстах наряду с нормальными буквами присутствуют неюникодные символы, которые появились в результате: 1) парсинга Веб-сайтов; 2) какой-то кривой конвертации из офисных форматов. Удаление неправильных байт из текстов решило все подобные проблемы.
Если совсем интересно, то могу поделиться опытом. У меня есть сервис извлечения ключевых слов. У сервиса есть API, им пользуются люди. Некоторое время назад в Squash начали появляться ошибки, связанные с некорректными байтами в строках. Я начал смотреть дампы параметров. Оказалось, что в некоторых входных текстах наряду с нормальными буквами присутствуют неюникодные символы, которые появились в результате: 1) парсинга Веб-сайтов; 2) какой-то кривой конвертации из офисных форматов. Удаление неправильных байт из текстов решило все подобные проблемы.
Sign up to leave a comment.
Чего нам ждать от Ruby 2.1?