Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby
Особенно не положительным 4-й пункт кажется: навязываемый "Ruby Way", который ещё и не имеет однозначной трактовки.
З.Ы. Как-то не нашёл куда логичнее будет это написать: руби почти насквозь императивный, поэтому в декларативные не лезет, а среди языков его нет...

Здравствуйте, Курилка, Вы писали:

К>Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby
К>Особенно не положительным 4-й пункт кажется: навязываемый "Ruby Way", который ещё и не имеет однозначной трактовки.

Сначала по пунктам:

1.Ruby is slow.

Да, медленный. Но Erlang, говорят, так же не быстр, тем не менее, препятствием это не является. Нужно выбирать области, в которых скорость Ruby не будет сказываться печатльным образом. Писать числодробилки на Ruby (пока) -- это демонстрировать отсутствие здравого смысла. Зато для некоторых задач производительность Ruby вообще не как не будет сказываться на скорости, т.к. будут наличиствовать более тормознутые компоненты. Вот примеры из собственного опыта использования Ruby:
a) обработка больших (сотни мегабайт, иногда гигабайты) объемов логов с извлечением из них информации с сохранением в РСУБД. Скорость работы дисковой подсистемы и скорость сохранения информации в БД (со включенными индексами) будет настолько медленнее скорости работы самого Ruby кода, что переписывание данныой задачи даже на C++ не даст прироста производительности и в несколько процентов.
b) создание управляющих скриптов для проведения каких-нибудь сложных действий при помощи других утилит. Например, использование svnadmin для получения dump-ов репозиториев, из архивация, копирование в специальные архивные каталоги и пр. Либо переодический поиск мусора, оставляемого приложением (устаревшие log-файлы, забытые tmp-файл b пр.) с последующей архивацией и/или удалением. Работа внешних утилит будет занимать практически 100% всего времени работы подобного скрипта.
c) обработка C++ исходников с целью поиска #include-зависимостей (в Mxx_ru используется написанный на Ruby вариант). Парсинг тысяч исходных файлов объемом в десятки килобайт так же серьезно нагружает дисковую подсистему. И при этом скорость Ruby скрипта все равно оказывается нормальной для повседневного использования.

Так же можно почитать различные высказывания о скорости работы Ruby-приложений в Web (на основе Ruby-On-Rails) к примеру: Scaling Rails или соотвествующую главу в Agile Web Development with Rails.

2. Ruby's development process is slow.

Смотря с чем сравнивать. Если с C#, то медленный. Если с Java, D или, прости господи, Perl 6, то нормальная скорость. Тем более, что это OpenSource проект. Выпускающий весьма стабильные релизы. Так что, можно оставить данное высказывание на совести автора.

3. Ruby's "official" documentation is sparse and, in some cases, nonexistent.

Да, документация по Core API и стандартным бибиотекам с ruby-doc.org действительно не полная. Но, блин, это же OpenSource со всеми вытекающими. Не хватает чего-нибудь, так разберись и допиши. И себе польза, и окружающим.

К тому же не нужно забывать, что практически вся стандартная библиотека Ruby доступна в Ruby-исходниках, а остальная часть -- в C исходниках. Обратиться к ним за разьяснение каких-то непонятных вопрос дело нескольких минут.

Ну и кроме сгенерированной rdoc-ом документации по API есть еще и книги по Ruby. Например, мне хватило первого издания Programming Ruby (которое доступно в on-line, и входит в дистрибутив OneClickRubyInstaller). А второе издание вообще покрыло столько вопросов, сколько мне на практике и не нужно. Кроме этой книги есть еще:
Ruby Developers Guide
The Ruby Way
Ruby for Rails: Ruby Techniques for Rails Developers
Agile Web Development with Rails
Так что, если не жалеть денег на приобретение книг (либо научившись пользоваться файлообменными сетями), то информации о Ruby совсем не мало.

4. Screw the Ruby Way, sometimes I just want to get things done.

Вообще бред. Программировать на Ruby нужно так, чтобы получался работающий код. Желательно, чтобы код был простым, понятным, сопровождаемым. Но это уже критерии оценки работающего кода. Если же кто-то вместо написания рабочего кода ищет красивые формы кода, то это клиника и к самому языку не имеет ни малейшего отношения.

