чем Ruby лучше Python? B)
скоростью? - no
возможностями? - no
лёгкостью и простотой? - такой же
поддержкой? - неа
....

найдите "характеристику" с положительным реультатом) я не вижу их, наверно потому что на кодю на ру 
ещё убивают всякие do end и тп аля паскаль (опять наверно потомучто я больше С уважаю=) ) 

Это сообщение отредактировал(а) slav0nic - 7.6.2006, 22:43

Вообще-то скорее yes. Потому как в Python байткод, а в Ruby, если я не ошибаюсь, его только обещают к 1.9.

Знаю, что в приличном обществе не принято ссылаться на этот ресурс, но все же 
Computer Language Shootout


Oops, перепутал позицию slav0nic  

Это сообщение отредактировал(а) Void - 7.6.2006, 22:46

скорость чего? Скорость разработки -- выше. Большинство задач решается "в одну строчку", что в условиях Python невозможно, сам знаешь почему. =) Скорость выполнения -- сопоставима (где-то выше, где-то ниже).

возможностями - был пример выше, по поводу наращивания втроенных классов. Посмотри внимательней. Замыкания в Python есть?

легкость и простота скорее выше. Ruby создает ощущение "продуманности до мелочей", а в Python: "ООП сюда вчера добавили?" Python'овский self в качестве параметра -- притча во языцах.

какая поддержка тебя интересует? Документация? Семминары? Библиотеки? Хостинг? 

Таки да.

Добавлено @ 22:53 
P.S.
Вот только Ruby vs Python нам не хватало. 

Мы о языке говорим или о его реализации? Есть два проекта Rite и Ruby 2.0. Развиваются они параллельно и имеют разные цели. Ruby 1.9 -- это мусорка для обкатки идей обоих проектов. Rite будет компилироваться в байт-код (Parrot?), а Ruby 2.0 останется интерпретируемым. На данном этапе Rite не развивается, т.к. всем лень (ждут Parrot?). =) Помимо Rite есть еще вагон и маленькая тележка всяких компиляторов. Но о них мало кому известно.

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

ЗЫ. Ruby 1.9 уже есть. Это нестабильная ветка проекта Ruby 2.0.

Добавлено @ 23:03 

Ну а показать? 

Синтаксис громоздкий конечно, но замыкания есть.

К сожалению, GvR собирается убрать lambda из Python 3. Дескать, вложенных функций достаточно. Жаль. 

Я уже посмотрел... =) Вместо a.map{ |x| x+n } на Ruby, приходится писать map( lambda x: x + n, a). Это к вопросу об "ООП вчера добавили?" =)

ЗЫ. Блин, а ведь знал же про замыкания в Python... за три года забыть успел. 

Ужас! В Ruby пришлось написать на целый символ больше, чем в Haskell
map \x -> x + n a
А в OCaml?
map ((+) n) a
(Пардон, не помню, как карринг операторов в Haskell выглядит).
Мы-то знаем, что счастье не в минимальном количестве символов. А то бы все давно перешли на J или K 

Хотя в Python синтаксис далек конечно от идеального. По поводу его лямбд в c.l.functional недавно флеймище был.

Добавлено @ 23:47 
P.S. Не оверквоть, пожалуйста. 

  

Void, а в споре рождается истина=) (я по поводу ...vs...) просто интересно узнать, зачем ещё один скриптовый язык  

Нашел сравнение производительности Python vs Ruby: http://ruby.brian-schroeder.de/editierdistanz/ . Программы писал явный сторонник, т.к. первое, что делает программист на Ruby -- это отключает автоматическую сборку мусора (GC.disable). Результаты и так различаются не сильно, а с отключенной сборкой мусора будут одинаковыми. Была статья Роганова Е.А. под названием "Кто хочет конфетку?" Вот там первый, кто заработал конфетку, был студент, который отключил сборку мусора. В МГИУ как раз и занимаются тем, что пытаются ускорить код на Ruby. Для меня это кощунство, а им нравится. =)

PS. Ссылку на статью не нашел, но читал ее в МГИУ (Роганова Н.А. показывала). Если кто найдет, скиньте.

Добавлено @ 23:56 

Каждый язык на протяжении своего развития тянет за собой длинный шлейф архитектурных ошибок, от которых не просто избавиться. Появление новых языков позволяет от этих ошибок избавиться. Я всегда характеризую Python как "процедурный Ruby". Они похожи до безобразия, но в Ruby практически идеальная реализация ООП (за счет того, что Ruby изначально ООП). Мне "процедурный стиль" надоел. Поэтому, миграции на Python не получилось. 

И кто за памятью следить будет? Ну для одноразового быстро выполняющегося скрипта это быть может еще и позволительно.
Это надо понимать, как признание того, что GC в Ruby кривой? Потому что временн́ой оверхед на сборку мусора, скажем, в .NET стремится к нулю. 

Это просто указание на то, что взят код на Python и однозначно перенесен на Ruby (без оптимизации и учета особенностей). Просто, GC пожирает время, которое можно сократить за счет его отключения. Команду return тоже не используют (а она съедает время). В общем, есть масса вещей, которые позволят свести код от "переделки с Python" к нормальному коду на Ruby. И тогда еще не известно "чье конг-фу круче".  

Это сообщение отредактировал(а) Rubynovich - 8.6.2006, 00:09

Ну не должен нормальный GC (mark&sweep generational, а не ref counting с разрывом циклов) пожирать время. Не должен. Если у Ruby и Python такая реализация GC, это их проблемы, а не повод сваливать управление памятью на непонятно кого.
К тому же в Python-то его не отключают, с какой радости в Ruby это надо делать.

Это понятно. 

Это сообщение отредактировал(а) Void - 8.6.2006, 00:20

Даже лишнее присваивание будет отнимать время, а чистка памяти тем более. В данном случае ею можно пренебречь, т.к. программа маленькая и по ее окончанию память все равно будет освобождена. 

Лично я таким маразмом, как оптимизация быстродействия кода на Ruby не занимался (оптимизация быстродействия -- это всегда потеря выразительности кода). Я просто знаю, что он будет всегда медленней того же кода на Си. Это жертва за его возможности и рюшечки.

Рано или поздно, вопрос быстродействия потеряет актуальность. Иначе, почему все больше языков используют интерпретатор?

ЗЫ. Вопрос о быстродействии языков абсурден, т.к. на листке бумаги все программы работают одинаково (никак). И вот тут как раз нужна немногословность, выразительность, скорость написания. Вот здесь уже может идти речь о языке. Такого понятия как скорость работы у языка просто нет. 

Алгоритмической оптимизацией тоже? Предпочтешь O(N^2) алгоритм в две строчки более громоздкому O(N * log(N))? 

Не везде.

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