Ответ на пункт 1.> 1. Недостаточная система макросов не позволяет определять новые конструкции языка. В Ruby, например, невозможно создать макрос, который определит новую конструкцию safeif, которая будет принимать четыре аргумента:
> а) объект;
> б) инструкции при равенстве объекта true;
> в) инструкции, когда объект равен false;
> г) инструкции, которые будут выполнены в случае, когда объект равен nil или возникли какие-нибудь ошибки.
Насколько важна такая конструкция? Такую конструкцию можно легко создать с помощью C-API. Я же сразу говорил, что Ruby еще достаточно молодой язык. Молодой - это не значит, что есть баги, это значит, что есть стабильное емкое ядро и меньше готовых второстепенных фичей. Эти фичи требуют обычно неопытные юзеры. Профессионалы могут легко и быстро создать для себя недостающие им фичи. Когда проект начинает обрастать такими фичами, профессионалы обычно ищут другой более молодой и чистый.
Ответ на пункт 2.
>(define n 3)
>((lambda (n) 0) 1)
>(display n)
>Результат: 0 3
Во-первых. Это это само собой разумеется, что конструкции на функциональном языке, не должны менять значений глобальных переменных. Однако это верно лишь для функциональных языков. Претензия в посте, который Вы привели http://www.ruby-forum.com/topic/93339 заключалась не в этом. Там автор выдвигал претензии к механизму разрешения области видимости. Это еще раз доказывает, что Вы сам пост толком не читали. Вот я и сказал, что переменные замыкания привязываются к глобальному контексту, также, как и в Scheme. А они в зависимости от реализации замыкания могут автоматически к глобальному контексту и не привязываться. Именно это имелось в виду, когда говорилось, что в Scheme замыкания ведут себя так же.
Во-вторых. Я говорил о замыкании, а Вы вообще привели здесь просто лямбда-функцию. То что Вы в ответ на высказывании о замыканиях приводите пример с лямбдой, говорит о том, что Вы просто не понимаете, о чем идет речь. Блок в Ruby ведет себя как замыкание, а не как лямбда.
В-четвертых. В функ яз замыкание создается с помощью лямбда (а там с помощью лямбда все создается, т к лямбда там центральное понятие). В то время как в Ruby, наоборот, с помощью замыкания эмулируется, всего лишь эмулируется лямбда. Попробуйте сделать так в Scheme, там такое с лямбдой сделать нельзя:
x=1; y=2; lambda{x+y}.call -> 3, x==1, y==2
Куда делись объявление и передача параметров? И куда делся вообще итератор? А теперь сделайте так, с приваиванием:
x=1; y=2; lambda{x=x+y}.call -> 3, x==3, y==2
Это эквивалентно простому:
x=1; y=2; x=x+y -> 3, x==3, y==2
А теперь с итератором, но без присваивания:
x=1; y=2; lambda{|x|x+y}.call(4) -> 6, x==4, y==2
Что эквивалентно:
x=1; y=2; x=4; x+y -> 6, x==4, y==2
А почему так по-Вашему нельзя? У нас императивный язык. И лямбда здесь вовсе никакая не лямбда. Это можно лишь заставить работать как лямбду при правильном использовании. А блок - тоже не совсем замыкание. Он относится к замыканию так же, как императивная процедура относится к математической функции, хотя процедуры часто тоже называют функциями.
Вы просто плохо представляете, на что жалуетесь. Это не баг. Это разница в парадигмах. Вы приводите внешне похожие синтаксические конструкции, не понимая разницу в семантике, и требуете, чтобы эти конструкции вели себя одинаково. Вы похожи на школьного преподавателя по информатике, который вколачивает допустим в Паскаль формулы из учебника по математики, иногда получает неверные результаты и жалуется на баги.
В-третьих.
>Matz не хотел признавать наличие архитектурной ошибки при работе с лямбда-функциями и поэтому назвал данную ошибку фичей.
Снова не читали пост. Даже мой перевод поста толком не прочли. Про "фичу" сказал автор поста, который как и Вы толком не понимал, что происходит. Matz не называл это "фичей", Matz сказал, что это ожидаемое поведение. А оно действительно ожидаемое, если не путать парадигмы программирования. Вы просто нашли пост по ключевому слову "bug", а это слово произнес автор поста, а не Matz. Вы думаете, что если бы это действительно был баг, то Matz не смог бы его профиксить?
И "профиксивание" видимо делается вовсе не для улучшения. Это просто выбор между компромиссами.
А теперь вопрос Вам на засыпку. Что именно было "профиксено" в версии 1.9?
Ответ на пункт 3.
>3. О передачи нескольких блоков и значениях по умолчанию для лябда-функций. Ты ведь хочешь получить максимально чистый язык, к чему находить обходные пути решения, которые коверкают язык? Чистый язык должен либо позволять добиться такого эффекта или же предоставлять возможности расширения самого себя. Запись передачи нескольких лямбда-функций не в качестве блока является излишней.
Вы имеете в виду какую чистоту? Императивную или функциональную? Смесь парадигм как раз может привести к "загрязнению". Какая-то парадигма должна доминировать. Нужны обе парадигмы? Используйте два языка и интегрируйте их, хотите на внешнем уровне, хотите на уровне API. Хотите один язык со всеми парадигмами? Тогда Вы - поклонник ширпотреба.
Вам еще один вопрос на засыпку. Для чего действительно при профессиональном применении используется эмуляция свойств функ языков в имп языках? Иначе проще либо не использовать функ "фишки", либо взять функ язык.
Кроме того, чистота обычно подразумевается на семантическом уровне. Единообразный синтаксис обычно требуют чайники, которым трудно изучать языковые конструкции. Matz использует печальный опыт Python, в котором в погоне за единообразным синтаксисом понатыкали заплат в ядро.
Ответ на пункт 4.
Вам какой вопрос был задан? - Что такое можно сделать с помощью МН, чего нельзя сделать с помощью его более изящных и эффективных альтернатив? И это вопрос не относительно Ruby, а относительно теории ООП. Что говорится в теории ООП про МН Вы явно не знаете.
А Вы на какой вопрос стали отвечать?
>Рассмотрим один из классических примеров множественного наследования: существует абстрактный класс работы с файлом
Откуда у Вас появились классы, если Вы еще не поставили задачу. Сначала поставьте задачу, а уже потом придумывайте классы. Это говорит об отсутствии у Вас реального опыта в программировании. Вы идете не от задачи, а от каких-то стереотипов, от какого-то уже заранее существующего шаблонного решения непонятно какой задачи. А потом утверждаете, что лучшего решения нет. Только, не говорите, что якобы задача и так очевидна, типа файлы. Сформулируйте.
Вы думаете, Matz не смог бы реализовать МН, если бы захотел? Имея кучу примеров реализации. Какие проблемы реализации МН в C++, какие в Python, Вы знаете? В Python реализация МН вообще оказалась излишней. Matz просто учится на чужих ошибках.
>В Ruby для реализации данного примера потребуется создать два модуля и четыре класса, тогда как при классической реализации множественного наследования будет достаточно лишь четырёх классов.
Для реализации какого примера? Для реализации уже кем-то созданной ромбовидной структуры классов? Для какой именно задачи она была создана? Только, не говорите, что якобы задача и так очевидна, типа файлы. Сформулируйте. Зачем эта структура нужна, зачем нужен абстрактный базовый класс, если теория ООП(а не Ruby) предоставляет гораздо более изящные инструменты? И без проблем связанных со множественным наследованием. Об этих инструментах и о проблемах МН Вы естественно ничего не слышали.
>Таким образом, Matz, изобретая колесо, усложняет разработку программного обеспечения на Ruby.
Matz ничего здесь не изобрел, это все в теории ООП и оно наоборот все упрощает.
Люди, не подсказывайте ему! Пусть сам ищет!
>Мы говорим об ограничениях Ruby, а не других языков.
Прежде чем говорить, об ограничениях, нужно говорить о назначении языка. А вот уже потом, можно сказать, какие язык имеет ограничения в рамках своего назначения.
>По поводу посредственной скорости: это является минусом Ruby и отрицать не имеет смысла.
Это не имеет смысла ни отрицать ни утверждать, если Вы не определили область применения. То, что Matz не стал заиматься преждевременной оптимизацией позволило ему сконцентрироваться на более важных свойствах языка.
>Повторяю тебе ещё раз, хочешь обсуждать меня -- создавай специальный топик и не меняй тему разговора, пытаясь скрыть недостатки языка.
Это Вы пытаетесь скрыть недостаток Ваших знаний, в повелительном наклонении указывая мне, что делать. Создам другой топик, когда захочу обсудить, что-то не относящееся к данному. Пока что, те свойства Вашей личности, которые становятся видны по Вашим высказываниям, вскрывают причины, почему Вы упорно ищете, как бы придраться к Ruby. А это имеет непосредственное отношение к теме. И является очень поучительным. Вам тяжело дались те скудные знания, которые Вы получили в области функ языков и в области ООП, и Вы ищете для себя повод, чтобы больше ничего не изучать.