5. Ruby has shitty XML support.

Бред в том смысле, что язык должен поддерживать XML. Пусть этим, например, Scala занимается, она для этого проектировалась. Поддержка XML должна содержатся в библиотеках. Такие библиотеки есть. Тот же REXML, который входит в стандартную библиотеку Ruby. И опять нужно вспомнить, что Ruby и REXML -- это OpenSource проекты. Если что-то не нравится, то жаловаться не конструктивно. Нет богатого дяденьки (в лице Novell, Sun или Microsoft), который будет вкладывать деньги в сопровождение. Просто так ничего не возникнет. Нужно либо самому доводить проблемную библиотеку до ума, либо помогать ее разработчикам.

---

Резюмируя: первый и третий пункт действительно содержат верную информацию, но с демонстрацией не понимания природы вещей (в частности факта OpenSource природы Ruby и его библиотек). Пятый пункт спорен. Четвертый -- маразм, не заслуживающий внимания.

eao197 wrote:
> c) обработка C++ исходников с целью поиска #include-зависимостей (в
> Mxx_ru используется написанный на Ruby вариант). Парсинг тысяч исходных
> файлов объемом в десятки килобайт так же серьезно нагружает дисковую
> подсистему. И при этом скорость Ruby скрипта все равно оказывается
> нормальной для повседневного использования.
Рекомендую добавить в mxx_ru кэш зависимостей include'ов — на ноутах с
медленным винтом значительно помогает.

Здравствуйте, Cyberax, Вы писали:

C>Рекомендую добавить в mxx_ru кэш зависимостей include'ов — на ноутах с
C>медленным винтом значительно помогает.

Да, это в планах. Как и еще целая куча фич

Здравствуйте, eao197, Вы писали:

Прочтя этот ответ я понял, осознал главную причину по которой нельзя использовать Руби в серьезных проектах. "это же OpenSource со всеми вытекающими" А вытекающие кривизна.

eao197 wrote:
> C>Рекомендую добавить в mxx_ru кэш зависимостей include'ов — на ноутах с
> C>медленным винтом значительно помогает.
> Да, это в планах. Как и еще целая куча фич
Могу еще фичу придумать — конвертер из .jam-файлов в Mxx_ru

Берете мой http://elewise.com/pubrepos/BuildPort/trunk/ и пишите
правила, которые будут выводить список целей в виде файлов проекта для
Mxx_ru (вместо стандартных правил, запускающих компиляцию).

Как показал беглый осмотр — файлы проектов самого Boost'а должны без
особых проблем конвертироваться.

Здравствуйте, VladD2, Вы писали:

VD>Прочтя этот ответ я понял, осознал главную причину по которой нельзя использовать Руби в серьезных проектах. "это же OpenSource со всеми вытекающими" А вытекающие кривизна.
Я думаю "За и против OpenSource" — это отдельная СВ. Давай здесь только про Руби.

P.S. Nemerle — это тоже Open source .

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Здравствуйте, VladD2, Вы писали:

VD>>Прочтя этот ответ я понял, осознал главную причину по которой нельзя использовать Руби в серьезных проектах. "это же OpenSource со всеми вытекающими" А вытекающие кривизна.
АХ>Я думаю "За и против OpenSource" — это отдельная СВ. Давай здесь только про Руби.

АХ>P.S. Nemerle — это тоже Open source .

Я иногда балдею с узости взглядов царящих на РСДН. Я уже давно замечаю, что если после шутски не вставить слово "лопата", то никто не засмеется. И давно замечаю, что нужно разжевывать и в рот закладывать.

ОК, раз тут неумеющих думать на шаг вперед большинство, то разжую смысл свои слов так чтобы дошло до последнего американца.

Отмазки eao197, а по другому это назвать тяжело, буквально напичканы указанием на то, что Руби ОпенСорс и мол все беды от этого. Так вот если, что-то дерьмовое, то она и в фарике дерьмовое и не фига пинять на обстоятельства. А то как в "Необыкновеннм чуде" — "Вывало наговорю с три короба, а душа у меня тонкая, ранимая... Вот и отравлю собеседника..." (разжовываю — то есть обосновываем свои проблемы чем угодно кроме недостатков в себе... до разжовываю — в себе, в данном случае нужно спроецировать на свои любимые игрушки).

