задам такой же вопрос как и Kaskad, только про Ruby
что есть в Ruby чего нет в других языках?
и в какаих целях его применяют?

What's Ruby
Ruby Documentation (там внизу есть статьи на эту тему)
Добавлено @ 10:01
Если есть вопросы по преимуществами в какой-то конкретной области - пиши. I'll do my best

Из последнего: http://www.rubyonrails.com/ - перспективная разработочка

было бы неплохо написать и прекрепить здесь обзорную статью по ключевым моментам Ruby (на русском). кто возьмётся?

Вот здесь на русском:
http://www.chair36.msiu.ru/science/science...tml/node33.html.

Pete
Неплохая Ruby advocacy статья, но вот такие:

Цитата

# в Ruby, в отличие от языка Python, понятия типа и класса являются синонимами; # Python не поддерживает наследования и не позволяет добавлять методы к существующим типам; # расширения для Ruby, написанные на C/C++ позволяют определять новые классы;

ляпы существенно портят впечатление. Закрадываются сомнения в компетентности автора. Я это к тому, что Питон все вышеперечисленное поддерживает.

Цитата

не требует объявления переменных;

Хоть убейте, я не считаю это преимуществом для мало-мальски больших проектов

Это сообщение отредактировал(а) Void - 13.1.2006, 16:50

Две ошибки. Первая, внутри .map присваивание как козе баян. Вторая, итератор .map здесь вообще не к месту.


Добавлено @ 20:21 

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

В Python длинная арифметика вшита через ж.... Haskell пропущу (на Ruby писать в стиле Haskell -- одно удовольствие)... про LISP можно забыть. =)

Добавлено @ 20:22 

Иди на http://ru.wikipedia.org/wiki/Ruby и читай

Добавлено @ 20:25 

Ruby очень быстро развивается. Быстрее, чем ML. Зачем учить детей тому, что в скором времени может исчезнуть? Уж лучше Haskell... 

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

Пример в студию. Хочу посмотреть как в Пайтон'е можно добавить метод к челым числам, без создания нового класса. Или как добавить метод к строке "Hello", без порождения нового класса?

Добавляем метод к целым числам без порождения нового класса:


Добавляем новый метод к строке "Hello", без порождения нового класса.



По поводу объявления переменных. Где присваивание, там и объяввление переменной. А вот до начала написания программы знать имена всех необходимых тебе переменных и пролистывать код каждый раз, когда понадобится еще одна -- это маразм XX века. Кстати, большинство моих программ на Ruby замечательно обходятся без переменных. Не веришь? Смотри выше... =)

ЗЫ. ООП в Ruby идеально! В Python же... ладно, пока промолчу. Подожду примеров (с передачей self в качестве параметра). =)

Добавлено @ 20:46 

Mi ne comprenas vin. По русски говори (код в студию). Что-то я такого безобразия на Haskell не припоминаю... 

Никак. Я процитировал пункт «Python не поддерживает наследования», что есть явный бред.


ML исчезнет? С какой радости? Применение ML-оидов невелико, но уменьшаться оно не собирается. Особо увеличиваться, впрочем тоже. Я не за ML для обучения, но хоронить его не стоит.


http://en.wikipedia.org/wiki/Pattern_matching
http://en.wikipedia.org/wiki/Algebraic_datatype

OCaml:

Понятнее стало?

И давайте без фанатизма. Для holywars и соответствующего тона у нас специальный раздел есть.

Добавлено @ 21:30 

Полностью согласен. И где же такая фигня наблюдается?  

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

Если я правильно понял, то задается некоторая структура (шаблон) объекта и проводится проверка вида "соответствует ли объект указанной структуре?"

Честно говоря, даже не очень понимаю как это можно применить на практике... Ну в Haskell оно понятно... а вот в Ruby? Скорее всего, это будет реализовываться дописыванием методов вида .nil? .array? .string? .tree? Кода будет примерно столько же... =)

Не об исчезновении я говорю, а о забвении. Все концептуальные языки программирования чаще всего остаются малоизвестными. Ruby в этом смысле не повезло. Какой-то ..... написал RoR. Хорошо, что не все догадываются, что RoR != Ruby.
 
По поводу переменных... Во всяких там Паскалях и Сях. Как вспомню... программы по 10 тыс. строк кода. Несколько экранов переменных с неудобоваримыми именами. Лучше писать программы без переменных, циклов и условных операторов. Ошибок меньше на порядок получается. И не надо думать о том, что объявлять, а что нет. 

Когда начинал программировать на Ruby, то думал, что отсутствие типа у переменных будет мне мешать. Но потом привыкаешь. В Ruby нет такого маразма, как в PHP, что переменная может возникнуть из пустоты (без присваивания). Если переменной не присвоено значение, то она равняется nil, а у nil практически нет методов. "Утиный контроль" хватает эту ошибку во время первого же запуска. Это не привычно поначалу, но потом перестаешь обращать на это внимание.

ЗЫ. Кстати, почти вернулись к певоначальной теме.   

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

Ага.

Вот такую вещь на Ruby изображали 

Ну мы же про нормальные высокоуровневые языки говорим  Вывод типов прекрасно решает любые проблемы с объявлением переменных. Не всегда можно отличить на глаз код с выводом типов и код на динамически типизированном языке.

Все таки малоизвестность и забвение — разные вещи. Из «концептуальных языков» многое потихоньку уползает в мэйнстрим. 

Метод multi -- это конечно круто, но не Ruby like. =) Вряд ли его кто-то будет так использовать... кроме мигрантов со всяких там Haskell.

"Вывод типов" -- это что-то типа этого?


В Ruby только одна опасность: переменные не имеют типа (точнее у них у всех тип "ссылка на объект") и появляется соблазн второго присваивания (причем с другим типом). Вот тогда и может возникнуть косяк. Если этого не делать, то привязка переменной к типу и не потребуется. 

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

Ну и вообще: http://en.wikipedia.org/wiki/Type_inference  

По поводу забвений. Вы всё ещё хотите найти язык, который будет служить вам вечно? Всё в этой жизни — временные увлечения.