>Ты зациклен на области применения. По Ушакову, "ограничить": стеснить известными пределами, условиями, поставить в какие-н. рамки, границы [1]. Неизвестно откуда ты взял область применения для этого слова. Ограниченность не зависит от области; кроме этого если язык не подходит под какую-то область, значит он стеснён известными пределами, условиями, то есть ограничен.При чем здесь определение из словаря? Вы в каких категориях мыслите? В абсолютных или относительных? Если Вы считаете, что ограниченность следует понимать абсолютно, тогда Вы правы, область применения к этому никакого отношения не имеет.
То есть Вы не согласны с утверждением "говорить об ограничениях без привязки к области применения не имеет смысла". Ваше право так считать.
Вы как хотите, а я мыслю в относительных категориях. Таким образом, раз Вы не можете назвать область применения, то областью применения автоматически становится некоторый набор технологий, к которым Вы привыкли, без привязки к реальным задачам.
Таким образом, тема, которую Вы ведете формулируется по-прежнему следующим образом.
>>Ограничения языка Ruby, которые ограничивают лично Вас в применении технологий программирования, к которым привыкли лично Вы.
-- То, что Вы все еще мыслите в абсолютных категория, говорит не просто об отсутствии реального опыта в программировании, но и о Вашей незрелости и как специалиста в какой бы то ни было области и вообще о незрелости Вашей личности, за неприкосновенность которой Вы все время выступаете.
>1. Макросы. Не сама ссылка является аргументом, но её содержание.Автор книги великолепно изложил материал, повторять его я нет смысла. Более того, ты продолжаешь говоришь о CAPI не смотря на то, что к макросам это не имеет отношения.
Безусловно, речь шла о содержании, а о чем же еще? О названии ссылки что-ли? Слово "содержание" было просто опущено для краткости. Кроме того, Вы здесь лукавите, я еще там использовал слово "теория", а это автоматически подразумевает содержание, хотя лучше наверное действительно использовать слово "материал". Только что это меняет?
-- Не сомневаюсь, что автор книги великолепно изложил материал. А вот судя по тем Вашим ссылкам, которые я здесь разбирал, еще не факт, что Вы этот великолепный материал понимаете. Вот и сформулируйте аргументы на основании этого великолепного материала. "Повторять нет смысла" - еще бы Вы здесь сам материал повторяли.
То есть Вы считаете, что содержание ссылки, материал который логически не связан с дискуссией, можно использовать целиком как аргумент. Или все-таки аргументы можно лишь выводить на основании этого материала?
-- Вы уже придираетесь к мелочам. Иссякают аргументы?
Какое C-API имеет отношение к макросам, я уже говорил, просто Вы делаете вид, что этого не заметили. А Вы так и не ответили в каких именно областях применения ограничения макросов Ruby существенны. Хотя конечно, если Вы мыслите в абсолютных категориях, как я указал Выше, то продолжайте просто перечислять ограничения. Однако, как я уже говорил почему тогда Вы выбрали именно эти ограничения из всех возможных.
>2. Значения по умолчанию для лямбда-функции. Это сильно не вредит никакому стилю программирования. Однако на текущий момент является ограничением Ruby.
-- Если Вы вообще что-то знаете о стилях.
В каких именно областях применения оно является ограничением и в каких стилях?
>3. Передача двух блоков. Лямбда-функция в Ruby не является блоком.
>{ a=0 } # это блок
>lambda { a=0 } # это лямбда-функция
>Блок может быть использован только в качестве аргумента.
Итак, Вы наконец признались, что считаете конструкцию lambda { ... } лямбда-функцией. Дам еще одну подсказку, в Ruby ключевое слово "lambda" просто синоним ключевого слова "proc".
А теперь еще раз посмотрите на пример, котрый сами же привели:
f = lambda { |n| n }; p f -> #<Proc:0x0294f9c4>
И еще раз внимательно подумайте, что же это такое. В моих сообщениях были и другие подсказки.
-- Вы просто пропустили огромное число подсказок в моих сообщениях. Неудивительно, что Вы постоянно "плаваете" во всех теориях, о которых шла речь.
>Напиши код, который ты имеешь в виду про "упаковку".
Это Вы доказываете, что проявление этого недостатка в том, что "при этом теряется синтаксическая привлекательность", да и то - единственное проявление. Вот Вы и приведите код, в котором по Вашему теряется привлекательность, и как это должно было бы быть по-Вашему.
>5. Множественное наследование. Обсуждать нет смысла. Ни я, ни ты не можем привести контрпример о нецелесообразности использования.
Пример не можете привести Вы. Пример, где нельзя было бы обойтись без МН да еще и не получив при этом преимуществ.
Я же просто не хочу приводить примеры, которых и так полно в теории ООП. Кроме того, я Вам это уже указал, а Вы это как бы проигнорировали, что Вы ошибочно считаете, что примеси сами по себе являются альтернативой МН.
Не можете или не хотите обсуждать - не обсуждайте, но из этого не следует, что нет смысла. Кроме того, Вы так и не разобрались, какие ограничения есть в МН и его реализациях, и как их устранили. Если считаете МН с его ограничениями - полноценная концепция, используйте языки, где она реализована. А Matz знает, что делает.
>6. Продукты. Ты не привёл ни одного продукта на Ruby, о каком контраргументе ты говоришь? В одном из постов я сделал это за тебя, приведя Top100 самых популярных сайтов на Ruby on Rails. Дерзай с примерами, которые не ориентированы на интернет.
-- Дерзайте сами со своими примерами.
Какой у меня был аргумент? Я как раз привел аргумент, почему все эти списки продуктов ни о чем не говорят. А Вы продолжаете упрекать меня в том, что я не привожу списки с продуктами. Вы начинаете искажать смысл.
>7. Производительность. Я не вижу ссылок на производительность или сравнительных таблиц с другими языками программирования. Я знаю, что Ruby 1.9 быстрее 1.8, хотя не во всех моментах [2].
Вы опять пытаетесь искажать смысл. Ссылки на сравнение производительности с другими языками мне следовало бы приводить если бы я отрицал, что у Ruby низкая производительность. Я разве это где-то отрицал? Аргумент был другой.
>8. Веб-технологии. Ты о чём? Цитируй моё утверждение и свой контраргумент.
-- Все есть в сообщении, которое я привел, Вы просто уже отмазываетесь.
>9. Альфа-преобразование. https://www.opennet.ru/openforum/vsluhforumID3/43307.html#67. В https://www.opennet.ru/openforum/vsluhforumID3/43307.html#66 ты соглашаешься, что с блоками что-то не так. Ты на что волну гонишь?
Опять искажение смысла. В #66 я нигде не соглашаюсь, что с блоками что-то не так, я там говорю о том, что ошибочно высказался относительно того, что в Scheme нельзя кое-что сделать. Из этого никак логически не следует, что с блоками в Ruby что-то не так. Кроме того, мои примеры, демонстрирующие поведение блока остаются в силе. Разбирайтесь, если хотите. А не хотите - не разбирайтесь.
Альфа-преобразование. Сообщение #67. В 1.8 нельзя, в 1.9 можно. Ну и что? Где доказательство, что с блоком что-то не так? Где доказательство, что это по-Вашему баг, а не ожидаемое поведение. В 1.8 одно поведение, в 1.9 другое. Следствие стратегии "осторожного баланса" [ http://www.ruby-lang.org/en/about/ ]. Или Вы считаете, что в 1.9 "лямбда" стала чистой, а выражение lambda {...} вообще стало лямбда-функцией?
-- Все что я высказывал по этому пункту относительно Вашей личности, остается в силе. Кроме этого. Вы уже начали играть со смыслом, пытаясь скрыть собственные многочисленные ляпы, на которые я Вам неоднократно указывал. Жалуетесь, что я якобы ухожу от темы, а сами пытались только что это сделать. Уйти от разговора о якобы баге и перевести его на "альфы". Докажите сначала, что не совсем чистая "лямбда" - это баг.
