Comments 255
==оффтоп==
производители пива молятся на жаркое лето
производители зонтиков молятся на дождливое лето
а производителям водки некогда молиться - надо производить
теперь по делу
автор сравнивает несравнимое - Ruby vs C++, Java, PHP4
С++ и Java это совсем другая опера
ну а сравнивать с PHP4 вообще наивно, ещё бы PHP pre-alpha бы сравнили. В PHP5 намного больше интересностей.
Ruby это круто для программирования но почему то все, кто хвалят Ruby всё время забывают маленькую вещь - производительность. Ведь и для offline программинга есть DarkBasic, позволяющий школьникам делать 3D игры, но движки на нём почему-то не пишут
PS. Извините что сумбурно, но может кто-то вместо того, что бы писать розовыми буквами слово Ruby напишет сравнительную характеристику производительности языков программирования?
PPS. Огромное спасибо за то, что не стали сравнивать PHP5 vs. RoR. Вроде уже поняли, что сравнивать фреймфорк с языком некорректно )
производители пива молятся на жаркое лето
производители зонтиков молятся на дождливое лето
а производителям водки некогда молиться - надо производить
теперь по делу
автор сравнивает несравнимое - Ruby vs C++, Java, PHP4
С++ и Java это совсем другая опера
ну а сравнивать с PHP4 вообще наивно, ещё бы PHP pre-alpha бы сравнили. В PHP5 намного больше интересностей.
Ruby это круто для программирования но почему то все, кто хвалят Ruby всё время забывают маленькую вещь - производительность. Ведь и для offline программинга есть DarkBasic, позволяющий школьникам делать 3D игры, но движки на нём почему-то не пишут
PS. Извините что сумбурно, но может кто-то вместо того, что бы писать розовыми буквами слово Ruby напишет сравнительную характеристику производительности языков программирования?
PPS. Огромное спасибо за то, что не стали сравнивать PHP5 vs. RoR. Вроде уже поняли, что сравнивать фреймфорк с языком некорректно )
UFO just landed and posted this here
UFO just landed and posted this here
настолько :)
настолько =)
Нужная скорость может достигаться повышеным кэшированием и расширением системы на несколько серверов. Но всё равно именно из-за этой причины (мифической тормознутости), я пока не спешу использовать Руби.
ЗЫ: В PHP Symfony тоже есть Yaml и я даже установил Aptana RadRails чтоб редактировать его с подсветкой :)
ЗЫ: В PHP Symfony тоже есть Yaml и я даже установил Aptana RadRails чтоб редактировать его с подсветкой :)
Все зависит от того, что вы имеете в виду под "производительностью". Для некоторых - это скорость работы приложений на нем. Для других - скорость разработки новых приложений (с Basic сравнение все-же - крайность, хотя, в конце 90-х, Basic был лидером среди языков, используемых начинающими программистами в штатах) не в жертву скорости работы.
Ruby разрабатывался как "удобный" язык. Я, когда выбирал "язык для себя", тоже исходил из соображений удобства (хотя, Ruby я и не и не использую).
Я согласен, каждый хвалит свое, но в данном случае афтар говорит именно о "вкусностях" Ruby.
Ruby разрабатывался как "удобный" язык. Я, когда выбирал "язык для себя", тоже исходил из соображений удобства (хотя, Ruby я и не и не использую).
Я согласен, каждый хвалит свое, но в данном случае афтар говорит именно о "вкусностях" Ruby.
Ruby сейчас позиционируется как средство решения всех проблем
Спору нет - для homepage с загрузкой до 300 хостов в сутки лучше выбора наверное нет.
Но как быть со 100 000 хостов?
Спору нет - для homepage с загрузкой до 300 хостов в сутки лучше выбора наверное нет.
Но как быть со 100 000 хостов?
http://www.habrahabr.ru/blog/mysql/18203…
и дело уже не в языке, а в железе и используемых алгоритмах
и дело уже не в языке, а в железе и используемых алгоритмах
даже если зарядить себе в попу самый лучший алгоритм - то все равно ruby будет медленнее python ;). Аналогично - если взять суперкрутое железо, все равно python будет быстрее ruby.
возвращаемся к началу: если вам нужна скорость - пользуйте асм или Си. Речь о удобстве. Python, не спорю, удобен, но для многих Ruby подходит больше (хотя, я пользую Parser).
*зевает* в своих спорах о скорости работы, все как один, почему-то забывают, что кроме скорости работы непосредственно того, на чем пишешь, есть еще скорость работы того, что используешь... к примеру базы данных, апач и прочие мелочи. Исходя из моего опыта, основные тормоза почему-то получаются в момент передачи даннх конечному пользователю или в момент выборки из базы данных сложным запросом...
может потому, что для производительных систем нужно делать нестандартную архитектуру всякие там "fast-cgi" и "stored procedures". на фоне таких оптимизаций интерпретатор ruby остаётся за крайнего даже при простом коде "hello world".
я такие вопросы не затрагивал. Я не пытаюсь спорить, просто мне кажеться, что не за то ругают пост.
Для меня "скорость работы" тоже играет немаловажную роль.
Просто, мне кажеться спор немного параллельный, т.е. уже перетекает за рамки темы поста: "удобства работы с языком". Я не в коем случае не агитирую за Ruby или за что-то другое, просто спор уже о другом.
Для меня "скорость работы" тоже играет немаловажную роль.
Просто, мне кажеться спор немного параллельный, т.е. уже перетекает за рамки темы поста: "удобства работы с языком". Я не в коем случае не агитирую за Ruby или за что-то другое, просто спор уже о другом.
я на это и агитирую. То что писать нужно - на нескольких языках. А до тех пор пока зацикливаетесь на Ruby или чем-то ином - до настоящего профессионала вам будет далеко.. ))
причём. у авторов такого рода статей все изъясняется при помощи таких ценностей, что сразу становится понятно - кроме Ruby, может пишут на PHP, но уж точно не пробовали C/C++/D :)
причём. у авторов такого рода статей все изъясняется при помощи таких ценностей, что сразу становится понятно - кроме Ruby, может пишут на PHP, но уж точно не пробовали C/C++/D :)
Я не зацикливаюсь, а лишь говорю, что "автор писал не о том...".
А насчет C++ и т.д.... давайте не смешивать разные вещи: веб-программирование и программирование вообще. Я работал на C++ довольно долго и в большом восторге от этого языка, но - делать на нем сайты - МАРАЗМ, с большой буквы. С тем же успехом можно штангенциркулем гвозди забивать. Для всего существуют свои инструменты и люди пользуются теми, что им удобнее.
А насчет C++ и т.д.... давайте не смешивать разные вещи: веб-программирование и программирование вообще. Я работал на C++ довольно долго и в большом восторге от этого языка, но - делать на нем сайты - МАРАЗМ, с большой буквы. С тем же успехом можно штангенциркулем гвозди забивать. Для всего существуют свои инструменты и люди пользуются теми, что им удобнее.
объясните в чём маразм вынести логику подсчета, скажем, какого-нибудь облака тегов в си? Я не о C++, я о СИ!!
Ни в одном комменте я не агитировал писать ВЕСЬ веб-проект на Си. Это слишком неудобно и не всегда эффективно.
Си сложнее, на нём уже не так легко пишется непрофессионалам. Потому и орут на каждом углу "ой маразм, маразм!".
Ни в одном комменте я не агитировал писать ВЕСЬ веб-проект на Си. Это слишком неудобно и не всегда эффективно.
Си сложнее, на нём уже не так легко пишется непрофессионалам. Потому и орут на каждом углу "ой маразм, маразм!".
> Я выбрал второй, так как не хотел, чтоб неправильные отступы были причиной неполадок в моем коде.
Дальше читать не стал.
Дальше читать не стал.
Извините что сумбурно, но может кто-то вместо того, что бы писать розовыми буквами слово Ruby напишет сравнительную характеристику производительности языков программирования?
Ruby медленнее PHP? Уже нет!
А чем руби плох для продакшна?
http://habrahabr.ru/blog/ruby/26147.html
вот тут как раз материал по сравнительной характеристике, в гугле материала достаточно, в том числе и графиков сравнения и, почему-то, ява тоже включена в список (php/java/ruby), причем не в один, значит есть смысл ее туда включать, с++ был лишним, да, но он не выпал из текста статьи, с ним сравнивали :)
php5 - а что это, панацея? Он как был однопоточным, так и остался, нет нормального fastcgi, яваподобный синтаксис ООП угнетать начинает. Да, сделали file_get/put_contents, scandir всякие, этим чуток улучшили разработку, но суть-то не меняется, под руками все те же средства.
Сравнивать ruby и darkbasic непрофессионально, не побоюсь этого слова, Вам же java && c++ мешали, так причем тут darkbasic к ruby? На ruby пишут и будут писать, это совершенно новая вещь, возьмите свою pre-alpha php и сравнивайте :)
Язык молодой, а Вы на него всех собак вешаете...
Сами 99% на php разрабатываете с применением ООП подхода...
http://habrahabr.ru/blog/ruby/26147.html
вот тут как раз материал по сравнительной характеристике, в гугле материала достаточно, в том числе и графиков сравнения и, почему-то, ява тоже включена в список (php/java/ruby), причем не в один, значит есть смысл ее туда включать, с++ был лишним, да, но он не выпал из текста статьи, с ним сравнивали :)
php5 - а что это, панацея? Он как был однопоточным, так и остался, нет нормального fastcgi, яваподобный синтаксис ООП угнетать начинает. Да, сделали file_get/put_contents, scandir всякие, этим чуток улучшили разработку, но суть-то не меняется, под руками все те же средства.
Сравнивать ruby и darkbasic непрофессионально, не побоюсь этого слова, Вам же java && c++ мешали, так причем тут darkbasic к ruby? На ruby пишут и будут писать, это совершенно новая вещь, возьмите свою pre-alpha php и сравнивайте :)
Язык молодой, а Вы на него всех собак вешаете...
Сами 99% на php разрабатываете с применением ООП подхода...
Хм, а зачем вешать текст, если и сами знаете что переведено хреново?
Читать результат крайне тяжело: с одной стороны обороты типа "впервые увидев это, я был запечатлен" выдают работу автоматического переводчика, с другой стороны кто-то еще руками добавил к тексту изрядное количество грамматических и орфографических ошибок и опечаток.
Читать результат крайне тяжело: с одной стороны обороты типа "впервые увидев это, я был запечатлен" выдают работу автоматического переводчика, с другой стороны кто-то еще руками добавил к тексту изрядное количество грамматических и орфографических ошибок и опечаток.
пример 4я причины неочевиден :)
заместь strtolower("YOU SHOULDN'T ALWAYS USE CAPITALS") можно написать "you shouldn't always use capitals". не вижу особой экономии, не имею ничего против скобок
заместь strtolower("YOU SHOULDN'T ALWAYS USE CAPITALS") можно написать "you shouldn't always use capitals". не вижу особой экономии, не имею ничего против скобок
Надоели эти статьи честно говоря, тем более переводы. Если автор действительно считает для себя руби идеалом, пусть считает и пишет на нем, не надо заниматься внушением (местами просто бредовым), это только собъет с толку начинающих, начнет разводить холивары между средними кодерами и устало улыбнет профессионалов, которые сами для себя всё решили и поняли.
Полностью согласен!
[offtopic]
Мне тоже такие статьи надоели.
Однако такие статьи — неизбежность хабра какой он есть. Один–два таких третьесортных перевода, и карма уже выросла, и «автор» на коне, и может «плюсовать»... (Я это узнал сам, со своим прошлым эккаунтом, кармы которому было не занимать...)
Учитывая, что на хабре всё опубликованное очень быстро уходит в небытие забытого и плохо ищется — стараться ради таких статей _особо_ сильно не имеет смысла. Достаточно держаться среднего для сайта серенького уровня. Ведь хабр — это поток, а не библиотека–копилка. Главное, чтобы тема и первый абзац цепляли. Фактические ошибки, полное искажение смысла при переводе и бессодержательность значения не имеют.
Но это хабр и его система. Она поощряет такую «попсу». Поощряет количество и массу. И чем дальше, тем её будет больше (моя оценка — должно появляться примерно по 3–4 фиговых бестолковых «статьи» на каждого нового пользователя). Я уже давно не прочитываю до конца эти бесконечные «простыни». Впрочем, иногда, в надежде на что-то содержательное кликаю. Увы :(
[/offtopic]
Мне тоже такие статьи надоели.
Однако такие статьи — неизбежность хабра какой он есть. Один–два таких третьесортных перевода, и карма уже выросла, и «автор» на коне, и может «плюсовать»... (Я это узнал сам, со своим прошлым эккаунтом, кармы которому было не занимать...)
Учитывая, что на хабре всё опубликованное очень быстро уходит в небытие забытого и плохо ищется — стараться ради таких статей _особо_ сильно не имеет смысла. Достаточно держаться среднего для сайта серенького уровня. Ведь хабр — это поток, а не библиотека–копилка. Главное, чтобы тема и первый абзац цепляли. Фактические ошибки, полное искажение смысла при переводе и бессодержательность значения не имеют.
Но это хабр и его система. Она поощряет такую «попсу». Поощряет количество и массу. И чем дальше, тем её будет больше (моя оценка — должно появляться примерно по 3–4 фиговых бестолковых «статьи» на каждого нового пользователя). Я уже давно не прочитываю до конца эти бесконечные «простыни». Впрочем, иногда, в надежде на что-то содержательное кликаю. Увы :(
[/offtopic]
Мне почему-то легче прочитать десяток-другой таких статей про Руби, чем самому его поставить, потом перечитать кучу литературы по языку, потом кучу по Рельсам.
Так я уже более-менее себе его представляю :)
Но использовать пока не тороплюсь. Жду таких же статей по рельсам :)
Так я уже более-менее себе его представляю :)
Но использовать пока не тороплюсь. Жду таких же статей по рельсам :)
На самом деле причин гораздо больше.
А статьи- переводы и вправду надоели, а своих писать не имею возможности из- за кармы.
А статьи- переводы и вправду надоели, а своих писать не имею возможности из- за кармы.
мне нравится ruby и rails - я использую их сам.
но не нравится подача материала в статье - хотя бы потому, что провоцирует holywar; так же нельзя не отметить некоторую сумбурность, передергивания(отступы в питон например).
если вы сами чувствуете что идеологически в статье что то не так(а вы чувствуете - как иначе объяснить извинения в конце статьи?) то может быть не надо заниматься переводом именно этой статьи и взять что то другое?
в любом случае удачных переводов, русскоязычны материалов о ruby мало, это да.
но не нравится подача материала в статье - хотя бы потому, что провоцирует holywar; так же нельзя не отметить некоторую сумбурность, передергивания(отступы в питон например).
если вы сами чувствуете что идеологически в статье что то не так(а вы чувствуете - как иначе объяснить извинения в конце статьи?) то может быть не надо заниматься переводом именно этой статьи и взять что то другое?
в любом случае удачных переводов, русскоязычны материалов о ruby мало, это да.
скоро надо будет написать статью с названием "10 причин, по которым не стоит писать стати на тему '10 причин почему эта чтука круче всего остального'".
Мы в студии сравнивали производительность PHP, Perl, Python и Ruby. Руби продул всем. Питон с ускорителем немного отстал от перла, пхп от питона с ускорителем, но дёрнул обычный питон. Ну и конечно же всех порвал Си++ (он шел вне зачета), да, оно и понятно :)
Конечно сравнивали на одной подзадаче, но все же.
Про скорость разработки: когда мне говорят про сложность разработки на перле я смеюсь в лицо :)
Конечно сравнивали на одной подзадаче, но все же.
Про скорость разработки: когда мне говорят про сложность разработки на перле я смеюсь в лицо :)
А PHP с ускорителем в тесты не входило?
UFO just landed and posted this here
Крупные проекты действительно проще писать, например, на питоне. Перл чудесен, но читается тяжело, даже если при написании кода стараться минимизировать «шумность» строк. На перле великолепно пишется одноразовый код.
а я вот на питоне с легко и просто подключаемыми модулями на Си - всех дёрну =). И времени потрачу, ну может, на 20% больше чем если бы не писал модуль на Си. А учитывая сколько времени начинают люди тратить на всякие тесты... И не надо говорить про dl() в PHP если вы сами не пробовали =) (упреждающе.. =))
7.Вы не сможите получать единорогов из птиц и конец, но вы получите ослов, если захотите. - сможЕте
8. XML — реально ненужен. - эх.. ещё как нужен
Если очень нравятся объекты и есть возможность пересесть на другую платформу (для многих это роскошь) - я бы выбрал .NET
8. XML — реально ненужен. - эх.. ещё как нужен
Если очень нравятся объекты и есть возможность пересесть на другую платформу (для многих это роскошь) - я бы выбрал .NET
Заинтриговал. Но руби пожалуй потом выучу. Сейчас купил макубук и разбираюсь с XCode и Objective-C. Но все-равно спасибо за информацию.
UFO just landed and posted this here
отступы - одна из самых вкусных фич в Python
Несомненно. И у меня иногда при чтении чужого кода возникает желание принудительно усадить автора за Питон на пару недель, что бы он научился таки правильно форматировать код с которым, как ему заведомо известно, будут работать другие люди.
Несомненно. И у меня иногда при чтении чужого кода возникает желание принудительно усадить автора за Питон на пару недель, что бы он научился таки правильно форматировать код с которым, как ему заведомо известно, будут работать другие люди.
> Не всегда. Например, исключения в С++ - это убожество и признак плохого тона.
Ух ты, первый раз такое слышу. А можно подробнее, что в них убогого? Не подумайте только, что я вас задираю. Просто интересно.
Ух ты, первый раз такое слышу. А можно подробнее, что в них убогого? Не подумайте только, что я вас задираю. Просто интересно.
> Все боятся этих отступов, но никто не может сказать, чем же они плохи на практике. Как по мне, то эти отступы - одна из самых вкусных фич в Python.
Мне они тоже по нраву, ещё как. Но однажды мне попалась программка, в которой отступы были сделаны из смеси пробелов и табов. Это было ужасно, я едва не лишился рассудка, пока разобрался, в чём дело.
Мне они тоже по нраву, ещё как. Но однажды мне попалась программка, в которой отступы были сделаны из смеси пробелов и табов. Это было ужасно, я едва не лишился рассудка, пока разобрался, в чём дело.
Простите, Вы не могли бы коротко пояснить пункт про убожество исключений в С++?
Тяжелая статья для пятничного вечера :)
Ну как уже достали идиотские статьи "В Руби все хорошо, у остальных все плохо".
Исключения. Верите или нет, исключения являются одной из важнейших вещей при разработке программ любого рода. Программисты на PHP4, не знают ничего о них и будут говорить вам, что можно просто печатать(ошибки) на экран или использовать их собственный «супер-пупер» класс для обслуживания ошибок. К счастью для всех нас, Ruby поставляется с try/catch (или еще лучше begin/rescue) блоками и набором предопределенных, расширяемых Исключений, для правильной обработки ошибок.
Программисты на ассемблере тоже могут рассказать дофига интересного. PHP4 мертв давно. В PHP5 исключения ЕСТЬ. Расширяемые и все такое.
Пространства имен: модули Ruby делают использование пространства имен легким, это должно понравиться энтузиастам C++ и Java.
Чего нет - того нет. В PHP6 будет. В Питоне - не знаю просто.
Встроенные регулярные веражения: Для всех знатоков Perl, вы можете заключить нечто в // и оно становится регулярным выражение, готовым для сравнения (для этого используем оператор =~).
Пардон, а ГДЕ нет регэкспов? В ассемблере? В PHP и Python есть.
Перегрузка операторов: Ruby позволяет определять операторы, такие как +, -, >, и т.д. для любого вашего класса.
Угу. "Счастливой отладки, придурки". Если вам надо переопределить МАТЕМАТИЧЕСКИЕ операторы - вы что-то не то делаете. Любое мыслимое применение такой операции реализуется и на других языках, возможно большим количеством кода, но зато более читаемо.
Пакеты: называемые «gems»(камешки), они действительно оправдывают свое название, кроме того — они работают. Пакеты поддерживают зависимости, а еще могут быть как кросс-платформенные, так и платформо-зависимыми
Ага. У Perl, PHP, Python конечно никаких библиотек нету. Совсем. Ни CPAN, ни PEAR, ни "чего-там-у-питона". И конечно, они не работают, и не поддерживают зависимости.
Интерактивная консоль: может использоваться для тестирования кода интерактивно, подобно консоли Python
php -a
Исключения. Верите или нет, исключения являются одной из важнейших вещей при разработке программ любого рода. Программисты на PHP4, не знают ничего о них и будут говорить вам, что можно просто печатать(ошибки) на экран или использовать их собственный «супер-пупер» класс для обслуживания ошибок. К счастью для всех нас, Ruby поставляется с try/catch (или еще лучше begin/rescue) блоками и набором предопределенных, расширяемых Исключений, для правильной обработки ошибок.
Программисты на ассемблере тоже могут рассказать дофига интересного. PHP4 мертв давно. В PHP5 исключения ЕСТЬ. Расширяемые и все такое.
Пространства имен: модули Ruby делают использование пространства имен легким, это должно понравиться энтузиастам C++ и Java.
Чего нет - того нет. В PHP6 будет. В Питоне - не знаю просто.
Встроенные регулярные веражения: Для всех знатоков Perl, вы можете заключить нечто в // и оно становится регулярным выражение, готовым для сравнения (для этого используем оператор =~).
Пардон, а ГДЕ нет регэкспов? В ассемблере? В PHP и Python есть.
Перегрузка операторов: Ruby позволяет определять операторы, такие как +, -, >, и т.д. для любого вашего класса.
Угу. "Счастливой отладки, придурки". Если вам надо переопределить МАТЕМАТИЧЕСКИЕ операторы - вы что-то не то делаете. Любое мыслимое применение такой операции реализуется и на других языках, возможно большим количеством кода, но зато более читаемо.
Пакеты: называемые «gems»(камешки), они действительно оправдывают свое название, кроме того — они работают. Пакеты поддерживают зависимости, а еще могут быть как кросс-платформенные, так и платформо-зависимыми
Ага. У Perl, PHP, Python конечно никаких библиотек нету. Совсем. Ни CPAN, ни PEAR, ни "чего-там-у-питона". И конечно, они не работают, и не поддерживают зависимости.
Интерактивная консоль: может использоваться для тестирования кода интерактивно, подобно консоли Python
php -a
Перегрузка +, -, == и тд - удобная игрушка, допустим для таких целей, как добавление объекта в коллекцию или если есть реализация комплексных чисел и их надо суммировать или сравнить два объекта. Если правильно применять, конечно, а применять неправильно можно вообще все.
Кстати, пространства имен есть уже как патч к 5 пхп и вроде в 5.3 уже обещали ввести
Кстати, пространства имен есть уже как патч к 5 пхп и вроде в 5.3 уже обещали ввести
Боюсь, тут смысл от меня ускользает.
Добавление в коллекцию - в массив? Или в "объект-контейнер"?
Добавление в коллекцию - в массив? Или в "объект-контейнер"?
нет, перегрузка операторов это из с++
типа для того чтобы "прибавить" один объект к другому.... или "отнять".... или "сравнить". т.е. ты сам пишешь, что в них надо сравнивать, чтобы прийти к выводу что object1>object2
типа для того чтобы "прибавить" один объект к другому.... или "отнять".... или "сравнить". т.е. ты сам пишешь, что в них надо сравнивать, чтобы прийти к выводу что object1>object2
Понятно. Ну это можно и без перегрузки реализовать, писанины просто немного побольше.
конечно, это для "красивостей"
Я не знаю, как в Руби (все мечтаю, что выдастся время посмотреть внимательно на него), а, вот, в СИ++ есть такая приятная штука, которая называется STL (Standart Template Library). Там реализованы шаблонные функции и класы. Шаблоны (templates), если совсем грубо, то это определение какой-то функции или класса, без указания конкретного типа данных, с которым происходит работа. Например, тот же самый sort() (Сортировка). Вы можете передать туда коллекцию, которая должна быть отсортирована. Но, чтобы отсортировать коллекцию, необходимо, чтобы объекты в коллекции поддерживали операции >, <, ==. Иначе говоря, шаблонная функция sort() готова будет отсортировать коллекцию объектов любых типов, если они поддерживают операции сравнения друг с другом. Ваш пользовательский класс инкапсулирует то, как он сравнивает, и чем он руководствуется. Таким образом, чтобы вы могли сортировать коллекции с объектами вашего нового класса, вам не надо писать никаких новых функций а-ля sortMyNewClass, или реализовывать интерфейс sortable, или изменять функцию sort(), чтобы она сравнивала иначе, в случае если classOf - это ваш новый класс. Достаточно в классе определить методы сравнения, и описать в них, как вы хотите, чтобы сравнивались объекты вашего класса друг с другом.
Надеюсь, получилось объяснить более-менее внятно. =)
P.S. По специфике своей работы, сам, 90% времени, использую PHP.
Надеюсь, получилось объяснить более-менее внятно. =)
P.S. По специфике своей работы, сам, 90% времени, использую PHP.
Понял, спасибо. Полезно, но по моему не очень часто надо :)
Стандартная библиотека Руби чаще всего переопределяет четыре оператора: <=> (сравнение объектов, используется модулем Enumerable для сортировки аналогично описанному вами), << (в значении "поместить в поток" привет С++ или "добавить в коллекцию") и равенства == и ===. Математические операторы определены также на векторах и матрицах. Остальное уже экзотика.
Все можно реализовать на ассемблере - просто писанины еще больше :)
Это удобно, лично мне, и мне нравится концепция ооп и все плюсы, которые я из нее получаю
Это удобно, лично мне, и мне нравится концепция ооп и все плюсы, которые я из нее получаю
Кто обещал? Где такое увидели?
Беру слова обратно, в 5.3 дейтвительно будут неймспейсы.
в 2007 году они наконец поняли что неймспейсы это круто. хихи. 8)
В каком году рубифаны поймут, что нормальный модуль к апачу это круто?
Для вас работа с апачем через FastCGI - это не достаточно нормально?
вам плюс, но поясню причину недовольства shared-хостеры не дадут fast-cgi (bиначре осто памяти не хватит) и потому хостинг для ruby заметно дороже чем для php.
Нет, недостаточно. Лишний софт, который требует отдельных настроек.
модуль к апачу тоже требует настроек
из плюсов - некоторое увелечение скорости и возможность работы с апачными внутренностями
из плюсов - некоторое увелечение скорости и возможность работы с апачными внутренностями
А модуль для апача - это не лишний софт? :) Или настройки модуля не требуется?
Настроить апач для работы с Руби по FastCGI - это скопировать - это скопировать один файл в папку с модулями апачи и добавить 4 строчки в конфиг - это что проблема?
Настроить апач для работы с Руби по FastCGI - это скопировать - это скопировать один файл в папку с модулями апачи и добавить 4 строчки в конфиг - это что проблема?
регэкспы-то есть, просто в php они чуть хитрее оформляются. а жаль, даже SSI понимает их так же, как Ruby.
хотя, признаюсь, я быстро привык писать eregi(…), это не критичное ограничение
хотя, признаюсь, я быстро привык писать eregi(…), это не критичное ограничение
+ и - математические только с вещественными числами
сложить два объекта обычным оператором + у вас вряд ли выйдет (что складывать? указатели на объекты?), вот если правильно переопределить - запросто!
на самом деле, очень удобно, если с умом подойти
сложить два объекта обычным оператором + у вас вряд ли выйдет (что складывать? указатели на объекты?), вот если правильно переопределить - запросто!
на самом деле, очень удобно, если с умом подойти
Хм.. какраз недавно я предстал перед выбором, какой язык изучать(болшей частью для себя, для баловства), и выбрал Питон... Не жалуюсь.
а замечание про отступы - действительно странное...
а замечание про отступы - действительно странное...
Ну внесу свои пять копеек.
1.
Статья очевидно старая, сравнивать с php4 совсем не хорошо. Лесом идут замечания про try/catch
2. Наличие не жесткого синтаксиса как в ruby так и perl ведет к коду плохому коду. Конечно это решается введением жесткого стиля кодирования.
3. При использовании unless c достаточно сложным блоком условий бывает трудно
4.
Не очень удачный пример с «!». Действительно используется, когда совершается нечто необратимое, например, когда метод меняет именно переданную строку, а не изменяет ее копию.
5.
Написать программу в одну строчку можно
6. Часто ругают ruby за то, что можно изменить "все что хочу", в том числе и область видимости метода.
7.
Не надо вводить людей в заблуждение, как раз таки включением модулей в класс и достигается множественно наследование.
8. Да, данный момент интерпретатор ruby достаточно медленный, но это никак не проблема языка, а конкретной его реализации.
1.
Программисты на PHP4, не знают ничего о них и будут говорить вам, что можно просто печатать(ошибки) на экран или использовать их собственный «супер-пупер» класс для обслуживания ошибок.
Статья очевидно старая, сравнивать с php4 совсем не хорошо. Лесом идут замечания про try/catch
2. Наличие не жесткого синтаксиса как в ruby так и perl ведет к коду плохому коду. Конечно это решается введением жесткого стиля кодирования.
3. При использовании unless c достаточно сложным блоком условий бывает трудно
4.
в то время, как знак «!» используется для методов, делающих нечто необратимое, на подобии удаления записи из базы данных, отщепления последнего символа из строки и т.п.
Не очень удачный пример с «!». Действительно используется, когда совершается нечто необратимое, например, когда метод меняет именно переданную строку, а не изменяет ее копию.
5.
мы не сможем написать программу в одну строчку.
Написать программу в одну строчку можно
irb(main):009:0> class A; def test; 'test'; end; end
=> nil
irb(main):010:0> A.new.test
=> "test"
6. Часто ругают ruby за то, что можно изменить "все что хочу", в том числе и область видимости метода.
7.
Ruby не позволяет множественного наследования.
Не надо вводить людей в заблуждение, как раз таки включением модулей в класс и достигается множественно наследование.
8. Да, данный момент интерпретатор ruby достаточно медленный, но это никак не проблема языка, а конкретной его реализации.
UFO just landed and posted this here
UFO just landed and posted this here
да божешь мой. Не игрушка - это когда не тратишь драгоценное CPU-тайм на финтифлюшечки и красивости. Для _некритичных_ к скорости приложений - можно и запарится, ничего против не имею. Но вот лично мне как то не доводилось делать коммерческие некритичные к скорости проекты =). Может, не повезло? =)
Знаю одну социальную сеть, на которой я зарегистрирован. IndabaMusic.com Это социальная сеть для музыкантов + сервис для совместного создания музыки. Конечно, вряд ли по количеству подписчиков эта штука зарулит майспейс, но ведь не все в мире музыканты :) Стабильно работает, и держит свою аудиторию. Проект на Рельсах. Смотрите :)
ЗЫ: После его подумал, а не хочу ли я выучить эти самые рельсы...
ЗЫ: После его подумал, а не хочу ли я выучить эти самые рельсы...
смотрите как можно сравнить по-забавнее: ни один самый популярный проект в одной любой сфере не неписан на Ruby. :). Возможно, с редким исключением, но общая картина такая. Если вы начнёте писать на Ruby, а конкурирующий проект на Python, то у них будет огромное преимущество, особенно если они не будут использовать django, а напишут свой более шустрый и подходящий нуждам фреймворк. Да, они потратят на это раза в 2 больше времени, но не факт что потратив +50% по времени на оптимизацию, вы сможете их догнать =).
смотрите как можно сравнить по-забавнее: ни один самый популярный проект в одной любой сфере не неписан на Ruby. :)
twitter.com? basecamphq.com? :)
Или даже - membrana.ru? :)
Ну тут уже вопрос что важнее скорость работы или скорость разработки. Вопрос более философской категории, чем практической. С одной стороны, разработчики на Рельсах смогут быстро сделать прототип, показать его инвестору(ам)/заказчику, получить дополнительное финансирование и может даже забросить эти рельсы :)
обязательно разыщите спецификацию их оборудования. возможно это станет для вас откровением.
Если для Ваших коммерческих проектов была так важна скорость - Вы видимо все их писали на чистом C/C++ ? :)
я писал где-то тут уже вокруг - писать надо на нескольких языках. Нет смысла парсинг конфиг-файла, который при запуске сервера один раз происходит, писать на Си. Но есть смысл писать на Си то, что каждый запрос отнимает, скажем, до 5% общего времени выполнения. Большей частью питон можно разогнать до высоких скоростей, переписывая стандартные модули (которые в большинстве своём на самом питоне) - на Си.
Если писать на питоне только то, чем пользуются один раз в неделю - то наверное это вообще не стоит упоминать.
А если же мешать питон и С - то вот тут и возникает вопрос - если как Вы сказали - все Ваши коммерческие проекты были так критичны к скорости - почему же Вы не использовали возможность добиться максимальной скорости написав все на чистом C/C++?
А если же мешать питон и С - то вот тут и возникает вопрос - если как Вы сказали - все Ваши коммерческие проекты были так критичны к скорости - почему же Вы не использовали возможность добиться максимальной скорости написав все на чистом C/C++?
чем вас пример с конфиг-файлом не устроил? )
тем что - как Вы сами написали "при запуске сервера один раз происходит" - то есть на производительность работающего приложения не влияет
блин да вы же прекрасно понимаете о чем я говорю - ну что за дурацкий флейм =).
да, внутри приложения море кода на C, однако тратиьт время на переписывание модулей питона, которые просто интерфейсят вызовы в библиотеки C нет смысла. Так же весь UI, естественно, не на Си =). А вот темплейтная система - на Си.
я сейчас и вовсе собираюсь начать проект http-сервера на Си, который будет выстраивать MVC/Event фреймворк для пользовательского питоновского кода. Hello World будет выдываваться в 30-50 раз быстрее чем на PHP. Хоть это и не показатель, но тем не менее может получиться создать самый быстрый фреймворк для языка сверх-высокого уровня.
да, внутри приложения море кода на C, однако тратиьт время на переписывание модулей питона, которые просто интерфейсят вызовы в библиотеки C нет смысла. Так же весь UI, естественно, не на Си =). А вот темплейтная система - на Си.
я сейчас и вовсе собираюсь начать проект http-сервера на Си, который будет выстраивать MVC/Event фреймворк для пользовательского питоновского кода. Hello World будет выдываваться в 30-50 раз быстрее чем на PHP. Хоть это и не показатель, но тем не менее может получиться создать самый быстрый фреймворк для языка сверх-высокого уровня.
Самый быстрый фреймворк для вывода "Hello, World!"?
Цель - супер.
Цель - супер.
не придирайтесь к словам. Логика фреймворка и бизнес логика программы две разные вещи. И фреймворки можно сравнивать - какой из них логику самого MVC выполнит быстрее. Естественно при этом бизнес логика не должна быть уж совсем тормознутым узким местом. Но чем плохо - если фреймворк сам по себе очень быстр, даже если бизнес-логика в 100 раз медленнее? )))
Не забудьте еще самую быструю СУБД вдобавок написать :)
видите прямую связь между СУБД и Фреймворком? Т.е. один без другого по вашему мнению быть не может? :)
нереляционную и вообще не ansi-sql совместимую БД написать не так уж сложно, если не пытаться делать её универсальной, а затачивать под какой-то один проект. Выстраивать индексы в памяти и тп. Некоторые проекты к этому прибегают. =)
нереляционную и вообще не ansi-sql совместимую БД написать не так уж сложно, если не пытаться делать её универсальной, а затачивать под какой-то один проект. Выстраивать индексы в памяти и тп. Некоторые проекты к этому прибегают. =)
Да помоему как раз Вы пытаетесь разводить флейм :)
Вы упрекали Руби что он не подходит из за скорости - так как для "как то не доводилось делать коммерческие некритичные к скорости проекты". А чего же тогда сами питон используете - если можно достичь большей скорости на чистом C/C++? :) Или скорость работы это не всегда - самое важное? :) Тогда в чем вы упрекаете Руби?
Вы упрекали Руби что он не подходит из за скорости - так как для "как то не доводилось делать коммерческие некритичные к скорости проекты". А чего же тогда сами питон используете - если можно достичь большей скорости на чистом C/C++? :) Или скорость работы это не всегда - самое важное? :) Тогда в чем вы упрекаете Руби?
я упрекаю руби в том, что питон по скорости написания кода не медленее руби (ну если представить что и тот и тот язык вы знаете от зубов), а вот по скорости питон редко когда меньше чем в 1.5-2 раза медленее руби =). Собственно. Смысл руби?. А то что писать на РОРе такие проекты как twitter - сами девелоперы twitter-а же и говорят "да ну его, надо мигрировать"... +)
Можно конечно писать на ROR+C, но при этом опять таки непонятно - почему не Питон+С, ведь это все же будет быстрее =).
Можно конечно писать на ROR+C, но при этом опять таки непонятно - почему не Питон+С, ведь это все же будет быстрее =).
очепятался :) конечно "а вот по скорости питон редко когда меньше чем в 1.5-2 раза быстрее руби"... +))))
А то что писать на РОРе такие проекты как twitter - сами девелоперы twitter-а же и говорят "да ну его, надо мигрировать"... +)
Вы путаете - наоборот разработчики twitter-а говорят, что не смотря на проблемы с масштабированием - они не пожалели что воспользовались ROR.
А смысл в Руби в том - что языки не равны друг другу - и если какой то язык подходит для разработчика больше - значит этот язык и нужно использовать.
Можно конечно писать на ROR+C, но при этом опять таки непонятно - почему не Питон+С, ведь это все же будет быстрее =).
Так Вы не ответили - если главное - скорость - как Вы сами же и сказали - зачем тогда вообще примешивать интерпретируемые языки (Руби, Питон,PHP)? :)
я сказал свою мысль уже раз 5 :). Те кусочки программы которые при переписывании на Си принесут прирост проивзодительности сопоставимый с временем, требуемым на реализацию - стоит делать. Но! При сравнении Питона и Руби совершенно резонный вопрос - раз уж они позволяют делать одинаковые вещи практически одинаковыми затратами - какой смысл в Руби, если по скорости он в пару раз медленнее? А если сравнить с питоном+psyco?
Тот уровень абстракции который в Руби выше чем в Питоне - не даёт таких преимуществ, которые можно было бы сказать "дааа потеря в скорости стоит того!"
Тот уровень абстракции который в Руби выше чем в Питоне - не даёт таких преимуществ, которые можно было бы сказать "дааа потеря в скорости стоит того!"
Ага - свою мысль Вы сказали 5 раз - и я ее понял, только на мой вопрос Вы так и не ответили :)
Это дело в большей степени индивидуальных предпочтений - для кого то более расширенные возможности искупают некоторые проблемы с производительностью - а для кого то нет
Тот уровень абстракции который в Руби выше чем в Питоне - не даёт таких преимуществ, которые можно было бы сказать "дааа потеря в скорости стоит того!"
Это дело в большей степени индивидуальных предпочтений - для кого то более расширенные возможности искупают некоторые проблемы с производительностью - а для кого то нет
я сейчас и вовсе собираюсь начать проект http-сервера на Си который будет выстраивать MVC/Event фреймворк для пользовательского питоновского кода.
Это конечно очень интересно - удачи! :)
хех, если получиться то что хочется... вам понравится =)
Ну посмотреть на это будет определенно полезно в любом случае - мне по крайней мере.
Хотя скорее всего идея с собственным http сервером неверное не всем придется по вкусу :(
Хотя скорее всего идея с собственным http сервером неверное не всем придется по вкусу :(
ну возможность привинтить к существующему серверу посредством fastcgi/cgi будет конечно же. Только я хочу сделать так, чтобы смысла в этом было мало ;). Если вы посмотрите в исходники lighttpd/apache/nginx - поймёте что http-сервер в общем-то написать не сложно. Единственный скользкий момент - ивенты FD (select,poll,epoll,kqueue) - в некотрых легко наделать кучу ошибок (особенно в epoll, он ошибок не прощает). На то и opensource :).
Ага – я представляю себе устройство web сервера – и это конечно не самое сложное то есть на свете.
Но проблема в другом – больше в психологии: Зачем заморачиваться с каким то другим сервером, когда апач (допустим) работает нормально и надежно? – Вот что люди будут думать.
Как пример – для web приложений Руби существует специальный сервер Mongrel – на самом руби и написанный. Причем руби приложения под этим сервером работаю быстрее и потребляют меньше ресурсов чем под Апачем/нджинксом и т.д.
Но не смотря на это хостеры с упорством сажают Руби приложения под Апач + FastCGI. Почему? В силу привычки и не желания разбираться с настройкой нового софта.
Скорее всего у Вас будет точно так же – к сожалению :(
Но проблема в другом – больше в психологии: Зачем заморачиваться с каким то другим сервером, когда апач (допустим) работает нормально и надежно? – Вот что люди будут думать.
Как пример – для web приложений Руби существует специальный сервер Mongrel – на самом руби и написанный. Причем руби приложения под этим сервером работаю быстрее и потребляют меньше ресурсов чем под Апачем/нджинксом и т.д.
Но не смотря на это хостеры с упорством сажают Руби приложения под Апач + FastCGI. Почему? В силу привычки и не желания разбираться с настройкой нового софта.
Скорее всего у Вас будет точно так же – к сожалению :(
посмотрим, я ведь для своего проекта это в первую очередь делаю =).
да и 10-1
да и 10-1
посмотрим, я ведь для своего проекта это в первую очередь делаю =).
да и 10-11 тысяч req/s там, где php (hello world) выдает 1200, а django - 3000... все же не шутки =).
да и 10-11 тысяч req/s там, где php (hello world) выдает 1200, а django - 3000... все же не шутки =).
Вы сами тестировали mongrel+rails? ТАК ПОПРОБУЙТЕ! Мои тесты из серии "Hello, World!" показали проигрышь почти в ~20 раз mod_perl! Попробуйте представить такую разницу на рабочей системе! В состояние будете объяснить руководству, что нужно покупать 20 серверов, чтобы выполнять те же задачи что может 1 сервер!?!? Вдумайтесь! На "выхлопе" реальных 50 запросов (HTTP) со средней машины pentium4! Если рельсы так работают без бизнес-логики с одним запросом на базу, то какая будет производительность для законченной production-системы? 10 запросов? Бред...
Пример рельсов специально разработанных под apache1/2 !? Разве существует что-то вроде mod_rails? Я такого не встречал. Рельсы запускается отдельным демоном, имеют свои веб-сервера(webrick, mongrel и пр.). То про что Вы говорите идеологически противоречит рельсам - "рельсы должны быть написаны на руби", мне тоже удивительно почему выбрали такую точку зрения, решение на более низкоуровнем языке даже под apache 1.3 будет МНОГО производительнее. Утверждения "быстрее и потребляют меньше ресурсов чем под Апачем/нджинксом" абсурдны, рельсы это framework написанный на руби, к сожаленью он "будет и должен" кушать очень много ресурсов. Единственный плюс такого подхода для построения веб-систем который я обнаружил - удобство для разработчика, пока не более...
P/S: Стал уважать производительность mod_php
P/S2: Производительность приложений RoR единственный минус мной обнаруженный, в остальном язык и платформа достойны внимания! Не смотря на это продолжаю изучать "эксперементально" RoR.
P/S3: Плз, не путайте протокол FCGI, веб-серверы Apache/Nginx/Lighty (в случае RoR они являются прокси-серверами, проще говоря frontend'ами, их производительность и RoR имеют мало общего, RoR исполняется со своим HTTP-сервером, который Вы можете выбрать, например mongrel) и платформу-фреймворк RoR.
Пример рельсов специально разработанных под apache1/2 !? Разве существует что-то вроде mod_rails? Я такого не встречал. Рельсы запускается отдельным демоном, имеют свои веб-сервера(webrick, mongrel и пр.). То про что Вы говорите идеологически противоречит рельсам - "рельсы должны быть написаны на руби", мне тоже удивительно почему выбрали такую точку зрения, решение на более низкоуровнем языке даже под apache 1.3 будет МНОГО производительнее. Утверждения "быстрее и потребляют меньше ресурсов чем под Апачем/нджинксом" абсурдны, рельсы это framework написанный на руби, к сожаленью он "будет и должен" кушать очень много ресурсов. Единственный плюс такого подхода для построения веб-систем который я обнаружил - удобство для разработчика, пока не более...
P/S: Стал уважать производительность mod_php
P/S2: Производительность приложений RoR единственный минус мной обнаруженный, в остальном язык и платформа достойны внимания! Не смотря на это продолжаю изучать "эксперементально" RoR.
P/S3: Плз, не путайте протокол FCGI, веб-серверы Apache/Nginx/Lighty (в случае RoR они являются прокси-серверами, проще говоря frontend'ами, их производительность и RoR имеют мало общего, RoR исполняется со своим HTTP-сервером, который Вы можете выбрать, например mongrel) и платформу-фреймворк RoR.
Большей частью питон можно разогнать до высоких скоростей, переписывая стандартные модули (которые в большинстве своём на самом питоне) - на Си.
Кстати - на Руби все точно так же :) И собственные модули на С переписывают и даже в Руби код вставки на С делают :)
и какие классные чуваки-рубироиды... а все отсьальные - дурачки! а особенно пыхыпышники, перловцы, сиплюшкины, джависты.....
Кроме того, вы ____можите_____ использовать оба оператора
ОЧЕПЯТКА!
ОЧЕПЯТКА!
эта статья "10 причин для перехода на Ruby" никак не перескается со статьёй "10 привычек, быстрее всего приводящие к бедности" (http://imager.habrahabr.ru/blog/27893.ht…) ?
опять меня заминусуют, но раби это критинизм.
UFO just landed and posted this here
"Впервые увидев это, я был запечатлен"
:-) Бросайте Ruby, учите Russian.
Шучу, конечно. Поправьте на "впечатлен".
:-) Бросайте Ruby, учите Russian.
Шучу, конечно. Поправьте на "впечатлен".
UFO just landed and posted this here
> А насколько легко писать биндинги для C-библиотек?
Несложно. Намного доступнее, чем PerlXS, по крайней мере.
Несложно. Намного доступнее, чем PerlXS, по крайней мере.
> Синтаксис конечно у него интересный, но не вижу принципиальных отличий от python.
да так, в пару раз медленнее, да и ООП чуть более назойлив... Ну ещё, говорят, эстетически Python Eggs не так круто смотрится как Ruby Gems... :)
да так, в пару раз медленнее, да и ООП чуть более назойлив... Ну ещё, говорят, эстетически Python Eggs не так круто смотрится как Ruby Gems... :)
Незнаю как у Вас "отношению складываются" с системой пакетов gems, но ни рельсы, ни адаптер/драйвер postgresql из них поставить не удалось... :( поставил всё нужное из пакетов deb за секунд 20 =) Теоретически gems очень крутая штуковина, но если бы еще работала... Если бы такая система была для CPAN, может кто знает? Если честно надоело уже бодаться со сборками из исходников)
UFO just landed and posted this here
3 — не логично. Точка с запятой учит логике.
4 — спорно, тут на любителя.
5 — жесть, бедная память сервака =(
8 — xml рулит, легко парсится и читается. Ваше заявление — абсурд.
Моё мнение, с руби можно побаловаться, но пока серверы стоят дороже возможности писать на «быстрых» языках
4 — спорно, тут на любителя.
5 — жесть, бедная память сервака =(
8 — xml рулит, легко парсится и читается. Ваше заявление — абсурд.
Моё мнение, с руби можно побаловаться, но пока серверы стоят дороже возможности писать на «быстрых» языках
Интересно, а каким образом возврат значения так сильно повлияет на память сервака?
насчет yml правильный тезис: писать и читать _простые_ структуры как конфиги или модели active record на yml горздо удобнее. Парсинг таких структур тоже проще. библиотек для обработки есть на c++ java python php. Я уж не говорю о том что yml это фактически json.
Помимо Ror, yml активно применяется в Symfony.
Я уж не говорю что завяли не то что xml sucks, а то что в некоторых случаях есть более удобный инструмент как yml
Помимо Ror, yml активно применяется в Symfony.
Я уж не говорю что завяли не то что xml sucks, а то что в некоторых случаях есть более удобный инструмент как yml
возможно вы правы, но меня полностью устраевает работа с xml, как разработчика. А как пользователю, мне не нужны прочие форматы, только xml. Во-первых, это уже стандарт. Во-вторых, xml не заканчивается на разметке или передаче данных.
Хотя, повторюсь, я не утверждаю что остальные технологии типа json это фуфло. Для разработчиков они действительно более удобоваримы. Но заявление автора что xml ушел в лес очень ошибочно.
YAML, кстати, очень хороший язык для сериализации. Более того, его можно рассматривать как подмножество JSON. Например, в одном ajax-приложении я использовал перловый модуль YAML::Syck для разбора JSON. Этот же модуль позволяет сбрасывать перловые структуры в конфиг и забирать их обратно, при этом конфиг отлично читается и правится от руки. Минимум лишних символов. ЕМНИП, YAML разрабатывался вообще для Python; во всяком случае, очень на него похож.
этож страшно даже подумать - некоторые алгоритмы и штуки на Си могут быть в сотни раз быстрее чем те же на Ruby. Купить 1 сервер или 100? :) Очень конечно примитивная аналогия, но тем не менее.. сейчас я тебя заплюсую.
Некоторые алгоритмы и штуки всегда будут быстрее на Си, чем на каком либо другом языке. Значит ли это что другие языки не нужны?
это значит что о Си забывать не стоит =). А вот "удобно" без строгой типизации можно и на питоне писать. Так я вот не пойму - зачем ещё более высокоуровневый (т.е. ещё более сверх-высокоуровневый) язык? На питоне скорость разработки чистого кода сравнима с Ruby. Да тоже самое и PHP касается, но он уже не так удобен и логичен. Так за что платятся потраченные такты Ruby? За возможность написать 5.times.. вместо for i in range(5)..?
Так за что платятся потраченные такты Ruby? За возможность написать 5.times.. вместо for i in range(5)..?
Видите ли в чем проблема :) Вы видите в 5.times улучшение синтаксиса - которое приятно, но не критично для выбора языка - а на самом деле в этом даже самом простом примере видна одна из тех вещей которые отличаю Руби от других языков (PHP, Java, Perl, Питон и т.д.) - Руби полностью ООП язык. Стоит ли улучшение синтаксиса - уменьшения производительности? Наверное нет. Но стоит ли уменьшения производительности новые возможности ООП - наверное да :)
а давайте Вы скажете какие-такие возможности ООП которых нет, скажем, в том же Питоне стоят уменьшения производительности? :)
А давайте :) Руби полностью ООП язык (все - объекты) - в отличее от Питона. В следствии этого (но и не только этого) в Руби можно изменять основные типы-классы - числа, массивы, строки и т.д. А в Питоне встроенные классы изменять нельзя.
считаете что это стоит снижения проивзодительности? :) Программисты старой закалки иногда до сих пор любят даже строгую типизацию. По той простой причине - что это наводит абсолютный порядок. А вот изменять встроенные типы - путаницу может ввести ещё какую. Да и особого смысла в этом - нет! Ну какоооой смысл? писать 5.yahoo(6) вместо yahoo(5,6)? Это не даёт преимуществ в логике. Это не даёт преимеществ в скорости разработки.
Это может и удобнее в каких-то конкретных случаях. Но эта функциональность легко дублируется простеньким пользовательским объектом =). Спрашивается - надо ли делать числа объектами всегда? Или лучше иметь возможность это сделать когда действительно нужно. И именно когда действительно нужно жертвовать проивзодительностью при работе с базовыми типами?
Это может и удобнее в каких-то конкретных случаях. Но эта функциональность легко дублируется простеньким пользовательским объектом =). Спрашивается - надо ли делать числа объектами всегда? Или лучше иметь возможность это сделать когда действительно нужно. И именно когда действительно нужно жертвовать проивзодительностью при работе с базовыми типами?
Согласен на все 100. Ничего хорошего в том, что можно писать 5.yahoo(6) вместо yahoo(5,6) нет. Более того - огромным преимуществом с точки зрения читабельности кода является уверенностьв том, что классы системных библиотек именно таковы, какими ты их знаешь, и автор кода не мог добавить туда отсебятины.
считаете что это стоит снижения проивзодительности? :)
Так кроме того есть еще несколько очень хороших вещей (как блоки например) - которые все вместе стоят того.
Программисты старой закалки иногда до сих пор любят даже строгую типизацию. По той простой причине - что это наводит абсолютный порядок.
Программисты старой закалки пишут на С/С++ - им эти споры вообще смешны :)
Да и особого смысла в этом - нет! Ну какоооой смысл? писать 5.yahoo(6) вместо yahoo(5,6)? Это не даёт преимуществ в логике. Это не даёт преимеществ в скорости разработки.
Подымитесь на уровень выше - это не изменение синтаксиса - это другая идеология. Разработчик имеет полный контроль над всеми элементами программы (захочет - цифры будут вести себя как строки, а строки - как массивы) - это одновременно гибкость и мощность и почти полное отсутствие ограничений в реализации любой задумки/мысли/идеи.
Не идея подгоняться под возможности языка - а язык расширяется, что бы воплотить идею - вот за это любят Руби :)
блоки в руби мне тоже нравятся. Но мне не нравится что их понимают только те кто общался с руби.
На счет девелоперов C/C++ - вы очень круто ошибаетесь. Как бы то ни было, но языки сверх-высокого уровня грамотный C/C++ девелопер будет использовать часто. Вон - половина прикладных утилит в том же gentoo написана на python. В основном - не особо критичные к скорости. Как думаете, кто их написал? =)
А по поводу изменения всего чего хочу. Я вам сразу 2 касяка скажу: например вы писали, писали свою программу и дописали к числам метод buff(). А в следующей версии ruby этот метод появился нативный. Что делать? Если вы оставите свой buff() то любой новый программист взглянув на ваш код - будет думать что buff() делает то что делает нативный buff(). Понимаете косяк?
На счет девелоперов C/C++ - вы очень круто ошибаетесь. Как бы то ни было, но языки сверх-высокого уровня грамотный C/C++ девелопер будет использовать часто. Вон - половина прикладных утилит в том же gentoo написана на python. В основном - не особо критичные к скорости. Как думаете, кто их написал? =)
А по поводу изменения всего чего хочу. Я вам сразу 2 касяка скажу: например вы писали, писали свою программу и дописали к числам метод buff(). А в следующей версии ruby этот метод появился нативный. Что делать? Если вы оставите свой buff() то любой новый программист взглянув на ваш код - будет думать что buff() делает то что делает нативный buff(). Понимаете косяк?
На счет девелоперов C/C++ - вы очень круто ошибаетесь.
Нет не ошибаюсь – достаточно хватает общения и в жизни и в сети. Хотя бы RSDN почитайте – сколько там заявлений о том что языки без статической типизации – ошибка природы.
Я вам сразу 2 касяка скажу: например вы писали, писали свою программу и дописали к числам метод buff(). А в следующей версии ruby этот метод появился нативный. Что делать? Если вы оставите свой buff() то любой новый программист взглянув на ваш код - будет думать что buff() делает то что делает нативный buff(). Понимаете косяк?
Понимаю – а второй косяк? :) Ну а по этому поводу – да риск конечно есть – но 1) документацию ни кто не отменял 2) Какой язык от этого защищен? Проблема обратной совместимости – это проблема всегда была везде. (Питон 3000 не будет обратно совместим с Питоном 2.5 допустим, у РНР такие же проблемы и т.д.)
Сервер стоит от 1 000 баксов. Поставить у хостера, от 50 в месяц. Арендовать сервер, от 200.
А сколько стоит время вменяемых программистов?
А сколько стоит время вменяемых программистов?
сервер за 1000 баксов - это домашняя машинка =). Стоимость настоящих серверов начинается от 3000, и то если заказывать прямо у производителя (я у IBM заказываю, через знакомых). Давайте подумаем о разнице, хотя бы 20-ти кратной. 3000 тысячи или 30000 тысяч. А сколько времени Вменяемому C++ программисту нужно будет чтобы ускорить проект в 20 раз? Немного, поверьте =). Особенно если Ruby :).
Вменяемый программист будет использовать инструментарий подходящий к ситуации. В случае большинства сайтов - это языки типа руби.
серверы от IBM призваны нестабильными, насколько я знаю. Хотя могу ошибаться, сам с ними дела не имел.
Да и это не важно. Ваше заявление что серваки за 1000 баксов это домашние странички — ложно. Клевета и треп.
Cервис статистики liveinternet.ru держится на одном серваке как раз, я думаю, в районе 1000 баксов, не дороже. А считает он пол рунета, если не больше.
Да и это не важно. Ваше заявление что серваки за 1000 баксов это домашние странички — ложно. Клевета и треп.
Cервис статистики liveinternet.ru держится на одном серваке как раз, я думаю, в районе 1000 баксов, не дороже. А считает он пол рунета, если не больше.
блин лишь бы поспорить. Хотсвап? Горячая замена блоков питания? RAID5 хотя бы? Серверный чипсет? Ксеоны/Оптероны? Вы вообще представляете сколько это стоит? :) 3 месяца назад брал 4-ксеоновый сервер (8 ядер всего), отдал 6000$.
все эти страшные словечки конечно здорово. Вы были в ДЦ хостерских? Мастерхост, петерхост и прочие. Многое их оборудование висит на supermicro решениях. Никаких горячих замен винтов, питания и прочего там нет, RAID максимум зеркало аппаратное, материнки не очень то сетевые (хотя тут я могу ошибаться, сужу по себе) и не о каких серверных процов речь не идет.
Вы доказываете, что крутые компы дорого стоят. Я доказываю, что для грамотного скрипта зачастую достаточно простого сервака. Брать тот же rax.ru в пример. Там все на Си, там свой web-сервер (0w) и своя бинарная база данных.
Крутые решения это здорово. Работал с HP, Dell решениями. Приходишь, на горячую достаешь винт, аппаратный рейд сразу трансформится на оставшихся. Красиво, вечело, но чаще не нужно.
Конечно, при пректировании масштабирования крупного проекта может показаться, мол лучше юзать дорогие серваки, где можно быстро что-то поменять. Но это все равно время и неудобства. Практика показывает, что проще взять не брендовые решения, но оставить несколько серваков в избыток.
Да и потом не каждый может позволить себе отдать 6 000 баксов «всего за 8 ядер». За 6 штук можно взять 2 мощных не брендовых сервака примерно схожей комплектухой что и ваши, а то и лучше. Но это будут 2 отдельный сервера, а не один.
Вы доказываете, что крутые компы дорого стоят. Я доказываю, что для грамотного скрипта зачастую достаточно простого сервака. Брать тот же rax.ru в пример. Там все на Си, там свой web-сервер (0w) и своя бинарная база данных.
Крутые решения это здорово. Работал с HP, Dell решениями. Приходишь, на горячую достаешь винт, аппаратный рейд сразу трансформится на оставшихся. Красиво, вечело, но чаще не нужно.
Конечно, при пректировании масштабирования крупного проекта может показаться, мол лучше юзать дорогие серваки, где можно быстро что-то поменять. Но это все равно время и неудобства. Практика показывает, что проще взять не брендовые решения, но оставить несколько серваков в избыток.
Да и потом не каждый может позволить себе отдать 6 000 баксов «всего за 8 ядер». За 6 штук можно взять 2 мощных не брендовых сервака примерно схожей комплектухой что и ваши, а то и лучше. Но это будут 2 отдельный сервера, а не один.
я ступил, не IBM, Intel. Перед глазами IBM-овский прайс просто валялся =).
UFO just landed and posted this here
Ну, я сам вроде вменяемый программист и так получилось что у меня дейсвтительно есть свой сервер и он дейсвтительно обошелся мне в 1100 примерно и размещение стоит действительно 70 баксов в месяц. Только в итоге я реально понимаю что разработка приложений на руби займет все же больше или столько же времени (с учетом того, что серверный код пишется достаточно быстро, дольше занимает отладка, клиентские скрипты, верстка итп) а работать тот же php будет гораздо быстрее. Тем более если кешировать его тем же мемкешом.
Хотя это моё мнение с моими позициями...
Хотя это моё мнение с моими позициями...
Каким образом ';' может научить логике?
Когда Ruby будет нативно понимать и не через одно место работать с уникодом, то только тогда можно что-то серьезное о руби говорить.
хы-хы.. хоть кто-нибудь его понимает нативно?
u"str", догадайтесь откуда сие +)
Java. Там все строки суть юникод. Не юникода нет.
это красивая сказка :)
теоретически все строки там юникод. практически же, я после прочтения Очень Умной Книжки про Java, как бы не Thinking in Java, где так и было написано, что все строки там юникод, попытался сделать HelloWorld.java на русском. Получил что-то типа "??????, ???!" :)
толку-то от внутреннего представления строк, если отображаются только латинские буквы
теоретически все строки там юникод. практически же, я после прочтения Очень Умной Книжки про Java, как бы не Thinking in Java, где так и было написано, что все строки там юникод, попытался сделать HelloWorld.java на русском. Получил что-то типа "??????, ???!" :)
толку-то от внутреннего представления строк, если отображаются только латинские буквы
Раскажите - это как "через одно место работает Руби с юникодом" - заинтриговали просто :)
Вот это «место».
http://wiki.rubyonrails.org/rails/pages/HowToUseUnicodeStrings
Да, и как насчет UTF-16/UCS-2?
Да, и как насчет UTF-16/UCS-2?
Ну и? Указать при работе с RoR в нескольких местах что кодировка - UTF-8 - это работа через одно место? Типа программа должна прочитать мысли разработчика - и сама поставить нужную кодировку? :)
К тому же Вы привели пример о RoR, а spoof писал о Руби вообще.
UTF-16 не совместим с ASCII (в отличее от UTF-8) - по этому не понятно для чего он нужен в данный момент
К тому же Вы привели пример о RoR, а spoof писал о Руби вообще.
UTF-16 не совместим с ASCII (в отличее от UTF-8) - по этому не понятно для чего он нужен в данный момент
Указать — я проблемы не вижу, но зачем же работать с уникодными строками как-то по-другому, чем с другими? Вдобавок всё, где внутреннее представление строк отлично от UTF-16, мягко говоря, работает с уникодом отвратно.
И я не заостряю внимание именно на руби — это болезнь многих (вот JRuby, например, внутри работает именно с UTF-16).
И я не заостряю внимание именно на руби — это болезнь многих (вот JRuby, например, внутри работает именно с UTF-16).
Я тоже от Руби был "запечатлен". Реально хороший язык. Лямда выражения, все объект, миксы, синглетоны и все такое. Но что меня остановило, это то что он очень медленный. Почему-то мне в голову приходят идеи, реализации которых даже на C++ медленными получаются, а на Руби ждать замучаешься. :)
вот бляха муха.
мастерство - не в том чтобы писать на Ruby. А в том чтобы выбирать правильный инструмент для каждого конкретного случая. Как правило, идеальным вариантом будет смесь из интерпретируемых/компилируемых языков. Часто нужно будет их заставлять свободно общаться между собой.
Скорость разработки же зачастую больше зависит от наличия готовых инструментов. И желания использовать уже написанное, вместо самописного.
Короче не знаю. Устало улыбаюсь. )))
мастерство - не в том чтобы писать на Ruby. А в том чтобы выбирать правильный инструмент для каждого конкретного случая. Как правило, идеальным вариантом будет смесь из интерпретируемых/компилируемых языков. Часто нужно будет их заставлять свободно общаться между собой.
Скорость разработки же зачастую больше зависит от наличия готовых инструментов. И желания использовать уже написанное, вместо самописного.
Короче не знаю. Устало улыбаюсь. )))
Все описанное в статье, можно сказать и о Python. Вплоть до lambda-функций и того, что все является объектом. А причина "так как не хотел, чтоб неправильные отступы были причиной неполадок в моем коде", имхо, может вызвать только улыбку. Питонеры меня поймут. Отступы это красиво и это приучает писать аккуратно. К тому же современные редакторы предлагают функцию auto-indent... Что касается Rails - на Python есть Django и Pylons :) Опять же, имхо, они более гибкие.
Пожалуй, выбор между Ruby и Python это больше дело вкуса. И главное - это просто делать свое дело быстро и качественно.
Пожалуй, выбор между Ruby и Python это больше дело вкуса. И главное - это просто делать свое дело быстро и качественно.
Ребята всё видят так как им хочется. Я уже не первый раз предлагаю сравнить Python и Ruby, но чёт всё никак не сростается, видать.
5 копеек с точки зрения JEE:
В свое время на theserverside.com начали активно тусоваться RoR фэны, шумели много, поэтому возникла мысль, что и язык и рельсы стоят того, чтобы примерить на себя. Попробовал: идея красивая, много изящных вещей, в целом приятное впечатление, но.
- проблемы с UTF-8. Для наших задач - это шоустоппер. В Java с юникодом гораздо лучше. Не идеально, но в целом больших проблем не возникает.
- нет внятной IDE. После того, как привыкнешь е действительно хорошему (Intellij IDEA рулит), трудно возвращаться к уровню текстового редактора. Возможно это был слишком поверхностный взгляд на вещи и многие проблемы, которые хорошая IDE решает в Java - в руби просто не существуют. Хотя вряд ли.
- не было стабильной платформы для разворачивания приложений. Ни нам, ни нашим клиентам не нужны глюки. Та платформа, на которой мы работаем - зрелая и стабильная. Поэтому и приложение работает годами без перезагрузок, и утечек памяти и прочих побочных эффектов, характерных молодым платформам не существует.
- производительность
в то же время понравилась идея использования соглашений вместо явного описания конфигурации, что и было успешно применено в нашем Java проекте - существенно сократили и упростили код. За это разработчикам рельсов большое человеческое спасибо.
Так что изучайте что-то новое - лишним точно не будет.
В свое время на theserverside.com начали активно тусоваться RoR фэны, шумели много, поэтому возникла мысль, что и язык и рельсы стоят того, чтобы примерить на себя. Попробовал: идея красивая, много изящных вещей, в целом приятное впечатление, но.
- проблемы с UTF-8. Для наших задач - это шоустоппер. В Java с юникодом гораздо лучше. Не идеально, но в целом больших проблем не возникает.
- нет внятной IDE. После того, как привыкнешь е действительно хорошему (Intellij IDEA рулит), трудно возвращаться к уровню текстового редактора. Возможно это был слишком поверхностный взгляд на вещи и многие проблемы, которые хорошая IDE решает в Java - в руби просто не существуют. Хотя вряд ли.
- не было стабильной платформы для разворачивания приложений. Ни нам, ни нашим клиентам не нужны глюки. Та платформа, на которой мы работаем - зрелая и стабильная. Поэтому и приложение работает годами без перезагрузок, и утечек памяти и прочих побочных эффектов, характерных молодым платформам не существует.
- производительность
в то же время понравилась идея использования соглашений вместо явного описания конфигурации, что и было успешно применено в нашем Java проекте - существенно сократили и упростили код. За это разработчикам рельсов большое человеческое спасибо.
Так что изучайте что-то новое - лишним точно не будет.
Про проблемы - это наверное давно было :) Сейчас
1) Проблем с UTF-8 нет.
2) IDE со всеми необходимыми функциями есть - даже несколько на выбор
3) С развертыванием приложений особых проблем не наблюдается.
1) Проблем с UTF-8 нет.
2) IDE со всеми необходимыми функциями есть - даже несколько на выбор
3) С развертыванием приложений особых проблем не наблюдается.
1) с каких пор ? По моему только в 2.0 обещали что-то сделать. Пока все остановились на том, что в рельсах сделали механизм String.chars и решили пока жить так. Или я что-то упустил ?
Да уже около года где то у RoR - UTF-8 кодировка по умолчанию для ввода/вывода - и все вещи (изменение регистра, нормализация и работа с регулярными выражениями) - для юникод строк замечательно работают.
А еще раньше - все это добавлялось с помощью плагина.
А еще раньше - все это добавлялось с помощью плагина.
Мы не о рор, а о поддержке юникода руби. Что касается плагина - Юлик конечно мегамолодец и плагин прекрасен, но он написан на руби и просто переопределяет методы у строки. Внутри руби строки как хранились тупым массивом по байту на строку, так и хранятся. И матз сказал что до 2.0 ничего менять не собирается. Это не называется - нет проблем. Это называется проблемы есть, но их можно обойти разными хаками.
Явщики привыкли что в ней везде внутри юникод :)
Явщики привыкли что в ней везде внутри юникод :)
Мы не о рор, а о поддержке юникода руби.
Так maximwirt говорил именно о RoR – о нем я и сказал.
А раз Вы знаете про Юлика и юникодовый плагин – тогда я Вам просто и скажу :) Идеология Руби – что Руби не внутренне заточен под одну кодировку (юникод в данном случае) – а сделан так что бы работать с любой - имеет как свои плюсы так и минусы.
А указание в начале программы (через глобальную переменную KCODE) – в какой кодировке желаете работать – решает почти все проблемы с юникодом. Об чем разговор тогда? :)
У каждого языка програмирования свои прелести и свои недостатки. Думаю, все прекрасно знают недостатки того же PHP и XML. Тем более, что автор явно на них указал. Только вот загвоздочка - почему-то не увидел ни слова о негативах Ruby, хотя они есть, и накоторые указаны в комментах. Так почему бы глубокоуважаемому автору не указать на них в статье?
А я недавно вник, какой на самом деле клёвый язык Javascript. Теперь серверную часть (на php) пишу с меньшим удовольствием, чем клиентскую, хотя раньше было наоборот. Если, конечно, не принимать во внимание выстругивание костылей для IE (но это в основном вёрстки касается).
Мне Ruby тоже нра)) но ...)) Может еще сравним RoR с .NET и все что мелкомягкие вокруг него выстроили??? =)) или все же не будем ? =) А вообще зачем опять холи вор устраивать, ясно что на вкус и цвет товарищей нет. Тут в комментах стока крика сразу поднялось, а автор всего лишь высказал свою точку зрения, а не аксиомы.
UFO just landed and posted this here
Согласен это минусы... но кроссплатформенность "открытых" решений не всегда сто процентная, на одной платформе может более правильно работатть чем на другой, та ктчо завязка под одну платформу не так уж и плохо, зато дают как бы гарантию, что все будет работать как нада)) другое дело что это не всегда так, но часто для корпораций это лучше ГНУ лицензия, или вообще чтот похожее на "AS IS" , ну а насчет платности.. опять таки крупные проекты что на Линукс, что на Виндовс машинах обходятся примерно одинаково,а вот поддержка прогаммеров таки у мелкософта намного мощнее... ну эт мое личное мнение, вполне возможно отличается от действительности, но пока на мое практике это именно так. =)
Ничепадобнаво (с). .NET ни разу не платная. И не только под Windows.
Програмирование - это не только искусство. Точнее не прежде всего. Прежде всего програмирование - это та самая вещь, которая в настоящее время должна быть поставлена на поток.
А теперь посмотрите: вы не выбрали питон из-за того, что не желаете ставить отступы (именно не желаете, иначе бы в примерах вы бы их поставили). Мне совершенно не понятно, как можно говорить об искусстве, а уже тем более "о конвеере" с людьми, которые даже не ставят отступы. Ещё Кнут завещал ставить отступы. Это общепризнано. То, что вы знакомы с большим кол-вом языков в том числе и скриптовых, не говорит о том, что вы хороший програмист. Вы сами сказали "развлечение".
Так вот, а теперь подумайте о сфере применения Ruby, кроме как для развлечения? Конкурировать он может разве что с питоном. Но как вы думаее, почему выберут питон? По причине, которую я описал первой и потому, что питон просто более универсален и используется сейчас практически везде, и потому что интерпретаторы питона есть практически для каждой ОС (в т.ч. и мобильной).
Не обижайтесь, судя по Вашему описанию, Ruby - хороший язык. История знает очень много хороших языков. Но честно говоря, после вашего описания, мне слабо верится в светлое будующее этого языка. Хотя отдельные вещи мне очень и очень понравились, но прежде всего "проограмирование должно быть поставлено на поток", а в этих целях, этот язык уже не является чем-то большим, чем питон. А последний имеет гораздо большую распространённость.
А теперь посмотрите: вы не выбрали питон из-за того, что не желаете ставить отступы (именно не желаете, иначе бы в примерах вы бы их поставили). Мне совершенно не понятно, как можно говорить об искусстве, а уже тем более "о конвеере" с людьми, которые даже не ставят отступы. Ещё Кнут завещал ставить отступы. Это общепризнано. То, что вы знакомы с большим кол-вом языков в том числе и скриптовых, не говорит о том, что вы хороший програмист. Вы сами сказали "развлечение".
Так вот, а теперь подумайте о сфере применения Ruby, кроме как для развлечения? Конкурировать он может разве что с питоном. Но как вы думаее, почему выберут питон? По причине, которую я описал первой и потому, что питон просто более универсален и используется сейчас практически везде, и потому что интерпретаторы питона есть практически для каждой ОС (в т.ч. и мобильной).
Не обижайтесь, судя по Вашему описанию, Ruby - хороший язык. История знает очень много хороших языков. Но честно говоря, после вашего описания, мне слабо верится в светлое будующее этого языка. Хотя отдельные вещи мне очень и очень понравились, но прежде всего "проограмирование должно быть поставлено на поток", а в этих целях, этот язык уже не является чем-то большим, чем питон. А последний имеет гораздо большую распространённость.
Если программирование поставят на поток, то сверх прибыльными будут те компании где это исскуство. Потому что, желание работать.
Так вот, а теперь подумайте о сфере применения Ruby, кроме как для развлечения? Конкурировать он может разве что с питоном. Но как вы думаее, почему выберут питон? По причине, которую я описал первой и потому, что питон просто более универсален и используется сейчас практически везде, и потому что интерпретаторы питона есть практически для каждой ОС (в т.ч. и мобильной).
Вообще то Руби ни чуть не менее универсальный чем Питон. И интерпретаторы для Руби есть практически для каждой OC (в т.ч. мобильной - и Руби даже запускали на, прости господи, iPhone :)
Но есть то, что есть чего у Питона нет - уже сейчас Руби может работать на платформе Java, с использованием Java серверов приложений и пользуясь всем огромным набором Java библиотек - причем работы по интеграции Руби в Java спонсируются SUN и IBM.
А платформа Java - это тот самый мир промышленного программирования, о котором Вы так проникновенно написали - и Руби уже почти там (в отличие от :)
А что там с Jython ? Которому уже сто лет в обед ?
Это тот который 6 лет лежал никому не нужный и не обновлялся пока авторы не заметили что Сан купил парней разрабатывающих jruby и его уже даже начали бодро использовать?
"Используйте наш замечательный продукт! Но если он нам наскучит - следующий багфикс релиз может выйти лет через пять"
Справедливости ради надо сказать, что IronPython - вполне себе адекватная штука.
"Используйте наш замечательный продукт! Но если он нам наскучит - следующий багфикс релиз может выйти лет через пять"
Справедливости ради надо сказать, что IronPython - вполне себе адекватная штука.
google_fan очень хорошо написал :) Только добавлю - когда получиться заставить работать допустим Django на Java, а потом развернуть Django под Java сервером приложений (таком как SUN-овский GlassFish) - то есть сделать все то что счас можно без проблем сделать с Ruby и Ruby on Rails - тогда и будем говорить "А что там с Jython ?" :)
А почему мерилом выступает RoR ? Который вы зачем-то хотите запустить на аппсервере. Jython нормально так работает. Например, для eclipse можно писать плагины на python. Это ли не показатель ?
Мерилом выступает Django - как реально работающие и востребованное приложение. Можно его запустить на Java и интегрировать с существующими Java приложениями. Позволяет это сделать Jython? Нет.
А JRuby c RoR - позволяет. Вот и все.
А писать плагины для eclipse можно на любом языке реализованном на Java платформе - хоть Jython, хоть JRuby, хоть Groovy, хоть Scala - это не показатель.
А JRuby c RoR - позволяет. Вот и все.
А писать плагины для eclipse можно на любом языке реализованном на Java платформе - хоть Jython, хоть JRuby, хоть Groovy, хоть Scala - это не показатель.
>можите
и все же это слово пишется через буковку "e":) в целом, хороший материал, спасибо! я как раз неторопясь осваиваю Руби...
и все же это слово пишется через буковку "e":) в целом, хороший материал, спасибо! я как раз неторопясь осваиваю Руби...
хотя, все это количество ошибок вводит в ступор. сейчас их нашел море.
Hi!I'mC++!
(10 секунд)
Hi (2 секунды) and I (1 секунда) am Ruby on Rails!
(10 секунд)
Hi (2 секунды) and I (1 секунда) am Ruby on Rails!
Косяки: number: 4.(7), конец, имет...
Спасибо за перевод.
А лямбда это насколько я понимаю, замыкание?
Спасибо за перевод.
А лямбда это насколько я понимаю, замыкание?
Почти уломали (:
Расскажите пожалуйста, а есть ли там какая-нибудь нативная поддержка работы с базами данных?
Расскажите пожалуйста, а есть ли там какая-нибудь нативная поддержка работы с базами данных?
И, еще, дайте, пожалуйста, ссылки на самые популярные IDE, заточенные под Ruby.
UFO just landed and posted this here
А есть ли что-нибудь менее монструозное?
Как-то не греет перспектива тратить часы на настройку IDE.
Например, для PHP есть NuSphere PhpEd. Есть ли что-то подобное: не громоздкое, но вмеру функциональное?
Как-то не греет перспектива тратить часы на настройку IDE.
Например, для PHP есть NuSphere PhpEd. Есть ли что-то подобное: не громоздкое, но вмеру функциональное?
+ еще The 3rd Rail от CodeGear
http://www.codegear.com/products/3rdrail
http://www.codegear.com/products/3rdrail
Какой бы распрекрасный и чудесный язык не был, он становится полезным только тогда, когда под него достаточно библиотек и биндингов. Посмотрел я недавно для своего проектика небольшого на языки разные динамические, скриптовые и выбрал питон. Ну не могу я отказаться от wxPython который мне сделает во всех осях нативный интерфейс, а корба вменяемая под руби есть?
бож ты мой, а нахрена простые типы делать объектами?!
чтобы избежать такого безобразия, вестимо:
if is_string(variable) ...
else if is_numeric(variable) ...
else if is_object(variable) ...
это вроде как есть в php, это давно уже не фишка руби:)
зачем, кстати, мне как сишнику непонятно. никогда не пользовалась:)
мб расскажете?:)
зачем, кстати, мне как сишнику непонятно. никогда не пользовалась:)
мб расскажете?:)
мм.. ну вот тот «пример» что я привёл, это и есть пхп .. и конечно это не фишка руби; фишка руби вот она:
вообщем я не очень понял что ты/вы хотела/ли мне сообщить
________________
хотя и пример мой не слишком реалистичный..
ну вот ещё пример ... по-мне такой код
гораздо приятнее и понятнее чем
а добавить метод стандартному array'ю - это ж сколько счастья может принести ;-)
Numeric.do_something = function() { ... }
String.do_something = function() { ... }
MyClass.do_something = function() { ... }
variable.do_something()
вообщем я не очень понял что ты/вы хотела/ли мне сообщить
________________
хотя и пример мой не слишком реалистичный..
ну вот ещё пример ... по-мне такой код
str.lower().replace('a','b').explode(' ')гораздо приятнее и понятнее чем
explode(strreplace('a','b',strlower(str)), ' ')а добавить метод стандартному array'ю - это ж сколько счастья может принести ;-)
а как по мне, так второй симпаничнее и привычнее. но - очевидно, дело вкуса:)
Привычнее — возможно, но разве «можно» симпатизировать этому монстру? Хотя навреное можно, ведь и симпатии и привычки — явления часто иррациональные.
Вообще, в первом случае всё линейно, одно из другого вытекает, а во втором вложенные скобки вносят хаос.
Я лучше избавлюсь от старых зависимостей чем работать в таком окружении, зная что в мире существует что-то гораздо более ясное. Ну это теория ;-) Хотя были и подтверждения практикой в моей жизни.
Вообще, в первом случае всё линейно, одно из другого вытекает, а во втором вложенные скобки вносят хаос.
Я лучше избавлюсь от старых зависимостей чем работать в таком окружении, зная что в мире существует что-то гораздо более ясное. Ну это теория ;-) Хотя были и подтверждения практикой в моей жизни.
UFO just landed and posted this here
Для написания хорошего продукта обязательно существование мозга и желание работать. А писать можно на чем угодно.
Вы делите шкуру неубитого медведя, наврят-ли кто-то из вас создаст проект хотя-бы близко похожий на яху или майспейс.
Так какой тогда смысл судить о производительности таких проектов?
Так-же, верх тупизны - написание десктоп-клиентов и задач заточеных под интенсивный процессинг на скриптовых языках.
Про руби вспоминают (если не говорить о теории языка, а быть ближе к реалиям) только в одной области, а именно - создание "типичных" (а не супер-мега-ультра) веб приложениий.
И именно здесь он бьёт всех остальных, потому что тут похер на сервер, годится любой. Нужно быстро красиво и просто создать готовое решение и просто его поддерживать.
Так на кой хер понадобились оптероны для сайта обычной компании?!
Так какой тогда смысл судить о производительности таких проектов?
Так-же, верх тупизны - написание десктоп-клиентов и задач заточеных под интенсивный процессинг на скриптовых языках.
Про руби вспоминают (если не говорить о теории языка, а быть ближе к реалиям) только в одной области, а именно - создание "типичных" (а не супер-мега-ультра) веб приложениий.
И именно здесь он бьёт всех остальных, потому что тут похер на сервер, годится любой. Нужно быстро красиво и просто создать готовое решение и просто его поддерживать.
Так на кой хер понадобились оптероны для сайта обычной компании?!
Sign up to leave a comment.
10 причин для перехода на Ruby