Так вот есть куча ОпенСорсов с документацией и т.п. И не фига перекладывать с больной головы на здоровую.

ЗЫ

Смайлик в конце предложения означет "Шутка" или сарказм.

ЗЗЫ

Приношу извинения, что сразу не разжувал мысль.

Здравствуйте, VladD2, Вы писали:

VD>ОК, раз тут неумеющих думать на шаг вперед большинство, то разжую смысл свои слов так чтобы дошло до последнего американца.

Я всё равно ничего не понял
Тупею на чужбине

Здравствуйте, Курилка, Вы писали:

К>Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby
К>Особенно не положительным 4-й пункт кажется: навязываемый "Ruby Way", который ещё и не имеет однозначной трактовки.
К>З.Ы. Как-то не нашёл куда логичнее будет это написать: руби почти насквозь императивный, поэтому в декларативные не лезет, а среди языков его нет...

Обвинение	Мое мнение	Надежды на лучшее
1.Ruby is slow	Да, действительно	Ruby 1.9 несколько быстрее. YARV (Ruby VM beta, будет использован в Ruby 2.0) быстрее на порядки, но пока глючит
2. Ruby's development process is slow.	Нет. В 1.9 (experimental branch) новые фичи возникают достаточно часто
3. Ruby's "official" documentation is sparse and, in some cases, nonexistent.	Это полуправда. Действительно, в документации описаны подробно не все стандартные библиотеки, но по всем сгенерирована автоматическая документация — по крайней мере, список основных классов/методов/параметров можно узнать быстро.	Постепенно исправляется энтузиастами. Текущее покрытие подробной документацией ~70% стандартной библиотеки
4. Screw the Ruby Way	Бред.
5. Ruby has shitty XML suppor	Не понимаю этого обвинения

Здравствуйте, Курилка, Вы писали:

К>Собственно хотел предложить для прочтения (и обсуждения тоже) статью 5 things I hate about Ruby

Собственно, со статьей-то уже все понятно. Но, если есть желание, то можно пообсуждать минусы Руби.

Имхо, их можно разделить на три категории.

1. Особенности, присущие динамическим языкам вообще, а не только Ruby.

Во-первых, это необходимость постоянного тестирования кода. О том, является ли обязательное тестирование кода в динамических языках злом или добром здесь уже многократно говорилось, не буду повторяться. Но в качестве минуса я этот пункт выделил потому, что при переходе на Ruby со статически типизированного языка это серьезно напрягает. Так и подмывает забить на какой-нибудь unit-тестик и не написать его. Как только такая слабость допущена -- все, началось движение по наклонной плоскости. Если еще одноразовые утилиты можно делать без unit-тестов, просто проводя вручную постоянную проверку работоспособности кода, то уже проект, который расчитывается на длительное развитие и сопровождение без автоматизированного тестирования просто обречен.

Во-вторых, это неочевидность связей по данным. В коде можно увидеть фрагмент:

# Determining dependencies list for all who will link this DLL.
dll_requirements = make_dll_requirements(
  dll_file, dll_info, link_lists, target )

target.mxx_add_required_libs( dll_requirements.libs )
target.mxx_add_required_lib_paths( dll_requirements.lib_paths )

Но понять, какого типа объект возвращается методом make_dll_requirements, что возвращают методы libs и lib_paths с ходу невозможно. Нужно делать браузинг по исходникам, чтобы докапаться до сути. Smalltalk в этом плане выигрывает у Ruby наличием развитых IDE с мощными браузерами классов.
Справидливости ради хочу заметить, что у данного минуса есть своя положительная сторона: часто просматривая код лучше понимаешь поведение программы.

2. Особенности текущей ситации с Ruby.

Ruby пришел из Японии и поэтому он больше известен на Востоке (говорят, по популярности там он давно оставил позади Perl с Python-ом). Но на Западе, да и у нас, Ruby только приобретает известность. Соотвественно, информации о нем меньше, меньше готовых Ruby-программистов.

