Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 142
Про то, что руби не работает под Windows не могу согласиться. Я уже не первый проект разрабатываю на RoR именно на Windows машине. Полет нормальный. Правда пришлось немного повозиться с установкой mysql2 гема, но все решаемо и гуглится за пару минут. Причем одно из приложений использовало демоны для конвертации видео файлов, но и они заработали без проблем.
Периодически приходится писать мелкие одноразовые скрипты. На 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 — отдельное развлечение.
Например, аргументы запуска скрипта в cp1251, но external charset — cp866. И выводить на консоль надо в cp866, имена файлов из аргументов якобы в cp866 надо интерпретировать как cp1251.
Ещё из забавного, одна из ruby-библиотек для работы с unicode (а надо было всего лишь делать downcase) на win работала на несколько порядков медленнее (require её занимал десятки-сотни секунд на ssd, на linux — ~100ms).
Также стоит сказать, что под win хромает поддержка библиотек для MRI на x86_64. А собирать какой-нибудь libxml2 — отдельное развлечение.
Например, аргументы запуска скрипта в cp1251, но external charset —SetConsoleCP(65001); cp866. И выводить на консоль надо в cp866, имена файлов из аргументов якобы в cp866 надо интерпретировать как cp1251.Это проблема не виндового терминала вообще говоря. Ибо есть GetCommandLineW/CommandLineToArgW, возвращающие юникодную командную строку, а вывод на терминал переключается в юникод вызовом SetConsoleOutputCP. Убогость его заключается в том, что вместо управляющих последовательностей используется набор winapi-функций, но это уже другой разговор.
Список систем, на которые портирован 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 в вычислительных задачах медленней других интерпретируемых языков? Насколько это важно на фоне синтаксических особенностей языка, удобства разработки и т.п.? Где это делает язык слабым звеном?
«Официальный интерпретатор портирован под большинство платформ, включая 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 в вычислительных задачах медленней других интерпретируемых языков? Насколько это важно на фоне синтаксических особенностей языка, удобства разработки и т.п.? Где это делает язык слабым звеном?
Смотрю я на наши графики в newrelic, и странное дело: на самых загруженных контроллерах база отъедает от рендеринга от силы процентов 20. Больше всего времени занимает сама обработка запроса, я так полагаю rack'ом.
Поэтому в моменте с затратными операциями я не соглашусь — не все так радужно в нашем королевстве, тупит руби сам по себе знатно.
Поэтому в моменте с затратными операциями я не соглашусь — не все так радужно в нашем королевстве, тупит руби сам по себе знатно.
А на чём реализован рендеринг?
Неужели никто не озаботился оптимизировать столь существенную просадку в производительности?
Или львиная доля процессорного времени уходит на работу десятков строчек контроллеров, дёргающих библиотеки и скармливающих им данные и шаблоны?
На самом деле я с Ruby и его проблемами не знаком, я сейчас работаю с Python, много лет перед этим посвятив PHP, а данная статья меня заинтересовала в плане расширения кругозора. Но мне очень странно слышать некоторые вещи, особенно учитывая что много хорошего ушло в мир именно из экосистемы Ruby, вот тот же SASS, который я сейчас использую в оригинальной реализации и на чёрный день поглядываю в сторону libsass, переписанной на C.
Неужели никто не озаботился оптимизировать столь существенную просадку в производительности?
Или львиная доля процессорного времени уходит на работу десятков строчек контроллеров, дёргающих библиотеки и скармливающих им данные и шаблоны?
На самом деле я с Ruby и его проблемами не знаком, я сейчас работаю с Python, много лет перед этим посвятив PHP, а данная статья меня заинтересовала в плане расширения кругозора. Но мне очень странно слышать некоторые вещи, особенно учитывая что много хорошего ушло в мир именно из экосистемы Ruby, вот тот же SASS, который я сейчас использую в оригинальной реализации и на чёрный день поглядываю в сторону libsass, переписанной на C.
Sass компилируется перед выкаткой, заячем библиотеку на C переписывать?
Не всегда. Есть и частные случаи, когда он компилируется на сервере.
С каждым запросом?
Зачем? Достаточно раз при изменении настроек.
Тогда зачем что-то переписывать, если это нужно 1 раз при выкатке?
О какой выкатке идёт речь?
К выкатке это не имеет никакого отношения.
Просто попытайтесь представить, что сайты не статичны и на их состояние могут влиять пользователи ;-)
К выкатке это не имеет никакого отношения.
Просто попытайтесь представить, что сайты не статичны и на их состояние могут влиять пользователи ;-)
Пытаюсь представить, каким образом пользователи могут влиять на состояние sass файлов исходниках — не выходит.
Например, щёлкая кнопочки и заполняя поля в соответствующем веб-интерфейсе настройки внешнего вида сайта и его разделов? При установке новых компонентов? При покупке и смене «темы» сайта? Все эти действия пользователь может прекрасно выполнить средствами интерфейса не привлекая разработчиков, которые пересоберут ему сайт и выкатят в продакшен статичную версию.
У вас клиенты меняют тему сайта сразу в sass? Или вы научились css из формочек в sass конвертировать? :)
Не понимаю суть вопроса. У вас разучились контроллеры писать? Или вы всегда вываливаете на клиента 100 различных инвариантов оформления?
Но я не позволяю контроллерам писать sass на диск
На самом деле даже скомпилировать sass для темы, можно и на ruby-native + скешировать результат, может быть прегенерить… А можно и compass'ом компилировать. В общем варианты есть, и тянуть сишную зависимость без надобности — это потерять часть пользователей, потому что не все понимают что нужно дополнительно установить чтобы некоторые дополнения установить.
Я просто оставлю это здесь http://en.wikipedia.org/wiki/Duck_typing
как Python или Rust
И тут я немного в выпал в осадок.
Хоть я и не являюсь фанатом Python и даже не пишу на нем, но не назову его «бесолезным».
С Rust ситуация еще интересней… Он же даже еще не зарелизился. Да и то что есть сейчас на бета релизе уже ну никак не назвать «бесолезным».
Автор не в настроении, досталось всем. ;)
Ну в Ruby, в отличие от Python, хоть нету этого кошмарного разделения на 2.x и 3.x, когда половина нужных библиотек работает только в 2.x, половина — в 3.x и крутись как хочешь (сейчас с этим уже чуток получше стало, а раньше например при попытке использовать в проекте PyQt+PyOpenGL становилось очень грустно).
Да, согласен проблема разработчиков гемов. Очень многие гемы которые используют C++ Extensions не смогут нормально сбилдиться и в худшем случаи придеться писать этот функционал самому, а если я не могу использовать помощь огромного комьюнити, тогда смысл работать с Ruby?
Конструктор — это немного не то слово, конструктор — это когда можно много чего собрать, а вот на Рельсах ты едешь в одном направлении.
NoSQL — это проблема. Придеться постоянно подставлять палочки, проверки и т.д. в тех местах где они совсем не нужны.
Поиск по проекту будет работать, когда проект не включает в себя много различных гемов и огромного колличества классов в которые уже добавлены эти модули. Если меняешь модуль то нужно убедиться, что не один из классов не слетит, иногда это бывает очень сложно.
Конструктор — это немного не то слово, конструктор — это когда можно много чего собрать, а вот на Рельсах ты едешь в одном направлении.
NoSQL — это проблема. Придеться постоянно подставлять палочки, проверки и т.д. в тех местах где они совсем не нужны.
Поиск по проекту будет работать, когда проект не включает в себя много различных гемов и огромного колличества классов в которые уже добавлены эти модули. Если меняешь модуль то нужно убедиться, что не один из классов не слетит, иногда это бывает очень сложно.
NoSQL — как раз не проблема.
Нет, в принципе, если использовать вместо AR, то может и проблема. Но это уже вопрос к разработчику — зачем использовать для CRUD задач NoSQL.
В остальном же, выпиливается AR в 4 строчки.
Нет, в принципе, если использовать вместо AR, то может и проблема. Но это уже вопрос к разработчику — зачем использовать для CRUD задач NoSQL.
В остальном же, выпиливается AR в 4 строчки.
Ни один из классов не слетит? я конечно не сильно опытный разработчик, но насколько я знаю эту проблему должны решать тесты, которые руби вроде как очень любит. И если у вас что то слетит вы увидите где конкретно это произошло после прогона тестов.
В чем проблема открыть поиск по проекту и найти все строки «include ModuleName» я тоже не знаю.
Зачем так жестоко, можно же определить/переопределить методы included/extended и там получить полную информацию начиная от имени класса где используется, заканчивая файлом и конкретной строкой. Если уж так хочется получить данную информацию.
> В чем проблема открыть поиск по проекту и найти все строки «include ModuleName» я тоже не знаю.
На самом деле, если уж автору так надо, достаточно чуть-чуть почитать про метапрограммирование в языке, определить `self.included` callback в модуле и хоть исключения бросать на попытку инклюда.
На самом деле, если уж автору так надо, достаточно чуть-чуть почитать про метапрограммирование в языке, определить `self.included` callback в модуле и хоть исключения бросать на попытку инклюда.
>>>Я стал относить Руби к числу бесполезных языков — таких же бесполезных, как Python или Rust.
Так а Python та чем не угодил?
Так а Python та чем не угодил?
Недавно начал изучать Python, но очень быстро был вынужден закончить. У меня полилась кровь из глаз, когда я увидел, что в метод первым параметром передается this, и я не смог продолжить.
Угу, только долго поработав с Pythonом понимаешь, что многое, что в других языках делается за счёт ключевых слов, в Pythone делается за счёт базовых механизмов языка. Я это к тому, что на уровне исполнения, методов в Python вообще не существует. Превращение функции в метод осуществляется за счёт механизма дескрипторов, а функция — это дескриптор! (см docs.python.org/3/howto/descriptor.html). Более того, сделать первый параметр неявным — совсем не сложно (метаклассы, либо чуть попроще — с помощью декораторов и инъекций в func_globals). Но дзен Python'a гласит: «Явное — лучше неявного». И мне кажется, именно это служит причиной явной передачи self в качестве первого аргумента.
«Пастернака не читал, но осуждаю»
Явная передача параметров очень удобна — это базируется на одном из главных принципов Питона.
Явная передача параметров очень удобна — это базируется на одном из главных принципов Питона.
Являясь тру С++ разработчиком, очень пессимистично начал изучать Python, но именно то, что в метод первым параметром передается this — это гениально! Одним этим фактом ООП превращается в АОП (Аспектно-ориентированное программирование), можно «выдрать» функционал из одного класса и засунуть в другой, можно научить утку не только лаять, но и запустить в космос парой строчек кода!
В чем же проблема как тру С++ разработчику написать функцию с именем вроде _Z7MyClass7MyMethod, которая принимает MyClass* в качестве первого параметра?
Не то чтобы не угодил, я знаю ребят которые пишут и довольны, как в прочем и на других языках. Просто я не вижу в нем смысла. Есть достаточно языков для консольных скриптов, есть достаточно языков для веб разработки.
Так что к питону нет никаких личных претензий, нормальный язык, просто в обществе принято писать новые языки программирования, которые почти такие же как остальные но там есть какая-нибудь табуляция.
Так что к питону нет никаких личных претензий, нормальный язык, просто в обществе принято писать новые языки программирования, которые почти такие же как остальные но там есть какая-нибудь табуляция.
Не могли бы Вы назвать список языков, делающих Python ненужным и бессмысленным, существовавших на момент его создания?
На момент создание уже существовал как миниму Perl, Icon, ABC и каждый можно было развивать. Но был создан новый язык (на сколько я помни он поначалу вообще был 'Hobby Language'). Так же был Bash, хоть он и был создан для Unix среды, но и питон по началу только в Unix среде использовался (вроде как только со второй версии под винду начали).
* 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 лет звучит странно.
Система типов: строгая, полиморфная
* 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 лет звучит странно.
Так разница есть и у C# с JAVA и у Objective-C с SWIFT. Но проблемы решались теже. Тем более у ABC и Python. Да, другой подход к решению, который на тот момент был удобен автору языка. Таким образом создается огромное колличество языков как публичных так и приватных. Но как мне кажется, если два языка решают одну и туже задачу то один из них явно бесполезен.
По поводу кроссплаформенности даже не спорю. Да и не говорил что это минус на то время был, просто подчеркнул факт.
По шеллу все просто. Если бы его начали полноценно портировать на другие системы (сигвин не рассматриваю), то разницы никакой небыло бы, выполняй скрипты и радуйся. Просто Питон продолжали развивать во всех направлениях, а Шелл нет.
По поводу кроссплаформенности даже не спорю. Да и не говорил что это минус на то время был, просто подчеркнул факт.
По шеллу все просто. Если бы его начали полноценно портировать на другие системы (сигвин не рассматриваю), то разницы никакой небыло бы, выполняй скрипты и радуйся. Просто Питон продолжали развивать во всех направлениях, а Шелл нет.
«если два языка решают одну и ту же задачу»
Все языки решают ту же задачу, что и ассемблер. Да и ассемблер — это лишь примочка к машинному коду.
Я правильно понимаю, что «бессмысленный новодел» 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 и знаком с людьми, которые их делали. Просто этот инструмент не самый лучший для этой и многих других целей. Это возможно, но это большинству не нужно. А то, что нужно — мы видим как лидеров индустрии.
Все языки решают ту же задачу, что и ассемблер. Да и ассемблер — это лишь примочка к машинному коду.
Я правильно понимаю, что «бессмысленный новодел» 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 и знаком с людьми, которые их делали. Просто этот инструмент не самый лучший для этой и многих других целей. Это возможно, но это большинству не нужно. А то, что нужно — мы видим как лидеров индустрии.
>Ничего дельного под Windows до сих пор не сделали.
хз, в РЖД интеграционные решения на jruby под виндой нормально работают, всякие рельсы тоже. В чем проблема-то?
>Для чего они существуют — не очень понятно
окей, лол
хз, в РЖД интеграционные решения на jruby под виндой нормально работают, всякие рельсы тоже. В чем проблема-то?
>Для чего они существуют — не очень понятно
окей, лол
ИМХО, сам Ruby — красивый язык со множеством хороших моментов, но вы правы в том, что текущая его реализация — немного лучше, чем УГ.
Всё таки рельсы я больше расцениваю как пинок для быстрого старта более-менее типичного проекта, когда вылезать за рамки прописных истин самих рельс не особо нужно, а потом, когда будет время, переписать на что-то более производительное.
Всё таки рельсы я больше расцениваю как пинок для быстрого старта более-менее типичного проекта, когда вылезать за рамки прописных истин самих рельс не особо нужно, а потом, когда будет время, переписать на что-то более производительное.
Не очень понимаю о каких выходах из рамок вы говорите. Есть же общие стандарты. Если вы хотите не REST-full API то вы в первую очередь выходите за рамки REST, а уже потом рельсы.
Во вторых, лишь ничтожно малое количество стартапов выходят в фазу «о, а у нас все получилось». И уж тем более в фазу «о, а пора снижать операционные издержки»
В третьих, и это самое главное, любая автоматизация бизнес процессов подразумевает, что эти бизнес процессы реально происходят в окружающей нас действительности. По своему опыту могу сказать, что львиная доля времени тратится на формализацию задачи. И только меньшая часть на код. Иными словами, толковых постановщиков задач и тестировщиков UX нужно больше чем разработчиков.
И если, ничего не мешаает автоматизировать процесс средствами веб, то придумать что-то лучше рельсы или питона будет очень трудно, я бы поставил на «невозможно».
Во вторых, лишь ничтожно малое количество стартапов выходят в фазу «о, а у нас все получилось». И уж тем более в фазу «о, а пора снижать операционные издержки»
В третьих, и это самое главное, любая автоматизация бизнес процессов подразумевает, что эти бизнес процессы реально происходят в окружающей нас действительности. По своему опыту могу сказать, что львиная доля времени тратится на формализацию задачи. И только меньшая часть на код. Иными словами, толковых постановщиков задач и тестировщиков UX нужно больше чем разработчиков.
И если, ничего не мешаает автоматизировать процесс средствами веб, то придумать что-то лучше рельсы или питона будет очень трудно, я бы поставил на «невозможно».
Никогда не стоит привязываться на 100% к какому-то языку, к какой-то платформе, фреймворку, т.к. король может оказаться голым.
К чему «гнать» на определённый ЯП, вообще не понятно. Просто не используй его, а в Твиттер напиши, что мол посмотрел на Руби, он мне не понравился. Пост сильно смахивает на очередное разжигание холивара, который ни к чему продуктивному не приведёт.
Автор, язык программирования — инструмент. Не более. И инструменты есть для самых разных задач. Руби не исключение. Фреймворки — вообще зло и от лукавого. Да, удобно, да, быстро, но стоит разобраться подробнее, и начинаются костыли, зависимости и велосипеды. А если всё равно это начнётся — зачем тогда начинать с фреймворков.
И да, Руби не для больших проектов. Для реально больших проектов я рекомендую Java, С и С++.
Go — хорош на многопоточности, но проигрывает C. Rust подаёт большие надежды, хотя многие скептически настроены. Python — вообще стал стандартом во многих областях программирования, но тоже не панацея от всех бед. Я был на python конференции, где тусили реально гуру. Они хвастались своими либами, наработками и реализациями идей. А в кулуарах на кофе-брейках скромно добавляли, что узкие места они всё равно дописывали на Си, так как важна была скорость и надёжность.
Повторю. Язык — инструмент программиста. Знаешь один — хорошо. Знаешь несколько — отлично. Чем больше знаний, тем больше применимости в тех или иных задачах. А вот писать ТОЛЬКО на Руби конечно же в корне не верно.
Имхо.
И да, Руби не для больших проектов. Для реально больших проектов я рекомендую Java, С и С++.
Go — хорош на многопоточности, но проигрывает C. Rust подаёт большие надежды, хотя многие скептически настроены. Python — вообще стал стандартом во многих областях программирования, но тоже не панацея от всех бед. Я был на python конференции, где тусили реально гуру. Они хвастались своими либами, наработками и реализациями идей. А в кулуарах на кофе-брейках скромно добавляли, что узкие места они всё равно дописывали на Си, так как важна была скорость и надёжность.
Повторю. Язык — инструмент программиста. Знаешь один — хорошо. Знаешь несколько — отлично. Чем больше знаний, тем больше применимости в тех или иных задачах. А вот писать ТОЛЬКО на Руби конечно же в корне не верно.
Имхо.
Одно маленькое дополнение:
> скромно добавляли, что узкие места они всё равно дописывали на Си
Мне кажется странным стесняться подобных подробностей, поскольку весь язык написан на Си, львиная доля библиотек — это обёртки вокруг сишных (а проще говоря универсальных), сама возможность оптимизировать язык за счёт переписывания узких мест на Си преподносится как достоинство языка (и вообще отсутствие такой возможности для интерпретируемого языка вызвала бы минимум удивление).
Таки это так же моё имхо, возможно гуру воспринимают это как-то иначе, но я с Вами соглашусь — «серебрянных пуль» не бывает.
> скромно добавляли, что узкие места они всё равно дописывали на Си
Мне кажется странным стесняться подобных подробностей, поскольку весь язык написан на Си, львиная доля библиотек — это обёртки вокруг сишных (а проще говоря универсальных), сама возможность оптимизировать язык за счёт переписывания узких мест на Си преподносится как достоинство языка (и вообще отсутствие такой возможности для интерпретируемого языка вызвала бы минимум удивление).
Таки это так же моё имхо, возможно гуру воспринимают это как-то иначе, но я с Вами соглашусь — «серебрянных пуль» не бывает.
поскольку весь язык написан на СиЕсть ещё pypy, написанный на rpython. Или Jython, например.
Есть, но это уже альтернативные реализации, кое-что от CPython теряющие, особенно в плане написанных на C библиотек и это головная боль и самая, что ни на есть наглядная иллюстрация невозможности «серебрянной пули».
Jython — это интеграция в экосистему энтерпрайз-софта, живущего чуть больше чем полностью во вселенной Java, но там всё своё, и «батарейки» свои, и гуру, пишущие обёртки над сишным кодом — тоже свои.
PyPy — это уже что-то вроде выхода в открытый космос — нечто грандиозное и впечатляющее, нечто большее, чем Python, особенно с того момента, когда он приютил у себя Stackless, но вот именно PyPy — и испытывает тяготы сложности интеграции с сишными либами, а по производительности, несмотря на применяющиеся техники компиляции — он до сишного кода таки не дотягивает. Свой особый мир со своими сверхвозможностями и недостатками.
На самом деле я не дошёл ещё до того, чтобы использовать PyPy, поэтому про недостатки пишу лишь понаслышке. Но думаю, тут без меня хватит тех, кто истоптал вокруг него все грабли.
Кстати, вот буквально вчера мне подбросили вот это: pypyjs.org — pypy с бэкэндом в javascript с asm.js.
Полноценный Python 2.7.8 (PyPy 2.5.0) в браузере.
По производительности на моей машине сопоставимо с CPython2 в консоли — в чём-то медленнее, в чём-то даже быстрее.
Jython — это интеграция в экосистему энтерпрайз-софта, живущего чуть больше чем полностью во вселенной Java, но там всё своё, и «батарейки» свои, и гуру, пишущие обёртки над сишным кодом — тоже свои.
PyPy — это уже что-то вроде выхода в открытый космос — нечто грандиозное и впечатляющее, нечто большее, чем Python, особенно с того момента, когда он приютил у себя Stackless, но вот именно PyPy — и испытывает тяготы сложности интеграции с сишными либами, а по производительности, несмотря на применяющиеся техники компиляции — он до сишного кода таки не дотягивает. Свой особый мир со своими сверхвозможностями и недостатками.
На самом деле я не дошёл ещё до того, чтобы использовать PyPy, поэтому про недостатки пишу лишь понаслышке. Но думаю, тут без меня хватит тех, кто истоптал вокруг него все грабли.
Кстати, вот буквально вчера мне подбросили вот это: pypyjs.org — pypy с бэкэндом в javascript с asm.js.
Полноценный Python 2.7.8 (PyPy 2.5.0) в браузере.
По производительности на моей машине сопоставимо с CPython2 в консоли — в чём-то медленнее, в чём-то даже быстрее.
Jython — это интеграция в экосистему энтерпрайз-софта, живущего чуть больше чем полностью во вселенной 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 в консоли — в чём-то медленнее, в чём-то даже быстрее.
Действительно. Говорим «Java» — подразумеваем «Enterprise», говорим «Enterprise» — подразумеваем «Java». ©
Устоявшееся, но крепкое как любой стереотип заблуждение. Взять тот же Android, который совсем из другой оперы.
А pypy.js, насколько я понял, пока всё же на сильно ранней стадии. Но уже сам факт наличия Python, работающего в браузере не медленнее Python в консоли — очень даже воодушевляет. Осталось скрестить его с WebGL и начать новую эпоху браузерных приложений. Если же ещё портируют Qt…
Устоявшееся, но крепкое как любой стереотип заблуждение. Взять тот же Android, который совсем из другой оперы.
А pypy.js, насколько я понял, пока всё же на сильно ранней стадии. Но уже сам факт наличия Python, работающего в браузере не медленнее Python в консоли — очень даже воодушевляет. Осталось скрестить его с WebGL и начать новую эпоху браузерных приложений. Если же ещё портируют Qt…
Но вы пробовали отследить все места, куда вы добавили этот модуль?
А что, греп отменили?
А что, греп отменили?
Это ж топикстартеру cygwin ставить придется.
Справедливости ради в Ruby такой функционал есть:
stackoverflow.com/questions/175655/how-to-find-where-a-method-is-defined-at-runtime
Правда сама проблема высосана из пальца, в каком языке с примесями подобной сложности нет? (и есть такой функционал по поиску исходных кодов как в Ruby?)
P.S. Лично я НИ РАЗУ не испытывал подобных проблем за многие годы знакомства с Ruby.
stackoverflow.com/questions/175655/how-to-find-where-a-method-is-defined-at-runtime
Правда сама проблема высосана из пальца, в каком языке с примесями подобной сложности нет? (и есть такой функционал по поиску исходных кодов как в Ruby?)
P.S. Лично я НИ РАЗУ не испытывал подобных проблем за многие годы знакомства с Ruby.
pry в помощь. Лучше посмотреть, какие классы в геме есть, перед тем как ставить, чтобы знать где могут быть проблемы (http://rightscale.rubyforge.org/right_http_gem_doc/ вверху есть Net::HTTP). тем более в случае с таким плохо документированным гемом.
А так от манкипатчинга только польза: можно поправить за кем-то ошибки или сделать бэкпорт фичи без форка. Проблемы из-за людей :)
А так от манкипатчинга только польза: можно поправить за кем-то ошибки или сделать бэкпорт фичи без форка. Проблемы из-за людей :)
Интересно, можно ли в Ruby пропатчить методы, используемые для патчинга, чтобы они выдавали нужные вам warningи…
Ну во-первых, манки-патчинг — это зло. Переписывать методы напрямую пример плохого тона.
В случае, если надо что-то переписать, есть несколько подходов:
1. Отнаследоваться от класса, который надо переписать и в нем дописать нужную логику.
2. Использовать цепочку алиасов.
И в том и в другом случае можно вывести всю необходимую информацию для дебага.
Для патчинга не использутся какие-либо методы, просто поверх включенных классов накладываются классы, которые смердживаются с базовыми и или переписывают методы или добавляют. Переписывать там, в общем-то, нечего.
В случае, если надо что-то переписать, есть несколько подходов:
1. Отнаследоваться от класса, который надо переписать и в нем дописать нужную логику.
2. Использовать цепочку алиасов.
И в том и в другом случае можно вывести всю необходимую информацию для дебага.
Для патчинга не использутся какие-либо методы, просто поверх включенных классов накладываются классы, которые смердживаются с базовыми и или переписывают методы или добавляют. Переписывать там, в общем-то, нечего.
Можно заморозить (#freeze) нужные классы и при изменении они будут кидать «RuntimeError: can't modify frozen class».
Соответственно перечислить все нэймспейсы и классы можно рекурсивно через Object.constants.
Но это только для отладки если, не думаю что в продакшне такое надо использовать.
Соответственно перечислить все нэймспейсы и классы можно рекурсивно через Object.constants.
Но это только для отладки если, не думаю что в продакшне такое надо использовать.
«Критикуешь — предлагай»
Какой язык программирования прямо совсем хорош-то?
P.S. Не туда попало, это автору поста вопрос, как удалить — хз
Какой язык программирования прямо совсем хорош-то?
P.S. Не туда попало, это автору поста вопрос, как удалить — хз
Как по мне, так манкипатчить stdlib — это полная ярость. Что мешает отнаследоваться от базовых классов?
На самом деле, это легко детектится через caller() метод, там в цепочке сразу бы вылезло, откуда уши растут.
На самом деле, это легко детектится через caller() метод, там в цепочке сразу бы вылезло, откуда уши растут.
С одной стороны — я согласен, с другой стороны — по-моему это троллинг. Вот честно, хочу одновременно и плюс и минус влепить.
А насчет…
Питон существует как минимум потому что под него местами алгоритмов больше, чем под джаву даже.
Я сейчас пишу один алгоритм обсчета на базе gensim, так нужной мне функции и время выполнения, и размер занимаемой памяти — O(n), и я могу спокойно понять, какой серверный ресурс мне нужен. Взял сервер с 12 ГБ памяти и точно знаю, что мне хватит (хотя на пределе, конечно).
И этот алгоритм реализован только на питоне. Ну, на матлабе еще.
На любых других языках — памяти жрется экспоненциально, то есть если оно не умрет, сожрав полтерабайта RAM — мне еще повезет.
И нет, кэшировать на диск нельзя, хотя было бы неплохо — оно иначе год решаться будет.
Если интересно — гуглите fast low-memory SVD.
А насчет…
Я стал относить Руби к числу бесполезных языков — таких же бесполезных, как Python или Rust. Для чего они существуют — не очень понятно
Питон существует как минимум потому что под него местами алгоритмов больше, чем под джаву даже.
Я сейчас пишу один алгоритм обсчета на базе gensim, так нужной мне функции и время выполнения, и размер занимаемой памяти — O(n), и я могу спокойно понять, какой серверный ресурс мне нужен. Взял сервер с 12 ГБ памяти и точно знаю, что мне хватит (хотя на пределе, конечно).
И этот алгоритм реализован только на питоне. Ну, на матлабе еще.
На любых других языках — памяти жрется экспоненциально, то есть если оно не умрет, сожрав полтерабайта RAM — мне еще повезет.
И нет, кэшировать на диск нельзя, хотя было бы неплохо — оно иначе год решаться будет.
Если интересно — гуглите fast low-memory SVD.
вот вы знаете что «Рельсы» не подходят для определенных задач, это просто отлично, рельсы и не позиционируют себя как швейцарский нож, быстрое прототипирование, быстрая разработка, много готовых компонентов — вот задача. для остального есть другие фрейм ворки.
смысл сравнивать руби и «Го» или ноду? да, руби медленный, но опять же, в об этом знают перед началом разработки и выбирают не через быстроту работы, а через быстроту разработки. Как и твиттер, запустились на рельсе, набрали просто кучу народу и перешли на другой язык, отлично.
Многопоточность, вот тут да, не совсем все хорошо.
смысл сравнивать руби и «Го» или ноду? да, руби медленный, но опять же, в об этом знают перед началом разработки и выбирают не через быстроту работы, а через быстроту разработки. Как и твиттер, запустились на рельсе, набрали просто кучу народу и перешли на другой язык, отлично.
Многопоточность, вот тут да, не совсем все хорошо.
1) Как уже кучу раз писалось, не панацея. Да, удобно и быстрая разработка. Но глядя на вектор развития, все идет к тому, что постепенно мало востребованные части выносятся из основной части, что-то оптимизируется. Вводятся новые абстракции, но не пустом месте, а как результат востребованности и унификации функций вносимых различными гемами (например ActiveJob как адаптер для Resque, Sidekiq и тп). В итоге Rails на текущий момент представляет из себя некоторый остов, для приложения. Если все это не нужно, есть Sinatra. А по поводу NoSQL, так вообще не понимаю что не так. AR -> Mongoid, DM -> MongoMapper, это если по MongoDB смотреть. Да и для остальных есть как минимум драйвера.
2) Это стоит лишь принять и использовать себе на пользу. На тему private не-private cкажу больше, внутренние переменные в классе не такие уж и внутренние. К ним тоже можно не только обратиться, но и полный список получить, объявить новые и тд. Динамический язык, метапрограммирование со всем вытекающим из этого.
3) Скорость всегда не была сильной стороной Ruby, но выбирают его не за это, а за скорость разработки, гибкость, читабельность, экосистему и тд. Если есть узкие места, можно написать расширение, благо пишутся они достаточно просто (FFI, SWIG).
4) Тут старая болячка — GIL, но анонсировано, что вскоре от нее избавятся и будет нормальная многопоточность, ждем.
2) Это стоит лишь принять и использовать себе на пользу. На тему private не-private cкажу больше, внутренние переменные в классе не такие уж и внутренние. К ним тоже можно не только обратиться, но и полный список получить, объявить новые и тд. Динамический язык, метапрограммирование со всем вытекающим из этого.
3) Скорость всегда не была сильной стороной Ruby, но выбирают его не за это, а за скорость разработки, гибкость, читабельность, экосистему и тд. Если есть узкие места, можно написать расширение, благо пишутся они достаточно просто (FFI, SWIG).
4) Тут старая болячка — GIL, но анонсировано, что вскоре от нее избавятся и будет нормальная многопоточность, ждем.
Как по мне, так Ruby — просто еще один язык. Нет в нем вещей (особенно под веб), которые нельзя сделать на другом языке, равно как и наоборот.
Что меня сильно напрягает пока что в нем — символы. Чувакам захотелось создавать хэши как {a: «b»}, и чтобы быстрее, чем {«a» => «b»} и чуваки запилили новый тип данных по сути. Это какая-то страшная глупость, по-моему. Все эти .to_sym, .to_s и прочие .intern нехило рвут шаблон по первости.
Претензии к windows тоже не очень понятно зачем — в окошках удобно жить только с с# и прочим дотнетом, для всего остального, переносимого из unix, надо будет что-то делать руками. А зачем? Имхо, пытаться строить системы на ОС только потому, что в команде есть фанаты данной ОС и им «неудобно» — еще одна страшная глупость, прямо как символы в Ruby.
Что меня сильно напрягает пока что в нем — символы. Чувакам захотелось создавать хэши как {a: «b»}, и чтобы быстрее, чем {«a» => «b»} и чуваки запилили новый тип данных по сути. Это какая-то страшная глупость, по-моему. Все эти .to_sym, .to_s и прочие .intern нехило рвут шаблон по первости.
Претензии к windows тоже не очень понятно зачем — в окошках удобно жить только с с# и прочим дотнетом, для всего остального, переносимого из unix, надо будет что-то делать руками. А зачем? Имхо, пытаться строить системы на ОС только потому, что в команде есть фанаты данной ОС и им «неудобно» — еще одна страшная глупость, прямо как символы в Ruby.
Символы это не новый тип данных, если только лично для вас, а в остальном это наследие FP и Lisp (создан в 1958 году)
Не очень важно, что это для внутренностей Ruby. Вопрос в практическом смысме…
Еще раз, сиволы это очень полезный инструмент из мира функционального программирования, то что вам кажется глупостью, помогает всем остальным работать с языком и получать нужные результаты. Если вы не видите разницы между строкой и символом поизучайте вопрос его практического приминения, например в сети — www.randomhacks.net/2007/01/20/13-ways-of-looking-at-a-ruby-symbol
Воспринимайте символы как константы, значения которых совпадают с их именами. Их идеально использовать в качестве флагов и ключей хешей.
Они очень быстро работают: два символа с одинаковым названием являются одним объектом, и символы не собираются сборщиком мусора. По этой причине символы не следует создавать динамически.
Они очень быстро работают: два символа с одинаковым названием являются одним объектом, и символы не собираются сборщиком мусора. По этой причине символы не следует создавать динамически.
Да, недостатки определенно есть. Но я предпочту руби (питон по вкусу) для работы с JSON или разбора слабоструктурированного текста. Тут динамическая природа как нельзя кстати. На яве несколько сложновато все же такие вещи делать. А вот с бинарными форматами мне больше нравится на яве работать.
Не могу так же не отметить, что у руби + рельсов довольно быстрая загрузка классов. Что-то изменить в рабочей папке с запущенным development сервером, нажать F5 — через считанные секунды виден результат (даже на большом проекте). Спасает при отладке/подгонке.
Тот же play framework + scala тяжело и нудно корячится после каждого изменения (не обладаю к сожалению мощной машиной).
Всему свое место…
Также. автор. почитайте/посмотрите Роберта «Uncle Bob» Мартина Architecture the Lost Years by Robert Martin. К нему добавить практически нечего. Тем не менее он не спешит выбрасывать руби
P.S. еще одна киллерфича руби (и подобных) языков — возможность написания DSL. Какое то время назад я понял, что это не просто buzz word. Было очень здорово предоставить удобное конфигурирование довольно сложного модуля не-руби программистам. Результат отличный.
Не могу так же не отметить, что у руби + рельсов довольно быстрая загрузка классов. Что-то изменить в рабочей папке с запущенным development сервером, нажать F5 — через считанные секунды виден результат (даже на большом проекте). Спасает при отладке/подгонке.
Тот же play framework + scala тяжело и нудно корячится после каждого изменения (не обладаю к сожалению мощной машиной).
Всему свое место…
Также. автор. почитайте/посмотрите Роберта «Uncle Bob» Мартина Architecture the Lost Years by Robert Martin. К нему добавить практически нечего. Тем не менее он не спешит выбрасывать руби
P.S. еще одна киллерфича руби (и подобных) языков — возможность написания DSL. Какое то время назад я понял, что это не просто buzz word. Было очень здорово предоставить удобное конфигурирование довольно сложного модуля не-руби программистам. Результат отличный.
Выпад в сторону Rust вызывает только улыбку. На счёт Python, всем этим людям wiki.python.org/moin/OrganizationsUsingPython нужно немедленно рассказать, что Python бесполезен, они сразу же образумятся и выкинут весь свой Python на помойку.
Если это был троллинг, то он слишком толстый. :)
Если это был троллинг, то он слишком толстый. :)
Где тег #юмор?
Блин, было бы это нечто в песочнице, можно было бы закопать его песочком. :-)
Автор гениален, даже если сам этого не осознаёт. Ведь начать явно холиварную тему, в которой должны были слхестнуться рубисты, а потом одним коротким изящным абзацем подтянуть питонистов и растисты — это верх мастерства!
Эзоп уже давно объяснил этот феномен
Ох уж эти хабровчане, для которых кроме веба ничего не существует.
За пределами веба руби никому нахер не сдался.
А делать сайтики вообще похрен на чем, это не задача для программиста.
Ничего серьезного на руби не пишут, потому что это не язык, а наколенная поделка.
Язык, у которого детских болезней не меньше, чем у php.
За пределами веба руби никому нахер не сдался.
А делать сайтики вообще похрен на чем, это не задача для программиста.
Ничего серьезного на руби не пишут, потому что это не язык, а наколенная поделка.
Язык, у которого детских болезней не меньше, чем у php.
Вот еще один интересный проект — github.com/manastech/crystal
Руби синтаксис и статическая компиляция с помощью LLVM. Скорость исполнения бинарников — на высоте.
Руби синтаксис и статическая компиляция с помощью LLVM. Скорость исполнения бинарников — на высоте.
Если бы Руби был создан раньше Питона, Питон не был бы нужен. Если бы Питон был создан раньше Руби, Руби не был бы нужен (и да, я действительно считаю, что создание и главное использование Руби — это ошибка).
Поясню. Языки очень похожи, фреймворки тоже, библиотеки тоже. Ну да, есть конечно нюансы, но в целом, за исключением мелких деталей, все очень похожее.
Зачем человечество потратило тысячи часов на создание велосипеда? Еще одного языка программирования, не приносящего никакой пользы (= ничего принципиально нового, сильно ускоряющего разработку, позволяющего избавиться от багов и т.п.)?
Так что я отчасти соглашусь с автором. Я не фанат Питона и не противник Руби, я противник того, чтобы тысячи (если не миллионы) человеко-часов уходили на создание очередного велосипеда только потому, что горстка парней из небезызвестной конторы внушила всем, что Руби — это круто.
Поясню. Языки очень похожи, фреймворки тоже, библиотеки тоже. Ну да, есть конечно нюансы, но в целом, за исключением мелких деталей, все очень похожее.
Зачем человечество потратило тысячи часов на создание велосипеда? Еще одного языка программирования, не приносящего никакой пользы (= ничего принципиально нового, сильно ускоряющего разработку, позволяющего избавиться от багов и т.п.)?
Так что я отчасти соглашусь с автором. Я не фанат Питона и не противник Руби, я противник того, чтобы тысячи (если не миллионы) человеко-часов уходили на создание очередного велосипеда только потому, что горстка парней из небезызвестной конторы внушила всем, что Руби — это круто.
Не согласен, языки совсем не похожи (недавно только допиливал один проект на питоне так что ощущения свежие). В питоне куча странно работающих конструкций, заядлые питонисты находят для этих странностей объяснения, но язык в котором на каждом шаге надо помнить 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 углубляю ибо появилось несколько задач в которых он справиться лучше рубей, но в основном большую часть задач решать на рубях быстро и приятно)
В 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 углубляю ибо появилось несколько задач в которых он справиться лучше рубей, но в основном большую часть задач решать на рубях быстро и приятно)
Поведение range — вполне документированная особенность. И вполне логичная, если мы представляем, что range заменяет нам внутренности C-подобной конструкции for(i=1; i < 4; i++).
Точно так же и join — объединение списка в строку — это не задача списка. Любой конечный итерируемый объект может быть объединён одним единственным методом строки. Или использован ещё как-то, если нам не строка нужна. А в каждом итерируемом классе подцеплять функцию объединения в строку — как раз не логично.
Точно так же и работа с CSV ( docs.python.org/3.4/library/csv.html ) и сортировка — всё это есть в Python «из коробки». Не понятно, почему Вы приводите этот пример в качестве нежданного превосходства Ruby. Python известен именно своей мощной библиотекой.
Точно так же про «меньшим количеством кода» — не понятно, Python достаточно лаконичный язык.
Когда я начинал изучать питон, мне тоже много вещей казались нелогичными и сбивающими с толку, потому что в других языках, которые я использовал до этого, всё делалось не так. Но это лишь вопрос привычки и знания — узнав как всё это использовать, обнаруживаешь логичность и продуманность. Питон, конечно, не идеальный язык, есть за что его ругать, но вот вышеперечисленное — явно не повод.
Конечно, языки не похожи, но это не значит, что один резко хуже другого, потому что стандарты другого — нравятся. Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
Точно так же и join — объединение списка в строку — это не задача списка. Любой конечный итерируемый объект может быть объединён одним единственным методом строки. Или использован ещё как-то, если нам не строка нужна. А в каждом итерируемом классе подцеплять функцию объединения в строку — как раз не логично.
Точно так же и работа с CSV ( docs.python.org/3.4/library/csv.html ) и сортировка — всё это есть в Python «из коробки». Не понятно, почему Вы приводите этот пример в качестве нежданного превосходства Ruby. Python известен именно своей мощной библиотекой.
Точно так же про «меньшим количеством кода» — не понятно, Python достаточно лаконичный язык.
Когда я начинал изучать питон, мне тоже много вещей казались нелогичными и сбивающими с толку, потому что в других языках, которые я использовал до этого, всё делалось не так. Но это лишь вопрос привычки и знания — узнав как всё это использовать, обнаруживаешь логичность и продуманность. Питон, конечно, не идеальный язык, есть за что его ругать, но вот вышеперечисленное — явно не повод.
Конечно, языки не похожи, но это не значит, что один резко хуже другого, потому что стандарты другого — нравятся. Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
Поведение 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 именно и отличается более серьёзной продуманностью интерфейсов, имеет необычное, но гибкое и простое в использовании ООП + серьёзные возможности метапрограммирования которые позволяют писать целые языки для написания программ, и это и есть прогресс — более человекопонятные языки программирования.
Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
Так я с этим тоже согласен, но считаю что инструментов всё же должно быть несколько, серебряной пули не бывает.
Ну я вот когда хочу получить числовую последовательность не хочу думать с 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 именно и отличается более серьёзной продуманностью интерфейсов, имеет необычное, но гибкое и простое в использовании ООП + серьёзные возможности метапрограммирования которые позволяют писать целые языки для написания программ, и это и есть прогресс — более человекопонятные языки программирования.
Для этого и нужно разнообразие — каждый находит себе инструмент, идеально лежащий в руке.
Так я с этим тоже согласен, но считаю что инструментов всё же должно быть несколько, серебряной пули не бывает.
«я знаю что range такой из-за того что он был добавлен на самой заре появления питона»
Тут Вы заблуждаетесь. Просто посмотрите на реализации range в других языках. У такой реализации есть причины, мало соотносящиеся с эпохой. Равно как есть альтернативные реализации с включением правой границы в диапазон.
«Это несложная задача, но лично мне было приятно что я увидел это в stdlib»
Так действительно ведь не сложная — несколько строк кода, которые легко адаптировать под собственную задачу. Ну ок, это скорее эстетический вопрос, не вижу причины спорить. Вряд ли этот отдельный пункт повлиял бы на выбор языка в целом, но Ruby — действительно язык для тех, кто ценит эстетический подход.
Тут Вы заблуждаетесь. Просто посмотрите на реализации range в других языках. У такой реализации есть причины, мало соотносящиеся с эпохой. Равно как есть альтернативные реализации с включением правой границы в диапазон.
«Это несложная задача, но лично мне было приятно что я увидел это в stdlib»
Так действительно ведь не сложная — несколько строк кода, которые легко адаптировать под собственную задачу. Ну ок, это скорее эстетический вопрос, не вижу причины спорить. Вряд ли этот отдельный пункт повлиял бы на выбор языка в целом, но Ruby — действительно язык для тех, кто ценит эстетический подход.
про range:
смотрел вот в этом посте — habrahabr.ru/company/wargaming/blog/221035/#comment_8327041
вообще на самом деле всё бы было не так плохо, если бы в питон добавили возможность получать последовательности и так как есть и с включением правой границы (как в руби, например, (1..3) = [1,2,3], (1...3) = [1,2])
смотрел вот в этом посте — habrahabr.ru/company/wargaming/blog/221035/#comment_8327041
вообще на самом деле всё бы было не так плохо, если бы в питон добавили возможность получать последовательности и так как есть и с включением правой границы (как в руби, например, (1..3) = [1,2,3], (1...3) = [1,2])
Я думаю главный затык в развитии питона последние годы произошёл из-за того, что товарищ Ван Россум немного оторвался от сообщества. Python 3 уже больше 10 лет, но только пару лет назад с версии 3.3 вяло начался процесс миграции. И всё из-за чего? Из языка выкинули несколько базовых возможностей, которые действительно были нужны и лишь годы спустя их наличие было нехотя признано необходимостью, когда стало очевидно, что народ остаётся на 2.7 и машет ручкой разработчикам.
Подобное отношение — неприятный симптом, заставляющий беспокоиться о будущем языка.
А короткая форма для задания range была бы в высшей степени уместна, раз уж появились такие вещи как list comprehension.
Подобное отношение — неприятный симптом, заставляющий беспокоиться о будущем языка.
А короткая форма для задания range была бы в высшей степени уместна, раз уж появились такие вещи как list comprehension.
Там же — habrahabr.ru/company/wargaming/blog/221035/#comment_8327961
В принципе неплохо рассмотрены достоинства полуоткрытых интервалов.
А насчёт то правильно, это не правильно и там-то эталон — имхо, это уже от лукавого. Так можно дойти и до эпического сражения «крестовые отвёртки vs плоские».
Есть разные инструменты для разных случаев — все должны быть доступны и под рукой.
В принципе неплохо рассмотрены достоинства полуоткрытых интервалов.
А насчёт то правильно, это не правильно и там-то эталон — имхо, это уже от лукавого. Так можно дойти и до эпического сражения «крестовые отвёртки vs плоские».
Есть разные инструменты для разных случаев — все должны быть доступны и под рукой.
Выше в комменте уже написали все в защиту Питона. Я только напомню, что вопрос синтаксиса — субъективен. Мне вот не нравятся то, что в Руби многие вещи делаются символами, типа |x| вместо понятного и лаконичного for x in array.
Основной посыл моего первого комментария: языки действительно похожи. Если сравнивать их с Си или тем более Ассемблером, Руби и Питон выглядят как братья-близнецы. Да, кому-то не нравится родинка на щеке одного, другим не нравится прическа другого. Но это все субъективно.
О том и речь, что это два языка с одинаковыми областями применения, которые очень похожи по возможностям и недостаткам. Как программист, я прекрасно понимаю желание «поиграться» в еще один язык программирования, как менеджер, я осуждаю растрату ресурсов нашей цивилизации. Хотя конечно я понимаю, что все вещи в мире делаются просто ради фана. Даже работа и зарабатывание денег — просто погоня за положительными эмоциями, для обеспечения жизнедеятельности, человеку нынче много не нужно. Так что чем бы дитя не тешилось, лишь бы НТВ не смотрело.
Основной посыл моего первого комментария: языки действительно похожи. Если сравнивать их с Си или тем более Ассемблером, Руби и Питон выглядят как братья-близнецы. Да, кому-то не нравится родинка на щеке одного, другим не нравится прическа другого. Но это все субъективно.
О том и речь, что это два языка с одинаковыми областями применения, которые очень похожи по возможностям и недостаткам. Как программист, я прекрасно понимаю желание «поиграться» в еще один язык программирования, как менеджер, я осуждаю растрату ресурсов нашей цивилизации. Хотя конечно я понимаю, что все вещи в мире делаются просто ради фана. Даже работа и зарабатывание денег — просто погоня за положительными эмоциями, для обеспечения жизнедеятельности, человеку нынче много не нужно. Так что чем бы дитя не тешилось, лишь бы НТВ не смотрело.
" Руби многие вещи делаются символами, типа |x| вместо понятного и лаконичного for x in array."
Так там и такой синтаксис есть =) Только он считается некрасивым в пользу функционального
array.each do |x|
…
end
и функциональный подход совсем не чужд ООП + приучает писать более правильный и удобный код (если без фанатизма).
«как менеджер, я осуждаю растрату ресурсов нашей цивилизации»
как менеджер вы должны понимать что конкуренция подстёгивает развитие чего-либо (в данном случае языков программирования), а вот монополистам нет смысла что-то улучшать и развивать, потому радоваться такому бурному прогрессу в программировании в последние годы надо именно благодаря разнообразию ЯП.
Я вот догнал c++11 недавно и очень порадовался тому что с ним произошло, несколько десятков лет он топтался на месте и с 2000 года появился реальный прогресс, на нём реально стало проще и быстрее писать + меньше думать о выделении памяти. А без конкуренции писали бы на асме.
Так там и такой синтаксис есть =) Только он считается некрасивым в пользу функционального
array.each do |x|
…
end
и функциональный подход совсем не чужд ООП + приучает писать более правильный и удобный код (если без фанатизма).
«как менеджер, я осуждаю растрату ресурсов нашей цивилизации»
как менеджер вы должны понимать что конкуренция подстёгивает развитие чего-либо (в данном случае языков программирования), а вот монополистам нет смысла что-то улучшать и развивать, потому радоваться такому бурному прогрессу в программировании в последние годы надо именно благодаря разнообразию ЯП.
Я вот догнал c++11 недавно и очень порадовался тому что с ним произошло, несколько десятков лет он топтался на месте и с 2000 года появился реальный прогресс, на нём реально стало проще и быстрее писать + меньше думать о выделении памяти. А без конкуренции писали бы на асме.
Вы так ругаетесь потому что, судя по всему, не осилили концепцию функционального программирования и т.н. «срезов» в начальных разделах документации, на которых базируются перечисленные конструкции, которые вы считаете «странными». Если потрудитесь понять это, то оказывается что это не странности, а очень логичные и правильные вещи. Да, с точки зрения синтаксиса непривычно, но однозначно понятнее чем тот же Lisp для людей, которые ФП до этого не видели (а с Python'ом сталкиваются люди разные, от Сишников, Паскалистов и Перловиков до Хаскелистов).
Ну и по поводу self и почему сделано именно так тоже можно осилить и проникнуться в документации и, например, здесь: habrahabr.ru/post/122082
Да, в Python много недостатков, кривостей, но то что вы перечислили — точно не проблема. Там с потоками беда и не хватает статической типизации (хотя бы опциональной), но как понимаю, Руби тут тоже ничего особо предложить не может.
Ну и по поводу self и почему сделано именно так тоже можно осилить и проникнуться в документации и, например, здесь: habrahabr.ru/post/122082
Да, в Python много недостатков, кривостей, но то что вы перечислили — точно не проблема. Там с потоками беда и не хватает статической типизации (хотя бы опциональной), но как понимаю, Руби тут тоже ничего особо предложить не может.
Проблема в том, что в функциональных языках это смотрится гармонично. А в питоне всё является объектом что переносит нас в плоскость ООП и с точки зрения ООП строка объединяющая строки уже не смотрится логичным решением.
И я не спорю что решения которые были приняты в питоне плохие или какие-то неправильные, вопрос был в том «нужен руби или нет», я считаю что однозначно нужен, ибо стартанув на 5 лет позже он дал более удобный, понятный,!!! консистентный!!! синтаксис. Там есть и функциональные возможности в полной мере, но объекты типов работают однообразно и логично с точки зрения ООП.
И статическая типизация ни Python'у, ни Ruby не нужны, у них своя ниша, где они лучшие. Сложные вычислительные задачи нужно делать на более подходящих языках, связывать их есть чем(брокеры сообщений, thrift, protobuf).
И я не спорю что решения которые были приняты в питоне плохие или какие-то неправильные, вопрос был в том «нужен руби или нет», я считаю что однозначно нужен, ибо стартанув на 5 лет позже он дал более удобный, понятный,!!! консистентный!!! синтаксис. Там есть и функциональные возможности в полной мере, но объекты типов работают однообразно и логично с точки зрения ООП.
И статическая типизация ни Python'у, ни Ruby не нужны, у них своя ниша, где они лучшие. Сложные вычислительные задачи нужно делать на более подходящих языках, связывать их есть чем(брокеры сообщений, thrift, protobuf).
«статическая типизация ни Python'у, ни Ruby не нужны»
Пример RPython и такого великолепного продукта на нём как PyPy ставит под сомнение это утверждение.
И такое может быть нужно и полезно. Просто это — уже немного другой язык.
Наконец, не всё ведь сводится к «числодробилкам». Здесь просто очередной компромисс между скоростью работы и скоростью разработки. Немного потеряв в скорости разработки можно получить хороший прирост в скорости работы на некоторых задачах.
Возвращаемся к разнообразию.
Пример RPython и такого великолепного продукта на нём как PyPy ставит под сомнение это утверждение.
И такое может быть нужно и полезно. Просто это — уже немного другой язык.
Наконец, не всё ведь сводится к «числодробилкам». Здесь просто очередной компромисс между скоростью работы и скоростью разработки. Немного потеряв в скорости разработки можно получить хороший прирост в скорости работы на некоторых задачах.
Возвращаемся к разнообразию.
Да, насчёт нелогичности range всё же соглашусь — это да. Срезы тут не при чём, у меня в голове ваш коммент смешался с чужим. :) Но опять же — к этому легко привыкаешь. В отличие от реальных проблем Python'а, которые, кажется, решены если и будут, то тогда, когда никому не надо уже будет. :)
А вот DSL в Ruby — мощная штука, конечно. Её в Python'е немного не хватает.
А вот DSL в Ruby — мощная штука, конечно. Её в Python'е немного не хватает.
Никогда не понимал такого рода статей, где по большей части нытье в сторону %langname%. Есть инструмент, есть задача под него, все! Зачем вы льете эту воду? Статью воспринял я как жалобы повара, который в мультиварке не может хорошо пожарить картошку.
Ну не нравится руби не используйте его )
Забавляет что половина каментов — холивар уже с питонистами )
Забавляет что половина каментов — холивар уже с питонистами )
jruby не пользовался и не вижу в нём большого смысла (на мои задачи хватает префорка воркеров с очередями задач), если прям так сильно нужна многопоточность, наверное всё таки нужно выбрать более подходящий язык программирования и инструменты.
Про манкипатчинг я писал выше, для MRI с 1.9+ версии выводит файл исходника и строку по методу, этого вполне достаточно чтобы при помощи git blame надавать по рукам засранцу кто это сделал.
Про наследование:
self.included — это чёрная магия, за которую в production коде надо бить по рукам, она нужна для гемов, но никак не для обычного кода
class << self — это хипстеры используют для своих мини проектов, так писать не нужно вообще
переименование методов — не представляю как можно использовать вообще
не наследуемые переменные класса — не представляю зачем это вообще может быть нужно (может быть просветите), если уж нужны они не наследыванием переносятся, а примешиванием.
Вам нужен code review + надавать чрезмерным метопрограммирования по рукам(лицам) и всё будет хорошо.
ДСЛ это возможность писать код который выглядит как конфиг или английский язык, да, его все реализуют каждый по своему, но базовые подходы одинаковые, опять же вопрос в реализации (когда люди охваченные маниакальным метапрограммированием начинают что-то делать, получается плохо).
Судя по большинству описанных проблем у вашей команды бардак в коде и не очень понимающие концепцию Ruby программисты, что на любых языках программирования приводит к проблемам.
Про манкипатчинг я писал выше, для MRI с 1.9+ версии выводит файл исходника и строку по методу, этого вполне достаточно чтобы при помощи git blame надавать по рукам засранцу кто это сделал.
Про наследование:
self.included — это чёрная магия, за которую в production коде надо бить по рукам, она нужна для гемов, но никак не для обычного кода
class << self — это хипстеры используют для своих мини проектов, так писать не нужно вообще
переименование методов — не представляю как можно использовать вообще
не наследуемые переменные класса — не представляю зачем это вообще может быть нужно (может быть просветите), если уж нужны они не наследыванием переносятся, а примешиванием.
Вам нужен code review + надавать чрезмерным метопрограммирования по рукам(лицам) и всё будет хорошо.
ДСЛ это возможность писать код который выглядит как конфиг или английский язык, да, его все реализуют каждый по своему, но базовые подходы одинаковые, опять же вопрос в реализации (когда люди охваченные маниакальным метапрограммированием начинают что-то делать, получается плохо).
Судя по большинству описанных проблем у вашей команды бардак в коде и не очень понимающие концепцию Ruby программисты, что на любых языках программирования приводит к проблемам.
Ну тут всё же проблема не в руби, а в том что им неправильно пользуются, на той же джаве без опыта намного хуже можно наговнокодить.
Ставку делали на удобство и гибкость. Всеми фичами можно и нужно пользоваться. Только не все могут нормально, поэтому и возникают потом проблемы в поддержке написанного.
Ну в командной разработке, лучше использовать те фичи, которыми умеют уверенно пользоваться все участники команды. На самом деле я не знаю языков программирования, где люди с разным уровнем погружения и понимания языка могут писать код и не иметь головняков (ну, может быть, только если их код никак не пересекается между собой, но такое нечасто бывает, наверное).
> self.included — это чёрная магия, за которую в production коде надо бить по рукам, она нужна для гемов, но никак не для обычного кода
ActiveSupport::Concern вы не используете?
> class << self — это хипстеры используют для своих мини проектов, так писать не нужно вообще
Потом методы класса можно по файлу в неожиданных местах находить. attr_accessor через singleton_class.send пишите, или для него можно побыть хипстером?
ActiveSupport::Concern вы не используете?
> class << self — это хипстеры используют для своих мини проектов, так писать не нужно вообще
Потом методы класса можно по файлу в неожиданных местах находить. attr_accessor через singleton_class.send пишите, или для него можно побыть хипстером?
ActiveSupport::Concern требует, чтобы был установлен ActiveSupport, а если проект не на рельсах, то не всегда он и нужен. Явно уж, только ради Concerns таскать его за собой не стоит.
«ActiveSupport::Concern вы не используете?»
Как-то не пригождается, нет надобности примешивать и методы класса и методы экземпляра одновременно, да и как-то поддерживать легче код без этой чёрной магии…
Про class << self я отношусь однозначно отрицательно,
то есть если вы один разрабатываете что-то — это ваше личное дело, а если разработчиков становиться >1 то возникает куча проблем:
1. Методы внутри class << self нельзя тупо скопипастить
2. Чтобы выяснить метод ли класса это или нет, надо скроллить туда сюда по классу, что меня лично бесит
3. Не все сразу понимают эту конструкцию, потому если в команде есть новички, такие фишки противопоказаны
И из плюсов — в названиях методов нужно писать на 5 буковок меньше…
Мне кажеться выбор однозначный.
«Потом методы класса можно по файлу в неожиданных местах находить»
Для этого в компании должны быть какие-то правила, чтобы код было приятно читать. Там где я работаю мы стараемся отделять методы класса примесями, а если их немного, то просто пишем выше всех методов.
" attr_accessor через singleton_class.send пишите, или для него можно побыть хипстером? "
attr_accessor абсолютно не хипстерский, а очень полезный декларативный элемент объектов в Ruby, минусов его использования не знаю, если подскажете буду признателен.
#send использую очень редко в основном для DSL.
Как-то не пригождается, нет надобности примешивать и методы класса и методы экземпляра одновременно, да и как-то поддерживать легче код без этой чёрной магии…
Про class << self я отношусь однозначно отрицательно,
то есть если вы один разрабатываете что-то — это ваше личное дело, а если разработчиков становиться >1 то возникает куча проблем:
1. Методы внутри class << self нельзя тупо скопипастить
2. Чтобы выяснить метод ли класса это или нет, надо скроллить туда сюда по классу, что меня лично бесит
3. Не все сразу понимают эту конструкцию, потому если в команде есть новички, такие фишки противопоказаны
И из плюсов — в названиях методов нужно писать на 5 буковок меньше…
Мне кажеться выбор однозначный.
«Потом методы класса можно по файлу в неожиданных местах находить»
Для этого в компании должны быть какие-то правила, чтобы код было приятно читать. Там где я работаю мы стараемся отделять методы класса примесями, а если их немного, то просто пишем выше всех методов.
" attr_accessor через singleton_class.send пишите, или для него можно побыть хипстером? "
attr_accessor абсолютно не хипстерский, а очень полезный декларативный элемент объектов в Ruby, минусов его использования не знаю, если подскажете буду признателен.
#send использую очень редко в основном для DSL.
Я про то, что можно писать
class << self
attr_accessor :x
end
# если без class << self, то по-другому уже
singleton_class.send :attr_accessor, :x
У меня коллеги сильно залипают на такие конструкции, потому тупо объявляем нужные методы с def self, либо примешиваем из модулей через extend.
В команде гибкостью языка стоит жертвовать в угоду большего взаимопонимания. Зато никто из них не жалуется что методы хрен знает откуда подключены и.т.п.
В команде гибкостью языка стоит жертвовать в угоду большего взаимопонимания. Зато никто из них не жалуется что методы хрен знает откуда подключены и.т.п.
Это да. Я в другой ветке писал, что язык за гибкость язык винить — странно, если эта гибкость полезна. А в руби я не могу сейчас вспомнить что-то бесполезное. Дело в людях: кто-то не умеет пользоваться, кто-то пользует фичу не по назначению.
Я, все-таки, считаю, что лучше поднимать уровень понимания в команде. Ведь это довольно базовые вещи: 1 раз понял — пользуешься всегда. К тому же, код написанный не в команде тоже иногда (а может и часто) надо будет читать (фрэймворки/библиотеки). И он не всегда написан хорошо.
Я, все-таки, считаю, что лучше поднимать уровень понимания в команде. Ведь это довольно базовые вещи: 1 раз понял — пользуешься всегда. К тому же, код написанный не в команде тоже иногда (а может и часто) надо будет читать (фрэймворки/библиотеки). И он не всегда написан хорошо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не совсем крутой Ruby