Рубі: погані частини [закрито]

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

Я рубіст, і хоча люблю мову, яку завжди важливо отримати перспективу. Отже, що ви вважаєте найгіршою особливістю (наприклад, методи, класи, практики) у Ruby? Мій намір тут - не починати аргументи щодо достоїнств самої мови чи її швидкості тощо. Я скоріше віддаю перевагу дискусії про те, які функції ви вважаєте небезпечними / клопітними / болісними у використанні, виходячи з минулого досвіду.

Ви повинні дивитися на Python vs Ruby: Битва до смерті від Gary Bernhardt. Він робить цитату:

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

У той час як він багато говорить про Python, зокрема, він торкається багатьох речей, які у Рубі просто дивні. Одним з найбільших загальних предметів є лачання мавп .

Об'єкти Ruby (на відміну від об'єктів у деяких інших об'єктно-орієнтованих мовах) можна змінювати індивідуально. Ви завжди можете додавати методи на основі об'єкта. У Ruby поведінка або можливості об'єкта можуть відхилятися від тих, що надаються його класом.

Хоча це забезпечує велику гнучкість та повноваження деяких найпопулярніших і найскладніших дорогоцінних каменів Рубі, вона може вкусити вас в зад, якщо ви намагаєтеся налагодити проблему, не розуміючи, що десь бібліотека десь змінила основний метод.

Деякі люди думають про рубін лише з точки зору рубіну на рейках, і це наче дратує, оскільки мова стоїть сама по собі.

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

Проблемною частиною цієї особливості є те, що тези (глобальні) зміни трапляються під час виконання, коли інтерпретатор Ruby наштовхується на визначення, яке може бути задовго після того, як ви вже створили кілька об'єктів, які тепер раптом змінюють їх поведінку.

У великій базі коду це може призвести до дуже, дуже важко знайти помилок - тим більше, що це ускладнюється слабкою Рубі (у порівнянні, наприклад, з CLR або JVM) історією налагодження та використанням інших функцій (наприклад eval) у цьому контексті може зробити досить важко знайти місце, де відбулася ця глобальна зміна. тобто якщо ви вже дійшли до того, що ви підозрюєте, що "правильний" клас спричинив проблеми! З мого досвіду, ви зазвичай починаєте з погоні за дикими гусками, оскільки проблеми починають виникати на об'єкті, використовуючи справжнього винуватця.

Тож найкраще було б або припинити використання відкритих класів ( #extendа введення змін у ModuleIMHO набагато безпечніше, простіше зрозуміти і краще перевірити), або якщо цього не вдасться уникнути:

• розширювати заняття лише новою поведінкою (тобто не змінюючи існуючу поведінку)
• мають визначене місце у дереві вихідного коду, де мають бути розміщені всі розширення, що використовують відкриті класи
• не використовувати #eval та друзів для створення відкритих занять
• помістіть усі звички відкритих класів на велику видиму діаграму, де всі розробники можуть їх побачити - і поясніть, що будь-які зміни на них - це "архітектурні рішення", що впливають на всю базу коду (що вони роблять), а не місце для швидких хакерів корисними для вашого поточного завдання

Найбільша причина, що я не використовую Рубі: це повільніше, ніж патока в січні на Північному полюсі під час льодовикового періоду. Мови бенчмаркінгу - це неточна наука, але Ruby виглядає різко повільніше, ніж навіть JavaScript та Python.

Якщо це можна поширити на Ruby on Rails, тоді:

1. Той факт, що логіка бази даних надає кожній таблиці auto_incrementпервинний ключ, включаючи таблиці, які їм не потрібні та не повинні їх мати.

2. Те, що складні ключі взагалі не підтримуються.

Для простої Рубі моє захоплення було б таким же, як і для будь-якої мови, яка торгує безпекою для виразності; легко зробити багато всього лише з невеликим кодом, але так само легко зробити величезний безлад з будь-якою кількістю коду.

Рубі охоплює метапрограмування (рефлексія, самоаналіз), програмування багато парадигми та динамізм на рідкому рівні. Стріляти в ногу легко з силою та гнучкістю.

Тривожно? Ruby має здатність бути надзвичайно читабельним або незламним. Я бачив код, схожий на те, що він належить до сценарію Bash.

Погані практики? Деякі рубіністи цінують кмітливість над мудрістю. Вони пишуть і діляться хитрощами, які демонструють свою кмітливість, але це створює нечитабельний і крихкий код.

Як осторонь: Javascript був катастрофою з боку дизайну, і книга "Гарні частини" намагається видобути приховану красу. Perl, мова, яка популяризувала "Існує більше, ніж один спосіб зробити це" (тобто гнучкість), має подібну книгу в "Perl, Best Practices". Історія Perl - це досвід експериментів і досвід, який перемагає важко, "Best Practices" представляє свої знання. Perl 6 буде, я думаю, це справедливо сказати, перезавантаження мови, заснованої на цих знаннях та інше. Рубі може страждати від подібних проблем.

@James і для циклів ... Коли ви робите цикл у рубіні, він викликає ".each". Тому "for" - це синтаксичний цукор для людей, які зручніші для циклів стилю C. Але як рубіст, ви постійно будете використовувати такі ітератори, як .map, .inject, .each_with_object. Вам ніколи не доведеться писати цикл for з на зразок "i = 0; i> 6; i ++" в рубіні, і, таким чином, ви втратите звичку. @andrew ... красномовний рубін не схвалює циклів.

Це більше стосується програмістів, ніж мови, але чому програмісти Ruby так сильно ненавидять циклі?

Я розумію, що у Рубі:

someCollection.each do |item|
   ...
end

але я ніколи не бачив, що використовується в ситуаціях, коли цикл for не робив би точно те саме.

Я кілька разів запитував і жодного разу не отримав хорошої відповіді на це.

Якщо це просто річ у стилі, я із задоволенням приймаю це, але я бачив, як програмісти Ruby дійсно попрацювали над цим, і мені дуже цікаво.

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