LINUX.ORG.RU
ФорумTalks

23.02.1993 был создан Руби


0

1

Теперь это тред о том, почему руби крутой, и как он решил проблемы, неразрешимые на других ЯП!

http://cs323822.userapi.com/v323822503/5f6a/_c3bCUFT2qQ.jpg

Ниже приведен перевод письма Маца в список рассылки ruby-talk ([ruby-talk:00382]). Письмо датировано 4 июня 1999 года. День рождения Ruby уточнен в письме [ruby-list:15977].
Ruby родился 23 февраля 1993 года. В тот день я беседовал со своим коллегой о возможности существования объектно-ориентированного скриптового языка. Я знал Perl (Perl4, а не Perl5), но он мне не нравился -- был в нем некий привкус игрушечного языка (да и до сих пор есть). А объектно-ориентированный интерпретируемый язык казался многообещающим. В то время я знал Python. Но он мне не нравился, так как я не считал его настоящим объектно-ориентированным языком. Его OO свойства казались надстройкой над языком. Мне, как языковому маньяку и фанату объектно-ориентированного программирования с пятнадцатилетним стажем, очень, очень хотелось, чтобы был истинно объектно-ориентированный, простой в использовании язык. Я пытался найти такой язык, но его не было. Тогда я решил его создать. Прошло несколько месяцев, прежде чем интерпретатор заработал. Я добавил в мой язык то, что мне хотелось -- итераторы, обработку исключений, автоматическую сборку мусора. Затем я реорганизовал свойства Perl'а и реализовал их как библиотеку классов. В декабре 1995 года я опубликовал Ruby 0.95 в японских новостных группах. С тех пор появились сайты, списки рассылок. В списках рассылок происходят жаркие дискуссии. Самый старый, ruby-list, сейчас содержит 14789 писем.

(источник: http://ruby.osdn.org.ua/faq/node7.html)

Для Ъ, не ходящим по другим языкам:

Класс языка: мультипарадигмальный: динамический, объектно-ориентированный, рефлективный, императивный, функциональный

Тип исполнения: интерпретируемый

Появился в: 1995

Автор(ы): Юкихиро Мацумото

Расширение файлов: .rb, .rbw

Релиз: 1.9.3-p385 (6 февраля 2013[3])

Типизация данных: строгая, динамическая (утиная)

Основные реализации: Ruby MRI (англ.), JRuby, IronRuby

Испытал влияние: Perl, Smalltalk, Eiffel, Ada, Lisp[1], Python, Dylan, CLU (англ.), C++

Повлиял на: Groovy, Amber, CoffeeScript, Perl 6

Лицензия лицензия Ruby или GNU GPL v2

Сайт: http://www.ruby-lang.org

★★★★☆
Ответ на: комментарий от geekless

Из того, что виртуальные методы позволяют с кучей boilerplate кода и оверхеда обобщать алгоритмы, не значит, что их можно рассматривать как полноценную замену нормальному параметрическому полиморфизму.

объекты для того, чтобы думать.

// Шутка про Чапаева и картошку.

dmfd
()
Ответ на: комментарий от dmfd

Из того, что виртуальные методы позволяют с кучей boilerplate кода и оверхеда обобщать алгоритмы, не значит, что их можно рассматривать как полноценную замену нормальному параметрическому полиморфизму.

Если ты отличаешь compile-time и run-time связывание, медицина тут бессильна.

geekless ★★
()
Ответ на: комментарий от geekless

А что, параметрический полиморфизм в рантайме не может работать? Может. Не понял суть претензии.

dmfd
()
Ответ на: комментарий от dmfd

И чем это будет отличаться от «виртуальные методы позволяют с кучей boilerplate кода и оверхеда»? Та же множественная динамическая диспетчерезация, вид сбоку.

geekless ★★
()
Ответ на: комментарий от geekless

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

dmfd
()
Ответ на: комментарий от dmfd

Ну здрасти. Если компилятор может точно определить ран-тайм тип объекта, он заменяет вызовы через vtable на прямые.

geekless ★★
()
Ответ на: комментарий от geekless

Если компилятор может точно определить ран-тайм тип объекта

Компилятор про рантайм ничего знать не может. Если имелось в виду "если тип известен в compile-time": ну так в этом случае не может быть и полиморфизма.

dmfd
()
Ответ на: комментарий от dmfd

Компилятор про рантайм ничего знать не может.

Если видит вызов конструктора, то может.

Почему я занимаюсь объяснением очевидных вещей, а?

geekless ★★
()
Ответ на: комментарий от geekless

Если видит вызов конструктора, то может.

Ок. У нас есть такая имитация параметрического полиморфизма:

int foo(IParameter* a);

Как компилятор здесь может убрать вызов через vtable? Создать специализированную версию этой функции, если "виден конструктор"? А если foo в другой единице трансляции? Это неслабая такая глобальная оптимизация, что-то мне не верится, что компиляторы в неё могут. Пригодился бы пруфлинк.

dmfd
()
Ответ на: комментарий от geekless

Кто-то говорил:

Те же яйца, вид сбоку.

Я так понял, имелось в виду, что с помощью виртуальных методов можно сделать то, что делается, скажем, шаблонами. И привёл пример того, что делается шаблонами. В этом примере виртуальный вызов никак оптимизирован быть не может, в то время как с помощью шаблонов получился бы более оптимальный код (но за счёт размера бинарника).

А то, что в паре простейших синтетических примеров компилятор может убрать виртуальный вызов, это, знаете ли, к полиморфизму отношения не имеет, да и никому не интересно: руками эта "оптимизация" выполняется с тем же успехом.

dmfd
()
Ответ на: комментарий от dmfd

Так вы мне расскажите, через какое место вы будете обеспечивать «полиморфизм на шаблонах» в рантайме.

Все эти рассуждения про сферических коней очень интересны ровно до тех пор, пока мы не упираемся в банальный key_press(widget). И тут внезапно «куча boilerplate кода и оверхеда» оказывается совсем не boilerplate.

geekless ★★
()
Ответ на: комментарий от geekless

Так вы мне расскажите, через какое место вы будете обеспечивать «полиморфизм на шаблонах» в рантайме.

Я не говорил "полиморфизм на шаблонах", я говорил "параметрический полиморфизм", а шаблоны привёл как пример. Не шаблонами едиными.

dmfd
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.