На данный момент Ruby не обладает высокой скоростью. Во-первых, это связано с самой динамической природой языка. Во-вторых, пока нет виртуальных машин и интерпретаторов, способных обеспечить высокую скорость. Но, усилия в этом направлении в Ruby 1.9 и YARV позволяют надеятся, что ситуация переменится. Чем больше людей будут пользоваться Ruby, тем больше внимания будет уделяться данной проблеме и тем больше шансов, что она будет успешно преодолена.

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

3. Особенности самого языка.

Мне кажется, что у Ruby ситуация похожая на C++: сильные стороны языка одновременно являются и его недостатками (косвенным образом это подтвержается еще и тем, что VladD2 ругает Ruby не меньше, чем C++). Так, в Ruby нет единственного правильного способа сделать что-нибудь, как правило, существует несколько равноценных путей из которых программист должен сам выбирать. Например, как можно вызвать метод у объекта, ссылка на который может быть нулевой?

if nil != obj
  obj.call_something
end
[rb]
А можно и так:
[rb]
obj.call_something if obj

Или как пройтись по всем элементам какого-то контейнера (например, массива)?

i = 0
while i != a.size
  do_something a[i]
  i += 1
end

или

for item in a
  do_something item
end

или

a.each { |item| do_something item }

Практика показывает, что при наличии такой свободы от программиста требуется больше знаний, умений и, если говорить по существу, чувства меры и наличие здравого смысла. А поскольку речь идет о динамическом языке, то к вышеперечисленному нужно добавить еще и дисциплинированность (для покрытия кода тестами). Та же практика показывает, что ожидать такого сочетания от большинства разработчиков не приходится
Естественно, что все читатели данного сообщения являются приятными исключениями из общей печальной статистики

Другая особенность Ruby в том, что он только на первый взгляд кажестя простым языком. На самом деле он не прост. Мелкие фокусы могут возникать на каждом шагу. Например:

i = 0; puts i ? 'non zero' : 'zero'

Что будет отображено? И почему?
Другая сторона сложности языка -- это возможности метапрограммирования. С одной стороны, для успешного применения метапрограммирования необходимо понимать внутреннее устройство Ruby классов (оношения между объектами, классами и метаклассами). Кстати, хорошо это дело освещается во втором издании Programming Ruby и в статье Seeing Metaclasses Clearly.

С другой стороны, как и с другими возможностями Ruby, метапрограммированием не сложно злоупотребить и превратить программу в головоломку. А поскольку язык здесь не ставит перед программистом никаких барьеров, то приходиться уповать на здравый смысл программиста. Но, как было упомянуто выше, далеко не всегда это возможно.

Две вышеописанные особенности Ruby делают этот язык для меня похожим на C++. Как следствие, Ruby хорошо подойдет небольшим командам опытных разработчиков или даже для индивидуального использования. В пользу этого так же играет и описанная в самом начале сложность с определением связи по данными в программе на динамическом языке. В маленькой, сплоченной команде отслеживать зависимости в коде будет проще. Да и ориентироваться в чужом коде в таких условиях так же гораздо удобнее.

А посему можно сказать, что минусом Ruby является то, что он вряд ли будет языком для больших команд. Хотя еще вопрос, считать ли это минусом

Здравствуйте, eao197, Вы писали:

E>С другой стороны, как и с другими возможностями Ruby, метапрограммированием не сложно злоупотребить и превратить программу в головоломку. А поскольку язык здесь не ставит перед программистом никаких барьеров, то приходиться уповать на здравый смысл программиста. Но, как было упомянуто выше, далеко не всегда это возможно.

Ага, вот благодаря этому рождаются такие вещи — круто, конечно, что можно такие фичи реализовать, но имхо результат получается довольно странный и не руби и не лисп (или хаскел для паттерн-мэтчинга) — нечто странное

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>Здравствуйте, VladD2, Вы писали:

VD>>>Прочтя этот ответ я понял, осознал главную причину по которой нельзя использовать Руби в серьезных проектах. "это же OpenSource со всеми вытекающими" А вытекающие кривизна.
АХ>>Я думаю "За и против OpenSource" — это отдельная СВ. Давай здесь только про Руби.

АХ>>P.S. Nemerle — это тоже Open source .

