Пока я отвечал Вам, у меня еще больше сложилось впечатление, что Matz очень хорошо знает, что делает. Балансирует систему и не гонится за дешевой популярностью. Я не являюсь фанатиком Ruby. У меня даже очень небольшой опыт программирования на нем. Если мне покажут что-то лучшее в той области применения, на которую претендует Ruby, именно в той области, а не вообще, я это очень внимательно рассмотрю. Но пока я вижу только какие-то мелкие придирки.Пока что можно сделать выводы, что Вы очень плохо разбираетесь в тех областях, за что пытаетесь критиковать Ruby. Вы приводите много ссылок и мало что можете объяснить своими словами. Потом еще выясняется обычно, что сами ссылки Вы толком не читали. Просто передираете откуда-то.
Но самое главное, Вы сразу теряетесь, при вопросах о назначении, областях применения и важности. Когда программист не может ответить на вопрос, зачем нужно то или иное, это говорит только о том, что у него нет реального практического опыта, он просто что-то об этом слышал.
Например, как выясняется, Вы просто не знаете, что такое "чистота системы", а главное, зачем это нужно. Путаете это понятие с полнотой реализации некой теории.
Что по-Вашему имеется в виду под понятием "чистая реализация концепции ООП"?
Вы больше походите на ламера, который пытается умничать.
Функциональное программирование в RubyИтак, Вы утверждали, что в Ruby по-Вашему неверно реализована альфа-редукция. Привели по этому поводу ссылку [ http://www.ruby-forum.com/topic/93339 ], и утверждали, что в этой ссылке говорится якобы о баге, который был профиксен. Также Вы привели пример, где по-Вашему проявляется неверная реализация альфа-редукции
p n=[1]*3; n.each { |n| p n }; p n
Повторяю в очередной раз.
1. Вы не поняли, о чем говорится в том посте - там ничего не говорится о функциональном программировании.
2. Слово "bug" использует только автор поста, да и то в вопросительной форме, Matz сказал, что это ожидаемое поведение, и что оно изменено в новой версии. Никакого бага. Ваши заявления о том, что Matz, что-то скрывает пока что являеются Вашими домыслами, Вы ничего не доказали. Почему это поведение ожидаемое, я объяснил в примерах в предыдущих сообщениях. То что Вы этого не поняли говорит только о том, что Вы не знаете имп парадигму.
3. Читайте заявление о языке Ruby [ http://www.ruby-lang.org/en/about/ ]. "Ruby is a language of careful balance. ...language that balanced functional programming with imperative programming." - "Осторожный баланс". Никто Вам не гарантировал чистую реализацию функ парадигмы. Пользуйтесь чистыми функ языками для чистого функ программирования. Ваши претензии не по адресу. А как Вы вообще представляете себе язык, где одновременно в чистом виде были бы реализованы обе парадигмы.
4. Докажите, что в Ruby вообще реализовано лямбда-исчисление, и где там по-Вашему должна была быть альфа-редукция и зачем она там нужна. Вы так на эти вопросы и не ответили. Я не знаю, что это такое и не обязан знать, я уже говорил. В статье из Википедии, ссылку на которую Вы приводите, это вообще называется альфа-конверсией. Вы снова "плаваете" в терминологии и не понимаете, о чем говорите. И вообще, объясняйте своими словами, нечего ссылками прикрываться. Тем более, все время выясняется, что Вы не понимаете сами, о чем там идет речь. Вы еще ссылки на печатные издания все время приводите. По-Вашему, все должны искать эти книги, чтобы только понять, о чем Вы говорите. Это говорит о том, что Вы просто умничающий ламер.
Вы так и не ответили на вопрос. Так Вы считаете или нет, что блок в Ruby является лямбдой? Вы до сих пор так и не поняли, что из себя представляет объект-блок в Ruby.
5. В сообщении [ http://www.opennet.ru/openforum/vsluhforumID3/43307.html#56 ] я задал Вам вопрос на засыпку. Что именно было "профиксено" в версии 1.9? А Вы меня переспрашиваете. Я-то знаю ответ на этот вопрос. Странно только, что Вы не знаете на него ответ, если утверждаете, что по-Вашему это баг, который наконец-то был профиксен в новой версии, и его по-Вашему никак не могли профиксить в старой. Откуда тогда Вы так уверены, что он по-Вашему наконец профиксен? Только потому, что стали выполняться знакомые Вам функ формулы?
>Объясни такое поведение для Ruby 1.8.7. Почему в 1.9 оно другое? Какую парадигму использует Ruby 1.8.7? Какую парадигму использует Ruby 1.9?
В обоих версиях используется императивная парадигма. Так и не поняли, что это такое?
Вот Вы и объясните, если утверждаете, что это был баг, а если не можете объяснить, то не говорите о баге. Matz уже сказал, что это ожидаемое поведение. Это и есть тот самый "осторожный баланс" [ http://www.ruby-lang.org/en/about/ ].
На самом деле, подсказок Вам дано было очень много, и в самой ссылке, которую Вы сами привели, но так и не разобрались. И в моих сообщениях. Вы эти подсказки упорно не видите. Если Вы такой невнимательный, то можно только представить, как Вы изучали функ программирование.
>Не понял при чём здесь итератор. Наверное, ты, случайно, опечатался и имел в виду аргумент.
Нет, не опечатался. Это была очередная подсказка. Именно итератор, а не просто параметр. В этом все и дело. Не знаете, что это такое? Вы до сих пор так и не поняли, что из себя представляет объект-блок в Ruby.
Множественное наследование в RubyВы сейчас снова пойдете в свой собственный Биореактор. Вам какой вопрос был в очередной раз задан?
>>Что такое можно сделать с помощью МН, чего нельзя сделать с помощью его более изящных и эффективных альтернатив? И это вопрос не относительно Ruby, а относительно теории ООП. Что говорится в теории ООП про МН Вы явно не знаете.
А Вы снова что говорите?
>Вернёмся к началу дискуссии о множественном наследовании. Мои слова были буквально следующими: "Множественное наследование в Ruby не реализовано в чистом виде".
Неправда, Вы говорили так.
>Чистая реализация ООП? Множественное наследование в Ruby не реализовано в чистом виде.
Неправильно. МН в Ruby вообще не реализовано.
Здесь Вы лишь демонстрируете, что путаете понятия "чистота" и "полнота". Видимо, Вы вообще не знаете, что такое "чистота". И самое главное, какие она дает преимущества. В частности Вы просто не понимаете выражение "чистая реализация ООП".
>После чего я показал, что использование примесей порождает сущности, которые не требуются при классическом множественном наследовании.
Вы ничего еще не показали. Вы так задачу и не поставили. Вы лишь показали, некоторую готовую реализацию с МН и пример эмитации этой структуры средствами Ruby и что при этом действительно возникают лишние сущности. Но Вы этим не показали, что без него нельзя вообще обойтись. Вы уже сформулировали задачу в терминах МН, естественно, что после этого Вы стали приводить реализацию самого МН, а не задачи. Изучив однажды МН, Вы просто в мыслях не можете выйти за его пределы.
Задача не ставится в терминах ООП! Уже будучи поставленной она решается с помощью ООП. Или какими-то другими средствами.
>Пусть, во множественном наследовании есть свои проблемы, однако Matz полностью от него отказался, хотя мог бы сочетать два подхода: иметь множественное наследование и примеси.
И зачем по-Вашему нужен старый вариант, в котором есть проблемы, если есть новый вариант, в котором проблем нет. Хотите оба варианта - используйте Python. Matz просто не стал повторять его ошибку.
>Сейчас же ты приведи пример, который потребует меньшего количества сущностей для реализации множественного наследования в Ruby, нежели при использовании классического множественного наследования.
Во-первых, пример в котором нельзя обойтись без МН никак не можете привести Вы. Нечего на меня перекладывать, если сами не можете. Этих примеров полно в теории ООП, изучайте. Во-вторых, не только с меньшим количеством сущностей, Вы опять уходите от главного. А главное - без тех проблем, которые есть в МН. Вы даже все еще так и не разобрались, что это за проблемы.
Короче, изучайте ООП, прежде чем придираться. Вы просто умничающий ламер.
Другие навороты в Ruby>Значения по умолчанию не имеют отношения ни к императивному, ни к функциональному программированию.
Снова неправильно. Они не имею отношения к функ, но имеют отношение к имп программированию. Но в Ruby нет только зн_по_ум для лямбда-функций, а если Вы сами признаете, что зн_по_ум не имеют отношения к функ прог, то насколько по-Вашему они важны? Кроме того Вы говорите о лямбда-функциях, а есть ли в Ruby лямбда-функции? Там точно есть блоки и итераторы, и у них другой синтаксис. Кроме того, Вы как всегда не читали толком причину, почему их не сделали. А причина в том, что уже не тянет LARL(1)-парсер. Хотя Вы вряд ли знаете, что это такое. Парсер нельзя до бесконечности загружать наворотами, а у Ruby и так очень богатый сиснтаксис.
>Не пудри мне мозги словами: "API", "смесь", "ширпотрёб".
Ни о чем.
>Если тебе не нужны похожие возможности, то почему ты не используешь Brainfuck, который так же является Тьюринг-полным языком?
Нелогично. Если я могу обойтись без тех фишек, которых нет в Ruby, это не значит, что мне не нужно то, что в нем есть, и что мне подойдет любой Тьюринг-полный язык.
>Насколько важна конструкция unless в Ruby? Ни насколько. Но она позволяет сделать язык более простым и выразительным.
То есть Вы хотите сказать, что он тоже не важен? Ну и насколько богаче и выразительнее делает язык приведенный Вами safeif.
>Наглядно увидеть преимущества и простоту создания макросов можно в [1], или же их первое применение в третей главе.
Вы снова прикрываетесь ссылками. Тем более ссылками на печатные издания и их главы. Никто не обязан искать книги, только для того, чтобы понять, что Вы имеете в виду. Своими словами объяснить не можете. Насколько Вы разбираетесь в содержимом своих же собственных ссылок, Вы уже неоднократно показывали.
>Я говорю о макросах, а не о конкретных фичах. Ты попросил привести пример того, что eval и method_missing недостаточны, я его привёл пример ограниченности макропрограммирование в Ruby. CAPI это не макропрограммирование.
Во-первых, после Ваших аргументов по поводу функ_прог и МН уже начинают возникать сомнения, насколько Вы хорошо разбираетесь и в этой теме.
Во-вторых, тот пример котрый Вы привели, safeif, Вы так и не объяснили насколько он важен?
В-третьих, макропрограммированием обычно расширяют язык в области концептуальных аспектов, в то время как safeif - это системная, техническая конструкция. В каких задачах требуются триггеры на изменение значения объекта? Как часто такие задачи возникают?
Если safeif важен - хорошо. А если нет - есть еще какие-то аргументы в пользу недостаточности eval и method_missing. И самое главное, в каких областях применеия?
И почему нельзя пользоваться C-API? Скриптовые языки как раз и развиваются обычно постепенным обрастанием вокруг C-API. А в Ruby именно С-API реализован очень чисто, просто и лаконично. В отличии, например от Python. А сами расширения возможностей макросов тоже как известно делаются на С. Я уже говорил сразу, что Ruby еще достаточно молодой язык, а это значит, что основное преимущество получают в нем именно профессиональные программисты, которые не ждут, когда дядя Matz что-то для них сделает, а сами могут сделать и предложить Matz'у.
