-- Отличительная особенность ламеров в том, что они не умеют учиться, ни на теории, ни на практике, ни на собственных ошибках. Из-за этого они постоянно комплексуют и пытаются выглядеть умнее, чем есть. Для этого они прикрываются разными цитатами, терминологией. Но на самом деле не могут все это логически увязать между собой. У них это никак не получается, и они просто пытаются тупо внешней формой своих высказываний подражать кому-то. Надеясь, что никто не заметит.-- Хотите продолжать трепыхаться, ну попробуйте-попробуйте, продолжайте веселить меня.
>1. Макросы. "Лишь зная, что такое макрос Lisp, можно увидеть, на сколько ограничено метапрограммирование в Ruby". (Peter Seibel. Practical Common Lisp)
Вот, наконец-то. Наконец-то появилось указание на область применения - метапрограммирование. Т.е. Вы можете увидеть, что автор книги, в отличии от Вас не рассуждает об ограничениях вообще, а привязывает их к конкретной области применения.
-- Судя по всему, Вы чисто случайно привели цитату с областью применения, иначе бы уже давно сказали бы об этом. Вы просто, как обычно, зацепились за слово "ограничено", и, сами того не подозревая, подтвердили мои высказывания об области применения. А может быть Вы вообще путаете "метапрограммирование" с "макропрограммированием"?
Только следует учесть еще один факт. Метапрограммирование - это слабость всех императивных языков, а не только Ruby. Метапрограммирование наиболее эффективно осуществляется на функциональных и декларативных языках, это общеизвестно. Так что это нельзя считать ограничением Ruby, это ограничение парадигмы. Matz просто не гонится за дешевой популярностью, не пытается "догнать" функциональные языки и следует стратегии "осторожного баланса" [ http://www.ruby-lang.org/en/about/ ].
Теперь другой вопрос, в каких задачах недостаточно того уровня метапрограммирования, который есть в Ruby?
Из Вашей же цитаты видно, что грамотные люди всегда подразумевают задачи и область применения.
-- А на самом деле, Вы метапрограммированием и не занимаетесь. Вы даже с блоками до сих пор толком разобраться не можете.
>2. Значения по-умолчанию. Их отсутствие принуждает меня использовать объявление функций через def, что не позволяет, например, мне создать хэш лямбда-функций со значениями по-умолчанию, который используется в функции принятия решения. В результате приходится эмулировать значения по умолчанию через дополнительные nil параметры. Не архи, как страшно, но не приятно. Вполне себе ограничение языка.
Т.е. Вы сами признаете, что это ограничивает Вас в создании "хэша лямбда-функций", но не в создании функций принятия решений. Кроме того, для создания функций принятия решений в Ruby есть другие эффективные средства, а не "через def".
-- Но, вероятнее всего Вы и функции принятия решений не создаете, просто опять вычитали где-то, иначе бы Вы знали, как их лучше создать в Ruby.
Итак, как я уже указывал выше, Вы все время приводите ограничения Ruby, которые ограничивают лично Вас, в применении синтаксических конструкций (даже не технологий), к которым привыкли лично Вы.
>3. proc является методом Kernel не рекомендованным к использованию. Альтернатива ему lambda.
Откуда это Вы взяли, что он не рекомендован к использованию? Сами придумали? Может лично для Вас он и не рекомендован, не спорю. А "lambda" это никакая не альтернатива, а синоним. Я уже это Вам сказал. А будучи синонимом тоже должна быть "не рекомендована".
Вот Вам и очередная подсказка, что же такое lambda в Ruby и почему она вовсе никакая не лямбда-функция.
>Далее, labmda и Proc.new имеют разное поведение, что не позволяет говорить об их отождествлении:
-- Ну вот, Вы снова лажанулись. Вам же было сказано, "lambda" - синоним "proc". Синоним, это значит надо подставить вместо, так как есть. Я же про Proc.new не говорил. Это у Вас каша в голове. Сами же говорите, что proc - это метод Kernel и тут же рассуждаете про метод new класса Proc.
Т.е. "lambda {...}" == "proc {...}". И ведут они себя совершенно идентично в версии 1.8. Может в версии 1.9 это и поменяли - не знаю.
А вот Вам и очередной вопрос на засыпку: откуда разница в поведении proc и Proc.new?
К тому же, Вы так и не ответили на вопрос (сами себе по крайней мере) - что же именно профиксили в версии 1.9?
-- А теперь, после того как Вы опять лажанулись, вернемся к вопросу, который стал причиной вышеизложенного.
Ваши слова:
>Передача двух блоков. Лямбда-функция в Ruby не является блоком.
>{ a=0 } # это блок
>lambda { a=0 } # это лямбда-функция
>Блок может быть использован только в качестве аргумента.
Итак, Вы наконец признались, что считаете конструкцию lambda { ... } лямбда-функцией.
Тогда, если Вы утверждаете, что {...} - это блок, почему тогда
def test; p "hello"; {p "world"}; end -> SyntaxError: compile error
но при этом
def test; p "hello"; proc{p "world"}.call; end; test -> "hello" "world"
и что такое тогда по-Вашему {a=>b}.
>>А теперь еще раз посмотрите на пример, котрый сами же привели:
>>f = lambda { |n| n }; p f -> #<Proc:0x0294f9c4>
>>И еще раз внимательно подумайте, что же это такое. В моих сообщениях были и другие подсказки.
-- Вы регулярно не справляетесь с моими аргументами, пытаясь делать вид, что их просто не было. Вместо этого радостно кидаетесь с новыми придирками и снова лажаетесь. А потом подтверждения моим же аргументам, сами же приводите в собственных ссылках, не замечая этого, демонстрируя собственную даже не рассеянность, а просто некомпетентность. См. выше про область применения.
Далее все к той же теме.
>4. Потеря синтаксической привлекательности при передаче двух блоков.
"при передаче двух блоков" - этой фразой Вы сами утверждаете, что передать два блока все-таки можно. Так на что именно Вы жалуетесь все-таки? На потерю привлекательности или на невозможность передать несколько блоков?
>Однако в Ruby этого добиться можно лишь передав функции не блоки, а
>лямбда-функции:
>def test b1, b2; b1.call || b2.call; end
>test lambda { print "hello" }, lambda { puts " world" }
Вы только что передали самые настоящие блоки, а никакие не лямбды. См. примеры выше.
Никакой лямбды в Ruby 1.8 нет. Про 1.9 пока не знаю. Где тогда по-Вашему класс Lambda, есть только класс Proc, объекты которого и называются блоками прямо в документации по Ruby.
Кстати, прямо в документации продекларировано то самое ожидаемое поведение, которое Вы называли багом. Поищите сами.
>Возможно, код "упаковки", о котором ты говоришь, более привлекателен. Напиши его.
Во-первых. Вы действительно называете это "потерей привлекательности"? Ну тогда вот это назовите потерей привлекательности тоже
def test; p "hello"; {p "world"}; end -> SyntaxError: compile error
Вы даже до сути докопаться здесь не смогли, откуда это все берется. А самое главное, какой у этого смысл.
Вас действительно раздражает просто слово "proc" (или "lambda") перед скобками? Тогда как общая компактность записи сохраняется.
Во-вторых. От этих конструкций "код упаковки" не избавит. Я ждал от Вас более каверзного примера, в котором дейсвительно помогает "код упаковки", но Вы до него даже не дошли. Вы же утверждали, что нельзя передать несколько блоков. Я просто подождал, когда Вы сами лажанетесь собственноручно их передав.
В-третьих. Прежде чем просить у меня примеры и контрпримеры, сначала сами приведите примеры, и при этом не лажанитесь. Мне нет необходимости говорить Вам, как правильно, я вполне удовлетворен тем, что мы выяснили, что у Вас не правильно.
Вы просто не понимаете лексической и синтаксической конструкции самого языка в целом, которая ни в чем не хуже традиционной, просто отличается. И даже имеет преимущества, но это отдельная тема. Но уж точно ни в чем не ограничивает, кроме мелких деталей.
-- Все вышеприведенное лишний раз доказывает, что Вы, как все чайники в программировании видите исключительно синтаксис и не видите семантику. Ваши рассуждения о множественном наследовании и Ваш пример по нему тоже подтверждают, что Вы видите только синтаксис и не знаете толком, зачем оно нужно. Вы просто ламер, который пытается прикрываться умными цитатами, надергивая их из книжек и форумов, но не понимая толком их смысл.
>5. Множественное наследование. Не я, ни ты не приводим конкретные преимущества и контрпримеры. Не имеет смысла обсуждать.
Значит теперь Вы это так сформулировали. Таким образом Вы, как и в прошлом сообщении, признаете, что Вы не можете привести ни примеров, ни преимуществ использования МН. Но при этом также выясняется, что Вы не знаете, как в Ruby решаются задачи, которые решались раньше с помощью МН.
Так в чем же ограничение Ruby? Только в том, что лично Вы не можете использовать в нем МН. Кстати, вот Вам еще одна подсказка. В популярном Object Pascal (Delphi) тоже никогда МН не было, но там эти задачи тоже как-то решались. Причем это было с "незапаиятных" для программирования времен.
И снова Вы лукавите, говоря, что я не привожу конкретные преимущества. Основной преимущество было и остается с самого начала. Ruby избавлен от проблем МН, ничего при этом не потеряв. Но Вы о проблемах МН так ничего и не выяснили. Хотя это общеизвестный факт в теории ООП.
Какой смысл приводить Вам правильные примеры, если вполне достаточно показать бессмысленность Ваших придирок. Какой смысл Вам что-то доказывать, если вполне достаточно показать нелепость Ваших аргументов.
-- Короче, Вы просто ламер. Ничего не знаете.
>6. Продукты. Приведи список продуктов, которые о чём-нибудь говорят, если продукты в Top100 "ни о чем не говорят".
Снова лукавите и передергиваете смысл. Я сказал так.
>>Какой у меня был аргумент? Я как раз привел аргумент, почему все эти списки продуктов ни о чем не говорят. А Вы продолжаете упрекать меня в том, что я не привожу списки с продуктами. Вы начинаете искажать смысл.
Я имел в виду все списки, при чем здесь Ваш Top100 из рекламы. Зачем Вы предлагаете мне искать какой-то список, если я сказал, что все списки ни о чем не говорят. Это как минимум нелогично. Вам следует по логике либо опровергать именно это высказывание, либо вообще заткнуться, а то опять облажаетесь. В этой ветке форума, аргументов на эту тему предостаточно, вот ищите их и опровергайте. А Вы просто по-ламерски делаете вид, что их не было.
И вообще, Ваши придирки к Ruby по поводу количества продуктов, ничем не отличаются от придирок поклонников MS к *nix'ам и свободному софту. Они тоже давят на количество и известность.
>7. Производительность. "Ссылки на сравнение производительности с другими языками мне следовало бы приводить если бы я отрицал, что у Ruby низкая производительность". Ты сказал, что у Ruby низкая производительность. Вопрос закрыт.
Снова лукавите, притворяетесь, как будто в первый раз слышите. Вопрос в области применения. Это подтверждает даже Ваша собственная цитата из "Practical Common Lisp" - грамотные люди об ограничениях без указания области применения не говорят. И этот вопрос Вам снова закрыть не удалось. У Вас куча незакрытых вопросов, чтобы говорить какой вопрос закрыт, а какой нет. Научитесь для начала не лажаться, а потом уже говорите что-то о закрытии вопроса.
У Вас даже таких задач нет, в которых бы производительность Ruby Вас чем-то ограничила. Вы сначала до них дойдите. У Вас реальной практики программирования вообще нет, это сразу видно.
>8. Веб-технологии. Цитируй мой аргумент и свой контраргумент. Твоё сообщение слишком размазано.
Чисто ламерские отмазки. Когда не можете ответить, говорите, что непонятно или "размазано". Если что-то где-то и размазано, так это каша, которая у Вас в голове. Ну конечно, в том сообщении еще и другие аргументы с контр-аргументами есть, на которые Вы не смогли ответить. Я Вам только на эти два указал для начала.
>9. Альфа-преобразование. Цитирую https://www.opennet.ru/openforum/vsluhforumID3/43307.html#66: "Однако это по прежнему не означает что правы Вы, утверждаю, что с блоками в Ruby что-то не так".
>Ты говоришь, что я не прав, но утверждаешь, что с блоками в Ruby что-то не так.
Опять ламерские цепляния к словам от безысходности. Как будто не видно, что там опечатка и должно стоять "утверждаЯ" вместо "утверждаЮ". Какой смысл мне было так говорить? Или Вы на смысл фраз вообще не смотрите. Не удивительно. Смысла синтаксических конструкций к которым Вы цепляетесь Вы тоже не понимаете.
Так Вы считаете, с учетом всего вышесказанного, что с блоками в Ruby что-то не так?
>Не существует таких понятий, как "чистая" или "не совсем чистая" лямбда-функция, -- не придумывай псевдо-теории.
Прежде чем рассуждать, что в теориях существует, покажите, что в теориях разбираетесь. В теории не существует, а на практике существуют объекты, которые при определенных условиях ведут себя, как лямбды. А программирование - это еще и практика, кроме теории. Вы просто ламер.
>Существует лишь одна лямбда-функция, всё остальное же является её неверной реализацией.
Либо вообще реализацией не является - не забывайте такой вариант. Вы очень туго соображаете.
Еще может быть эмуляция, я такой термин тоже использовал. В любом случае это все Вам не поможет.
Так Вы все еще считаете что в Ruby 1.8 реализована именно лямбда функция?
Так Вы считаете или нет, что в Ruby 1.8 был именно баг, а не ожидаемое поведение?
Кстати, Вы так и не ответили на вопрос - зачем в императивных языках используются функциональные элементы, если функциональное программирование там в чистом виде использовать невозможно.
Хотите продолжать трепыхаться. Давайте. Веселите меня.