VD>Я иногда балдею с узости взглядов царящих на РСДН. Я уже давно замечаю, что если после шутски не вставить слово "лопата", то никто не засмеется. И давно замечаю, что нужно разжевывать и в рот закладывать.

Если это замечает только один человек, то скорее всего с его юмором что-то не то...

Здравствуйте, eao197, Вы писали:

E>Собственно, со статьей-то уже все понятно.

А что понятно? Мужик в общем-то прав по всем пунктам. Как раз твоя позиция выглядит более предвзятой.

На счет того, что я ругаю Руби — это не правда. Я ругаю необоснованную его рекламу. А основными недостатками языка являются тормоза, отсуствие полноценной IDE (комплит, рефакториг, ...), отсутствие статической типизации, черезмерная экономия на длинне идентификаторов в стандартной библиотеке, отсуствие декларации переменных, чреватые рнтайм-ошибками приведения типов, текстуальность метарасширений. А сам язык как раз очень ничего. По крайней мере по сравнению с Питомном или ДжиХрипом он мне больше нравится.

VladD2 wrote:
> На счет того, что я ругаю Руби — это не правда. Я ругаю необоснованную
> его рекламу. А основными недостатками языка являются тормоза, отсуствие
> полноценной IDE (комплит, рефакториг, ...)
А у Немерля уже есть IDE? А как там с рефакторингом? А почему медленнее
С++ работает?

> отсутствие статической типизации
А это не минус. Это огромный плюс в тех задачах, где Ruby используется.

Здравствуйте, VladD2, Вы писали:

VD>А что понятно? Мужик в общем-то прав по всем пунктам. Как раз твоя позиция выглядит более предвзятой.

Про те два пункта, где он был прав я и сказал в своем резюме. Пункт 4-й (про Ruby Way) -- это полный маразм. Поддержка XML-я непосредственно в язык -- это из той же оперы.

VD>На счет того, что я ругаю Руби — это не правда. Я ругаю необоснованную его рекламу.

О как! Т.е. отсутствие громких флеймов под заголовками "Ruby рулит" и "Ruby -- профанация не пройдет" -- это и есть необоснованная реклама. Особенно, если сравнивать с другими .NET-языками.

VD>А основными недостатками языка являются тормоза,

Ruby предназначен для быстрой разработки, а не для быстрого исполнения. Сама его природа (открытые типы, например) определяет, что он не сможет в принципе достигать скорости C++. А раз так, зачем корячиться.

