Рубин: Плохие части [закрыто]

Недавно я прочитал книгу Крокфорда «Javascript: хорошие части», и одним из основополагающих условий было то, что языки программирования могут иметь плохие наборы функций, которых программисты должны избегать.

Я Rubyist, и хотя я люблю язык, всегда есть ценность в получении перспективы. Итак, что вы считаете худшей особенностью (например, методы, классы, практики) в Ruby? Мое намерение здесь не состоит в том, чтобы начать спор о достоинствах самого языка или его скорости и так далее. Скорее я бы предпочел обсуждение того, какие функции вы считаете опасными / хлопотными / болезненными для использования, основываясь на прошлом опыте.

Вы должны смотреть Питон против Рубина: Битва за Смерть Гари Бернхардта. Он делает цитату:

Те вещи, которые я нахожу в Ruby уродливыми, делают возможным создание удивительного программного обеспечения для Ruby, такого как RSpec, и того, что Python никогда не смог бы сделать (учитывая текущую реализацию).

Хотя он много говорит о Python, в частности, он затрагивает много вещей, которые просто странны в Ruby. Один из главных общих вопросов - исправление обезьян .

Объекты Ruby (в отличие от объектов в некоторых других объектно-ориентированных языках) могут быть изменены индивидуально. Вы всегда можете добавить методы для каждого объекта. В Ruby поведение или возможности объекта могут отличаться от тех, которые предоставляет его класс.

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

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

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

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

В большой базе кода это может привести к очень, очень трудным для поиска ошибок - особенно потому, что это усугубляется слабой (по сравнению, например, с CLR или JVM) историей отладки, и использование других функций (например eval) в этом контексте может сделать довольно трудно найти место, где произошло это глобальное изменение. то есть, если вы уже достигли точки, когда вы подозреваете, что «правильный» класс вызывает проблемы! По моему опыту, вы обычно начинаете с погони за диким гусем, так как проблемы начинают всплывать на объекте, используя настоящего преступника.

Поэтому лучше всего было бы либо прекратить использовать открытые классы ( #extendи помещать изменения в ModuleIMHO гораздо безопаснее, проще для понимания и лучше тестировать), либо если этого нельзя избежать:

• расширять классы только новым поведением (т.е. не переопределяя существующее поведение)
• иметь определенное место в дереве исходного кода, где должны быть размещены все расширения, использующие открытые классы
• не использовать #evalи друзей для создания открытых классов
• поместите все виды использования открытых классов на большой видимой диаграмме, где все разработчики могут их видеть, и поясните, что любые изменения в них являются «архитектурными решениями», влияющими на всю кодовую базу (что они делают), а не местом для быстрых полезных хаков для вашей текущей задачи

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

Если это можно распространить на Ruby on Rails, то:

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

2. Тот факт, что составные ключи не поддерживаются вообще.

Для простого Ruby моя хватка была бы такой же, как и для любого языка, который обменивает безопасность на выразительность; легко сделать много всего с помощью небольшого кода, но так же легко создать огромный беспорядок с любым количеством кода.

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

Неудобные? Рубин обладает способностью быть чрезвычайно читабельным или непостижимым. Я видел код, который выглядит так, как будто он принадлежит скрипту Bash.

Плохие практики? Некоторые рубиисты ценят ум за мудрость. Они пишут и делятся трюками, которые демонстрируют их ум, но это создает нечитаемый и хрупкий код.

В дополнение: Javascript был катастрофой по замыслу, и книга «Хорошие детали» пытается раскрыть его скрытую красоту. Perl, язык, который популяризировал «Есть больше, чем один способ сделать это» (то есть гибкость), имеет похожую книгу «Perl, Best Practices». История Perl - это опыт экспериментов и с трудом завоеванный опыт, «Best Practices» представляет его знания. Perl 6 будет, я думаю, справедливо сказать, перезагрузкой языка, основанного на этих знаниях и многом другом. Ruby может страдать от подобных проблем.

@James и for loop ... Когда вы делаете цикл for в ruby, он вызывает ".each". Следовательно, «для» - это синтаксический сахар для людей, которым более комфортно работать с петлями в стиле C. Но как Rubyist вы будете использовать итераторы, такие как .map, .inject, .each_with_object, все время. Вам никогда не придется писать цикл for с чем-то вроде «i = 0; i> 6; i ++» в ruby, и в итоге вы избавитесь от привычки. @andrew ... красноречивый рубин не поддерживает циклы.

Это больше о программистах, чем о языке, но почему программисты на Ruby так ненавидят циклы?

Я понимаю, что Руби имеет:

someCollection.each do |item|
   ...
end

но я никогда не видел, чтобы это использовалось в ситуациях, когда цикл for не делал бы то же самое.

Я спрашивал несколько раз и никогда не получал хорошего ответа на этот вопрос.

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

Я бы вообще избегал вещей, которые были добавлены только для обратной совместимости с другими языками. Например, Перлизмы и for x in y.