чем 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, надеюсь, никто не отменял. 

Без раздумий предпочту O(N**2) в одну строчку. Раньше, для меня это было кощунством, но теперь стал понимать, что все равно 100 раз переделывать. Проще будет переписать одну строчку, чем двадцать.  

Оптимизировать можно после сдачи проекта и за отдельную плату. =) 

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

M Cr@$h

Тема выделена из разговора об особенностях Ruby.

лямду собираются убирать? кому оно мешало? еще один шаг в сторону от лиспа...

Лямду не уберут! На гугловской презентации Python3000 Гвидо дал однозначно понять, что он оставит лямбду!

Теперь немного по теме сабжа. Я знакомился с языками по пути Pascal - C - Java - PHP - Perl - Python - Ruby - ...
Вероятно, очевидно, что мой выбор - Python. Перл был очень гибкий, но при этом довольно "страшненький". После Java'ы в Perl'е не хватало нормального человеческого ООП. Работа с хэшами и массивами была отнюдь не так очевидна как в питоне.  Вобщем попав на Python, выучил его на одном дыхании. В нем было все что нужно и главное все было понятно! Поизучав Руби, не нашел чего-то такого, той изюминки, способной пересадить на него. 
В питоне же таких изюминок целых несколько. 
1) Его синтаксис, делающий его пожалуй самым читабельным языком 
2) Очень четкие принципы, заложенные в язык (Zen of Python), и одновременно являющиеся рекомендациями к тому, как писать программы. Надо сказать, очень правильные рекомендации. Еще очень отрадно, что создатель языка (Гвидо ван Россум) принимает самое активное участие в развитии языка, более того, его слово является решающим, правда, не знаю про Matz'а.
Конечно есть такое чувство, что Ruby в каком-то роде более целостный чем Python. Например в Python'е различие классов и типов (последние нельзя менять), немногострочная лямбда. Однако все это мелочи, ибо первое - практически никак не сказывается на практике, а второе не нужно ввиду вышеупомянутой идеологии языка. self - это вовсе не проблема, это лишь отражение того, что explicit is better than implicit. Кстати, в пайтоне возможно множественное наследование, чего в руби нет.
В руби понравились блоки. Жаль только что методу можно передавать только 1 блок. Ведь в smalltalk'е можно было сколько угодно . Да и вообще smalltalk более ООП чем руби  Блин, отвлекся... В пайтоне есть генераторы с yield, но используются они гораздо реже.
Решающими фактороми были, впрочем, распространенность языка и библиотек и более развитая инфраструктура.
А вообще выбор языка - это дело совершенно личное. Если ваш язык вас устраивает, и вы на нем продуктивны - я только рад за вас. Думаю, перловщики с удовольствием перейдут на Ruby. Много языков - это не плохо. Ибо из конкуренции появляется качество 
 

Не скажи. В Smalltalke квалификатор private для методов чисто фиктивный, т е он не запрещает вызов private-метода. По крайней мере так было в VA лет 6 назад, когда я его смотрел. Также отсутствует квалификатор  protected, это вообще ужас - на каждом шагу нужно делать закрытые от прямого вызова методы, которые будут наследоваться. Все это говорит о том, что в Smalltalk нарушена инкапсуляция - один из 3 основных критериев ООП.

Это сообщение отредактировал(а) Амортизатор2 - 7.3.2007, 21:03

Хммм....
Вопрос ведь не в языке - в любом языке можно извратиться и вызвать защищенный метод, хотя бы исправив *.h :-)
А данные принципы (инкапсуляция, полиморфизм, наследование) были сформулированы позднее, чем появился Smalltalk

К тому же, согласно одному из определений:

Таким образом, Smalltalk реализует инкапсуляцию в части объединения данных и кода, и делает это получше, чем С++ :-)

FunnyFalcon, все-таки отсутствие закрытых методов уменьшает инкапсуляцию.

Smalltalk более ООП по сравнению с другими языками, т к в нем все есть объекты - даже куски кода. Но на практики это сомнительное преимущество.

Сомнительное лично для вас? Тогда советую почитать хорошую литературу про использование ООП.
Вся эта макулатура типа «профессиональное программирование на С++», конечно же яйца выеденного не стоит. Действительно книги про использование ООП - это, например, Рефакторинг кода Фаулера

Амортизатор2, про квалификаторы в Смолтоке вы верно подметили, мне после жавы их очень не хватает (курочу Squeak на досуге) и не только в смоллтолке но и в питоне...
Тут вот была интересная дискуссия на тему квалификаторов в контексте Смолтока, я там как раз отписался (ник xonix).

есть mixin'ы

http://shootout.alioth.debian.org/debian/b...&lang2=ruby

+1
Не берусь утверждать, но по-моему множественное наследование используется в основном в качестве mixin.

Вопрос: кто когда вообще использовал множественное наследование не в качестве mixin?
И, если использовал, нельзя ли было обойтись в этом случае mixin? Какие преимущества у того и другого подхода?

считается, что у другого подхода есть только недостатки, а именно:
- неясность структуры
- возможные проблемы с именами членов
- сложность реализации
и т.д.

Уточните)

из Вики:

Я пару месяцев назад хотел поковырять Ruby On Rails. Ествестенно, начал с изучения Ruby. Прочитав полкнижки (в основном про синтаксис и идиомы языка), что-либо дальше учить расхотелось, ибо от Ruby сильно так попахивает перлом, который снискал славу "write only language".
Конечно, это дело вкуса, на каком языке писать. Так вот на мой вкус python рулит, руби курит в сторонке. Это по части синтаксиса...
По части библиотек, написанных для языка, я таки тоже думаю, что руби курит.

Время программы на  компьтеров не важно. Важно время жизни.

Мне не понравился Питон сразу же из за того что заставил табы делать и дальше хелло ворлд дело не ушло, а рубю полюбил по мне так лучше str.length чем len(str). )

+1