К тому же здесь уже несколько раз приводились примеры, которые показывали, что в реальных задачах издержки Ruby составляют доли процентов от издержек остальных компонентов (ссылки сейчас искать некогда, но в Философии была тема про скорость импорта в БД данных из гигабайтных логов программой, написанной на F#; в Средствах разработки dmz сравнивал скорость парсинга логов на Python и Perl, туда же было добавлено сравнение с Ruby; в исходниках лежит мой проект svn-dumper-loader -- там svn dump на 160Mb репозитории работает минуту, а затем две минуты dump-файл архивируется bzip2, при таких показателях сам Ruby скрипт просто летает).

VD>отсуствие полноценной IDE (комплит, рефакториг, ...),

Да есть IDE для Ruby, как open-source (FreeRDE, Mongrel, RDT), так и коммерческие (Komodo).
Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.

VD>отсутствие статической типизации,

Ну вот, блин, приплыли. Это же динамический язык. Приводить динамическому языку в недостаток отсутствие динамической типизации -- это то же самое, что обвинять женщин в том, что они не мужчины.

VD>черезмерная экономия на длинне идентификаторов в стандартной библиотеке,

Вот уж не замечал. Вот список методов, начинающихся на букву A из Core Library:

a (CGI::HtmlExtension)
abbrev (Abbrev)
abbrev (Array)
abort (Kernel)
abort (Process)
abort_on_exception (Thread)
abort_on_exception (Thread)
abort_on_exception= (Thread)
abort_on_exception= (Thread)
abs (Float)
abs (Complex)
abs (Fixnum)
abs (Numeric)
abs (Bignum)
abs2 (Complex)
absolute? (Pathname)
acos (Math)
acos (Math)
acos! (Math)
acosh (Math)
acosh (Math)
acosh! (Math)
add (ThreadGroup)
add (Set)
add (Benchmark::Tms)
add (Logger)
add! (Benchmark::Tms)
add? (Set)
add_builtin_type (YAML)
add_domain_type (YAML)
add_finalizer (ObjectSpace)
add_observer (Observable)
add_private_type (YAML)
add_ruby_type (YAML)
adler (Zlib::ZStream)
adler32 (Zlib)
ajd (Date)
ajd_to_amjd (Date)
ajd_to_jd (Date)
alias_method (Module)
alive? (Thread)
all? (Enumerable)
all_symbols (Symbol)
all_waits (ThreadsWait)
all_waits (ThreadsWait)
allocate (Class)
amjd (Date)
amjd_to_ajd (Date)
ancestors (Module)
angle (Numeric)
angle (Complex)
any? (Enumerable)
append_features (Module)
arg (Complex)
arg (Numeric)
args (NoMethodError)
arity (Method)
arity (UnboundMethod)
arity (Proc)
asctime (Time)
asin (Math)
asin (Math)
asin! (Math)
asinh (Math)
asinh (Math)
asinh! (Math)
assoc (Array)
at (Array)
at (Time)
at_exit (Kernel)
atan (Math)
atan (Math)
atan! (Math)
atan2 (Math)
atan2 (Math)
atan2! (Math)
atanh (Math)
atanh (Math)
atanh! (Math)
atime (File::Stat)
atime (Pathname)
atime (File)
atime (File)
attr (Module)
attr_accessor (Module)
attr_reader (Module)
attr_writer (Module)
autoload (Kernel)
autoload (Module)
autoload? (Module)
autoload? (Kernel)
avail_in (Zlib::ZStream)
avail_out (Zlib::ZStream)
avail_out= (Zlib::ZStream)

А вот фрагмент списка имен классов из Core Library:

Abbrev
ArgumentError
Array
Base64
Benchmark
Benchmark::Tms
Bignum
Binding
CGI
CGI::Cookie
CGI::HtmlExtension
CGI::QueryExtension
CGI::Session
CGI::Session::FileStore
CGI::Session::MemoryStore
Class
Comparable
Complex
ConditionVariable
Continuation
Data
Date
DateTime
Dir
EOFError
Enumerable
Errno
Exception
FalseClass
File
File::Constants
File::Stat
FileTest
FileUtils

Какие из них ты считаешь черезмерно сокращенными?

Ну и не нужно забывать, что в мире динамических языков процветают принципы code less и don't repeat yourself. Поэтому идентификаторы to_i, to_f, to_s, to_str, to_sym -- являются нормальными и удобными в использовании.

VD>отсуствие декларации переменных, чреватые рнтайм-ошибками приведения типов,

Это к пункту про статическую типизацию.

VD>текстуальность метарасширений.

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

VD>А сам язык как раз очень ничего.

Да уж... Язык-то как раз полезен теми вещами, которые ты только что здесь раскритиковал.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

черезмерная экономия на длинне идентификаторов в стандартной библиотеке, отсуствие декларации переменных,

А что длжно быть как в винде?

DoSomethingByLeftHandEatShitAndDie

Kluev wrote:
> черезмерная экономия на длинне идентификаторов в стандартной библиотеке,
> отсуствие декларации переменных,
> А что длжно быть как в винде?
> DoSomethingByLeftHandEatShitAndDie
AccessCheckByTypeResultListAndAuditAlarmByHandle

VD>>отсуствие полноценной IDE (комплит, рефакториг, ...),

E>Да есть IDE для Ruby, как open-source (FreeRDE, Mongrel, RDT), так и коммерческие (Komodo).
E>Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.

Есть еще коммерческий TextMate для MacOS

Здравствуйте, Mamut, Вы писали:

E>>Более того, Rubyist-ов совсем это не парит. Большинство используют VIM, emacs и TextMate (под MacOS), не испытывая при этом никаких сожалений.

M>Есть еще коммерческий TextMate для MacOS

Так я же его указал
Живьем его не видел, но по роликам -- классная штука. Хотя, имхо, это не IDE, а продвинутый программерский редактор.

Кстати, для RubyOnRails на основе Eclipse делают IDE: RadRails