Не совсем крутой Ruby

image

Помню, как два года назад столкнулся с Руби. Язык показался прекрасным, все в нем понятно и просто, нет ничего лишнего, нет ничего не очевидного. Шло время, навыки росли, времена менялись и вот уже Руби не кажется мне таким привлекательным как раньше: медленно работает, да и большие проекты поддерживать тяжело. Почему? Да потому что большие проекты и Руби — это вообще вещи несовместимые. Ты видишь скорость выполнения на других языках и хочется плакать — из-за того, что когда-то был сделан выбор именно в сторону этого языка программирования.

Ниже вы найдете 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. Для чего они существуют — не очень понятно, но они существуют и будут продолжать существовать до тех пор, пока остаются люди, которые уверены в том, что это лучшие языки современности.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 142

    +6
    Про то, что руби не работает под Windows не могу согласиться. Я уже не первый проект разрабатываю на RoR именно на Windows машине. Полет нормальный. Правда пришлось немного повозиться с установкой mysql2 гема, но все решаемо и гуглится за пару минут. Причем одно из приложений использовало демоны для конвертации видео файлов, но и они заработали без проблем.
      +2
      Периодически приходится писать мелкие одноразовые скрипты. На 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 — отдельное развлечение.
        0
        Например, аргументы запуска скрипта в cp1251, но external charset —SetConsoleCP(65001); cp866. И выводить на консоль надо в cp866, имена файлов из аргументов якобы в cp866 надо интерпретировать как cp1251.
        Это проблема не виндового терминала вообще говоря. Ибо есть GetCommandLineW/CommandLineToArgW, возвращающие юникодную командную строку, а вывод на терминал переключается в юникод вызовом SetConsoleOutputCP. Убогость его заключается в том, что вместо управляющих последовательностей используется набор winapi-функций, но это уже другой разговор.
          0
          Ruby и python с помощью каких-то системных вызовов получают текущую кодировку в консоли. И то, что она не совпадает для argv и остального вывода — довольно печально. Та же java считает в таком случае, что кодировка — cp1251.
        +8
        Список систем, на которые портирован 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 в вычислительных задачах медленней других интерпретируемых языков? Насколько это важно на фоне синтаксических особенностей языка, удобства разработки и т.п.? Где это делает язык слабым звеном?
          +1
          Смотрю я на наши графики в newrelic, и странное дело: на самых загруженных контроллерах база отъедает от рендеринга от силы процентов 20. Больше всего времени занимает сама обработка запроса, я так полагаю rack'ом.
          Поэтому в моменте с затратными операциями я не соглашусь — не все так радужно в нашем королевстве, тупит руби сам по себе знатно.
            +1
            А на чём реализован рендеринг?
            Неужели никто не озаботился оптимизировать столь существенную просадку в производительности?
            Или львиная доля процессорного времени уходит на работу десятков строчек контроллеров, дёргающих библиотеки и скармливающих им данные и шаблоны?

            На самом деле я с Ruby и его проблемами не знаком, я сейчас работаю с Python, много лет перед этим посвятив PHP, а данная статья меня заинтересовала в плане расширения кругозора. Но мне очень странно слышать некоторые вещи, особенно учитывая что много хорошего ушло в мир именно из экосистемы Ruby, вот тот же SASS, который я сейчас использую в оригинальной реализации и на чёрный день поглядываю в сторону libsass, переписанной на C.
              0
              Sass компилируется перед выкаткой, заячем библиотеку на C переписывать?
                0
                Не всегда. Есть и частные случаи, когда он компилируется на сервере.
                  –1
                  С каждым запросом?
                    0
                    Зачем? Достаточно раз при изменении настроек.
                      0
                      Тогда зачем что-то переписывать, если это нужно 1 раз при выкатке?
                        0
                        О какой выкатке идёт речь?
                        К выкатке это не имеет никакого отношения.
                        Просто попытайтесь представить, что сайты не статичны и на их состояние могут влиять пользователи ;-)
                          0
                          Пытаюсь представить, каким образом пользователи могут влиять на состояние sass файлов исходниках — не выходит.
                            0
                            Например, щёлкая кнопочки и заполняя поля в соответствующем веб-интерфейсе настройки внешнего вида сайта и его разделов? При установке новых компонентов? При покупке и смене «темы» сайта? Все эти действия пользователь может прекрасно выполнить средствами интерфейса не привлекая разработчиков, которые пересоберут ему сайт и выкатят в продакшен статичную версию.
                              0
                              У вас клиенты меняют тему сайта сразу в sass? Или вы научились css из формочек в sass конвертировать? :)
                                0
                                Не понимаю суть вопроса. У вас разучились контроллеры писать? Или вы всегда вываливаете на клиента 100 различных инвариантов оформления?
                                  0
                                  Но я не позволяю контроллерам писать sass на диск
                                    0
                                    На самом деле даже скомпилировать sass для темы, можно и на ruby-native + скешировать результат, может быть прегенерить… А можно и compass'ом компилировать. В общем варианты есть, и тянуть сишную зависимость без надобности — это потерять часть пользователей, потому что не все понимают что нужно дополнительно установить чтобы некоторые дополнения установить.
          0
          Это до тех пор, пока вам не нужно ставить сторонние бинарные джемы со своими бинарными зависимостями.
          +1
          Я просто оставлю это здесь http://en.wikipedia.org/wiki/Duck_typing
            +24
            как Python или Rust

            И тут я немного в выпал в осадок.
            Хоть я и не являюсь фанатом Python и даже не пишу на нем, но не назову его «бесолезным».
            С Rust ситуация еще интересней… Он же даже еще не зарелизился. Да и то что есть сейчас на бета релизе уже ну никак не назвать «бесолезным».
              +26
              Автор не в настроении, досталось всем. ;)
                +10
                Странно что PHP обошел стороной ))
                  +3
                  м.б. он бросил руби в пользу пхп)
                    +1
                    Ну разве что ради интерфейсов и абстрактных классов XDDD

                    Вообще идеальной технологии не бывает, всему свое место и свое время.
                +1
                Ну в Ruby, в отличие от Python, хоть нету этого кошмарного разделения на 2.x и 3.x, когда половина нужных библиотек работает только в 2.x, половина — в 3.x и крутись как хочешь (сейчас с этим уже чуток получше стало, а раньше например при попытке использовать в проекте PyQt+PyOpenGL становилось очень грустно).
                  +9
                  А какие библиотеки в Питоне написаны только для Python 3?
              +1
              В чем проблема с работой руби под виндой? Рубиинсталлер и все без проблем работает. Рельсы(мне лень это проверять, но я уверен в этом на 98%) тоже заработают без проблем, а railsinstaller сделает все в десяток кликов мышкой. То, что гемы могут вылетать с кучей ошибок — это да, но это проблема разработчиков этих гемов(на самом деле никакой проблемы особо и нет), а не руби.
              В чем проблема рельс? Все прекрасно знают, что это такой огромный конструктор и если нужна легкость, то выбирать его глупо. Благо это не один фреймворк на руби. NoSQL? Тоже ок.
              В чем проблема открыть поиск по проекту и найти все строки «include ModuleName» я тоже не знаю.
                –13
                Да, согласен проблема разработчиков гемов. Очень многие гемы которые используют C++ Extensions не смогут нормально сбилдиться и в худшем случаи придеться писать этот функционал самому, а если я не могу использовать помощь огромного комьюнити, тогда смысл работать с Ruby?

                Конструктор — это немного не то слово, конструктор — это когда можно много чего собрать, а вот на Рельсах ты едешь в одном направлении.

                NoSQL — это проблема. Придеться постоянно подставлять палочки, проверки и т.д. в тех местах где они совсем не нужны.

                Поиск по проекту будет работать, когда проект не включает в себя много различных гемов и огромного колличества классов в которые уже добавлены эти модули. Если меняешь модуль то нужно убедиться, что не один из классов не слетит, иногда это бывает очень сложно.
                  +1
                  NoSQL — как раз не проблема.
                  Нет, в принципе, если использовать вместо AR, то может и проблема. Но это уже вопрос к разработчику — зачем использовать для CRUD задач NoSQL.
                  В остальном же, выпиливается AR в 4 строчки.
                    0
                    >зачем использовать для CRUD задач NoSQL.

                    ну, смотря какие именно задачи
                    0
                    Ни один из классов не слетит? я конечно не сильно опытный разработчик, но насколько я знаю эту проблему должны решать тесты, которые руби вроде как очень любит. И если у вас что то слетит вы увидите где конкретно это произошло после прогона тестов.
                    +1
                    В чем проблема открыть поиск по проекту и найти все строки «include ModuleName» я тоже не знаю.

                    Зачем так жестоко, можно же определить/переопределить методы included/extended и там получить полную информацию начиная от имени класса где используется, заканчивая файлом и конкретной строкой. Если уж так хочется получить данную информацию.
                      0
                      Можно, только оно в development работать не будет, там lazy loading классов.
                      0
                      > В чем проблема открыть поиск по проекту и найти все строки «include ModuleName» я тоже не знаю.
                      На самом деле, если уж автору так надо, достаточно чуть-чуть почитать про метапрограммирование в языке, определить `self.included` callback в модуле и хоть исключения бросать на попытку инклюда.
                      +3
                      >>>Я стал относить Руби к числу бесполезных языков — таких же бесполезных, как Python или Rust.

                      Так а Python та чем не угодил?
                        –12
                        Недавно начал изучать Python, но очень быстро был вынужден закончить. У меня полилась кровь из глаз, когда я увидел, что в метод первым параметром передается this, и я не смог продолжить.
                          +11
                          Угу, только долго поработав с Pythonом понимаешь, что многое, что в других языках делается за счёт ключевых слов, в Pythone делается за счёт базовых механизмов языка. Я это к тому, что на уровне исполнения, методов в Python вообще не существует. Превращение функции в метод осуществляется за счёт механизма дескрипторов, а функция — это дескриптор! (см docs.python.org/3/howto/descriptor.html). Более того, сделать первый параметр неявным — совсем не сложно (метаклассы, либо чуть попроще — с помощью декораторов и инъекций в func_globals). Но дзен Python'a гласит: «Явное — лучше неявного». И мне кажется, именно это служит причиной явной передачи self в качестве первого аргумента.
                            +5
                            «Пастернака не читал, но осуждаю»
                            Явная передача параметров очень удобна — это базируется на одном из главных принципов Питона.
                              +7
                              Являясь тру С++ разработчиком, очень пессимистично начал изучать Python, но именно то, что в метод первым параметром передается this — это гениально! Одним этим фактом ООП превращается в АОП (Аспектно-ориентированное программирование), можно «выдрать» функционал из одного класса и засунуть в другой, можно научить утку не только лаять, но и запустить в космос парой строчек кода!
                                0
                                В чем же проблема как тру С++ разработчику написать функцию с именем вроде _Z7MyClass7MyMethod, которая принимает MyClass* в качестве первого параметра?
                                  –1
                                  В конвенции вызова. Она для instance-методов может быть не stdcall/cdecl, по крайней мере в MSVC. И для не-instance-методов __thiscall вроде как не скомпилируется.
                                    0
                                    Это да, АБИ могут быть разные.

                                    Оффтоп: мне любопытно, как кланговцы будут пилить совместимость с MSVС и, как они запилят, хотелось почитать их код.
                              –13
                              Не то чтобы не угодил, я знаю ребят которые пишут и довольны, как в прочем и на других языках. Просто я не вижу в нем смысла. Есть достаточно языков для консольных скриптов, есть достаточно языков для веб разработки.

                              Так что к питону нет никаких личных претензий, нормальный язык, просто в обществе принято писать новые языки программирования, которые почти такие же как остальные но там есть какая-нибудь табуляция.
                                +3
                                Не могли бы Вы назвать список языков, делающих Python ненужным и бессмысленным, существовавших на момент его создания?
                                  –13
                                  На момент создание уже существовал как миниму Perl, Icon, ABC и каждый можно было развивать. Но был создан новый язык (на сколько я помни он поначалу вообще был 'Hobby Language'). Так же был Bash, хоть он и был создан для Unix среды, но и питон по началу только в Unix среде использовался (вроде как только со второй версии под винду начали).

                                    +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 лет звучит странно.
                                      –10
                                      Так разница есть и у C# с JAVA и у Objective-C с SWIFT. Но проблемы решались теже. Тем более у ABC и Python. Да, другой подход к решению, который на тот момент был удобен автору языка. Таким образом создается огромное колличество языков как публичных так и приватных. Но как мне кажется, если два языка решают одну и туже задачу то один из них явно бесполезен.

                                      По поводу кроссплаформенности даже не спорю. Да и не говорил что это минус на то время был, просто подчеркнул факт.

                                      По шеллу все просто. Если бы его начали полноценно портировать на другие системы (сигвин не рассматриваю), то разницы никакой небыло бы, выполняй скрипты и радуйся. Просто Питон продолжали развивать во всех направлениях, а Шелл нет.
                                        +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 и знаком с людьми, которые их делали. Просто этот инструмент не самый лучший для этой и многих других целей. Это возможно, но это большинству не нужно. А то, что нужно — мы видим как лидеров индустрии.
                              +4
                              >Ничего дельного под Windows до сих пор не сделали.

                              хз, в РЖД интеграционные решения на jruby под виндой нормально работают, всякие рельсы тоже. В чем проблема-то?

                              >Для чего они существуют — не очень понятно

                              окей, лол
                                +13
                                в РЖД
                                всякие рельсы тоже
                                :D
                                  +2
                                  Для полного феншуя в РЖД должны использовать IronRuby :)
                                    +3
                                    Судя по работе их сайта — не удивлюсь.
                                • UFO just landed and posted this here
                                    0
                                    Не пали контору!)
                                  +3
                                  ИМХО, сам Ruby — красивый язык со множеством хороших моментов, но вы правы в том, что текущая его реализация — немного лучше, чем УГ.
                                  Всё таки рельсы я больше расцениваю как пинок для быстрого старта более-менее типичного проекта, когда вылезать за рамки прописных истин самих рельс не особо нужно, а потом, когда будет время, переписать на что-то более производительное.
                                    0
                                    Не очень понимаю о каких выходах из рамок вы говорите. Есть же общие стандарты. Если вы хотите не REST-full API то вы в первую очередь выходите за рамки REST, а уже потом рельсы.
                                    Во вторых, лишь ничтожно малое количество стартапов выходят в фазу «о, а у нас все получилось». И уж тем более в фазу «о, а пора снижать операционные издержки»
                                    В третьих, и это самое главное, любая автоматизация бизнес процессов подразумевает, что эти бизнес процессы реально происходят в окружающей нас действительности. По своему опыту могу сказать, что львиная доля времени тратится на формализацию задачи. И только меньшая часть на код. Иными словами, толковых постановщиков задач и тестировщиков UX нужно больше чем разработчиков.
                                    И если, ничего не мешаает автоматизировать процесс средствами веб, то придумать что-то лучше рельсы или питона будет очень трудно, я бы поставил на «невозможно».
                                    +1
                                    Никогда не стоит привязываться на 100% к какому-то языку, к какой-то платформе, фреймворку, т.к. король может оказаться голым.
                                      +7
                                      К чему «гнать» на определённый ЯП, вообще не понятно. Просто не используй его, а в Твиттер напиши, что мол посмотрел на Руби, он мне не понравился. Пост сильно смахивает на очередное разжигание холивара, который ни к чему продуктивному не приведёт.
                                        +5
                                        Автор, язык программирования — инструмент. Не более. И инструменты есть для самых разных задач. Руби не исключение. Фреймворки — вообще зло и от лукавого. Да, удобно, да, быстро, но стоит разобраться подробнее, и начинаются костыли, зависимости и велосипеды. А если всё равно это начнётся — зачем тогда начинать с фреймворков.
                                        И да, Руби не для больших проектов. Для реально больших проектов я рекомендую Java, С и С++.
                                        Go — хорош на многопоточности, но проигрывает C. Rust подаёт большие надежды, хотя многие скептически настроены. Python — вообще стал стандартом во многих областях программирования, но тоже не панацея от всех бед. Я был на python конференции, где тусили реально гуру. Они хвастались своими либами, наработками и реализациями идей. А в кулуарах на кофе-брейках скромно добавляли, что узкие места они всё равно дописывали на Си, так как важна была скорость и надёжность.

                                        Повторю. Язык — инструмент программиста. Знаешь один — хорошо. Знаешь несколько — отлично. Чем больше знаний, тем больше применимости в тех или иных задачах. А вот писать ТОЛЬКО на Руби конечно же в корне не верно.

                                        Имхо.
                                          +6
                                          Одно маленькое дополнение:

                                          > скромно добавляли, что узкие места они всё равно дописывали на Си

                                          Мне кажется странным стесняться подобных подробностей, поскольку весь язык написан на Си, львиная доля библиотек — это обёртки вокруг сишных (а проще говоря универсальных), сама возможность оптимизировать язык за счёт переписывания узких мест на Си преподносится как достоинство языка (и вообще отсутствие такой возможности для интерпретируемого языка вызвала бы минимум удивление).

                                          Таки это так же моё имхо, возможно гуру воспринимают это как-то иначе, но я с Вами соглашусь — «серебрянных пуль» не бывает.
                                            0
                                            поскольку весь язык написан на Си
                                            Есть ещё pypy, написанный на rpython. Или Jython, например.
                                              +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 в консоли — в чём-то медленнее, в чём-то даже быстрее.
                                                0
                                                Jython — это интеграция в экосистему энтерпрайз-софта, живущего чуть больше чем полностью во вселенной Java, но там всё своё, и «батарейки» свои, и гуру, пишущие обёртки над сишным кодом — тоже свои.
                                                Не знаю, как в Jython, но в JRuby обёртки на java-библиотеками. И кроме энтерпрайза в java-мире ещё очень много чего существует.

                                                Кстати, вот буквально вчера мне подбросили вот это: pypyjs.org — pypy с бэкэндом в javascript с asm.js.
                                                Полноценный Python 2.7.8 (PyPy 2.5.0) в браузере.
                                                По производительности на моей машине сопоставимо с CPython2 в консоли — в чём-то медленнее, в чём-то даже быстрее.
                                                По вычислительным задачам, кстати js на v8 (chrome) и ionmonkey (firefox) отставание однопоточного cpu-bounded кода от c++ (портировался с помощью sed, заменой «this.» на "", «var» на «auto») всего в полтора раза. Так что jit в этих реализациях js очень неплох.
                                                  +2
                                                  Действительно. Говорим «Java» — подразумеваем «Enterprise», говорим «Enterprise» — подразумеваем «Java». ©
                                                  Устоявшееся, но крепкое как любой стереотип заблуждение. Взять тот же Android, который совсем из другой оперы.

                                                  А pypy.js, насколько я понял, пока всё же на сильно ранней стадии. Но уже сам факт наличия Python, работающего в браузере не медленнее Python в консоли — очень даже воодушевляет. Осталось скрестить его с WebGL и начать новую эпоху браузерных приложений. Если же ещё портируют Qt…
                                          +5
                                          У верблюда два горба,
                                          Потому что жизнь — борьба

                                          У каждого языка есть преимущества и недостатки. Ценной информация о недостатках становится, когда упоминаются конкретные проблемы, причины их появления и способы обхода. Из этой статьи я вынес только, что Ruby многим не угодил пользователю Artyom18. Попейте чаю с липовым цветом, что ли.
                                            +3
                                            Но вы пробовали отследить все места, куда вы добавили этот модуль?

                                            А что, греп отменили?
                                              +1
                                              Это ж топикстартеру cygwin ставить придется.
                                                0
                                                Так вроде без cygwin POSIX-зависимые методы работать не будут, т.е. вообще печально все.
                                                  0
                                                  есть msysgit который идет с sh.exe и несколькими другими стандартными утилитами, очень удобно когда приходится что то выполнять на windows.
                                                    0
                                                    Это специально подготовленный бандл cygwin'а.
                                                0
                                                Справедливости ради, переписанный кусок stdlib грепом не находится.
                                                  +1
                                                  Справедливости ради в Ruby такой функционал есть:
                                                  stackoverflow.com/questions/175655/how-to-find-where-a-method-is-defined-at-runtime

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

                                                  P.S. Лично я НИ РАЗУ не испытывал подобных проблем за многие годы знакомства с Ruby.
                                                    0
                                                    Эта функциональность бесполезна, если программист не подозревает о том, что кто-то заботливый пропатчил Net::HTTP и выкинул один code path. А вот функциональность «не мешать патчить stdlib, но ругаться при этом в stderr» мне была бы полезна — сэкономила бы не менее чем полдня только в данном случае.

                                                    З.Ы. а вообще проблема неожиданного monkeypatching существует объективно, вне зависимости от вашего опыта знакомства с руби.
                                                      0
                                                      pry в помощь. Лучше посмотреть, какие классы в геме есть, перед тем как ставить, чтобы знать где могут быть проблемы (http://rightscale.rubyforge.org/right_http_gem_doc/ вверху есть Net::HTTP). тем более в случае с таким плохо документированным гемом.

                                                      А так от манкипатчинга только польза: можно поправить за кем-то ошибки или сделать бэкпорт фичи без форка. Проблемы из-за людей :)
                                                        0
                                                        point is мне неоткуда знать заранее, что Net::HTTP или какой бы то ни было ещё класс пропатчен. затем мне и нужны помянутые warningи.
                                                        Лучше посмотреть, какие классы в геме есть, перед тем как ставить
                                                        видите ли, в обсуждаемом случае этот гем вообще никто явно не ставил, от него зависел то ли right_aws, то ли s3_backup — не помню точно.
                                                        А так от манкипатчинга только польза: можно поправить за кем-то ошибки или сделать бэкпорт фичи без форка
                                                        да, вон rightscale уже поправили. лучше форк, в том числе и чтобы не уподобляться.
                                                          0
                                                          Интересно, можно ли в Ruby пропатчить методы, используемые для патчинга, чтобы они выдавали нужные вам warningи…
                                                            0
                                                            Ну во-первых, манки-патчинг — это зло. Переписывать методы напрямую пример плохого тона.
                                                            В случае, если надо что-то переписать, есть несколько подходов:
                                                            1. Отнаследоваться от класса, который надо переписать и в нем дописать нужную логику.
                                                            2. Использовать цепочку алиасов.

                                                            И в том и в другом случае можно вывести всю необходимую информацию для дебага.

                                                            Для патчинга не использутся какие-либо методы, просто поверх включенных классов накладываются классы, которые смердживаются с базовыми и или переписывают методы или добавляют. Переписывать там, в общем-то, нечего.
                                                              0
                                                              Можно заморозить (#freeze) нужные классы и при изменении они будут кидать «RuntimeError: can't modify frozen class».
                                                              Соответственно перечислить все нэймспейсы и классы можно рекурсивно через Object.constants.
                                                              Но это только для отладки если, не думаю что в продакшне такое надо использовать.
                                                      +2
                                                      «Критикуешь — предлагай»
                                                      Какой язык программирования прямо совсем хорош-то?

                                                      P.S. Не туда попало, это автору поста вопрос, как удалить — хз
                                                        +1
                                                        Как по мне, так манкипатчить stdlib — это полная ярость. Что мешает отнаследоваться от базовых классов?
                                                        На самом деле, это легко детектится через caller() метод, там в цепочке сразу бы вылезло, откуда уши растут.
                                                      +2
                                                      С одной стороны — я согласен, с другой стороны — по-моему это троллинг. Вот честно, хочу одновременно и плюс и минус влепить.

                                                      А насчет…
                                                      Я стал относить Руби к числу бесполезных языков — таких же бесполезных, как Python или Rust. Для чего они существуют — не очень понятно


                                                      Питон существует как минимум потому что под него местами алгоритмов больше, чем под джаву даже.
                                                      Я сейчас пишу один алгоритм обсчета на базе gensim, так нужной мне функции и время выполнения, и размер занимаемой памяти — O(n), и я могу спокойно понять, какой серверный ресурс мне нужен. Взял сервер с 12 ГБ памяти и точно знаю, что мне хватит (хотя на пределе, конечно).
                                                      И этот алгоритм реализован только на питоне. Ну, на матлабе еще.
                                                      На любых других языках — памяти жрется экспоненциально, то есть если оно не умрет, сожрав полтерабайта RAM — мне еще повезет.
                                                      И нет, кэшировать на диск нельзя, хотя было бы неплохо — оно иначе год решаться будет.
                                                      Если интересно — гуглите fast low-memory SVD.
                                                        0
                                                        вот вы знаете что «Рельсы» не подходят для определенных задач, это просто отлично, рельсы и не позиционируют себя как швейцарский нож, быстрое прототипирование, быстрая разработка, много готовых компонентов — вот задача. для остального есть другие фрейм ворки.

                                                        смысл сравнивать руби и «Го» или ноду? да, руби медленный, но опять же, в об этом знают перед началом разработки и выбирают не через быстроту работы, а через быстроту разработки. Как и твиттер, запустились на рельсе, набрали просто кучу народу и перешли на другой язык, отлично.

                                                        Многопоточность, вот тут да, не совсем все хорошо.
                                                          –3
                                                          Многопоточность на самом деле, не умеет готовить тем кто особенно не нужна всем
                                                          +2
                                                          1) Как уже кучу раз писалось, не панацея. Да, удобно и быстрая разработка. Но глядя на вектор развития, все идет к тому, что постепенно мало востребованные части выносятся из основной части, что-то оптимизируется. Вводятся новые абстракции, но не пустом месте, а как результат востребованности и унификации функций вносимых различными гемами (например ActiveJob как адаптер для Resque, Sidekiq и тп). В итоге Rails на текущий момент представляет из себя некоторый остов, для приложения. Если все это не нужно, есть Sinatra. А по поводу NoSQL, так вообще не понимаю что не так. AR -> Mongoid, DM -> MongoMapper, это если по MongoDB смотреть. Да и для остальных есть как минимум драйвера.

                                                          2) Это стоит лишь принять и использовать себе на пользу. На тему private не-private cкажу больше, внутренние переменные в классе не такие уж и внутренние. К ним тоже можно не только обратиться, но и полный список получить, объявить новые и тд. Динамический язык, метапрограммирование со всем вытекающим из этого.

                                                          3) Скорость всегда не была сильной стороной Ruby, но выбирают его не за это, а за скорость разработки, гибкость, читабельность, экосистему и тд. Если есть узкие места, можно написать расширение, благо пишутся они достаточно просто (FFI, SWIG).

                                                          4) Тут старая болячка — GIL, но анонсировано, что вскоре от нее избавятся и будет нормальная многопоточность, ждем.
                                                            –6
                                                            Как по мне, так Ruby — просто еще один язык. Нет в нем вещей (особенно под веб), которые нельзя сделать на другом языке, равно как и наоборот.
                                                            Что меня сильно напрягает пока что в нем — символы. Чувакам захотелось создавать хэши как {a: «b»}, и чтобы быстрее, чем {«a» => «b»} и чуваки запилили новый тип данных по сути. Это какая-то страшная глупость, по-моему. Все эти .to_sym, .to_s и прочие .intern нехило рвут шаблон по первости.

                                                            Претензии к windows тоже не очень понятно зачем — в окошках удобно жить только с с# и прочим дотнетом, для всего остального, переносимого из unix, надо будет что-то делать руками. А зачем? Имхо, пытаться строить системы на ОС только потому, что в команде есть фанаты данной ОС и им «неудобно» — еще одна страшная глупость, прямо как символы в Ruby.
                                                              +2
                                                              Символы это не новый тип данных, если только лично для вас, а в остальном это наследие FP и Lisp (создан в 1958 году)
                                                                –2
                                                                Не очень важно, что это для внутренностей Ruby. Вопрос в практическом смысме…
                                                                  +4
                                                                  Еще раз, сиволы это очень полезный инструмент из мира функционального программирования, то что вам кажется глупостью, помогает всем остальным работать с языком и получать нужные результаты. Если вы не видите разницы между строкой и символом поизучайте вопрос его практического приминения, например в сети — www.randomhacks.net/2007/01/20/13-ways-of-looking-at-a-ruby-symbol
                                                                +1
                                                                Воспринимайте символы как константы, значения которых совпадают с их именами. Их идеально использовать в качестве флагов и ключей хешей.

                                                                Они очень быстро работают: два символа с одинаковым названием являются одним объектом, и символы не собираются сборщиком мусора. По этой причине символы не следует создавать динамически.
                                                                  0
                                                                  С 2.2 кстати можно уже и символы поручить GC на сборку, живем!
                                                                +1
                                                                Да, недостатки определенно есть. Но я предпочту руби (питон по вкусу) для работы с JSON или разбора слабоструктурированного текста. Тут динамическая природа как нельзя кстати. На яве несколько сложновато все же такие вещи делать. А вот с бинарными форматами мне больше нравится на яве работать.
                                                                Не могу так же не отметить, что у руби + рельсов довольно быстрая загрузка классов. Что-то изменить в рабочей папке с запущенным development сервером, нажать F5 — через считанные секунды виден результат (даже на большом проекте). Спасает при отладке/подгонке.
                                                                Тот же play framework + scala тяжело и нудно корячится после каждого изменения (не обладаю к сожалению мощной машиной).
                                                                Всему свое место…

                                                                Также. автор. почитайте/посмотрите Роберта «Uncle Bob» Мартина Architecture the Lost Years by Robert Martin. К нему добавить практически нечего. Тем не менее он не спешит выбрасывать руби

                                                                P.S. еще одна киллерфича руби (и подобных) языков — возможность написания DSL. Какое то время назад я понял, что это не просто buzz word. Было очень здорово предоставить удобное конфигурирование довольно сложного модуля не-руби программистам. Результат отличный.
                                                                  +2
                                                                  Выпад в сторону Rust вызывает только улыбку. На счёт Python, всем этим людям wiki.python.org/moin/OrganizationsUsingPython нужно немедленно рассказать, что Python бесполезен, они сразу же образумятся и выкинут весь свой Python на помойку.

                                                                  Если это был троллинг, то он слишком толстый. :)
                                                                    +10
                                                                    Это даже не троллинг, это просто глупость ума.
                                                                      +3
                                                                      Простите за оффтопик, но вспомнилось, как нам недавно при пересечении Грузинско-Армянской границы предлагали взять «щенка собаки»
                                                                        +1
                                                                        Могли и «щенка лисы» предложить, да
                                                                    +3
                                                                    Где тег #юмор?
                                                                      +2
                                                                      Блин, было бы это нечто в песочнице, можно было бы закопать его песочком. :-)
                                                                        +11
                                                                        Автор гениален, даже если сам этого не осознаёт. Ведь начать явно холиварную тему, в которой должны были слхестнуться рубисты, а потом одним коротким изящным абзацем подтянуть питонистов и растисты — это верх мастерства!
                                                                        • UFO just landed and posted this here
                                                                            +10
                                                                            Эзоп уже давно объяснил этот феномен
                                                                              –10
                                                                              Ох уж эти хабровчане, для которых кроме веба ничего не существует.
                                                                              За пределами веба руби никому нахер не сдался.
                                                                              А делать сайтики вообще похрен на чем, это не задача для программиста.
                                                                              Ничего серьезного на руби не пишут, потому что это не язык, а наколенная поделка.
                                                                              Язык, у которого детских болезней не меньше, чем у php.
                                                                                  0
                                                                                  Наконец то! Вспомнили Скетчап, кроссплатформенный софт, написанный на Руби — отличный пример использования языка в больших проектах. А то уже сам собирался писать :)
                                                                                  0
                                                                                  А можно поподорбнее про «детские болезни» которых не меньше чем у PHP и назовите какой язык вы считаете «достойным» и у которого конечно же нет этих болячек и написано очень много качественного кода.
                                                                                  0
                                                                                  Вот еще один интересный проект — github.com/manastech/crystal

                                                                                  Руби синтаксис и статическая компиляция с помощью LLVM. Скорость исполнения бинарников — на высоте.
                                                                                    +1
                                                                                    Если бы Руби был создан раньше Питона, Питон не был бы нужен. Если бы Питон был создан раньше Руби, Руби не был бы нужен (и да, я действительно считаю, что создание и главное использование Руби — это ошибка).

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

                                                                                    Зачем человечество потратило тысячи часов на создание велосипеда? Еще одного языка программирования, не приносящего никакой пользы (= ничего принципиально нового, сильно ускоряющего разработку, позволяющего избавиться от багов и т.п.)?

                                                                                    Так что я отчасти соглашусь с автором. Я не фанат Питона и не противник Руби, я противник того, чтобы тысячи (если не миллионы) человеко-часов уходили на создание очередного велосипеда только потому, что горстка парней из небезызвестной конторы внушила всем, что Руби — это круто.
                                                                                      +1
                                                                                      А Пепси вы пьете?
                                                                                        +2
                                                                                        Нет.
                                                                                        0
                                                                                        Не согласен, языки совсем не похожи (недавно только допиливал один проект на питоне так что ощущения свежие). В питоне куча странно работающих конструкций, заядлые питонисты находят для этих странностей объяснения, но язык в котором на каждом шаге надо помнить 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 углубляю ибо появилось несколько задач в которых он справиться лучше рубей, но в основном большую часть задач решать на рубях быстро и приятно)
                                                                                          +3
                                                                                          Поведение range — вполне документированная особенность. И вполне логичная, если мы представляем, что range заменяет нам внутренности C-подобной конструкции for(i=1; i < 4; i++).

                                                                                          Точно так же и join — объединение списка в строку — это не задача списка. Любой конечный итерируемый объект может быть объединён одним единственным методом строки. Или использован ещё как-то, если нам не строка нужна. А в каждом итерируемом классе подцеплять функцию объединения в строку — как раз не логично.

                                                                                          Точно так же и работа с CSV ( docs.python.org/3.4/library/csv.html ) и сортировка — всё это есть в Python «из коробки». Не понятно, почему Вы приводите этот пример в качестве нежданного превосходства Ruby. Python известен именно своей мощной библиотекой.

                                                                                          Точно так же про «меньшим количеством кода» — не понятно, Python достаточно лаконичный язык.

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

                                                                                          Конечно, языки не похожи, но это не значит, что один резко хуже другого, потому что стандарты другого — нравятся. Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
                                                                                            +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 именно и отличается более серьёзной продуманностью интерфейсов, имеет необычное, но гибкое и простое в использовании ООП + серьёзные возможности метапрограммирования которые позволяют писать целые языки для написания программ, и это и есть прогресс — более человекопонятные языки программирования.

                                                                                            Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
                                                                                            Так я с этим тоже согласен, но считаю что инструментов всё же должно быть несколько, серебряной пули не бывает.
                                                                                              0
                                                                                              «я знаю что range такой из-за того что он был добавлен на самой заре появления питона»

                                                                                              Тут Вы заблуждаетесь. Просто посмотрите на реализации range в других языках. У такой реализации есть причины, мало соотносящиеся с эпохой. Равно как есть альтернативные реализации с включением правой границы в диапазон.

                                                                                              «Это несложная задача, но лично мне было приятно что я увидел это в stdlib»

                                                                                              Так действительно ведь не сложная — несколько строк кода, которые легко адаптировать под собственную задачу. Ну ок, это скорее эстетический вопрос, не вижу причины спорить. Вряд ли этот отдельный пункт повлиял бы на выбор языка в целом, но Ruby — действительно язык для тех, кто ценит эстетический подход.
                                                                                                0
                                                                                                про range:
                                                                                                смотрел вот в этом посте — habrahabr.ru/company/wargaming/blog/221035/#comment_8327041
                                                                                                вообще на самом деле всё бы было не так плохо, если бы в питон добавили возможность получать последовательности и так как есть и с включением правой границы (как в руби, например, (1..3) = [1,2,3], (1...3) = [1,2])
                                                                                                  0
                                                                                                  Я думаю главный затык в развитии питона последние годы произошёл из-за того, что товарищ Ван Россум немного оторвался от сообщества. Python 3 уже больше 10 лет, но только пару лет назад с версии 3.3 вяло начался процесс миграции. И всё из-за чего? Из языка выкинули несколько базовых возможностей, которые действительно были нужны и лишь годы спустя их наличие было нехотя признано необходимостью, когда стало очевидно, что народ остаётся на 2.7 и машет ручкой разработчикам.
                                                                                                  Подобное отношение — неприятный симптом, заставляющий беспокоиться о будущем языка.
                                                                                                  А короткая форма для задания range была бы в высшей степени уместна, раз уж появились такие вещи как list comprehension.
                                                                                                    0
                                                                                                    Согласен.
                                                                                                    0
                                                                                                    Там же — habrahabr.ru/company/wargaming/blog/221035/#comment_8327961
                                                                                                    В принципе неплохо рассмотрены достоинства полуоткрытых интервалов.
                                                                                                    А насчёт то правильно, это не правильно и там-то эталон — имхо, это уже от лукавого. Так можно дойти и до эпического сражения «крестовые отвёртки vs плоские».
                                                                                                    Есть разные инструменты для разных случаев — все должны быть доступны и под рукой.
                                                                                              0
                                                                                              Выше в комменте уже написали все в защиту Питона. Я только напомню, что вопрос синтаксиса — субъективен. Мне вот не нравятся то, что в Руби многие вещи делаются символами, типа |x| вместо понятного и лаконичного for x in array.

                                                                                              Основной посыл моего первого комментария: языки действительно похожи. Если сравнивать их с Си или тем более Ассемблером, Руби и Питон выглядят как братья-близнецы. Да, кому-то не нравится родинка на щеке одного, другим не нравится прическа другого. Но это все субъективно.

                                                                                              О том и речь, что это два языка с одинаковыми областями применения, которые очень похожи по возможностям и недостаткам. Как программист, я прекрасно понимаю желание «поиграться» в еще один язык программирования, как менеджер, я осуждаю растрату ресурсов нашей цивилизации. Хотя конечно я понимаю, что все вещи в мире делаются просто ради фана. Даже работа и зарабатывание денег — просто погоня за положительными эмоциями, для обеспечения жизнедеятельности, человеку нынче много не нужно. Так что чем бы дитя не тешилось, лишь бы НТВ не смотрело.
                                                                                                0
                                                                                                " Руби многие вещи делаются символами, типа |x| вместо понятного и лаконичного for x in array."
                                                                                                Так там и такой синтаксис есть =) Только он считается некрасивым в пользу функционального
                                                                                                array.each do |x|

                                                                                                end
                                                                                                и функциональный подход совсем не чужд ООП + приучает писать более правильный и удобный код (если без фанатизма).

                                                                                                «как менеджер, я осуждаю растрату ресурсов нашей цивилизации»
                                                                                                как менеджер вы должны понимать что конкуренция подстёгивает развитие чего-либо (в данном случае языков программирования), а вот монополистам нет смысла что-то улучшать и развивать, потому радоваться такому бурному прогрессу в программировании в последние годы надо именно благодаря разнообразию ЯП.
                                                                                                Я вот догнал c++11 недавно и очень порадовался тому что с ним произошло, несколько десятков лет он топтался на месте и с 2000 года появился реальный прогресс, на нём реально стало проще и быстрее писать + меньше думать о выделении памяти. А без конкуренции писали бы на асме.
                                                                                                0
                                                                                                Вы так ругаетесь потому что, судя по всему, не осилили концепцию функционального программирования и т.н. «срезов» в начальных разделах документации, на которых базируются перечисленные конструкции, которые вы считаете «странными». Если потрудитесь понять это, то оказывается что это не странности, а очень логичные и правильные вещи. Да, с точки зрения синтаксиса непривычно, но однозначно понятнее чем тот же Lisp для людей, которые ФП до этого не видели (а с Python'ом сталкиваются люди разные, от Сишников, Паскалистов и Перловиков до Хаскелистов).

                                                                                                Ну и по поводу self и почему сделано именно так тоже можно осилить и проникнуться в документации и, например, здесь: habrahabr.ru/post/122082

                                                                                                Да, в Python много недостатков, кривостей, но то что вы перечислили — точно не проблема. Там с потоками беда и не хватает статической типизации (хотя бы опциональной), но как понимаю, Руби тут тоже ничего особо предложить не может.
                                                                                                  0
                                                                                                  Проблема в том, что в функциональных языках это смотрится гармонично. А в питоне всё является объектом что переносит нас в плоскость ООП и с точки зрения ООП строка объединяющая строки уже не смотрится логичным решением.

                                                                                                  И я не спорю что решения которые были приняты в питоне плохие или какие-то неправильные, вопрос был в том «нужен руби или нет», я считаю что однозначно нужен, ибо стартанув на 5 лет позже он дал более удобный, понятный,!!! консистентный!!! синтаксис. Там есть и функциональные возможности в полной мере, но объекты типов работают однообразно и логично с точки зрения ООП.

                                                                                                  И статическая типизация ни Python'у, ни Ruby не нужны, у них своя ниша, где они лучшие. Сложные вычислительные задачи нужно делать на более подходящих языках, связывать их есть чем(брокеры сообщений, thrift, protobuf).
                                                                                                    +1
                                                                                                    «статическая типизация ни Python'у, ни Ruby не нужны»

                                                                                                    Пример RPython и такого великолепного продукта на нём как PyPy ставит под сомнение это утверждение.
                                                                                                    И такое может быть нужно и полезно. Просто это — уже немного другой язык.

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

                                                                                                    Возвращаемся к разнообразию.
                                                                                                  0
                                                                                                  Да, насчёт нелогичности range всё же соглашусь — это да. Срезы тут не при чём, у меня в голове ваш коммент смешался с чужим. :) Но опять же — к этому легко привыкаешь. В отличие от реальных проблем Python'а, которые, кажется, решены если и будут, то тогда, когда никому не надо уже будет. :)

                                                                                                  А вот DSL в Ruby — мощная штука, конечно. Её в Python'е немного не хватает.
                                                                                                +2
                                                                                                Никогда не понимал такого рода статей, где по большей части нытье в сторону %langname%. Есть инструмент, есть задача под него, все! Зачем вы льете эту воду? Статью воспринял я как жалобы повара, который в мультиварке не может хорошо пожарить картошку.
                                                                                                  0
                                                                                                  Ну не нравится руби не используйте его )
                                                                                                  Забавляет что половина каментов — холивар уже с питонистами )
                                                                                                  • UFO just landed and posted this here
                                                                                                      +1
                                                                                                      jruby не пользовался и не вижу в нём большого смысла (на мои задачи хватает префорка воркеров с очередями задач), если прям так сильно нужна многопоточность, наверное всё таки нужно выбрать более подходящий язык программирования и инструменты.

                                                                                                      Про манкипатчинг я писал выше, для MRI с 1.9+ версии выводит файл исходника и строку по методу, этого вполне достаточно чтобы при помощи git blame надавать по рукам засранцу кто это сделал.
                                                                                                      Про наследование:
                                                                                                      self.included — это чёрная магия, за которую в production коде надо бить по рукам, она нужна для гемов, но никак не для обычного кода
                                                                                                      class << self — это хипстеры используют для своих мини проектов, так писать не нужно вообще
                                                                                                      переименование методов — не представляю как можно использовать вообще
                                                                                                      не наследуемые переменные класса — не представляю зачем это вообще может быть нужно (может быть просветите), если уж нужны они не наследыванием переносятся, а примешиванием.
                                                                                                      Вам нужен code review + надавать чрезмерным метопрограммирования по рукам(лицам) и всё будет хорошо.
                                                                                                      ДСЛ это возможность писать код который выглядит как конфиг или английский язык, да, его все реализуют каждый по своему, но базовые подходы одинаковые, опять же вопрос в реализации (когда люди охваченные маниакальным метапрограммированием начинают что-то делать, получается плохо).

                                                                                                      Судя по большинству описанных проблем у вашей команды бардак в коде и не очень понимающие концепцию Ruby программисты, что на любых языках программирования приводит к проблемам.
                                                                                                      • UFO just landed and posted this here
                                                                                                          +1
                                                                                                          Ну тут всё же проблема не в руби, а в том что им неправильно пользуются, на той же джаве без опыта намного хуже можно наговнокодить.
                                                                                                          • UFO just landed and posted this here
                                                                                                            0
                                                                                                            Ставку делали на удобство и гибкость. Всеми фичами можно и нужно пользоваться. Только не все могут нормально, поэтому и возникают потом проблемы в поддержке написанного.
                                                                                                              0
                                                                                                              Ну в командной разработке, лучше использовать те фичи, которыми умеют уверенно пользоваться все участники команды. На самом деле я не знаю языков программирования, где люди с разным уровнем погружения и понимания языка могут писать код и не иметь головняков (ну, может быть, только если их код никак не пересекается между собой, но такое нечасто бывает, наверное).
                                                                                                            0
                                                                                                            > self.included — это чёрная магия, за которую в production коде надо бить по рукам, она нужна для гемов, но никак не для обычного кода

                                                                                                            ActiveSupport::Concern вы не используете?

                                                                                                            > class << self — это хипстеры используют для своих мини проектов, так писать не нужно вообще

                                                                                                            Потом методы класса можно по файлу в неожиданных местах находить. attr_accessor через singleton_class.send пишите, или для него можно побыть хипстером?
                                                                                                              0
                                                                                                              ActiveSupport::Concern требует, чтобы был установлен ActiveSupport, а если проект не на рельсах, то не всегда он и нужен. Явно уж, только ради Concerns таскать его за собой не стоит.
                                                                                                                –2
                                                                                                                «ActiveSupport::Concern вы не используете?»
                                                                                                                Как-то не пригождается, нет надобности примешивать и методы класса и методы экземпляра одновременно, да и как-то поддерживать легче код без этой чёрной магии…

                                                                                                                Про class << self я отношусь однозначно отрицательно,
                                                                                                                то есть если вы один разрабатываете что-то — это ваше личное дело, а если разработчиков становиться >1 то возникает куча проблем:
                                                                                                                1. Методы внутри class << self нельзя тупо скопипастить
                                                                                                                2. Чтобы выяснить метод ли класса это или нет, надо скроллить туда сюда по классу, что меня лично бесит
                                                                                                                3. Не все сразу понимают эту конструкцию, потому если в команде есть новички, такие фишки противопоказаны
                                                                                                                И из плюсов — в названиях методов нужно писать на 5 буковок меньше…
                                                                                                                Мне кажеться выбор однозначный.

                                                                                                                «Потом методы класса можно по файлу в неожиданных местах находить»
                                                                                                                Для этого в компании должны быть какие-то правила, чтобы код было приятно читать. Там где я работаю мы стараемся отделять методы класса примесями, а если их немного, то просто пишем выше всех методов.

                                                                                                                " attr_accessor через singleton_class.send пишите, или для него можно побыть хипстером? "
                                                                                                                attr_accessor абсолютно не хипстерский, а очень полезный декларативный элемент объектов в Ruby, минусов его использования не знаю, если подскажете буду признателен.

                                                                                                                #send использую очень редко в основном для DSL.
                                                                                                                  0
                                                                                                                  Я про то, что можно писать

                                                                                                                  class << self
                                                                                                                    attr_accessor :x
                                                                                                                  end
                                                                                                                  
                                                                                                                  # если без class << self, то по-другому уже
                                                                                                                  singleton_class.send :attr_accessor, :x
                                                                                                                  
                                                                                                                    0
                                                                                                                    У меня коллеги сильно залипают на такие конструкции, потому тупо объявляем нужные методы с def self, либо примешиваем из модулей через extend.
                                                                                                                    В команде гибкостью языка стоит жертвовать в угоду большего взаимопонимания. Зато никто из них не жалуется что методы хрен знает откуда подключены и.т.п.
                                                                                                                      0
                                                                                                                      Это да. Я в другой ветке писал, что язык за гибкость язык винить — странно, если эта гибкость полезна. А в руби я не могу сейчас вспомнить что-то бесполезное. Дело в людях: кто-то не умеет пользоваться, кто-то пользует фичу не по назначению.

                                                                                                                      Я, все-таки, считаю, что лучше поднимать уровень понимания в команде. Ведь это довольно базовые вещи: 1 раз понял — пользуешься всегда. К тому же, код написанный не в команде тоже иногда (а может и часто) надо будет читать (фрэймворки/библиотеки). И он не всегда написан хорошо.
                                                                                                                        0
                                                                                                                        Согласен

                                                                                                          Only users with full accounts can post comments. Log in, please.