Здравствуйте, FR, Вы писали:
ГВ>>Впрочем, я вообще не могу представить императивный язык, который мог бы обскакать LISP по своим возможностям. Хоть с шаблонами, хоть с дженериками. По производительности LISP обставляется легко, а по гибкости — даже не представляю.
FR>Forth? FR>Да и многие императивные динамические языки (Python, Ruby) по гибкости тоже мало лиспу уступают.
Насчёт "мало уступают" — согласен вобщем-то. Но я имел ввиду — обскакать. Ну Forth, в принципе — ещё туда-сюда. ИМХО.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, prVovik, Вы писали:
V>>Здравствуйте, Курилка, Вы писали:
К>>>(не факт что статическая, т.к. мы слишком общо сейчас обсуждаем, давай возьмём лисп и приведи вариант, где будет преимущество стат. типизации шаблонов C++) V>>Я уже плохо помню синтсакис лиспа, но поробуй в нем завести две строковые переменные и перемножить их. Получишь ошибку времени выполнения. V>>В С++ таких проблем нет.
V>>
V>>template <class T> T mul(T a, T b){ return a*b; }
V>>
V>>При вызове mul("Вася", "Маша") получаем сообщение об ошибке еще на этапе компиляции.
К>Любой компилятор лиспа тебе тоже выдаст такое же, зря ты лисп недооцениваешь, К>из умножения автоматически выводятся типы, которыми могут быть параметры, соотв-но тебе по рукам надают за это, К>а переменных свободных нету в ФЯ, ещё раз повторяю!
Неужели? А примерчик можно? У меня вот не получилось:
(defun my_mul (a b) (declare (number a b)) (* a b))
(setq num (read))
(cond
( (= num 12345 ) (write (my_mul "Vasja" "Masha")) )
( T (write (my_mul 10 2 )) )
)
CLISP-2.27 Программа работает нормально, пока не введешь магическое число 12345, после которого она падает с ошибкой. Не помогает даже мокание компилятора мордой в молоко: (declare (number a b)).
Здравствуйте, prVovik, Вы писали:
V>CLISP-2.27 Программа работает нормально, пока не введешь магическое число 12345, после которого она падает с ошибкой. Не помогает даже мокание компилятора мордой в молоко: (declare (number a b)).
А вот при использовании статической типизации ошибка вылезла бы еще во время компиляции.
Здравствуйте, prVovik, Вы писали:
V>Неужели? А примерчик можно? У меня вот не получилось: V>
V>(defun my_mul (a b) (declare (number a b)) (* a b))
V>(setq num (read))
V>(cond
V> ( (= num 12345 ) (write (my_mul "Vasja" "Masha")) )
V> ( T (write (my_mul 10 2 )) )
V>)
V>
V>CLISP-2.27 Программа работает нормально, пока не введешь магическое число 12345, после которого она падает с ошибкой. Не помогает даже мокание компилятора мордой в молоко: (declare (number a b)).
Поймал, типа .
Попробуй http://www.drscheme.org/
Про нее пишут, что она делает type inference, чтобы помечать потенциальные ошибки.
Вообще, такое возможно благодаря soft type system. Вот некоторые цитаты.
Soft typing is a generalization of static type checking that accommodates both dynamic typing and static typing in one framework. A soft type checker infers types for identifiers and inserts explicit run-time checks to transform untypable programs to typable form. Soft Scheme is a practical soft type system for R4RS Scheme.
I'm not a CS PhD, nor do I play one on TV, but maybe I
ease your aching soul.
A [static] type system is a state of mind. A way of
viewing the world. Specifically a way of saying
statically what is and isn't a valid program. Now
there are many ways of seeing the world and so there
are many type systems. And they all say certain
programs are valid and certain programs are invalid
and they all get it wrong a occasionally. But you
knew that already.
Now if we take this view that a type system is a
static thing we can apply many type systems to the
same program. This is what the PLT guys have done —
Soft Scheme, MrSpidey, and MrFlow all apply different
type systems to Scheme and all accept and reject
certain (and different) programs. So if you desire
you can HM Scheme (which is what Soft Scheme does I
believe) and program in an ML style. Not many Scheme
programs will pass that test but you can make sure the
ones you write do. So you can be statically typed.
And then you can write programs that don't pass the
type checker and you can just tell the Scheme system
to put in the appropriate run time checks and fail if
you made a type error.
So we can take a dynamically type system and by
limiting the language we use we can turn it into a
statically typed system. Any statically typed system.
Now lets go the other way. Hmmm... Can't be done. If
the type system you use fits your program then you're
home. So writing compilers in ML and simulations in
Java probably doesn't suck. It's when you go the
other way that you feel the pain. And that's when you
wished you had a dynamically typed language: because
there are more problems than there are type systems to
handle them and though more advanced type systems
require you to tie less of your hand behind your back
they'll never do away with it entirely (and least
while they remain decidable).
So for my money I'd rather use Scheme than ML. A lot
of my programs look like ML but there are occasions
where they don't and its those outliers that make the
difference. I'm happy to have static type systems
built on to Scheme so that I can statically check 90%
of my programs and I'm just as happy to throw away the
type system for the other 10% of programs. It's the
perfect middle ground!
Здравствуйте, Gaperton, Вы писали:
G>В этом высказывании главная часть выделена. Второстепенная (хоть и тоже важная) отделена от главной словом-связкой "причем". Обе части являются неотъемлемой частью тезиса (одного). Начало отмечено фразой "а во вторых". Плюс ко всему, речь идет не о признаке ФЯ, а о полиморфизме в современных ФЯ. Он обеспечивается выполнением pattern matching по всем аргументам, что не предполагает наличие классов. Называть такое "мультиметодом" можно с большой натяжкой, и тем более нельзя сравнивать с мультиметодами С++, python, whatever, так как общего здесь очень мало. Так что я не понимаю, что именно я опроверг.
А, ну, то есть я не понял. Так что же ты вместо того чтобы сказать, что я тебя не понял, и ты говоришь про патерн-матчинг, начал доказывать, что мултиметода — это норенная особенность ФЯ?
G>У меня просьба, личного характера. Не мог бы ты читать весь текст моих постов, а не отрывки, перед тем, как отвечаешь на них? Если тебя сильно не затруднит, конечно. В противном случае я не буду на них отвечать, все равно получается беседа слепого с глухим.
А у меня к тебе пробсьба общественно характера. Смени стиль общения. Прекрати постоянно пытаться задевать других людей.
ЗЫ
В общем, редлагаю не разводить здесь флэйм.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Я уже замучился повторять, что шаблоны — это не машина для генерации кода!!! Шаблоны — это средство создания статически полиморфного кода со статической типизацией. Это их ЕДИНСТВЕННОЕ концептуальное предназначение. Тут утверждается, что макросы лиспа более гибки и мощны, но позвольте, разме могут они создавать статически полиморфный код? НЕТ!. А шаблоны могут! И в этом их основная прелесть! Ничего другого от них и не требуется! Ну не должен телефон уметь забивать гвозди!
Погоди, не кипятись. Никто и не спорит с тем, что шаблоны C++ — "средство создания статически полиморфного кода". Более того, они не просто "могут" создавать СПМК, а это единственное, что они обязаны делать.
В свою очередь у LISP со статической типизацией, в основном, всё не очень хорошо. Но и речь-то шла не о статическом полиморфизме. А о том, какие композиционные возможности предоставляют шаблоны C++ и макросы LISP. Понимаешь разницу? Если нет, то давай сопоставим допустимые разновидности аргументов шаблонов C++ и макросов LISP. Сопоставление очень простое — на две строки:
шаблоны C++ — типы, сигнатуры функций или константы;
макросы LISP — списки.
Теперь сделаем другое сравнение. Что есть программа на C++ и LISP:
C++ — операторы, функции, переменные, опеределения типов; (гусары, молчать! Я знаю, что допускаю здесь упрощение.)
LISP — список, представляющий лямбда-выражение.
Следовательно, аргументом макроса LISP может служить любая конструкция, моделируемая на этом языке, тогда как аргументом шаблона C++, например, оператор "switch" с набором case-веток служить не может (т.е. — может, но его надо просто завернуть в функцию). На LISP это делается с полпинка. Вот и вся разница. Потому и говорят тебе, что макросы LISP предоставляют больше возможностей по компоновке конечной программы (пожалуй, утверждение должно звучать именно так, а не "... модификации программы"). И действительно, C++-шаблоны в этом смысле представляются примитивным решением по сравнению с макросами LISP, т.к. не могут вопсринимать в качестве аргументов нкоторые конструкции C++.
V>Вот у меня появился вопрос: а для чего вообще нужны лиспу макросы в том виде, в котором они в нем присутствуют? Почему бы не обходится динамическим полиморфизмом, ведь бонусов от статически типизированного кода мы всеравно не плучим?
Речи о статически типизированом коде, вобщем-то, не было. Да, с точки зрения конструкции программы, LISP умееет оперировать типами (структурированными списками), но это не совсем то же самое, что и статически типизированный код C++.
V>P.S.: Страуструп на счет макросов очень точно подметил, что активное их использовании говорит о недостатках выбранного языка, о недостаточности его выразительных средств (там, правда, упаминался еще один вариант, но я не об этом ). Так что такое распространение макросов в лиспе наталкивает на мысли...
Опять передёргиваешь. Причём здесь Срауструп? Страуструп говорит о макросах с низкоуровневой семантикой, которые на выходе могут выплюнуть всё, что угодно. К примеру:
#define MY_MACRO(abc) abc + - / BCD
С точки зрения препроцессора — вполне себе допустимый макрос. С точки зрения синтаксиса C++ результат его применения — недопустим.
В свою очередь, макрос LISP не может выдать некорректный с точки зрения LISP-машины код. И в то же время, он позволяет выполнять очень навороченные модификации и работу как со своим телом, так и с аргументами. Т.е., за синтаксис можно не бояться. Это — первое, что роднит LISP-макросы и C++-шаблоны.
Второе. Как шаблоны могут принимать в качестве параметров типы, так и LISP-макросы могут принимать в качестве параметров списочные структуры. Результат подстановки и в том и в том случае даёт некую новую вычислительную структуру: тип C++ — для мшаблонов C++ и лямбда-выражение для LISP.
Полученная структура обрабатывается кодогенератором C++ и исполняющей системой LISP соответственно.
Результирующий код, разумеется, может быть ошибочным в смысле несоответствия требованиям пользователя, но это уже совсем другое.
Давай так. Чтобы не было терминологических передёргиваний, будем называть C++-макросы: "макросами", а LISP-макросы: "defmacro-выражениями". Идёт? И ещё, я сам — давний сторонник именно статической типизации, но и на мой взгляд LISP-макросы куда как более гибкое и мощное средство, нежели шаблоны C++. Но! Именно с указанной несколько выше точки зрения.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Ты неправильно делаешь противопоставление. VD>Я предлагаю не противопоставлять не сопоставимые вещи.
Ладно, уболтал.
ГВ>>Сильная типизация и гибкость — вообще антагонисты и конкретный баланс зависит от потребностей разработки. Сильная типизация нам нужна для жёсткости и надёжность, а LISP-овская унификация — для гибкости и компактности конструкций. VD>По-моему, предположение о том, что компактность это безусловное благо в корене не верно.
Я не говорил о том, что компактность — абсолютное благо.
VD>Говорить нужно в первую очередь о выражительности и понятности. И тут Лисп в полной заднице. Стоит чуть-чуть увеличить сложность задачи, как код на лиспе превращается в лес скобок понять смысл которого можно только путем последовательной мысленной интерпретации.
Ну, во-первых, он всегда представляет собой "лес скобок". Просто в силу синтаксиса.
VD> Тут он сравни Перлу. Программы сразу понятны только тому кто их пишет. Так сказать тайт-онли-языки. Мне кажется такой подход очень опасным.
Во-вторых, давай не будем сравнивать восприятие LISP-программы теми, кто привык к императивному стилю и самими LISP-программистами. Угу?
VD>Кстати, я давно наблюдаю за стилем кодирования приверженцев ФС (функционального стиля). И он мене очень не нарвится. Постонянное стремление к компактности кода переходит все разумные границы. Одно-двух буквенные переменные и функции, стремление написать как можно больше в одну строку, зачастую наплевателство на струкуризацию кода. В общем компактность кода ставится выше простоты его восприятия. Причем все это подкрепляется словами об абстракции. Это не абстракция — это раздалбайство.
Как много шума на пустом месте. Давай ещё джихад на тему "4 пробела vs. табуляция начнём"! Это всё второстепенно. И причём тут "стиль кодирования приверженцев ФЯ"? Знаешь, из того, что кто-то где-то пишет так, что это кому-то где-то непонятно, ничего не следует относительно гибкости использованного средства. Не надо связывать разнородные сущности.
VD>Гибкость тоже имеет свои пределы. Универсальные системы всегда проигрывают специализированным как в простоте понимания, так и в производительности и надежности. Для решения конкретных задач нужно искать не самое "гибкое" средство, а самое подходящее. И я не думаю, что, например, тот же Янус будет проще создать на Лиспе, Хаскеле или Окамле, как в прочем и на С++.
Всё имеет свои пределы. И гибкость, и универсальность.
Вобщем, честно говоря, я так и не понял, что ты тут хотел сказать. ИМХО, ты со мной согласился:
ГВ>>Сильная типизация и гибкость — вообще антагонисты и конкретный баланс зависит от потребностей разработки.
VD>Гибкость тоже имеет свои пределы.
...только как-то уж очень многословно. Хотя, если выразиться точнее, то ты приписал мне утверждение о беспредельной ценности гибкости и начал его опровергать. Поскольку отрицание такого утверждения содержалось в исходной реплике, то я могу сделать вывод о том, что ты со мной согласен.
ГВ>>На самом деле, получается своего рода "стремление" к LISP. Т.е., для того, чтобы наиграть кучу интересных вещей приходится на C++ писать некий "метаязык", VD>А почму метаязык — это сразу лисп?
Ответ содержится в поскипанной тобой части реплики:
ГВ>На самом деле, получается своего рода "стремление" к LISP. Т.е., для того, чтобы наиграть кучу интересных вещей приходится на C++ писать некий "метаязык", который выражается в виде своих последовательностей скобочек разного вида и т.п. Тогда как чистый LISP — это и есть только скобочки и символы (значения символов).
Метафора — и почти что не более того. Да, получающиеся метаязыки нередко состоят из набора функций, и конструкторов объектов. Мы их вкладываем один в другой и получаем последовательность скобочек. Ну и объявления шаблонов — как раз наборы треугольных скобочек. Естественно, это не LISP.
VD> Получается именно метаязык. Но средства у него свои. И проблемы С++ — это не непохожесть на Лисп, а наличие горы граблей и то что эти метасредства эмулируются на побочных эффектах средств для метапрограммирования не предназначенных.
Возможно, что и так.
VD>Мы вот как раз пытаемся создать систему метапрограммирования для C# (R#
). Если все получится как хочется, то выйдет очень гибкая система при этом собственными механизмами модификации кода.
VD>Что касается макросов Лиспа, тот тут на лицо терминалогическая путанница. Они по сути не имеют права называться макросами, так как работают на уровне синтаксиса языка, а не на уровене модификации тектса.
Трудно сказать, имеют ли они право так называться или нет. ИМХО — имеют, как устоявшаяся терминология. Сам LISP создан в 1962 г., когда появилась конструкция defmacro — не знаю.
ГВ>>Не одного тебя, но и кода там получается, AFAIK, поменее, чем на C++/Java/C#. Просто в силу разных парадигм. LISP не делает различия между данными и программой (оценка зависит только от того, вызван ли quote, или eval для списка), а императивные языки такое различие делают. Отсюда и гибкость, и компактность кода. VD>Еще раз повторюс, что компактность достигнутая потерей смысла — это зло.
Если бы компактность достигалась потерей смысла, то и конечная программа никогда не была бы написана. Я не сомневаюсь, что LISP-текст довольно трудно читать программистам, привыкшим к императивному стилю программирования (я из их числа). Ну и что из того? Это только вопрос привычки. Равно как и чтение C++-шаблонов.
VD>То же и с гибкостью. На Лиспе нельзя решить элементаные задачи, при это постоянно идут рассуждения о его гибкости. Кому нужна такая гибкость?
[skip] VD>И итоге выходит, что реальный потенциал императивного языка снабженного современным набором средств разработки нманого выше чем очень гибких и компактных. Так в чем правда, брат? (с) отморозок из отмороженного фильма.
Ещё раз. LISP имеет в своей основе очень неплохую парадигму: "программа = данные". Наличие библиотек — это только наличие библиотек и ничего более. Вопрос времени и популярности конкретного языка. Я вижу в идеях Java и .Net очень многое похожее на LISP.
ГВ>> Не, скорее наоборот — это C++ и в страшном сне не приснится то, что можно творить на LISP. Например, можно и вложенные while как параметр передать.
VD>Но нельзя создать статически типизированный код. В общем, опять пошло сравнение предназначенного для разного вещей. Надоело. Не могут делать макросы Лиспа того что могут шаблон. И не потому что у них гибкости не хватает, а потому что не предназначены для этого. Так что прикрате проводить аналогии и что-то по этим аналогиям доказывть.
Исходно речь шла о сравнении шаблонов C++ с макросами LISP только в аспекте допустимых трансформаций программы. О достижении этой программой каких-либо свойств никто вобщем-то, не говорил. И никто не утверждал, что макросы LISP позволяют порождать статически типизированый код, свойства которого полностью аналогичны коду на C++. (предыдущее предложение читать и цитировать только полностью!) И аналогии проводились только для того, чтобы собеседнику было понятнее — на каких свойствах ммакросов LISP заостряется внимание.
ГВ>>Я согласен с Quintanar. Он правильно употребил термин "примитивные". Никакого уничижительного оттенка там заметно не было. Тем более, что Quintanar специально оговорился: ГВ>>
ГВ>>Примитивный в том смысле, что Лисп позволяет делать более мощные модификации программы на основе параметров макроса.
VD>Нет слов. Ладно. Начинаю разводить ту же демагогию, держитесь.
VD>
Итак, макросы лиспа приметивны потому что не позволяют проивзодить примитивные операции записи в файл, вывода на принтер и т.п. Так же они примитивны по сравнению с простейшим оператором if, так как в отличии от него не позволяют выполнять проверок в рантайме. Ну, и уж несомненно они явлются полнейшим примитивизмом по сравнению с такими мощнешими средствами С++ как Шаблоны! Ведь в отличии от шаблонов они не позволют создавать статически-типизированный, типобезопасный код. В то же время шаблоны С++ не просто на голову рабивают это примитивное образование, но и вообще низвергают весь лисп в небытие, так как кроме всех выше перечисленных достоинств еще позволяют создавать выско-производительный код, а так же, использую побочные эффекты, даже эмулировать действия тех самых примитивных макросов Листпа.
Хм. Где-то я уже слышал что-то подобное пару лет назад. Это у меня дежа-вю, что ли?
VD>Ну, что нормально если я буду общаться в такой манере? Нет? Ну, тогда не нужно использовать подбные подходы.
Ещё раз. Медленно. Сопоставлялись только возможности комбинирования конструкций языка программирования, доступные для LISP-макросов и C++-шаблонов. Только и всего. Ни о статической типизации, ни о полной типобезопасности, ни о вводе-выводе речи не было и быть не могло.
Соответственно, твоя иллюстрация "демагогии" летит даже не мимо кассы, а... в противоположную сторону, что ли... да, как-то так.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Соответственно, твоя иллюстрация "демагогии" летит даже не мимо кассы, а... в противоположную сторону, что ли... да, как-то так.
Нет уж. Твое сравнение точно такое же. Просто тут для тебя все очевидно. Сравни с макросами лисам сопоставимые вещи, например, OpenC++. Вот тогда и поговорим о гибкости и возможностях.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ГВ>>Соответственно, твоя иллюстрация "демагогии" летит даже не мимо кассы, а... в противоположную сторону, что ли... да, как-то так. VD>Нет уж. Твое сравнение точно такое же. Просто тут для тебя все очевидно. Сравни с макросами лисам сопоставимые вещи, например, OpenC++.
А какая связь между макросами LISP (я надеюсь, ты это имел ввиду под "лисам") и OpenC++? Я просто не знаю OpenC++ — может, расскажешь?
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А какая связь между макросами LISP (я надеюсь, ты это имел ввиду под "лисам") и OpenC++? Я просто не знаю OpenC++ — может, расскажешь?
Да, спасибо, посмотрю, но тем не менее к теме дискуссии это пока не относится. Мы всё-таки, сопоставляли C++ templates и LISP defmacro. Я так полагаю, что в итоге ты согласился с доводами оппонентов по существу.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да, спасибо, посмотрю, но тем не менее к теме дискуссии это пока не относится. Мы всё-таки, сопоставляли C++ templates и LISP defmacro.
Позволю уточнить — вы.
ГВ> Я так полагаю, что в итоге ты согласился с доводами оппонентов по существу.
По существу я уже сказал. Если сравнивать средства мета-программирования, то лушче смотреть на продвинутые вещи вроде ОпенС++. А шаблоны можно сравинить со средствами обощенного программирования в статически типизированных языках. А так как Лисп к таковым не относится, то и не стоит сравнивать.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ГВ>>Да, спасибо, посмотрю, но тем не менее к теме дискуссии это пока не относится. Мы всё-таки, сопоставляли C++ templates и LISP defmacro. VD>Позволю уточнить — вы.
Угу, пусть так.
ГВ>> Я так полагаю, что в итоге ты согласился с доводами оппонентов по существу. VD>По существу я уже сказал. Если сравнивать средства мета-программирования, то лушче смотреть на продвинутые вещи вроде ОпенС++. А шаблоны можно сравинить со средствами обощенного программирования в статически типизированных языках. А так как Лисп к таковым не относится, то и не стоит сравнивать.
В ринципе я стобой согласен. Вобщем-то, по большому счёту, сравнение не совсем правомерное, но отельные аспекты — вполне себе даже сравнимы. По крайней мере, в таком обсуждении. Ну да ладно.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>В ринципе я стобой согласен. Вобщем-то, по большому счёту, сравнение не совсем правомерное, но отельные аспекты — вполне себе даже сравнимы. По крайней мере, в таком обсуждении. Ну да ладно.
Самое забавное что многие сторонники С++ действительно считают шаблоны некой заменой компйлтайм-метакода а-ля макросы Лиспа, и всячески пытаются аворотить на них что-то. И я постоянно спорю с ними доказывая им, что применение побочных эффектов не есть гуд. Они в ответ мне все время твердят, что это нормальное использование... И возможности просто потрясающие...
А сталкиваясь с теми кто защищает ФП я вижу раздражение не качественностью шаблонов вызванной тем, что они не реализуют всех возможностей мета-программирования. И при этом нет даже желания взглянуть на то, что плохим называется применение не по назначению.
Я понимаю откуда взгляд на шаблоны как на хреновые мета-мекросы. И понимаю откуда все это восхищение побочными эффектами. Просто надо понять и признать несколько очень простых фактов.
1. В С++ нет шаттных средств мета-программировния.
2. С++ не совершенен и ему очень нужны подобные средства.
3. Шаблоны позволяют частично решить эту проблему.
4. Есть средства и подходы позволяющие решать эти задачи более чистым образом. Идеальным было бы расширение С++ с целью введения штатных мета-средств. Но можно пережить и фишками вроде кодогенераторов и ОпенС++.
Отсюда вся кривость решений мета-программирования основанного на шаблонах. И ощущение убогости. Реально же шаблоны С++ прекрасно решают задачи которые ставились перед ними в момент их создания. Но это другие задачи. Это задачи обобщенного программирования, например, создания коллекций.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: N_>>Я знаю только ad-hoc и параметрический полиморфизмы. VD>Ну, а дальше можно выделить два подкласса — это статический полиморфизм и динамический. Динамический требует выбора в рантайме, статический ведет к генерации множества вопложений полиморфного кода и типов.
На самом деле вы оба правы. Статический/динамический относится к компиляции, следовательно, это варианты реализации полиморфизма. Потому что логика программы от этого не меняется. А ad-hoc и параметрический различаются по логике. Т.е. есть два варианта классификации полиморфизма (по логике и по реализации). Их действительно часто путают.
Здравствуйте, Gaperton, Вы писали:
G>1) Существует два способа. Первый — параметрические типы (аналог шаблонов), и второй — АДТ (абстрактные типы данных, ближе всего к интерфейсам). Вроде как все знакомо. G>2) А вот здесь начинается самое интересное. Во-первых, для каждого типа (класса), соответствующего АДТ (реализующего интерфейс) надо явно указать набор функций, которые реализуют АДТ. Функции могут быть совершенно произвольными, в частности две разных реализации АДТ могут вообще говоря иметь пересекающийся набор функций. Что прикольно.
Категорически не согласен. Значит, метод write может выполнять чтение? То есть сделать так можно, но не нужно. Конечно, все реализации метода имеют некоторый общий знаменатель. Я думаю, что в ООП этот знаменатель есть интуитивное представление о том, что должен делать метод. В ФП встречается такая новая вещь, как законы. Некоторое математическое равенство, включающее метод(ы), должно выполняться на всех реализациях.
Это всё второстепенно. И причём тут "стиль кодирования приверженцев ФЯ"? Знаешь, из того, что кто-то где-то пишет так, что это кому-то где-то непонятно, ничего не следует относительно гибкости использованного средства. Не надо связывать разнородные сущности.
Поскольку отрицание такого утверждения содержалось в исходной реплике, то я могу сделать вывод о том, что ты со мной согласен. 
Не, скорее наоборот — это C++ и в страшном сне не приснится то, что можно творить на LISP. Например, можно и вложенные while как параметр передать.
