Помню, как два года назад столкнулся с Руби. Язык показался прекрасным, все в нем понятно и просто, нет ничего лишнего, нет ничего не очевидного. Шло время, навыки росли, времена менялись и вот уже Руби не кажется мне таким привлекательным как раньше: медленно работает, да и большие проекты поддерживать тяжело. Почему? Да потому что большие проекты и Руби — это вообще вещи несовместимые. Ты видишь скорость выполнения на других языках и хочется плакать — из-за того, что когда-то был сделан выбор именно в сторону этого языка программирования.
Ниже вы найдете 5 наиболее угнетающих меня вещей в Руби. Все они расписаны достаточно поверхностно.
1) Rails
Раньше казалось, что на Рельсах можно писать все. Быстро и уверенно. Не сомневаться в поддержке сообщества и вообще процветать. Однако, оказалось, что Рельсы — это очередная RAD-технология, в которой, не дай бог, ты отступишь вправо или влево. А если хочется использовать NoSQL или вообще XML? Как? А никак, можно смело выпиливать половину библиотек и даже не париться, однако не стоит забывать, что от этого Рельсы не станут работать быстрее, нет, нет, вы так же будете очень долго время ждать, пока проект подгрузит все не нужные вам зависимости. Никакой гибкости при Рельсах вы не получите.
2) ООП
Кто-то может смело сказать, что Руби — это ООП язык, но тут-то он и ошибется. Ведь в каком языке программирования Private — это не Private, а «Ну как бы Private, но так уж и быть можно и не Private». Про Protected и говорить нечего, до выхода Ruby 2.0 Private и Protected вообще ничем не отличались. Зачем все это внедрять в язык? Сидели бы как JS и не парились, хотя даже там есть хоть какое-то разделение (пусть и не очевидное). А вы слышали про Абстрактные классы в Руби? Нет? Конечно нет, ведь они не живут в этом доме. Я, конечно, не против Модулей в Руби. Но вы пробовали отследить все места, куда вы добавили этот модуль? А если проект большой? Вы точно никогда не найдете, куда именно вставили тот или иной модуль. Можно, конечно, на это все писать тесты, но кто в здравом уме будет писать тесты на инклуды (includes)?
3) Скорость выполнения
Вот это вообще больная тема. Скорость в сравнении с другими языками просто поражает (JS, GO): обычно наполнения массива числами и суммирование всех элементов на Ruby выполнится за 0.15, на Node.js — 0.056, на Go — 0.005. И как мне кажется, это серьезная заявка на просадки в скорости. При этом я не использовал старую версию 1.9.3, нет, я взял новенькую 2.2.0, где все должно быть радужно и прекрасно.
4) Многопоточность
Хорошо, в вашем языке нет скорости, нет малого ресурсопотребления. А что есть? Может быть, многопоточность сделали? Но нет, нет тут многопоточности, нет, ну она есть, но по-моему это не правильно, когда в один потом работает все быстрее, чем в несколько. Конечно, есть вариант использовать Rubinius и его крутые нативные треды, но вы же понимаете, что половину библиотек он поддерживать не будет. И это на самом деле подводит к пункту 5.
5) Кроссплатформенность
Казалось бы, Руби весь такой крутой с огромным комьюнити, но и тут есть подвох. Ничего дельного под Windows до сих пор не сделали. Все веб-проекты заточены под Unix и это немного сводит сума. Не то, чтобы я был большой фанат продукции Microsoft, но все же хочется иметь выбор. Хочется, чтобы команда пользовалась именно тем, чем ей удобном (у нас в команде есть Windows-фанат и Frontend разработчик, а запускать проект приходится в виртуалке), а не тем, что диктует язык программирования (когда речь идет о веб-разработке). Ведь node.js может работать под Windows, Java может работать под Windows, а хваленый Руби — нет.
Таким образом, я перечислил основные проблемы Ruby и Ruby сообщества. Я стал относить Руби к числу бесполезных языков — таких же бесполезных, как Python или Rust. Для чего они существуют — не очень понятно, но они существуют и будут продолжать существовать до тех пор, пока остаются люди, которые уверены в том, что это лучшие языки современности.
Комментарии (142)
IncorrecTSW
07.05.2015 22:47+24как Python или Rust
И тут я немного в выпал в осадок.
Хоть я и не являюсь фанатом Python и даже не пишу на нем, но не назову его «бесолезным».
С Rust ситуация еще интересней… Он же даже еще не зарелизился. Да и то что есть сейчас на бета релизе уже ну никак не назвать «бесолезным».Alexey2005
08.05.2015 00:36+1Ну в Ruby, в отличие от Python, хоть нету этого кошмарного разделения на 2.x и 3.x, когда половина нужных библиотек работает только в 2.x, половина — в 3.x и крутись как хочешь (сейчас с этим уже чуток получше стало, а раньше например при попытке использовать в проекте PyQt+PyOpenGL становилось очень грустно).
A1MaZ
07.05.2015 22:49+1В чем проблема с работой руби под виндой? Рубиинсталлер и все без проблем работает. Рельсы(мне лень это проверять, но я уверен в этом на 98%) тоже заработают без проблем, а railsinstaller сделает все в десяток кликов мышкой. То, что гемы могут вылетать с кучей ошибок — это да, но это проблема разработчиков этих гемов(на самом деле никакой проблемы особо и нет), а не руби.
В чем проблема рельс? Все прекрасно знают, что это такой огромный конструктор и если нужна легкость, то выбирать его глупо. Благо это не один фреймворк на руби. NoSQL? Тоже ок.
В чем проблема открыть поиск по проекту и найти все строки «include ModuleName» я тоже не знаю.Artyom18 Автор
07.05.2015 23:29-13Да, согласен проблема разработчиков гемов. Очень многие гемы которые используют C++ Extensions не смогут нормально сбилдиться и в худшем случаи придеться писать этот функционал самому, а если я не могу использовать помощь огромного комьюнити, тогда смысл работать с Ruby?
Конструктор — это немного не то слово, конструктор — это когда можно много чего собрать, а вот на Рельсах ты едешь в одном направлении.
NoSQL — это проблема. Придеться постоянно подставлять палочки, проверки и т.д. в тех местах где они совсем не нужны.
Поиск по проекту будет работать, когда проект не включает в себя много различных гемов и огромного колличества классов в которые уже добавлены эти модули. Если меняешь модуль то нужно убедиться, что не один из классов не слетит, иногда это бывает очень сложно.at0mic
08.05.2015 01:38+1NoSQL — как раз не проблема.
Нет, в принципе, если использовать вместо AR, то может и проблема. Но это уже вопрос к разработчику — зачем использовать для CRUD задач NoSQL.
В остальном же, выпиливается AR в 4 строчки.
Fedcomp
08.05.2015 07:36Ни один из классов не слетит? я конечно не сильно опытный разработчик, но насколько я знаю эту проблему должны решать тесты, которые руби вроде как очень любит. И если у вас что то слетит вы увидите где конкретно это произошло после прогона тестов.
fuCtor
08.05.2015 06:13+1В чем проблема открыть поиск по проекту и найти все строки «include ModuleName» я тоже не знаю.
Зачем так жестоко, можно же определить/переопределить методы included/extended и там получить полную информацию начиная от имени класса где используется, заканчивая файлом и конкретной строкой. Если уж так хочется получить данную информацию.
matiouchkine
14.05.2015 08:39> В чем проблема открыть поиск по проекту и найти все строки «include ModuleName» я тоже не знаю.
На самом деле, если уж автору так надо, достаточно чуть-чуть почитать про метапрограммирование в языке, определить `self.included` callback в модуле и хоть исключения бросать на попытку инклюда.
Alex10
07.05.2015 22:51+3>>>Я стал относить Руби к числу бесполезных языков — таких же бесполезных, как Python или Rust.
Так а Python та чем не угодил?
mr_T
07.05.2015 23:34-12Недавно начал изучать Python, но очень быстро был вынужден закончить. У меня полилась кровь из глаз, когда я увидел, что в метод первым параметром передается this, и я не смог продолжить.
BasicWolf
07.05.2015 23:49+11Угу, только долго поработав с Pythonом понимаешь, что многое, что в других языках делается за счёт ключевых слов, в Pythone делается за счёт базовых механизмов языка. Я это к тому, что на уровне исполнения, методов в Python вообще не существует. Превращение функции в метод осуществляется за счёт механизма дескрипторов, а функция — это дескриптор! (см docs.python.org/3/howto/descriptor.html). Более того, сделать первый параметр неявным — совсем не сложно (метаклассы, либо чуть попроще — с помощью декораторов и инъекций в func_globals). Но дзен Python'a гласит: «Явное — лучше неявного». И мне кажется, именно это служит причиной явной передачи self в качестве первого аргумента.
MuLLtiQ
08.05.2015 01:42+5«Пастернака не читал, но осуждаю»
Явная передача параметров очень удобна — это базируется на одном из главных принципов Питона.
laphroaig
08.05.2015 03:03+7Являясь тру С++ разработчиком, очень пессимистично начал изучать Python, но именно то, что в метод первым параметром передается this — это гениально! Одним этим фактом ООП превращается в АОП (Аспектно-ориентированное программирование), можно «выдрать» функционал из одного класса и засунуть в другой, можно научить утку не только лаять, но и запустить в космос парой строчек кода!
ilmirus
08.05.2015 09:52В чем же проблема как тру С++ разработчику написать функцию с именем вроде _Z7MyClass7MyMethod, которая принимает MyClass* в качестве первого параметра?
kekekeks
08.05.2015 10:03-1В конвенции вызова. Она для instance-методов может быть не stdcall/cdecl, по крайней мере в MSVC. И для не-instance-методов __thiscall вроде как не скомпилируется.
ilmirus
08.05.2015 10:07Это да, АБИ могут быть разные.
Оффтоп: мне любопытно, как кланговцы будут пилить совместимость с MSVС и, как они запилят, хотелось почитать их код.
Artyom18 Автор
07.05.2015 23:34-13Не то чтобы не угодил, я знаю ребят которые пишут и довольны, как в прочем и на других языках. Просто я не вижу в нем смысла. Есть достаточно языков для консольных скриптов, есть достаточно языков для веб разработки.
Так что к питону нет никаких личных претензий, нормальный язык, просто в обществе принято писать новые языки программирования, которые почти такие же как остальные но там есть какая-нибудь табуляция.
BlessMaster
07.05.2015 23:46+3Не могли бы Вы назвать список языков, делающих Python ненужным и бессмысленным, существовавших на момент его создания?
Artyom18 Автор
08.05.2015 00:11-13На момент создание уже существовал как миниму Perl, Icon, ABC и каждый можно было развивать. Но был создан новый язык (на сколько я помни он поначалу вообще был 'Hobby Language'). Так же был Bash, хоть он и был создан для Unix среды, но и питон по началу только в Unix среде использовался (вроде как только со второй версии под винду начали).
BlessMaster
08.05.2015 01:03+13* ABC (1987): императивный, процедурный, структурный;
Система типов: строгая, полиморфная
* Icon (1975): императивный, логический;
Система типов: динамическая
* Perl (1987): императивный, объектно-ориентированный, функциональный;
Система типов: слабая динамическая
* Python (1991): объектно-ориентированный, рефлективный, императивный, функциональный, аспектно-ориентированный, динамический;
Система типов: строгая, динамическая
Вы действительно между этими языками видите разницу только «новомодные табы»?
Языки шелла — я искренне удивлён, что они появились в ряду универсальных языков, а тем более как аргумент против необходимости одного из них, на фоне аргумента «Windows же!».
Кроссплатформенность:
Windows хоть сколько-то популярен становится во времена Windows 3.1, но ещё является всего-лишь необязательной надстройкой над DOS.
Windows 9x завоёвывает сердца во второй половине 90-х, но это очень нестабильная система.
Windows NT — появляется примерно в то же время, но малопопулярен и требователен к ресурсам, не совместима с Windows-9x.
Windows XP — начало 2000-х, первая система которая стабильно работает у пользователей.
Зачем всем этим языкам на раннем этапе существования могла понадобиться поддержка Windows, если они все появились до того, как Windows вообще что-то стал значить? Уже во времена 9x все обсуждаемые языки так или иначе были адаптированы под Windows и аргумент «не кроссплатформенно» спустя почти 20 лет звучит странно.Artyom18 Автор
08.05.2015 02:25-10Так разница есть и у C# с JAVA и у Objective-C с SWIFT. Но проблемы решались теже. Тем более у ABC и Python. Да, другой подход к решению, который на тот момент был удобен автору языка. Таким образом создается огромное колличество языков как публичных так и приватных. Но как мне кажется, если два языка решают одну и туже задачу то один из них явно бесполезен.
По поводу кроссплаформенности даже не спорю. Да и не говорил что это минус на то время был, просто подчеркнул факт.
По шеллу все просто. Если бы его начали полноценно портировать на другие системы (сигвин не рассматриваю), то разницы никакой небыло бы, выполняй скрипты и радуйся. Просто Питон продолжали развивать во всех направлениях, а Шелл нет.BlessMaster
08.05.2015 03:07+5«если два языка решают одну и ту же задачу»
Все языки решают ту же задачу, что и ассемблер. Да и ассемблер — это лишь примочка к машинному коду.
Я правильно понимаю, что «бессмысленный новодел» Python существенно не отличаясь от ABC, безуспешно пытается у последнего отбить хоть какую-то долю рынка?
— «Появившись сравнительно поздно, Python создавался под влиянием множества языков программирования:
ABC — отступы для группировки операторов, высокоуровневые структуры данных (map)[15][16] (Python фактически создавался как попытка исправить ошибки, допущенные при проектировании ABC);
Modula-3 — пакеты, модули, использование else совместно с try и except, именованные аргументы функций (на это также повлиял Common Lisp);
С, C++ — некоторые синтаксические конструкции (как пишет сам Гвидо ван Россум — он использовал наиболее непротиворечивые конструкции из С, чтобы не вызвать неприязнь у С-программистов к Python[15]);
Smalltalk — объектно-ориентированное программирование;
Lisp — отдельные черты функционального программирования (lambda, map, reduce, filter и другие);
Fortran — срезы массивов, комплексная арифметика;
Miranda — списочные выражения;
Java — модули logging, unittest, threading (часть возможностей оригинального модуля не реализована), xml.sax стандартной библиотеки, совместное использование finally и except при обработке исключений, использование @ для декораторов;
Icon — генераторы.»
* ABC — императивный, процедурный, структурный;
* Python: объектно-ориентированный, рефлективный, императивный, функциональный, аспектно-ориентированный, динамический;
Возможности Python на порядок шире возможностей ABC или Icon.
Но не нужен именно Python, а вместо него лучше либо ABC, либо Icon?
Странная логика. Почему действительно не ассемблер в таком случае?
Честно, я не понимаю. Это выглядит как чья-то злая воля, заставившая сообщество поддерживать именно «худший Python», а не «лучший ABC». Но может быть на самом деле всё с точностью до наоборот? И история просто всё расставила по своим местам?
В конце концов сюда можно вспомнить и PHP, который много и справедливо критикуют как очень слабый в плане архитектуры язык, который вообще появился как шаблонизатор для Perl, но быстро своими особенностями и популярностью переросший и погрёбший Perl в Web под собой.
А c языками шелл всё просто. Они нужны только в шелл. Не в веб разработке, не в научной работе, не в разработке прикладных или системных приложений. Они создавались и оптимизировались как языки упрощающие автоматизацию работы с файловой системой и некоторыми особенностями os. Они во многом не самодостаточны, а всю работу выполняют отдельные утилиты, частью shell не являющиеся.
Хотя я лично видел сайты сделанные на bash и знаком с людьми, которые их делали. Просто этот инструмент не самый лучший для этой и многих других целей. Это возможно, но это большинству не нужно. А то, что нужно — мы видим как лидеров индустрии.
mukizu
07.05.2015 23:31+4>Ничего дельного под Windows до сих пор не сделали.
хз, в РЖД интеграционные решения на jruby под виндой нормально работают, всякие рельсы тоже. В чем проблема-то?
>Для чего они существуют — не очень понятно
окей, лол
Regis
08.05.2015 01:55+13в РЖД
всякие рельсы тоже
:D
uSide
07.05.2015 23:33+3ИМХО, сам Ruby — красивый язык со множеством хороших моментов, но вы правы в том, что текущая его реализация — немного лучше, чем УГ.
Всё таки рельсы я больше расцениваю как пинок для быстрого старта более-менее типичного проекта, когда вылезать за рамки прописных истин самих рельс не особо нужно, а потом, когда будет время, переписать на что-то более производительное.Renius
09.05.2015 12:36Не очень понимаю о каких выходах из рамок вы говорите. Есть же общие стандарты. Если вы хотите не REST-full API то вы в первую очередь выходите за рамки REST, а уже потом рельсы.
Во вторых, лишь ничтожно малое количество стартапов выходят в фазу «о, а у нас все получилось». И уж тем более в фазу «о, а пора снижать операционные издержки»
В третьих, и это самое главное, любая автоматизация бизнес процессов подразумевает, что эти бизнес процессы реально происходят в окружающей нас действительности. По своему опыту могу сказать, что львиная доля времени тратится на формализацию задачи. И только меньшая часть на код. Иными словами, толковых постановщиков задач и тестировщиков UX нужно больше чем разработчиков.
И если, ничего не мешаает автоматизировать процесс средствами веб, то придумать что-то лучше рельсы или питона будет очень трудно, я бы поставил на «невозможно».
dim_s
08.05.2015 00:10+1Никогда не стоит привязываться на 100% к какому-то языку, к какой-то платформе, фреймворку, т.к. король может оказаться голым.
tonymadbrain
08.05.2015 00:53+7К чему «гнать» на определённый ЯП, вообще не понятно. Просто не используй его, а в Твиттер напиши, что мол посмотрел на Руби, он мне не понравился. Пост сильно смахивает на очередное разжигание холивара, который ни к чему продуктивному не приведёт.
pandas
08.05.2015 01:04+5Автор, язык программирования — инструмент. Не более. И инструменты есть для самых разных задач. Руби не исключение. Фреймворки — вообще зло и от лукавого. Да, удобно, да, быстро, но стоит разобраться подробнее, и начинаются костыли, зависимости и велосипеды. А если всё равно это начнётся — зачем тогда начинать с фреймворков.
И да, Руби не для больших проектов. Для реально больших проектов я рекомендую Java, С и С++.
Go — хорош на многопоточности, но проигрывает C. Rust подаёт большие надежды, хотя многие скептически настроены. Python — вообще стал стандартом во многих областях программирования, но тоже не панацея от всех бед. Я был на python конференции, где тусили реально гуру. Они хвастались своими либами, наработками и реализациями идей. А в кулуарах на кофе-брейках скромно добавляли, что узкие места они всё равно дописывали на Си, так как важна была скорость и надёжность.
Повторю. Язык — инструмент программиста. Знаешь один — хорошо. Знаешь несколько — отлично. Чем больше знаний, тем больше применимости в тех или иных задачах. А вот писать ТОЛЬКО на Руби конечно же в корне не верно.
Имхо.BlessMaster
08.05.2015 01:20+6Одно маленькое дополнение:
> скромно добавляли, что узкие места они всё равно дописывали на Си
Мне кажется странным стесняться подобных подробностей, поскольку весь язык написан на Си, львиная доля библиотек — это обёртки вокруг сишных (а проще говоря универсальных), сама возможность оптимизировать язык за счёт переписывания узких мест на Си преподносится как достоинство языка (и вообще отсутствие такой возможности для интерпретируемого языка вызвала бы минимум удивление).
Таки это так же моё имхо, возможно гуру воспринимают это как-то иначе, но я с Вами соглашусь — «серебрянных пуль» не бывает.
grossws
08.05.2015 02:05поскольку весь язык написан на Си
Есть ещё pypy, написанный на rpython. Или Jython, например.BlessMaster
08.05.2015 03:41+1Есть, но это уже альтернативные реализации, кое-что от CPython теряющие, особенно в плане написанных на C библиотек и это головная боль и самая, что ни на есть наглядная иллюстрация невозможности «серебрянной пули».
Jython — это интеграция в экосистему энтерпрайз-софта, живущего чуть больше чем полностью во вселенной Java, но там всё своё, и «батарейки» свои, и гуру, пишущие обёртки над сишным кодом — тоже свои.
PyPy — это уже что-то вроде выхода в открытый космос — нечто грандиозное и впечатляющее, нечто большее, чем Python, особенно с того момента, когда он приютил у себя Stackless, но вот именно PyPy — и испытывает тяготы сложности интеграции с сишными либами, а по производительности, несмотря на применяющиеся техники компиляции — он до сишного кода таки не дотягивает. Свой особый мир со своими сверхвозможностями и недостатками.
На самом деле я не дошёл ещё до того, чтобы использовать PyPy, поэтому про недостатки пишу лишь понаслышке. Но думаю, тут без меня хватит тех, кто истоптал вокруг него все грабли.
Кстати, вот буквально вчера мне подбросили вот это: pypyjs.org — pypy с бэкэндом в javascript с asm.js.
Полноценный Python 2.7.8 (PyPy 2.5.0) в браузере.
По производительности на моей машине сопоставимо с CPython2 в консоли — в чём-то медленнее, в чём-то даже быстрее.grossws
08.05.2015 03:53Jython — это интеграция в экосистему энтерпрайз-софта, живущего чуть больше чем полностью во вселенной Java, но там всё своё, и «батарейки» свои, и гуру, пишущие обёртки над сишным кодом — тоже свои.
Не знаю, как в Jython, но в JRuby обёртки на java-библиотеками. И кроме энтерпрайза в java-мире ещё очень много чего существует.
Кстати, вот буквально вчера мне подбросили вот это: pypyjs.org — pypy с бэкэндом в javascript с asm.js.
По вычислительным задачам, кстати js на v8 (chrome) и ionmonkey (firefox) отставание однопоточного cpu-bounded кода от c++ (портировался с помощью sed, заменой «this.» на "", «var» на «auto») всего в полтора раза. Так что jit в этих реализациях js очень неплох.
Полноценный Python 2.7.8 (PyPy 2.5.0) в браузере.
По производительности на моей машине сопоставимо с CPython2 в консоли — в чём-то медленнее, в чём-то даже быстрее.BlessMaster
08.05.2015 07:38+2Действительно. Говорим «Java» — подразумеваем «Enterprise», говорим «Enterprise» — подразумеваем «Java». ©
Устоявшееся, но крепкое как любой стереотип заблуждение. Взять тот же Android, который совсем из другой оперы.
А pypy.js, насколько я понял, пока всё же на сильно ранней стадии. Но уже сам факт наличия Python, работающего в браузере не медленнее Python в консоли — очень даже воодушевляет. Осталось скрестить его с WebGL и начать новую эпоху браузерных приложений. Если же ещё портируют Qt…
stardust_kid
08.05.2015 01:06+5У верблюда два горба,
Потому что жизнь — борьба
У каждого языка есть преимущества и недостатки. Ценной информация о недостатках становится, когда упоминаются конкретные проблемы, причины их появления и способы обхода. Из этой статьи я вынес только, что Ruby многим не угодил пользователю Artyom18. Попейте чаю с липовым цветом, что ли.
at0mic
08.05.2015 01:33+3Но вы пробовали отследить все места, куда вы добавили этот модуль?
А что, греп отменили?
develop7
08.05.2015 11:31Справедливости ради, переписанный кусок stdlib грепом не находится.
youlose
08.05.2015 11:59+1Справедливости ради в Ruby такой функционал есть:
stackoverflow.com/questions/175655/how-to-find-where-a-method-is-defined-at-runtime
Правда сама проблема высосана из пальца, в каком языке с примесями подобной сложности нет? (и есть такой функционал по поиску исходных кодов как в Ruby?)
P.S. Лично я НИ РАЗУ не испытывал подобных проблем за многие годы знакомства с Ruby.develop7
08.05.2015 17:17Эта функциональность бесполезна, если программист не подозревает о том, что кто-то заботливый пропатчил Net::HTTP и выкинул один code path. А вот функциональность «не мешать патчить stdlib, но ругаться при этом в stderr» мне была бы полезна — сэкономила бы не менее чем полдня только в данном случае.
З.Ы. а вообще проблема неожиданного monkeypatching существует объективно, вне зависимости от вашего опыта знакомства с руби.
printercu
08.05.2015 18:23pry в помощь. Лучше посмотреть, какие классы в геме есть, перед тем как ставить, чтобы знать где могут быть проблемы (http://rightscale.rubyforge.org/right_http_gem_doc/ вверху есть Net::HTTP). тем более в случае с таким плохо документированным гемом.
А так от манкипатчинга только польза: можно поправить за кем-то ошибки или сделать бэкпорт фичи без форка. Проблемы из-за людей :)develop7
08.05.2015 19:37point is мне неоткуда знать заранее, что Net::HTTP или какой бы то ни было ещё класс пропатчен. затем мне и нужны помянутые warningи.
Лучше посмотреть, какие классы в геме есть, перед тем как ставить
видите ли, в обсуждаемом случае этот гем вообще никто явно не ставил, от него зависел то ли right_aws, то ли s3_backup — не помню точно.А так от манкипатчинга только польза: можно поправить за кем-то ошибки или сделать бэкпорт фичи без форка
да, вон rightscale уже поправили. лучше форк, в том числе и чтобы не уподобляться.
Riateche
10.05.2015 18:42Интересно, можно ли в Ruby пропатчить методы, используемые для патчинга, чтобы они выдавали нужные вам warningи…
at0mic
10.05.2015 19:37Ну во-первых, манки-патчинг — это зло. Переписывать методы напрямую пример плохого тона.
В случае, если надо что-то переписать, есть несколько подходов:
1. Отнаследоваться от класса, который надо переписать и в нем дописать нужную логику.
2. Использовать цепочку алиасов.
И в том и в другом случае можно вывести всю необходимую информацию для дебага.
Для патчинга не использутся какие-либо методы, просто поверх включенных классов накладываются классы, которые смердживаются с базовыми и или переписывают методы или добавляют. Переписывать там, в общем-то, нечего.
youlose
10.05.2015 21:25Можно заморозить (#freeze) нужные классы и при изменении они будут кидать «RuntimeError: can't modify frozen class».
Соответственно перечислить все нэймспейсы и классы можно рекурсивно через Object.constants.
Но это только для отладки если, не думаю что в продакшне такое надо использовать.
youlose
08.05.2015 12:06+2«Критикуешь — предлагай»
Какой язык программирования прямо совсем хорош-то?
P.S. Не туда попало, это автору поста вопрос, как удалить — хз
at0mic
09.05.2015 01:04+1Как по мне, так манкипатчить stdlib — это полная ярость. Что мешает отнаследоваться от базовых классов?
На самом деле, это легко детектится через caller() метод, там в цепочке сразу бы вылезло, откуда уши растут.
Jabher
08.05.2015 01:54+2С одной стороны — я согласен, с другой стороны — по-моему это троллинг. Вот честно, хочу одновременно и плюс и минус влепить.
А насчет…
Я стал относить Руби к числу бесполезных языков — таких же бесполезных, как Python или Rust. Для чего они существуют — не очень понятно
Питон существует как минимум потому что под него местами алгоритмов больше, чем под джаву даже.
Я сейчас пишу один алгоритм обсчета на базе gensim, так нужной мне функции и время выполнения, и размер занимаемой памяти — O(n), и я могу спокойно понять, какой серверный ресурс мне нужен. Взял сервер с 12 ГБ памяти и точно знаю, что мне хватит (хотя на пределе, конечно).
И этот алгоритм реализован только на питоне. Ну, на матлабе еще.
На любых других языках — памяти жрется экспоненциально, то есть если оно не умрет, сожрав полтерабайта RAM — мне еще повезет.
И нет, кэшировать на диск нельзя, хотя было бы неплохо — оно иначе год решаться будет.
Если интересно — гуглите fast low-memory SVD.
firstrow
08.05.2015 05:48вот вы знаете что «Рельсы» не подходят для определенных задач, это просто отлично, рельсы и не позиционируют себя как швейцарский нож, быстрое прототипирование, быстрая разработка, много готовых компонентов — вот задача. для остального есть другие фрейм ворки.
смысл сравнивать руби и «Го» или ноду? да, руби медленный, но опять же, в об этом знают перед началом разработки и выбирают не через быстроту работы, а через быстроту разработки. Как и твиттер, запустились на рельсе, набрали просто кучу народу и перешли на другой язык, отлично.
Многопоточность, вот тут да, не совсем все хорошо.at0mic
08.05.2015 10:46-3Многопоточность на самом деле, не умеет готовить тем кто особенно не нужна всем
fuCtor
08.05.2015 06:44+21) Как уже кучу раз писалось, не панацея. Да, удобно и быстрая разработка. Но глядя на вектор развития, все идет к тому, что постепенно мало востребованные части выносятся из основной части, что-то оптимизируется. Вводятся новые абстракции, но не пустом месте, а как результат востребованности и унификации функций вносимых различными гемами (например ActiveJob как адаптер для Resque, Sidekiq и тп). В итоге Rails на текущий момент представляет из себя некоторый остов, для приложения. Если все это не нужно, есть Sinatra. А по поводу NoSQL, так вообще не понимаю что не так. AR -> Mongoid, DM -> MongoMapper, это если по MongoDB смотреть. Да и для остальных есть как минимум драйвера.
2) Это стоит лишь принять и использовать себе на пользу. На тему private не-private cкажу больше, внутренние переменные в классе не такие уж и внутренние. К ним тоже можно не только обратиться, но и полный список получить, объявить новые и тд. Динамический язык, метапрограммирование со всем вытекающим из этого.
3) Скорость всегда не была сильной стороной Ruby, но выбирают его не за это, а за скорость разработки, гибкость, читабельность, экосистему и тд. Если есть узкие места, можно написать расширение, благо пишутся они достаточно просто (FFI, SWIG).
4) Тут старая болячка — GIL, но анонсировано, что вскоре от нее избавятся и будет нормальная многопоточность, ждем.
crackpot
08.05.2015 09:38-6Как по мне, так Ruby — просто еще один язык. Нет в нем вещей (особенно под веб), которые нельзя сделать на другом языке, равно как и наоборот.
Что меня сильно напрягает пока что в нем — символы. Чувакам захотелось создавать хэши как {a: «b»}, и чтобы быстрее, чем {«a» => «b»} и чуваки запилили новый тип данных по сути. Это какая-то страшная глупость, по-моему. Все эти .to_sym, .to_s и прочие .intern нехило рвут шаблон по первости.
Претензии к windows тоже не очень понятно зачем — в окошках удобно жить только с с# и прочим дотнетом, для всего остального, переносимого из unix, надо будет что-то делать руками. А зачем? Имхо, пытаться строить системы на ОС только потому, что в команде есть фанаты данной ОС и им «неудобно» — еще одна страшная глупость, прямо как символы в Ruby.
MpaK999
08.05.2015 10:07+2Символы это не новый тип данных, если только лично для вас, а в остальном это наследие FP и Lisp (создан в 1958 году)
crackpot
08.05.2015 10:08-2Не очень важно, что это для внутренностей Ruby. Вопрос в практическом смысме…
MpaK999
08.05.2015 10:12+4Еще раз, сиволы это очень полезный инструмент из мира функционального программирования, то что вам кажется глупостью, помогает всем остальным работать с языком и получать нужные результаты. Если вы не видите разницы между строкой и символом поизучайте вопрос его практического приминения, например в сети — www.randomhacks.net/2007/01/20/13-ways-of-looking-at-a-ruby-symbol
lolmaus
08.05.2015 10:37+1Воспринимайте символы как константы, значения которых совпадают с их именами. Их идеально использовать в качестве флагов и ключей хешей.
Они очень быстро работают: два символа с одинаковым названием являются одним объектом, и символы не собираются сборщиком мусора. По этой причине символы не следует создавать динамически.
j_wayne
08.05.2015 09:51+1Да, недостатки определенно есть. Но я предпочту руби (питон по вкусу) для работы с JSON или разбора слабоструктурированного текста. Тут динамическая природа как нельзя кстати. На яве несколько сложновато все же такие вещи делать. А вот с бинарными форматами мне больше нравится на яве работать.
Не могу так же не отметить, что у руби + рельсов довольно быстрая загрузка классов. Что-то изменить в рабочей папке с запущенным development сервером, нажать F5 — через считанные секунды виден результат (даже на большом проекте). Спасает при отладке/подгонке.
Тот же play framework + scala тяжело и нудно корячится после каждого изменения (не обладаю к сожалению мощной машиной).
Всему свое место…
Также. автор. почитайте/посмотрите Роберта «Uncle Bob» Мартина Architecture the Lost Years by Robert Martin. К нему добавить практически нечего. Тем не менее он не спешит выбрасывать руби
P.S. еще одна киллерфича руби (и подобных) языков — возможность написания DSL. Какое то время назад я понял, что это не просто buzz word. Было очень здорово предоставить удобное конфигурирование довольно сложного модуля не-руби программистам. Результат отличный.
iroln
08.05.2015 10:03+2Выпад в сторону Rust вызывает только улыбку. На счёт Python, всем этим людям wiki.python.org/moin/OrganizationsUsingPython нужно немедленно рассказать, что Python бесполезен, они сразу же образумятся и выкинут весь свой Python на помойку.
Если это был троллинг, то он слишком толстый. :)
habrahabr22
08.05.2015 10:43+2Блин, было бы это нечто в песочнице, можно было бы закопать его песочком. :-)
monax
08.05.2015 11:04+11Автор гениален, даже если сам этого не осознаёт. Ведь начать явно холиварную тему, в которой должны были слхестнуться рубисты, а потом одним коротким изящным абзацем подтянуть питонистов и растисты — это верх мастерства!
eugzol
08.05.2015 12:34Не понятно, какие проблемы в Rails с XML и NoSQL. Равно как и с какой целью надо писать тесты на инклуды. Конкретный пример бы тут пригодился.
Rondo
08.05.2015 12:44+10Эзоп уже давно объяснил этот феномен
SerJook
09.05.2015 13:27-10Ох уж эти хабровчане, для которых кроме веба ничего не существует.
За пределами веба руби никому нахер не сдался.
А делать сайтики вообще похрен на чем, это не задача для программиста.
Ничего серьезного на руби не пишут, потому что это не язык, а наколенная поделка.
Язык, у которого детских болезней не меньше, чем у php.
olegkrasnov
10.05.2015 14:55+1
VCheese
11.05.2015 12:53Наконец то! Вспомнили Скетчап, кроссплатформенный софт, написанный на Руби — отличный пример использования языка в больших проектах. А то уже сам собирался писать :)
youlose
10.05.2015 17:09А можно поподорбнее про «детские болезни» которых не меньше чем у PHP и назовите какой язык вы считаете «достойным» и у которого конечно же нет этих болячек и написано очень много качественного кода.
googol
10.05.2015 17:28Вот еще один интересный проект — github.com/manastech/crystal
Руби синтаксис и статическая компиляция с помощью LLVM. Скорость исполнения бинарников — на высоте.
andyN
10.05.2015 19:40+1Если бы Руби был создан раньше Питона, Питон не был бы нужен. Если бы Питон был создан раньше Руби, Руби не был бы нужен (и да, я действительно считаю, что создание и главное использование Руби — это ошибка).
Поясню. Языки очень похожи, фреймворки тоже, библиотеки тоже. Ну да, есть конечно нюансы, но в целом, за исключением мелких деталей, все очень похожее.
Зачем человечество потратило тысячи часов на создание велосипеда? Еще одного языка программирования, не приносящего никакой пользы (= ничего принципиально нового, сильно ускоряющего разработку, позволяющего избавиться от багов и т.п.)?
Так что я отчасти соглашусь с автором. Я не фанат Питона и не противник Руби, я противник того, чтобы тысячи (если не миллионы) человеко-часов уходили на создание очередного велосипеда только потому, что горстка парней из небезызвестной конторы внушила всем, что Руби — это круто.youlose
10.05.2015 22:10Не согласен, языки совсем не похожи (недавно только допиливал один проект на питоне так что ощущения свежие). В питоне куча странно работающих конструкций, заядлые питонисты находят для этих странностей объяснения, но язык в котором на каждом шаге надо помнить 100500 нюансов очень сложен в работе (в пример можно привести Perl там почти все странности документированы, но после Ruby запоминать их уже неохота, или PHP где море уродства и большая часть даже не документирована), типо когда range(1,4) возвращает [1,2,3], или join элементов массива в строку через задницу: "-".join([1,2,3]), self передавать в методах и.т.п.
В Ruby почти во всём коде очень продуманные интерфейсы и инструменты которыми приятно пользоваться людям. У Ruby очень мощная и продуманная std библиотека для того чтобы работать со стандартными типами я вообще не подключаю ничего, там реально есть всё (недавно встала задача отсортировать топологически граф который загружался из CSV и в std я обнаружил ruby-doc.org/stdlib-2.0/libdoc/tsort/rdoc/TSort.html где я за 10 минут и 5-10 строчек необработанные данные из CSV отсортировал, без лишних преобразований данных и дополнительных гемов).
Недавно коллегу который никогда не программировал, за полдня научил писать парсер на selenium-webdriver + Ruby и его программу можно «прочитать по-английски», что является очень хорошим показателем выразительности языка.
Подытожу: Ruby выразительнее чем Python, требует меньше кода, имеет однообразные интерфейсы, имеет понятное и мощное ООП. По возможностям примерно похожи, может быть есть смысл сравнить возможности метапрограммирования, но я не настолько хорошо знаю Python, чтобы самостоятельно с этим справиться. И польза Ruby именно в выразительности (очень мало языков программирования об этом заботятся), потому что программы пишутся для людей, а не компьютеров и именно это позволяет писать меньше багов.
И да, Ruby — Круто! (я не фанатик, если что, сейчас вот erlang углубляю ибо появилось несколько задач в которых он справиться лучше рубей, но в основном большую часть задач решать на рубях быстро и приятно)BlessMaster
12.05.2015 01:41+3Поведение range — вполне документированная особенность. И вполне логичная, если мы представляем, что range заменяет нам внутренности C-подобной конструкции for(i=1; i < 4; i++).
Точно так же и join — объединение списка в строку — это не задача списка. Любой конечный итерируемый объект может быть объединён одним единственным методом строки. Или использован ещё как-то, если нам не строка нужна. А в каждом итерируемом классе подцеплять функцию объединения в строку — как раз не логично.
Точно так же и работа с CSV ( docs.python.org/3.4/library/csv.html ) и сортировка — всё это есть в Python «из коробки». Не понятно, почему Вы приводите этот пример в качестве нежданного превосходства Ruby. Python известен именно своей мощной библиотекой.
Точно так же про «меньшим количеством кода» — не понятно, Python достаточно лаконичный язык.
Когда я начинал изучать питон, мне тоже много вещей казались нелогичными и сбивающими с толку, потому что в других языках, которые я использовал до этого, всё делалось не так. Но это лишь вопрос привычки и знания — узнав как всё это использовать, обнаруживаешь логичность и продуманность. Питон, конечно, не идеальный язык, есть за что его ругать, но вот вышеперечисленное — явно не повод.
Конечно, языки не похожи, но это не значит, что один резко хуже другого, потому что стандарты другого — нравятся. Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.youlose
12.05.2015 21:52+3Поведение range — вполне документированная особенность. И вполне логичная, если мы представляем, что range заменяет нам внутренности C-подобной конструкции for(i=1; i < 4; i++).
Ну я вот когда хочу получить числовую последовательность не хочу думать с C-подобной конструкции (я знаю что range такой из-за того что он был добавлен на самой заре появления питона)
Точно так же и join — объединение списка в строку — это не задача списка.
с чего бы это вдруг? у вас хвосты собаками виляют? =)
Даже если это так, то почему для сортировки мы вызываем list.sort(callback), а не callback.sort(list) это же задача коллбек функции правильно отсортировать список? Это называется неконсистентность интерфейсов.
А в каждом итерируемом классе подцеплять функцию объединения в строку — как раз не логично.
А зачем подцеплять какие-то функции? В том же руби любой объект при включении Enumerable примеси с реализованным методом #each имеет полный набор действий со списками и сортировки и.т.п. В питоне думаю с этим тоже проблем не должно быть.
Точно так же и работа с CSV ( docs.python.org/3.4/library/csv.html ) и сортировка
Топографическая сортировка графов, а не просто сортировка, то есть мне нужно было отсортировать древовидную структуру объектов которые были перепутаны, а добавлять в базу их надо было от родителей к детям. Можно вас попросить пример как граф полученный из CSV вы отсортируете с питоном из коробки раз это так просто и очевидно? (у меня, кстати, каждый объект принадлежал двум разным родителям внутри одного файла, бинарное дерево взаимосвязей объектов и была ещё связь отдельным полем, |id_obj, prop1, prop2, parent_id, another_parent_id|). Это несложная задача, но лично мне было приятно что я увидел это в stdlib + мне очень понравилась сама реализация, то что я смог отсортировать не дерево объектов (потому что это не требовалось), а именно массив массивов с данными из CSV.
Точно так же про «меньшим количеством кода» — не понятно, Python достаточно лаконичный язык.
Ну тут я немного погорячился, да я согласен, Python не менее лаконичный язык.
Питон, конечно, не идеальный язык, есть за что его ругать, но вот вышеперечисленное — явно не повод.
Так я это не для того чтобы ругать, человек спросил: «Зачем нужен ещё один неотличимый язык?», если следовать такой логике, то нам надо продолжать на ассемблере писать =). Ruby именно и отличается более серьёзной продуманностью интерфейсов, имеет необычное, но гибкое и простое в использовании ООП + серьёзные возможности метапрограммирования которые позволяют писать целые языки для написания программ, и это и есть прогресс — более человекопонятные языки программирования.
Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
Так я с этим тоже согласен, но считаю что инструментов всё же должно быть несколько, серебряной пули не бывает.BlessMaster
14.05.2015 17:25«я знаю что range такой из-за того что он был добавлен на самой заре появления питона»
Тут Вы заблуждаетесь. Просто посмотрите на реализации range в других языках. У такой реализации есть причины, мало соотносящиеся с эпохой. Равно как есть альтернативные реализации с включением правой границы в диапазон.
«Это несложная задача, но лично мне было приятно что я увидел это в stdlib»
Так действительно ведь не сложная — несколько строк кода, которые легко адаптировать под собственную задачу. Ну ок, это скорее эстетический вопрос, не вижу причины спорить. Вряд ли этот отдельный пункт повлиял бы на выбор языка в целом, но Ruby — действительно язык для тех, кто ценит эстетический подход.youlose
14.05.2015 17:54про range:
смотрел вот в этом посте — habrahabr.ru/company/wargaming/blog/221035/#comment_8327041
вообще на самом деле всё бы было не так плохо, если бы в питон добавили возможность получать последовательности и так как есть и с включением правой границы (как в руби, например, (1..3) = [1,2,3], (1...3) = [1,2])BlessMaster
14.05.2015 18:52Я думаю главный затык в развитии питона последние годы произошёл из-за того, что товарищ Ван Россум немного оторвался от сообщества. Python 3 уже больше 10 лет, но только пару лет назад с версии 3.3 вяло начался процесс миграции. И всё из-за чего? Из языка выкинули несколько базовых возможностей, которые действительно были нужны и лишь годы спустя их наличие было нехотя признано необходимостью, когда стало очевидно, что народ остаётся на 2.7 и машет ручкой разработчикам.
Подобное отношение — неприятный симптом, заставляющий беспокоиться о будущем языка.
А короткая форма для задания range была бы в высшей степени уместна, раз уж появились такие вещи как list comprehension.
BlessMaster
14.05.2015 19:02Там же — habrahabr.ru/company/wargaming/blog/221035/#comment_8327961
В принципе неплохо рассмотрены достоинства полуоткрытых интервалов.
А насчёт то правильно, это не правильно и там-то эталон — имхо, это уже от лукавого. Так можно дойти и до эпического сражения «крестовые отвёртки vs плоские».
Есть разные инструменты для разных случаев — все должны быть доступны и под рукой.
andyN
12.05.2015 21:55Выше в комменте уже написали все в защиту Питона. Я только напомню, что вопрос синтаксиса — субъективен. Мне вот не нравятся то, что в Руби многие вещи делаются символами, типа |x| вместо понятного и лаконичного for x in array.
Основной посыл моего первого комментария: языки действительно похожи. Если сравнивать их с Си или тем более Ассемблером, Руби и Питон выглядят как братья-близнецы. Да, кому-то не нравится родинка на щеке одного, другим не нравится прическа другого. Но это все субъективно.
О том и речь, что это два языка с одинаковыми областями применения, которые очень похожи по возможностям и недостаткам. Как программист, я прекрасно понимаю желание «поиграться» в еще один язык программирования, как менеджер, я осуждаю растрату ресурсов нашей цивилизации. Хотя конечно я понимаю, что все вещи в мире делаются просто ради фана. Даже работа и зарабатывание денег — просто погоня за положительными эмоциями, для обеспечения жизнедеятельности, человеку нынче много не нужно. Так что чем бы дитя не тешилось, лишь бы НТВ не смотрело.youlose
12.05.2015 22:16" Руби многие вещи делаются символами, типа |x| вместо понятного и лаконичного for x in array."
Так там и такой синтаксис есть =) Только он считается некрасивым в пользу функционального
array.each do |x|
…
end
и функциональный подход совсем не чужд ООП + приучает писать более правильный и удобный код (если без фанатизма).
«как менеджер, я осуждаю растрату ресурсов нашей цивилизации»
как менеджер вы должны понимать что конкуренция подстёгивает развитие чего-либо (в данном случае языков программирования), а вот монополистам нет смысла что-то улучшать и развивать, потому радоваться такому бурному прогрессу в программировании в последние годы надо именно благодаря разнообразию ЯП.
Я вот догнал c++11 недавно и очень порадовался тому что с ним произошло, несколько десятков лет он топтался на месте и с 2000 года появился реальный прогресс, на нём реально стало проще и быстрее писать + меньше думать о выделении памяти. А без конкуренции писали бы на асме.
JC_Piligrim
14.05.2015 04:27Вы так ругаетесь потому что, судя по всему, не осилили концепцию функционального программирования и т.н. «срезов» в начальных разделах документации, на которых базируются перечисленные конструкции, которые вы считаете «странными». Если потрудитесь понять это, то оказывается что это не странности, а очень логичные и правильные вещи. Да, с точки зрения синтаксиса непривычно, но однозначно понятнее чем тот же Lisp для людей, которые ФП до этого не видели (а с Python'ом сталкиваются люди разные, от Сишников, Паскалистов и Перловиков до Хаскелистов).
Ну и по поводу self и почему сделано именно так тоже можно осилить и проникнуться в документации и, например, здесь: habrahabr.ru/post/122082
Да, в Python много недостатков, кривостей, но то что вы перечислили — точно не проблема. Там с потоками беда и не хватает статической типизации (хотя бы опциональной), но как понимаю, Руби тут тоже ничего особо предложить не может.youlose
14.05.2015 08:18Проблема в том, что в функциональных языках это смотрится гармонично. А в питоне всё является объектом что переносит нас в плоскость ООП и с точки зрения ООП строка объединяющая строки уже не смотрится логичным решением.
И я не спорю что решения которые были приняты в питоне плохие или какие-то неправильные, вопрос был в том «нужен руби или нет», я считаю что однозначно нужен, ибо стартанув на 5 лет позже он дал более удобный, понятный,!!! консистентный!!! синтаксис. Там есть и функциональные возможности в полной мере, но объекты типов работают однообразно и логично с точки зрения ООП.
И статическая типизация ни Python'у, ни Ruby не нужны, у них своя ниша, где они лучшие. Сложные вычислительные задачи нужно делать на более подходящих языках, связывать их есть чем(брокеры сообщений, thrift, protobuf).BlessMaster
14.05.2015 17:41+1«статическая типизация ни Python'у, ни Ruby не нужны»
Пример RPython и такого великолепного продукта на нём как PyPy ставит под сомнение это утверждение.
И такое может быть нужно и полезно. Просто это — уже немного другой язык.
Наконец, не всё ведь сводится к «числодробилкам». Здесь просто очередной компромисс между скоростью работы и скоростью разработки. Немного потеряв в скорости разработки можно получить хороший прирост в скорости работы на некоторых задачах.
Возвращаемся к разнообразию.
JC_Piligrim
14.05.2015 04:34Да, насчёт нелогичности range всё же соглашусь — это да. Срезы тут не при чём, у меня в голове ваш коммент смешался с чужим. :) Но опять же — к этому легко привыкаешь. В отличие от реальных проблем Python'а, которые, кажется, решены если и будут, то тогда, когда никому не надо уже будет. :)
А вот DSL в Ruby — мощная штука, конечно. Её в Python'е немного не хватает.
strangeworks
14.05.2015 11:46+2Никогда не понимал такого рода статей, где по большей части нытье в сторону %langname%. Есть инструмент, есть задача под него, все! Зачем вы льете эту воду? Статью воспринял я как жалобы повара, который в мультиварке не может хорошо пожарить картошку.
railsfun
16.05.2015 10:23Ну не нравится руби не используйте его )
Забавляет что половина каментов — холивар уже с питонистами )
guai
17.05.2015 21:46-1Тоже не нравится руби, особенно его реализация jruby. Вот почему:
Хреновый дизайн, в частности, до второй версии не было Module#prepend, без которого в манипуляции модулями не было консистентности. Лямды, блоки и методы до сих пор неконсистентны. Евалы до сих пор повсеместно используются.
Косяки с кодировками, utf-8 привернули недавно и костыльно
Манкипатчинг. Никогда не найдешь, откуда взялась та или иная функциональность.
Наследование дурацкое: self.included, class <<self, переименование методов, не наследуемые переменные класса и тд
ДСЛ, которым они хвалятся, возник стихийно и недопродуман
Конкретно jruby:
хреновые исходники, слабое комьюнити, хреновый interoperability с явой; исключения пролезают, куда не должны; дэдлоки; работа с потоками ужасно глючная. все сделано по-своему, вместо того, чтобы реюзать код явы; зачем там строки с кодировками в массивах байтов, до сих пор не понимаю
разработчики хватаются за новые фишечки, не доведя до ума имеющиесяyoulose
17.05.2015 23:17+1jruby не пользовался и не вижу в нём большого смысла (на мои задачи хватает префорка воркеров с очередями задач), если прям так сильно нужна многопоточность, наверное всё таки нужно выбрать более подходящий язык программирования и инструменты.
Про манкипатчинг я писал выше, для MRI с 1.9+ версии выводит файл исходника и строку по методу, этого вполне достаточно чтобы при помощи git blame надавать по рукам засранцу кто это сделал.
Про наследование:
self.included — это чёрная магия, за которую в production коде надо бить по рукам, она нужна для гемов, но никак не для обычного кода
class << self — это хипстеры используют для своих мини проектов, так писать не нужно вообще
переименование методов — не представляю как можно использовать вообще
не наследуемые переменные класса — не представляю зачем это вообще может быть нужно (может быть просветите), если уж нужны они не наследыванием переносятся, а примешиванием.
Вам нужен code review + надавать чрезмерным метопрограммирования по рукам(лицам) и всё будет хорошо.
ДСЛ это возможность писать код который выглядит как конфиг или английский язык, да, его все реализуют каждый по своему, но базовые подходы одинаковые, опять же вопрос в реализации (когда люди охваченные маниакальным метапрограммированием начинают что-то делать, получается плохо).
Судя по большинству описанных проблем у вашей команды бардак в коде и не очень понимающие концепцию Ruby программисты, что на любых языках программирования приводит к проблемам.guai
17.05.2015 23:37так и есть, и архитекторы зря сделали ставку на руби, и бардак, и прогеры не все блещут. всё как у людей
но когда в языке есть вещи, которые надо дополнительно ограничивать административными средствами, я считаю его плохим (ну, разумеется, ограничивать сильнее совсем уж извращений, типа написания всего кода в 1 строку)
ну и посыл статьи в том же, не юзайте руби для чего-то серьёзного
PS: немножко ошибся, я имел в виду не наследуемые методы класса, а не переменныеyoulose
18.05.2015 08:48+1Ну тут всё же проблема не в руби, а в том что им неправильно пользуются, на той же джаве без опыта намного хуже можно наговнокодить.
guai
18.05.2015 10:05я считаю, описанные мной проблемы, не все только потому, что мы не умеем готовить руби. мы умеем, пришлось научиться. пришлось лазить по исходникам, править косяки jruby самостоятельно. и не все можно поправить, косяки дизайна никуда не денутся, тулинг слабый тоже одномоментно никуда не денется, тормоза никуда не денутся и тд
поэтому я и не люблю руби
совершенно не в кайф в нем делать, ну вообще-то совсем ничего, даже для простых одноразовых скриптов чаще использую груви.
маловат тот его кусок, при выходе из которого, проблемы встают в полный рост.
printercu
18.05.2015 09:47Ставку делали на удобство и гибкость. Всеми фичами можно и нужно пользоваться. Только не все могут нормально, поэтому и возникают потом проблемы в поддержке написанного.
youlose
18.05.2015 19:56Ну в командной разработке, лучше использовать те фичи, которыми умеют уверенно пользоваться все участники команды. На самом деле я не знаю языков программирования, где люди с разным уровнем погружения и понимания языка могут писать код и не иметь головняков (ну, может быть, только если их код никак не пересекается между собой, но такое нечасто бывает, наверное).
printercu
18.05.2015 09:42> self.included — это чёрная магия, за которую в production коде надо бить по рукам, она нужна для гемов, но никак не для обычного кода
ActiveSupport::Concern вы не используете?
> class << self — это хипстеры используют для своих мини проектов, так писать не нужно вообще
Потом методы класса можно по файлу в неожиданных местах находить. attr_accessor через singleton_class.send пишите, или для него можно побыть хипстером?at0mic
18.05.2015 13:32ActiveSupport::Concern требует, чтобы был установлен ActiveSupport, а если проект не на рельсах, то не всегда он и нужен. Явно уж, только ради Concerns таскать его за собой не стоит.
youlose
18.05.2015 19:50-2«ActiveSupport::Concern вы не используете?»
Как-то не пригождается, нет надобности примешивать и методы класса и методы экземпляра одновременно, да и как-то поддерживать легче код без этой чёрной магии…
Про class << self я отношусь однозначно отрицательно,
то есть если вы один разрабатываете что-то — это ваше личное дело, а если разработчиков становиться >1 то возникает куча проблем:
1. Методы внутри class << self нельзя тупо скопипастить
2. Чтобы выяснить метод ли класса это или нет, надо скроллить туда сюда по классу, что меня лично бесит
3. Не все сразу понимают эту конструкцию, потому если в команде есть новички, такие фишки противопоказаны
И из плюсов — в названиях методов нужно писать на 5 буковок меньше…
Мне кажеться выбор однозначный.
«Потом методы класса можно по файлу в неожиданных местах находить»
Для этого в компании должны быть какие-то правила, чтобы код было приятно читать. Там где я работаю мы стараемся отделять методы класса примесями, а если их немного, то просто пишем выше всех методов.
" attr_accessor через singleton_class.send пишите, или для него можно побыть хипстером? "
attr_accessor абсолютно не хипстерский, а очень полезный декларативный элемент объектов в Ruby, минусов его использования не знаю, если подскажете буду признателен.
#send использую очень редко в основном для DSL.printercu
18.05.2015 23:52Я про то, что можно писать
class << self attr_accessor :x end # если без class << self, то по-другому уже singleton_class.send :attr_accessor, :xyoulose
19.05.2015 09:57У меня коллеги сильно залипают на такие конструкции, потому тупо объявляем нужные методы с def self, либо примешиваем из модулей через extend.
В команде гибкостью языка стоит жертвовать в угоду большего взаимопонимания. Зато никто из них не жалуется что методы хрен знает откуда подключены и.т.п.printercu
19.05.2015 11:21Это да. Я в другой ветке писал, что язык за гибкость язык винить — странно, если эта гибкость полезна. А в руби я не могу сейчас вспомнить что-то бесполезное. Дело в людях: кто-то не умеет пользоваться, кто-то пользует фичу не по назначению.
Я, все-таки, считаю, что лучше поднимать уровень понимания в команде. Ведь это довольно базовые вещи: 1 раз понял — пользуешься всегда. К тому же, код написанный не в команде тоже иногда (а может и часто) надо будет читать (фрэймворки/библиотеки). И он не всегда написан хорошо.
noder
Про то, что руби не работает под Windows не могу согласиться. Я уже не первый проект разрабатываю на RoR именно на Windows машине. Полет нормальный. Правда пришлось немного повозиться с установкой mysql2 гема, но все решаемо и гуглится за пару минут. Причем одно из приложений использовало демоны для конвертации видео файлов, но и они заработали без проблем.
grossws
Периодически приходится писать мелкие одноразовые скрипты. На linux всё прекрасно. Но на win и у ruby, и python'а есть некоторые «особенности». Часть из них связана с тем, что cmd — не очень удачный терминал, который тащит за собой довольно тяжелое наследие.
Например, аргументы запуска скрипта в cp1251, но external charset — cp866. И выводить на консоль надо в cp866, имена файлов из аргументов якобы в cp866 надо интерпретировать как cp1251.
Ещё из забавного, одна из ruby-библиотек для работы с unicode (а надо было всего лишь делать downcase) на win работала на несколько порядков медленнее (require её занимал десятки-сотни секунд на ssd, на linux — ~100ms).
Также стоит сказать, что под win хромает поддержка библиотек для MRI на x86_64. А собирать какой-нибудь libxml2 — отдельное развлечение.
kekekeks
grossws
Ruby и python с помощью каких-то системных вызовов получают текущую кодировку в консоли. И то, что она не совпадает для argv и остального вывода — довольно печально. Та же java считает в таком случае, что кодировка — cp1251.
BlessMaster
Список систем, на которые портирован Ruby впечатляет:
«Официальный интерпретатор портирован под большинство платформ, включая Unix, Microsoft Windows (в том числе Windows CE), DOS, Mac OS X, OS/2, Amiga, BeOS, Syllable, Acorn RISC OS и другие»
Кстати, никто ничего не написал по поводу производительности, а это, имхо, самый существенный вопрос из всех поднятых. И при этом самый комплексный. На самом деле я тут покапитанствую немного на тему.
С одной стороны — странно использовать интерпретируемый язык для математических вычислений, для которых хотелось бы выжимать каждый такт из процессора. Но даже этот вопрос давно обошли созданием обёрток над библиотеками, написанными на соответствующих языках.
С другой стороны — достоинство интерпретируемых языков это не скорость их непосредственной работы, а скорость разработки. Весь круг задач, где программа пишется дольше, чем она вообще работает, где основную работу выполняет внешний по отношению к интерпретатору код — это сфера где интерпретаторы будут безраздельно царствовать ещё очень долго.
В самом деле, в жизни типичного веб-приложения большую часть времени работает база данных, а скрипты лишь переводят ей веб-запросы, и переводят от неё ответы в веб. При этом как только дело касается хоть сколько-нибудь затратных операций — парсинг json, html, отрисовка шаблона, обработка изображений, звука, видео, шифрование — в дело вступают оптимизированные библиотеки. Сам же интерпретируемый язык предоставляет удобный интерфейс для применения этих библиотек в разработке.
Удобство и скорость разработки — вот два козыря, которые никто не может перебить, приводящие к тому что веб вообще держится на интерпретируемых языках, которые ни один не сильны в дисциплине «числодробления». Но даже тут ищутся и находятся компромиссы: JIT (как родной — v8, так и поверх JVM/.NET — JRuby/IronRuby, Jython/IronPython, JPHP/Phalanger), транслирование в код на Си/Си++. Это возможно, если это нужно проекту и интерпретатор стал узким местом. Но обычно узким местом является НЕ интерпретатор.
В результате поднимается вопрос — насколько вообще существенно, что Ruby в вычислительных задачах медленней других интерпретируемых языков? Насколько это важно на фоне синтаксических особенностей языка, удобства разработки и т.п.? Где это делает язык слабым звеном?
at0mic
Смотрю я на наши графики в newrelic, и странное дело: на самых загруженных контроллерах база отъедает от рендеринга от силы процентов 20. Больше всего времени занимает сама обработка запроса, я так полагаю rack'ом.
Поэтому в моменте с затратными операциями я не соглашусь — не все так радужно в нашем королевстве, тупит руби сам по себе знатно.
BlessMaster
А на чём реализован рендеринг?
Неужели никто не озаботился оптимизировать столь существенную просадку в производительности?
Или львиная доля процессорного времени уходит на работу десятков строчек контроллеров, дёргающих библиотеки и скармливающих им данные и шаблоны?
На самом деле я с Ruby и его проблемами не знаком, я сейчас работаю с Python, много лет перед этим посвятив PHP, а данная статья меня заинтересовала в плане расширения кругозора. Но мне очень странно слышать некоторые вещи, особенно учитывая что много хорошего ушло в мир именно из экосистемы Ruby, вот тот же SASS, который я сейчас использую в оригинальной реализации и на чёрный день поглядываю в сторону libsass, переписанной на C.
Renius
Sass компилируется перед выкаткой, заячем библиотеку на C переписывать?
BlessMaster
Не всегда. Есть и частные случаи, когда он компилируется на сервере.
Renius
С каждым запросом?
BlessMaster
Зачем? Достаточно раз при изменении настроек.
Renius
Тогда зачем что-то переписывать, если это нужно 1 раз при выкатке?
BlessMaster
О какой выкатке идёт речь?
К выкатке это не имеет никакого отношения.
Просто попытайтесь представить, что сайты не статичны и на их состояние могут влиять пользователи ;-)
Renius
Пытаюсь представить, каким образом пользователи могут влиять на состояние sass файлов исходниках — не выходит.
BlessMaster
Например, щёлкая кнопочки и заполняя поля в соответствующем веб-интерфейсе настройки внешнего вида сайта и его разделов? При установке новых компонентов? При покупке и смене «темы» сайта? Все эти действия пользователь может прекрасно выполнить средствами интерфейса не привлекая разработчиков, которые пересоберут ему сайт и выкатят в продакшен статичную версию.
Renius
У вас клиенты меняют тему сайта сразу в sass? Или вы научились css из формочек в sass конвертировать? :)
BlessMaster
Не понимаю суть вопроса. У вас разучились контроллеры писать? Или вы всегда вываливаете на клиента 100 различных инвариантов оформления?
Renius
Но я не позволяю контроллерам писать sass на диск
youlose
На самом деле даже скомпилировать sass для темы, можно и на ruby-native + скешировать результат, может быть прегенерить… А можно и compass'ом компилировать. В общем варианты есть, и тянуть сишную зависимость без надобности — это потерять часть пользователей, потому что не все понимают что нужно дополнительно установить чтобы некоторые дополнения установить.
OnYourLips
Это до тех пор, пока вам не нужно ставить сторонние бинарные джемы со своими бинарными зависимостями.