Здравствуйте, Gaperton, Вы писали:
V>>Приведу аналогию. Вот компания Nokia выпустила сотовый телефон в титановом корпусе. Он очень крепкий и, наверное, им можно забивать гвозди. Дак вот, сравнивать этот телефон с молотком мне кажется некорректно, даже несмотря на то, что телефоном в принцепе можно забивать гвозди. . V>>Понятно, что молотком забивать гвозди проще, но из-за этого у телефона его телефонных качеств не прибавляется и не убавляется . G>Все аналогии некорректны. Мы не дети, чтобы переходить на яблоки.
Думаю, у меня получилать очень хорошая аналогия
V>>Я говорю: "А зато, с помощью молотка нельзя звонить". На что мне отвечают: V>>
Бред какой-то... Лиспу не нужны эти возможности шаблонов, поскольку в его рамках они бессмысленны.
V>> G>Правильно тебе отвечают. В лиспе делается все тоже самое, что делается на шаблонах, легко обходясь без понятия шаблона.
Из твоих слов следует, что на лиспе легко можно писать статически полиморфный код со статической типизацией? Это так?
Здравствуйте, Gaperton, Вы писали:
G>Может. В динамически типизированных языках можно вывести типы статически из контекста употребления. Не все, конечно, но во многих местах — можно. Из известных языков, где применяется type inference — JScript .NET (сюрприз!).
Если есть вывод типов, то есть и статическая типизация. Но есть языки просто не предназначенные для статической типизации. Например, тот же Питон. В нем вообще нет объявлений переменных. Первое же упоминание и появляется переменная. Далее переменная может быть переопределена. Получается, что сделать типзированную переменную очень трудно. Проще создать неких вариант или указатель. Далее списки. Конечно можно предпологать, что в списке должны быть объекты только одного типа. Но это предположение нестыкуется с нетипизированныеми языками. Ну, нет в нем понятия типизированного списка. В итоге для процедуры то может и можно вывести, что список однотипный, но общаться то с ней прйдется именно нетипизированными списками. А что с этого толку? Ведь на пребразование уйдет слишком много времени. А ведь код на сегодня все больше закладывается в независимые компонеты, а стало быть у компилятора просто нет всей информации. В итоге теоритически то можно выводить типы. Но фактически сам язык и его рантайм должны быть заточены под это. У JScript .NET рантайм строготипизированный. А вот у Лиспа он явно на типизацию не рассчитан.
G> Все гораздо проще. В динамически типизированном языке любая функция — "шаблонная". И любой "класс". Там просто нет нужды в механизме, подобном шаблонам — и так все шаблон, причем работает в рантайме. Поэтому макросы лиспа вроде как нельзя сравнивать с шаблонами С++.
Именно! У низ разная "заточка".
G>Хотя, если посмотреть книжку Александреску, в которой он жестко надругался над С++
Я бы сказал жестоко.
G> — то очень даже можно и нужно .
Скорее у него вышло нечто вроде Окамла.
G> Там он демонстрирует, что в compile time при помощи шаблонов можно сделать практически все, что угодно — благодаря наличию рекурсии мы имеем вычислительную полноту. Ничего не напоминает? Мне напоминает макросы лисп . Так что ответ не так однозначен.
И все-таки не однозначен. Макросы Лиспа не делются на компайл и рантайм. Лисп вещь в себе. К тому же при серьезной идее весма странная реализация. Все эти цдр адр... ужас.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Спорный тезис, в моих устах, является ложной посылкой, если используется в качестве посылки.
Спорно.
Точнее ошибочно.
G> Посылка может являтся либо истинной, либо нет.
Спорная посылка — это посылка истинность или ложность которой не очевидна. С точки зрения логики мы имем три состояния:
1. Истинно. И тогда формально верное заключение сделанное на базе это предпосылки тоже верно.
2. Неверно (соотвественно не верен и вывод).
3. Спорно. При этом формально верное заключение сделанное на базе это предпосылки тоже спорным. Заметь! Спорным, а не неверным!
G>А вообще, может не будем цепляться к словам? Это оффтоп.
В данном случая ты усомнившись в предпосылке сделал заключение о неверности всего вывода. Ты уж или развенчивай предпосылки или уж хотя бы называй выводы спроными. А то получается без доказательства или фактов ты наклеиваеш на выводы ярлык ложности.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Я обычно говорю ADT (АДТ) . Что это ты сегодня за мой русский язык взялся?
Я не за русский. Но не очень понятно зачем буквы переставил. Вдруг что-то в этом есть мне не понятное.
G>О как (век живи — век учись)! Пример пожалуйста, особенно "обычного языка", где учитываются значения аргументов при полиморфном вызове в run-time (твой комментарий по правилам русского языка относится ко всему абзацу, а не ко второй половине ).
1. Мы кажется уже договорились, что полиморфизм бывает статический. При этом 90% современных языков это делают.
2. мультиметодыmultimethods
G>Не думаю, что в списке примеров окажется С#,
Здравствуйте, VladD2, Вы писали:
G>>О как (век живи — век учись)! Пример пожалуйста, особенно "обычного языка", где учитываются значения аргументов при полиморфном вызове в run-time (твой комментарий по правилам русского языка относится ко всему абзацу, а не ко второй половине ).
VD>1. Мы кажется уже договорились, что полиморфизм бывает статический. При этом 90% современных языков это делают.
К чему это ты? Я не понимаю.
VD>2. мультиметодыmultimethods
Вместе с тем, достаточно часто возникают ситуации, когда гомоморфные иерархии, определяемые как иерархии классов с одинаковым открытым интерфейсом, унаследованным от общего базового класса [1], взаимодействуют через функцию, виртуальную к произвольному числу полиморфных параметров. Такая функция называется мультиметодом [2], а возможность ее использования существует в языке программирования CLOS (Common Lisp Object System). Однако широко распространенные ОО языки программирования не поддерживают подобный механизм в связи с отсутствием его эффективной реализации [3].
В первой ссылке по твоему поиску. Почитал бы ты сам свой гугл , что ли.
G>>Не думаю, что в списке примеров окажется С#, VD>Встроенных нет. Но народ над этим думает http://rover.cs.northwestern.edu/~surana/blog/past/000117.html
Примеров "обычных языков" нет. Впрочем, как и необычных. Все понятно. Вопрос снят.
VD>>>А кое где реализуются имеющимися средствами. G>>Гхм. Имеющееся средство называется... VD>В гугле думаю сразу поймешь о чем я говорю. У нас на сайте тоже статейки имеются.
Хитрый ленинский прищур не изчез, однако . У нас тоже на кое-кого кое-какой материалец имеется . Мои ответы на свои посты тоже ищи в гугле. Сразу все поймешь. Там все есть.
Здравствуйте, VladD2, Вы писали:
VD>Что ты понимашь под специализацией?
Создание отдельной функции/класса для каждого конкретного типа. В случае шаблонов от этого не уйти. А вслучае полиморфных функций в ФЯ можно. То что некоторые компиляторы эти функции специализируют, их дело, но в принципе это совершенно необязательно.
VD>С++ логическое развите С. Все его возможности С++ включает. С предпочитается только если нужно переносить код на экзотические платформы. Ну, и отдельными фанатами. В общем, С++ от наличия С не становится не перестает быть системым языком.
Ну и где же многочисленные операционные системы, созданные на С++, который включает С? Под Юниксами даже обычные пользовательские программы, как правило, написаны на С.
VD>Идея шаблонов была в АДА (если не ошибаюсь) и об этом писал Страуступ. А то что что-то где-то изучается еще не значит что оно служит прототипом всему остальному.
Ну ХЗ что там было в АДА. Ценные идеи заложенные в Лиспе постепенно внедрялись в ИЯ (взять хотя бы оператор if ), а некоторым из них это еще предстоит. Вот, интересно, какие идеи принадлежащие исключительно С++ перейдут в следующие языки и будет ли через 40 лет после его рождения о нем кто-то еще помнить.
VD>На примере того же С/С++ люди скорее видят вред макросов. Я бы не называл макросами то что проходит синтаксическую обработку. Иначе возникает путанница.
Это проблемы С++, а не макросов.
VD>Ага. Вот только толку с них никакого. И суть языка от этого не меняется. Или продолжается интерпритация или начинаются ограничения.
Почему ты думаешь, что Лисп нельзя откомпилировать в машинный код? Я давал ссылку на статью про фирму (или продукт) Orbitz. Там ясно написано, что они оптимизировали Лисп для большей производительности и получали очень высокую скорость.
VD>Да нет там никакой эффективности. Суть языка интерпретаторная. Не может быть быстрым нетипизированный код заточенный на работу со связанными списками.
Это заблуждение. Опровержение — Yahoo купила продукт Пола Грехема, написанный на Лиспе, а не поделки его С++снутых конкурентов.
VD>То есть говорить об отсуствии чего-то в Лиспе бессмиысленно. А о незаточенности С++ подо что-то нормально? Еще раз повторю свою мысль. Заявление об убогости шаблонов С++ провакациооно и неразумно. Они прекрасно решают поставленную перед ними задачу, и имеют массу приемуществ перед другими подходмаи. Эдак все что тебе не нравится можно назвать убогим. По мне так сам Лис убог. Что-же теперь?
Я не называл шаблоны убогими. Я назвал их примитивными по сравнению с макросами в Лиспе (по сравнению, а не вообще). В рамках С++ они может и решают свои задачи и лучше, чем что-то еще, но макросы Лиспа более гибкий и мощный инструмент.
VD>Зашибись. Что нельзя написать на С++? А что нельзя написать на ассемблере? Твоя фраза изумительно к ним подожид. Может написать что-то на ассемблере или понять его не так уж и легко, но пользоваться им можно без проблем. Не находиш что от замены Лисап на Асм ничего не изменилось? Такие рассуждения бессмысленны.
Это ты сам что-то бессмысленное придумал. Я уже говорил, что макрос выглядит как обычная функция, только вместо вызова ее в рантайме, происходит подстановка ее результата в компайлтайме. Что тут сложного?
Q>>А если есть 2 вложенных while? VD>Ты говорил о невозможности. Ну, да и это решается если потрахаться.
Ну вот уже надо трахаться. А ведь это буквально самое простое, что позволяют сделать макросы.
VD>Да. Правдой было бы сказать что ее вообще нет. Все списки пишутся на этом языке. Использование же слов вроде примитивные, вульгарные нужно только для того чтобы унизить чьи-то чувства. Я не поборник С++, но и я чувствую неспроведливось в этих действиях.
Ну давай теперь политкоректно называть это list-challenged или macros-challenged, как это принято в USA чтобы не оскорблять ничьих чувств.
VD>Аналогии не могут использоваться при доказательстве (и темболее при обвинении). Ими можно только иллюстрировать некое описание. Иначе такое доказательство начинает называться демагогией. Так что давай без анлогий. Темболее таких долеких.
Я ничего и не доказываю. Я сделал попытку показать, что идеологически шаблоны куда ближе к макросам Лиспа, чем к полиморфным функциям ФЯ.
VD>Еще раз повторюсь, что шаблоны в С++ не являются чистыми макросами. Это фича для обобщенного программирования. Как ее можно сравнивать с макросами из нетипизированного интерпретируемого языка я вообще не понимаю. Что же касается возможностей, то дай бог всем ФЯ иметь такие возможности как у С++. Этому бы языку устранить грабли, цены бы ему не было бы.
Вот это точно бездоказательное утверждение.
Кроме того, я надеюсь, что ты сравниваешь шаблоны с макросами в Лиспе, а не с убожеством называемом макросами в С/C++.
Здравствуйте, prVovik, Вы писали:
V>Мне действительно по барабану, что и где появлялось первым. Порох, например, китайци первыми придумали, и что теперь всем остальным не использовать огнестрельное оружие?
Какие-то странные выводы Где я написал, что, если что-то появилось раньше в Лиспе, то это нельзя использовать?
V>А зачем надо генерировать функции с похожей функциональностью? Разве нельзя обойтись динамическим полиформизмом? Ведь он и был придуман ради того, чтобы одни и теже функции могли вести себя немного по разному, в зависимости от переданных параметров? Сделать полиморфный вариант STL — это совершенно не проблема.
Во-первых, это невозможно для некоторых функций. Во-вторых, специальная версия для конкретного типа эффективнее полиморфной (контейнеры object'ов в C# vs специализированные контейнеры). В-третьих, ты сам об этом сказал, в С/С++ подобная полиморфность достигается за счет устранения контроля типов, что опасно.
V>Решением этих проблем может стать отказ от универсального полиморфного кода и переход к статически типизированному. Именно для этого и служат шаблоны в С++!!!! Именно для создания статически типизированного кода!!! Поэтому я и говорил, что шаблоны С++ оперируют типами. Или другими словами, шаблоны в С++ — это механизм организации статического полиморфизма. Это узкоспециализированный механизм, который АБСОЛЮТНО не предназначен для генерации кода. Из-зи этого совершенно не имеет смысла сравнивать лисповые макросы с шаблонами.
Если бы он был не предназначен для генерации кода, то все шаблоны бы компилировались в объектники, а не хранились бы в header файлах, как не пойми чего.
G>Вместе с тем, достаточно часто возникают ситуации, когда гомоморфные иерархии, определяемые как иерархии классов с одинаковым открытым интерфейсом, унаследованным от общего базового класса [1], взаимодействуют через функцию, виртуальную к произвольному числу полиморфных параметров. Такая функция называется мультиметодом [2], а возможность ее использования существует в языке программирования CLOS (Common Lisp Object System). Однако широко распространенные ОО языки программирования не поддерживают подобный механизм в связи с отсутствием его эффективной реализации [3].
G>В первой ссылке по твоему поиску. Почитал бы ты сам свой гугл , что ли.
Нда, конструктивный разговор с тобой получается. Выдрал из контекста то что больше понраивалсь и доволен.
G>>>Не думаю, что в списке примеров окажется С#, VD>>Встроенных нет. Но народ над этим думает http://rover.cs.northwestern.edu/~surana/blog/past/000117.html G>Примеров "обычных языков" нет. Впрочем, как и необычных. Все понятно. Вопрос снят.
Ну, то-есть сделал вид что ничего не заметил и объявил себя правым? Заодно поёрничал...
Ай как некрасиво.
VD>>В гугле думаю сразу поймешь о чем я говорю. У нас на сайте тоже статейки имеются. G>Хитрый ленинский прищур не изчез, однако . У нас тоже на кое-кого кое-какой материалец имеется . Мои ответы на свои посты тоже ищи в гугле. Сразу все поймешь. Там все есть.
Жаль что по человечески ты общаться не хочешь.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Ну и где же многочисленные операционные системы, созданные на С++, который включает С? Под Юниксами даже обычные пользовательские программы, как правило, написаны на С.
В каждой современной ОС есть С++-код. А тот же БеОС вроде был в чистую на нем написан.
Q>Ну ХЗ что там было в АДА. Ценные идеи заложенные в Лиспе постепенно внедрялись в ИЯ (взять хотя бы оператор if ), а некоторым из них это еще предстоит. Вот, интересно, какие идеи принадлежащие исключительно С++ перейдут в следующие языки и будет ли через 40 лет после его рождения о нем кто-то еще помнить.
Боюсь через 40 лет не нем еще код писать будут.
Q>Это проблемы С++, а не макросов.
Да нет. Макросы в чистом виде многое усложняют. Тут проблема не только всинтаксисе.
Q>Почему ты думаешь, что Лисп нельзя откомпилировать в машинный код?
По сути. Нутро у него на интерпретацию заточено. Вот Си проектировался чтобы было удобно биты двигать. Его тоже пытались интерпретировать, но ничего хорошего из этого не вышло.
Q> Я давал ссылку на статью про фирму (или продукт) Orbitz. Там ясно написано, что они оптимизировали Лисп для большей производительности и получали очень высокую скорость.
Очень хорошая понятие не определенное. Не думаю, что она сравнима с современными С++-компиляторами.
Q>Это заблуждение. Опровержение — Yahoo купила продукт Пола Грехема, написанный на Лиспе, а не поделки его С++снутых конкурентов.
Нда. Я бы сказал всем доказательствам доказательство.
Q>Я не называл шаблоны убогими. Я назвал их примитивными по сравнению с макросами в Лиспе (по сравнению, а не вообще). В рамках С++ они может и решают свои задачи и лучше, чем что-то еще, но макросы Лиспа более гибкий и мощный инструмент.
Это разные инстументы. Тут вообще сравнения не умесны. А уж с применением слов вроде примитивные и подавно.
Q>Это ты сам что-то бессмысленное придумал. Я уже говорил, что макрос выглядит как обычная функция, только вместо вызова ее в рантайме, происходит подстановка ее результата в компайлтайме. Что тут сложного?
macro From Wikipedia: A macro is an abstraction, whereby a certain textual pattern is replaced according to a defined set of rules. The interpreter or compiler automatically replaces the pattern when it is encountered. In compiled languages, macro-expansion always happens at compile-time.
Еще раз. Если обработка ведется на уровне синтаксиса, то это уже не макросы. Так что и шаблоны, и "макросы" Лиспа по сути расширенная синтаксисческая обработка. По крайней мере суть шаблонов С++ — обобщение кода. А применение макросвойств является побочным эффектом и естественно даже не может сравниваться со специально для этого предназначенными. Сравнивать шаблоны с Лиспом некорректно еще и потому, что шаблоны в основмно оперериуют с типами (причем в компайлтайме), а в Лиспе вообще нет понятия тип до рантайма.
Q>Ну вот уже надо трахаться. А ведь это буквально самое простое, что позволяют сделать макросы.
А никто макросам оды не пел.
Q>Ну давай теперь политкоректно называть это list-challenged или macros-challenged, как это принято в USA чтобы не оскорблять ничьих чувств.
Плевать я на ЮСУ хотел. Я тебе об отношении толкую. Ну, не воспринимаются нормально аргументы подкрепленные такими словами.
Q>Я ничего и не доказываю. Я сделал попытку показать, что идеологически шаблоны куда ближе к макросам Лиспа, чем к полиморфным функциям ФЯ.
Ты доказывашь примитивность шалонов по сравнению с макросами Лиспа.
VD>>Еще раз повторюсь, что шаблоны в С++ не являются чистыми макросами. Это фича для обобщенного программирования. Как ее можно сравнивать с макросами из нетипизированного интерпретируемого языка я вообще не понимаю. Что же касается возможностей, то дай бог всем ФЯ иметь такие возможности как у С++. Этому бы языку устранить грабли, цены бы ему не было бы.
Q>Вот это точно бездоказательное утверждение.
Ага. И то что 90% софта на плюсах писано тоже не доказательство.
Q>Кроме того, я надеюсь, что ты сравниваешь шаблоны с макросами в Лиспе, а не с убожеством называемом макросами в С/C++.
Я вообще не хочу сравнивать макросы с шаблонами.
К примеру, могу рассказать про дженерики в Шарпе. Они решают ту же задачу что и шаблоны с теми ограничениями что не поддерживают переменных ну и там по мелочи. Так вот они компилируются в мсил и воплощаются уже в рантайме. А раз в рантайме, то это уж точно не макросы. Но суть то та же!
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Мне кажется нужно вообще сделать общую статью о функциональном стиле программирования с кучей примеров на разных языках. Тогда каждый сможет найти язык на котором примеры ему будут понятны, а остальные поймет по аналогии. VD>Как идея?
Знаешь Влад, имхо было бы интересна статья аля "полиморфизм с разных т.зр.", где можно было бы рассмотреть все разл. подходы, принятые в разных языках (в ФП в т.ч.) с тем как это перекладывается на процессор и пр.
В своих силах по этому поводу сомневаюсь , но в обсуждении был бы рад поучаствовать и внести посильный вклад.
Что скажешь?
Здравствуйте, VladD2, Вы писали:
VD>Причем тут С++ я не знаю. Но сам описанный тобой метод называется спекулятивным устранением виртуальных вызовов.
VD>Ты заявлял, что в ФЯ дело осбтоит совершенно иначе. Вот с этим я и не согласен.
Я такого не заявлял.
VD>Ну, снова. Давай не будем использовать подобные приемы. Не стоит зачислять себя в ряд ученых, а аппонента в ряд веб-программистов. VD>Этот термин не прижился нигде. Он просто редок.
Не надо мешать индустрию и науку. У инженеров работающих на производстве и у ученых совершенно разная терминология. То, что для инженера швеллер, труба, уголок, рельс или полоса для ученого всего лишь балка. Так как по сути, у них отличаются только моменты инерции. Это наверное глупо выглядит, когда иженеры начинают обсуждать теорию упругости в своих терминах.
Здесь то же самое. Большинство здесь инженеры, а обсуждают вещи из computer science. Давайте придерживаться терминалогии соответствующей теме. Если термин где-то не используется — это не повод считать что он не прижился. Ведь если термин из ядерной физики не прижился на кухне у домохозяйки, это не значит что физики-ядерщики должны заменить их на кухонные.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Gaperton, Вы писали:
WH>Учись гуглить вставай на лыжи... инетом будешь не обижен. WH>Предложение в следующий стандарт С++ подойдет?
Подойдет для чего? Что ты мне доказать хочешь? Я в курсе что такое мультиметоды, вообще-то. И то, что добавить их можно при желании куда угодно — дурацкое-то дело нехитрое, а семантика простая. Вот когда они появятся в стандарте и популярных компиляторах, тогда и будешь спрашивать "подойдет?". А пока — хоть обгуглись.
А вообще, между нами девочками, вопрос адресовался Владу, лично, который вместо того, чтобы написать нормальный содержательный ответ демонстрирует какие-то странные ужимки. Наверно готовится к очередному замеру. А потом еще удивляется, что с ним нормально общаться не получается.
Здравствуйте, prVovik, Вы писали:
Q>>Бред какой-то. Типа, если в Лиспе нет оператора for, то он не может покрыть возможностей С++? Лиспу не нужны эти возможности шаблонов, поскольку в его рамках они бессмысленны. V>Повторяю еще раз. Шаблоны в С++ нужны для манипуляции типами. Ты говоришь, что шаблоны в лиспе лучше, чем шаблоны в С++. Из этого сравнения следует вывод, что шаблоны лиспа лучше манипулируют типами, чем шаблоны С++. Но в лиспе нет типов!!! Следовательно, само сравнение шаблонов С++ и лиспа БРЕДОВОЕ!
Ну, это не совсем так.
Насколько я помню, тип данных определяется набором применимых к нему операций. Т.е., к составному типу применима операция "извлечь элемент X" или, скажем, "вызвать метод Z"
Действительно, базовый LISP оперирует символами в списках и тут никаких новых типов не определишь. В этом и сила и слабость LISP-машины. Если мы сконструируем список например, так:
(
(class myclass)
((member m1) a)
((member m2) b)
)
то можно будет говорить о том, что мы создали список определённого типа, или же — объект некоторого типа. Почему? Потому что к этому списку применимы некоторые, вполне кокнкретные операции, например — извлечение значения члена m1, определение имени типа и т.п.
Так что, вся разница между C++ и LISP с этой точки зрения сводится к тому, что C++ позволяет оперировать понятием "тип" на уровне языка, а LISP — на уровне надстройки. Не быстро, разумеется, это работает, но тем не менее...
V> Это разные, несравнимые вещи.
Ну скажем так — сравнивать их можно, но сравнение будет совсем не в пользу C++. На LISP потенциально можно играть описаниями типов похлеще, чем с помощью шаблонов C++. Ну что такое плюсовый шаблон с точки зрения машины, ориентированой на обработку структур символов? Ну взяли набор символов, заменили по некоторым правилам одни символы на другие и — вуаля, получили специализацию шаблона. А используя LISP мы можем вообще взять да и выпулить нафиг часть описаний методов. Или перевернуть всё вверх ногами и скомпилировать новый код шаблона (reflection+emitting в одном флаконе). И всё это — не выходя за рамки элементарной, в сущности, исполнительной системы. Одна беда — не слишком быстро оно работает.
Кстати, где-то на Franz inc, есть наблюдение, что производительность труда программистов на Lisp что-то там, на порядок, что ли, больше, чем на C++. Что вобщем-то, неудивительно при потенциале самого LISP.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
Q>>Я не называл шаблоны убогими. Я назвал их примитивными по сравнению с макросами в Лиспе (по сравнению, а не вообще). В рамках С++ они может и решают свои задачи и лучше, чем что-то еще, но макросы Лиспа более гибкий и мощный инструмент. VD>Это разные инстументы. Тут вообще сравнения не умесны. А уж с применением слов вроде примитивные и подавно.
Уместны, уместны.
Q>>Это ты сам что-то бессмысленное придумал. Я уже говорил, что макрос выглядит как обычная функция, только вместо вызова ее в рантайме, происходит подстановка ее результата в компайлтайме. Что тут сложного? VD>macro From Wikipedia: A macro is an abstraction, whereby a certain textual pattern is replaced according to a defined set of rules. The interpreter or compiler automatically replaces the pattern when it is encountered. In compiled languages, macro-expansion always happens at compile-time.
Wikipedia может думать всё, что угодно, но я так припоминаю, что конструкция defmacro была в LISP, когда wikipedia ещё и в проекте не было. И на самом деле макро в LISP выглядит почти так же, как и определение функции.
VD>Еще раз. Если обработка ведется на уровне синтаксиса, то это уже не макросы.
Ещё раз. defmacro определяет макрос. Просто значение термина "макрос" для C++ и LISP очень сильно отличается. И его функциональное наполнение — тоже.
VD> Так что и шаблоны, и "макросы" Лиспа по сути расширенная синтаксисческая обработка. По крайней мере суть шаблонов С++ — обобщение кода. А применение макросвойств является побочным эффектом и естественно даже не может сравниваться со специально для этого предназначенными. Сравнивать шаблоны с Лиспом некорректно еще и потому, что шаблоны в основмно оперериуют с типами (причем в компайлтайме), а в Лиспе вообще нет понятия тип до рантайма.
Да есть там всё. И deftype есть.
Q>>Я ничего и не доказываю. Я сделал попытку показать, что идеологически шаблоны куда ближе к макросам Лиспа, чем к полиморфным функциям ФЯ. VD>Ты доказывашь примитивность шалонов по сравнению с макросами Лиспа.
Quintanar абсолютно прав. И в том, что шаблоны C++ близки lisp-макросам и в том, что шаблоны несколько уже, чем LISP-макросы. Хотя, тут, наверное, правильно говорить, што шаблоны C++ смахивают на этакий статический LISP. Но — только смахивают. Не больше.
Q>>Кроме того, я надеюсь, что ты сравниваешь шаблоны с макросами в Лиспе, а не с убожеством называемом макросами в С/C++. VD>Я вообще не хочу сравнивать макросы с шаблонами.
У вас путаница в терминологии. Действительно, нельзя сравнивать макросы C++ и макросы LISP — это очень разные вещи по сути. Макросы С++ работают с plain-text исходников, а макросы LISP — это почти такие же лямбды, как и любое определение функции LISP. А вот макросы LISP и шаблоны C++, как это ни удивительно, но сравнивать можно (терминологически ужасно, но что поделаешь?). И в принципе, шаблоны C++ тут проигрывают. C++ вообще заметно проигрывает LISP-у в гибкости (Ага, Влад, это я сказал). Впрочем, я вообще не могу представить императивный язык, который мог бы обскакать LISP по своим возможностям. Хоть с шаблонами, хоть с дженериками. По производительности LISP обставляется легко, а по гибкости — даже не представляю. Имено за счёт того, что базис LISP — простейшие операции с простейшими символами и замечательная парадигма "программа=данные". Соответственно, любую LISP-овскую конструкцию можно свести к списку. LISP-макросы/функции/типы — в том числе.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
Q>> ну и что, единственное их отличие от обычных функций состоит в том, что они преобразуют код программы на этапе компиляции. VD>Которой по сути нет. И получается, что точно так же генерируют специализации, только из-за того, что рантайм пермешан с компайлтаймом, черт ногу сломит в классификации того или иного явления.
Генерирует он или нет — сильно зависит от исполняющей системы.
Q>> А сделать ими можно просто на несколько порядков больше, чем в С++. VD>Очередное преувеличение. Аналогично моожно сделать обратное заявление. А что? Попробуй сделать типизированную конструкцию на Лиспе?
Ты неправильно делаешь противопоставление. Сильная типизация и гибкость — вообще антагонисты и конкретный баланс зависит от потребностей разработки. Сильная типизация нам нужна для жёсткости и надёжность, а LISP-овская унификация — для гибкости и компактности конструкций.
Q>> В С++, например, невозможно объявить новую конструкцию в языке. VD>Да можно. Есть маньяки которые уже пол Плюсов переписали. Вот только получается так же натянуто и криво как и на Лиспе. В итоге черт ногу сломит в этом коде.
На самом деле, получается своего рода "стремление" к LISP. Т.е., для того, чтобы наиграть кучу интересных вещей приходится на C++ писать некий "метаязык", который выражается в виде своих последовательностей скобочек разного вида и т.п. Тогда как чистый LISP — это и есть только скобочки и символы (значения символов).
VD>Честно говоря Лисп с его миллионом скобочек меня вводит в состояние гипноза.
Не одного тебя, но и кода там получается, AFAIK, поменее, чем на C++/Java/C#. Просто в силу разных парадигм. LISP не делает различия между данными и программой (оценка зависит только от того, вызван ли quote, или eval для списка), а императивные языки такое различие делают. Отсюда и гибкость, и компактность кода.
Q>> а в Лиспе — это одна из простейших задач. Тут вообще не о чем спорить, в Лиспе данные и код выглядят одинаково VD>одинаково фигово.
Ну, на императивный язык типа C++ мало похоже, разумеется. Но по сути Quintanar не ошибается. С точки зрения исполнительной системы LISP код и данные унифицированы. Чего не скажешь ни о C# ни о C++ ни о Java.
Q>> и последний легко обрабатывать средствами самого языка. С++ с его шаблонами такое и не снилось. VD>Ну, а Лиспу не снилось то что делают на шаблонах плюсов.
Не, скорее наоборот — это C++ и в страшном сне не приснится то, что можно творить на LISP. Например, можно и вложенные while как параметр передать.
VD> Лисп конечно можно выразить через самого себя. Но вот работать это будет еще медленее чем он сам. А плюсы не смотря на ве количество граблей заложенных в них позволяют писать шустрый код.
Вот тут ты прав — C++-код на самом деле работает пошустрее, чем LISP-овский. Но с другой стороны, LISP и не претендует на звание языка системного ПО. Хотя, и на нём web-серверы пишут.
Q>>Кстати, уверен, что с утверждением, что шаблоны в С++ примитивны по сравнению с макросами в Лисп, согласится любой, кто знает оба языка. И еще раз, примитивны не в смысле, что они просты, а что возможностей они предоставляют на порядки меньше. VD>Да разные они. Для разного предназначены. Твое утверждение изначально некорректно. И принципияльно содержит в сбебе желаение узизить эти самые шаблоны.
Я согласен с Quintanar. Он правильно употребил термин "примитивные". Никакого уничижительного оттенка там заметно не было. Тем более, что Quintanar специально оговорился:
Примитивный в том смысле, что Лисп позволяет делать более мощные модификации программы на основе параметров макроса.
Единственная ошибка была в том, что не повторил расшифровку термина "макрос", что вызвало кучу нежелательных аллюзий. И вагон флейма.
VD>Нормально бы звучал заявление вроде "В лиспе есть возможности которые или вообще отстсуствуют в С++ или трудно реализуются." Как в прочем верно было ы и братное. Но тут и спорить бы никто не стал.
Да ладно тебе кипеть возмущённым разумом. Quintanar был прав в исходном сравнении на 100%.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Впрочем, я вообще не могу представить императивный язык, который мог бы обскакать LISP по своим возможностям. Хоть с шаблонами, хоть с дженериками. По производительности LISP обставляется легко, а по гибкости — даже не представляю.
Forth?
Да и многие императивные динамические языки (Python, Ruby) по гибкости тоже мало лиспу уступают.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Так что, вся разница между C++ и LISP с этой точки зрения сводится к тому, что C++ позволяет оперировать понятием "тип" на уровне языка, а LISP — на уровне надстройки. Не быстро, разумеется, это работает, но тем не менее...
V>> Это разные, несравнимые вещи. ГВ>Ну скажем так — сравнивать их можно, но сравнение будет совсем не в пользу C++. На LISP потенциально можно играть описаниями типов похлеще, чем с помощью шаблонов C++. Ну что такое плюсовый шаблон с точки зрения машины, ориентированой на обработку структур символов? Ну взяли набор символов, заменили по некоторым правилам одни символы на другие и — вуаля, получили специализацию шаблона. А используя LISP мы можем вообще взять да и выпулить нафиг часть описаний методов. Или перевернуть всё вверх ногами и скомпилировать новый код шаблона (reflection+emitting в одном флаконе). И всё это — не выходя за рамки элементарной, в сущности, исполнительной системы. Одна беда — не слишком быстро оно работает.
Я уже замучился повторять, что шаблоны — это не машина для генерации кода!!! Шаблоны — это средство создания статически полиморфного кода со статической типизацией. Это их ЕДИНСТВЕННОЕ концептуальное предназначение. Тут утверждается, что макросы лиспа более гибки и мощны, но позвольте, разме могут они создавать статически полиморфный код? НЕТ!. А шаблоны могут! И в этом их основная прелесть! Ничего другого от них и не требуется! Ну не должен телефон уметь забивать гвозди!
Вот у меня появился вопрос: а для чего вообще нужны лиспу макросы в том виде, в котором они в нем присутствуют? Почему бы не обходится динамическим полиморфизмом, ведь бонусов от статически типизированного кода мы всеравно не плучим?
P.S.: Страуструп на счет макросов очень точно подметил, что активное их использовании говорит о недостатках выбранного языка, о недостаточности его выразительных средств (там, правда, упаминался еще один вариант, но я не об этом ). Так что такое распространение макросов в лиспе наталкивает на мысли...
[нафиг поскипано]
V>P.S.: Страуструп на счет макросов очень точно подметил, что активное их использовании говорит о недостатках выбранного языка, о недостаточности его выразительных средств (там, правда, упаминался еще один вариант, но я не об этом ). Так что такое распространение макросов в лиспе наталкивает на мысли...
Слушай, ты вообще знаешь о каких макросах речь?
Такое ощущение, что ты плюсовые переносишь на лисп и поэтому так и кричишь
Тут же уже объясняли, что это совершенно разные вещи.
А в лиспе нет расницы между кодом и данными поэтому программа может генерировать программы...
Ты страшный зануда. VD>В данном случая ты усомнившись в предпосылке сделал заключение о неверности всего вывода. Ты уж или развенчивай предпосылки или уж хотя бы называй выводы спроными. А то получается без доказательства или фактов ты наклеиваеш на выводы ярлык ложности.
Ладно, скажу тебе правду. В данном случае я во второй строке выразил (не специально получилось) свое мнение касательно первой посылки. Я надеюсь, вопрос исчерпан? Или продолжим разбор моих опечаток и стиля? Ты спрашивай, не стесняйся
. 
, но в обсуждении был бы рад поучаствовать и внести посильный вклад.
