Как рассказать человеку о полиморфизме?

> Пример полиморфной релаизации

Не было ли у препода родственников в славной стране Индии? Абстрактные сущности, потом реализации, причем отдельно читалки и писалки, да все это с интерфейсами... Прям махараджа, любитель велосипедного спорта, какой-то пример придумал, не иначе.

> Чушь ПОЛНАЯ, ты перепутал полиморфизм и перегрузку функций.

Щито?

Перегрузка - это на самом деле один из видов полимфоризма - специальный полиморфизм (по буржуйски - ad-hoc polymorphism), когда функция для разных типов данных определена по-разному.

> отдельно читалки и писалки, да все это с интерфейсами...

Отдельно _интерфейсы_ Reader и Writer. Один класс может реализовывать методы обоих интерфейсов. Факт, что класс реализует интерфейс обозначает наличие среди, возможно, большого числа его методов декларируемых интерфейсом. То есть, никто не мешает сделать класс MemoryStorage, реализующий оба интерфейса.

> Прям махараджа, любитель велосипедного спорта, какой-то пример придумал, не иначе.

Никто не мешает ув. Анонимусу привести свой пример, который будет объективно отражать реальность и в то же время будет понятен зелёным студентам. Именно из-за второго я попытался привести его здесь.

> ну, ты сам посмотри на модель, что ты привел. Это же текст русской народной песни "Огород городить"!

В каком месте? Есть единственная версия кода, работающая с любой реализацией читалки и писалки. В любое время можно создать новуые реалищации читалки и писалки... Вполне имеет право на жизнь имхо. Что не так? =)

> Кратко недостатки ООП я бы описал так: "Создаем себе трудности, затем мужественно их преодолеваем".

Можно пример модели, для той-же задачи, но правильной? Без создания трудностей.

>Ты всегда всё по диагонали читаешь?

Нет, конечно. Но вот чтобы связать все воедино понадобилось достаточно много времени. Да еще наработать запас необходимых идиом... Научить этому невозможно, можно только самому понять.

> И человеку, далёкому от программирования, вообще сложно догнать, чем фундаментально целое число отличается от вещественного...

Человеку, далкому от программирования сложно догнать что такое полиморфизм ;)

> А вот в случае с деревом, как с простейшей после односвязного списка структорой, всё очевидно...

Еще раз повторюсь, по моему мнению намного лучше показывать параметрический полиморфизм на каком-нибудь не рекурсивном типе данных, особенно если имеет место быть инерция мышления. Мне вот когда я хаскель изучать начал было очень неочевидно...

>Да, то, что ты отделяешь структуры данных от функций говорит лишь о том, что ты не познал ещё дао...

Может быть, может быть.

ЗЫ: Сложно было выдти на такой стиль изложения и уровень аргументации с самого первого поста?

>...который будет объективно отражать реальность и в то же время будет понятен зелёным студентам.

Да-да, именно понятен зеленым студентам, которым ООП и на #@! не сралось. Страшно конечно, что студетны не хотят понимать фундаментальные основы...

Можно ведь в качестве примера привести реализацию рекурсивной структуры данных c помощью паттерна Composite и ее обход с помощью Visitor... Только зачем?

anonymous (*) (18.07.2007 14:39:40):

>> Чушь ПОЛНАЯ, ты перепутал полиморфизм и перегрузку функций.

> Перегрузка - это на самом деле один из видов полимфоризма - специальный полиморфизм (по буржуйски - ad-hoc polymorphism),

Спец по Хакселю?

Прочитай сначала, о чем речь идет:

DNA_Seq(17.07.2007 23:01:35):

>Полиморфизм в ООП насколько я помню это возможность давать одинкаковые имена функциям,...

Ключевое слово -- "ООП". ФП тут не при чем, DNA_Seq говорил про ООП, как и в оригинальном вопросе. ad-hoc polymorphism (по Strachey) отождествляется с перегрузкой функций только в ФП, а в ООП принято _противопоставлять_ ad-hoc polymorphism и "истинный" параметрический полиморфизм (parametric polymorphism по Strachey). Хотя сам Strachey рассуждал в терминах ФП, нынешние апологеты ООП видят полиморфизм только там, где есть позднее связывание.

> Да еще наработать запас необходимых идиом... Научить этому невозможно, можно только самому понять.

Да? Про bnf на первом курсе рассказывают. А тут хошь, не хошь, а понятие о полиморфных структурах вдолбится само.

> Человеку, далкому от программирования сложно догнать что такое полиморфизм ;)

Нет. Это куда как более общее математическое понятие, чем те частные случаи в ООП или в ADT, которыми размахивают программахеры.

> Еще раз повторюсь, по моему мнению намного лучше показывать параметрический полиморфизм на каком-нибудь не рекурсивном типе данных, особенно если имеет место быть инерция мышления.

Нерекурсивный тип данных - это что-то типа Maybe, что как раз совсем неочевидно. Список или дерево интуитивно понятны, а "что-то или ничего" - слишком дзенская концепция, думалку напрягает. Хотя, готов признать, что это восприятие может быть индивидуальным.

И вообще надо сразу говорить о полиморфных функциональных типах. Вроде такого очевидного примера, как

(\f g x -> f (g x))

Тут уж точно поймёт каждый, кто прогулял менее половины школьной математики.

>Да? Про bnf на первом курсе рассказывают.

Рассказывают. Значит мне плохо рассказывали.

>Это куда как более общее математическое понятие, чем те частные случаи в ООП или в ADT, которыми размахивают программахеры.

Понимаю, только я (да и никто в этом топике) не пытался объяснить полиморфизм в математическом смысле. Вопрос был - помочь объяснить ad-hoc полиморфизм в самой примитивной его форме.

>И вообще надо сразу говорить о полиморфных функциональных типах ... Тут уж точно поймёт каждый, кто прогулял менее половины школьной математики.

Ты в школе лямбда-исчисление изучал? Рад за тебя.

>это что-то типа Maybe

Ну зачем же Maybe? привел же я пример в виде декартовых координат...

А вообще, ФП мешают нехилые пробелы в образовании современных программистов... Но это не их вина.

>В каком месте? Есть единственная версия кода, работающая с любой реализацией читалки и писалки. В любое время можно создать новуые реалищации читалки и писалки... Вполне имеет право на жизнь имхо. Что не так? =)

видишь ли, для данной задачи построение объектной модели является излишним усложнением. Вот, собственно, в этом самом месте и начинается то, что вызывает в голове слово "городушка".

Ведь при реализации тебе так и так придется реализовавать прямое и обратное кодирование для каждого алгоритма; чтение и запись для каждого... гм... направления.

Так какие же бонусы ты как разработчик получаешь от завертывания всего этого дела в "объект"? А тот, кто потом этот код попытается использовать повторно?

>Можно пример модели, для той-же задачи, но правильной? Без создания трудностей.

конечно можно. но будет гораздо лучше, если ты _сам_ найдешь решение.

ну так что, подсказки принимаешь? ;)

> Понимаю, только я (да и никто в этом топике) не пытался объяснить полиморфизм в математическом смысле. Вопрос был - помочь объяснить ad-hoc полиморфизм в самой примитивной его форме.

Вот в ad hoc форме его хрен поймёшь. Формализация вообще не то что лучший, а единственный путь к полноценному пониманию любой сущности, так что и начинать объяснять надо с математики всегда.

> Ты в школе лямбда-исчисление изучал? Рад за тебя.

Конечно же нет. Я изучал теорию множеств и логику, этого достаточно.

> Ну зачем же Maybe? привел же я пример в виде декартовых координат...

Это не есть полиморфная сущность. Вот само понятие декартового пространства - полиморфно. Алгебра полиморфна, кольцо полиморфно, и т.д.

> Но это не их вина.

А чья же ещё? Если чувак водку пьянствовал, вместо того, чтобы в библиотеку сходить и книги нужные почитать - то виноват он сам, и только он, никого кроме.

>Это не есть полиморфная сущность...

Не полиморфная, но это алгебраический тип данных, так что про полиморфизм говорить уместно.

>Если чувак водку пьянствовал, вместо того, чтобы в библиотеку сходить и книги нужные почитать...

Уууу, загнул. Хороших ВУЗов у нас мало, и хрен туда поступишь... А в плохих... А в полхих никто не может объяснить "нафига это". На этот вопрос я себе ответил только на 4-м курсе когда стал вплотную работать. Сазу и тема дипломная появилась и многие вещи были пересмотрены...

ФП ближе к математике, а в ООП ставятся более жизненные вопросы типа прототипирования, быстрой разработки, повторного использования, проектирования. Разработаны различные виды информационных моделей. А в чистом ФП единственная информационная модель - комбинаторная, а в нее очень сложно въехать.

Кроме того, в чистом ФП тоже есть свои заморочки типа операций ввода-вывода или хранения состояния, и их нужно знать и понимать. Обучить всему этому может только преподаватель _высочайшего_ класса, только такой преподователь может в легкую сотни тысяч баксов зарабатывать, а не возиться с сопливыми и неблагодарными студентами.

> Не полиморфная, но это алгебраический тип данных, так что про полиморфизм говорить уместно.

Это декартово произведение множества на себя же. Да, понятно, что декартово произведение - один из фундаментальных механизмов определения производных типов, но просто это никак к теме полиморфизма не относится.

> Уууу, загнул. Хороших ВУЗов у нас мало, и хрен туда поступишь...

Библиотеки есть даже в мелких районных центрах. И в каждой библиотеке наверняка валяется пара-тройка старых (то есть, хороших) учебников по дискретной математике. И прилежные школьники эти учебники читают, без всяких там ВУЗов, если уж выбрали себе карьеру программиста.

> ФП ближе к математике, а в ООП ставятся более жизненные вопросы типа прототипирования, быстрой разработки, повторного использования, проектирования.

Хорошая формулировка. "Ставятся вопросы". Именно, что ставятся, но никак не решаются. Единственный способ реально быстрого и гибкого прототипирования - это формализация, построение мат. модели (пусть даже и модели сферического коня в вакууме - это же всего лишь прототип). ООП - один из частных, узкоспециализированных методов формализации, ужасно ограниченный, и я совершенно не понимаю тех, кто его выпячивает в качестве универсальной технологии, с которой надо как минимум начинать попытки формализации. Когда предметная область легко поддаётся объектной декомпозиции, это и так видно сразу, когда же не поддаётся, то не хер её в ООП втискивать.

>Кроме того, в чистом ФП тоже есть свои заморочки типа операций ввода-вывода или хранения состояния, и их нужно знать и понимать.

ФП вообще не при чем в контексте обсуждаемой темы. Мы говорим про теории типов, про ООП как частный и убогий случай типизировнаной формализации, про способы определения параметрических типов и типов высшего порядка и операций над ними. ФП тут никаким боком, ему, наоборот, плоховато становится когда мы таким образом теорию множеств дополняем (попробуй написать тип комбинатора фиксированной точки!).

> Обучить всему этому может только преподаватель _высочайшего_ класса,

Обучить простейшему виду типизированной теории множеств, обучить теории доказательств и элементам конструктивной математики может даже почти любой школьный учитель, а уж ВУЗовский препод и вовсе не напряжется на такой мелочёвке, в пару-тройку лекций уложит всю тему.

>ФП вообще не при чем в контексте обсуждаемой темы. Мы говорим про теории типов, про ООП как частный и убогий случай типизировнаной формализации, про способы определения параметрических типов и типов высшего порядка и операций над ними. ФП тут никаким боком, ему, наоборот, плоховато становится когда мы таким образом теорию множеств дополняем (попробуй написать тип комбинатора фиксированной точки!).

Тогда какую парадигму и какой язык ты предлагаешь использовать?

>Хорошая формулировка. "Ставятся вопросы". Именно, что ставятся, но никак не решаются.

Почему? Решаются, только есть способы лучше. 15 лет адепты ООП бьются об object-relational impedance mismatch и только сейчас поняли что фиг оно решается. И GoF уж 11 лет как выпустили свои "Паттерны проектирования", а до этого был Коплин.

Или парсинг XML, тоже еще та проблема которая если посчитать его за рекурсивную структуру данных решается в момент.

> Тогда какую парадигму и какой язык ты предлагаешь использовать?

Вах, зачэм парадыгм, зачэм езыг? Мы же обсуждаем методологии проектирования, не так ли? А это такое дело, где нельзя себя ограничивать парадигмами. Есть один язык - математика, им и надо пользоваться при формализации требований предметной области.

А уж как это протом запрограммировать - мелочи. Лучше всего, конечно же, мультипарадигмные метаязыки использовать, с ними вообще красота: строишь мат. модель предметной области, описываешь решение задачи на языке этой модели, после чего делаешь на своём мета-языке реализацию абстрактного модельного языка, куда переносишь без изменений абстрактное же решение задачи, изложенное в терминах формализованной предметной области.

Но это всё рулит, когда задачи сложные. А когда простые, то после формализации и получения абстрактного решения можно хоть на ассемблере писать.

> Решаются, только есть способы лучше.

Как правило, всегда наступает такой момент, когда OOD начинает создавать больше проблем, чем оно решает. И тогда процесс разработки сводится к борьбе с проблемами, порождёнными OOD, вместо решения задач предметной области. Понятно, что при превышении этого самого порога, задача гарантированно решена не будет никогда. И GoF patterns моим словам хорошее подтверждение. :)

>Но это всё рулит, когда задачи сложные. А когда простые, то после формализации и получения абстрактного решения можно хоть на ассемблере писать.

А пример задачи можно узнать?

>с ними вообще красота: строишь мат. модель предметной области, описываешь решение задачи на языке этой модели, после чего делаешь на своём мета-языке реализацию абстрактного модельного языка...

... наслаждаешься всеми минусами каскадной модели разработки. Все-таки и предметная область может менятся и не всегда полноценно возможно ее исследовать. Да и программы все развиваются по спирали с добавлением новых фич от версии к версии. А при таком подходе предметно-ориентированный язык может стать тормозом покурче OOD ;)

А свой предметно-ориентированный язык в той или иной степени создает каждый программист... Лисп тут рулит больше всех, но достойные реализации недоступны простым смертным.

>красота: строишь мат. модель предметной области, описываешь решение задачи на языке этой модели, после чего делаешь на своём мета-языке реализацию абстрактного модельного языка

Сказочники ептыть :)). Для весьма широкого класса задач мат. модель построить вообще нельзя, хотя бы в силу сложности исследуемой области. Люди второй десяток лет занимаются исследованиеми самообучающимися genetic fuzzy systems и т.д., а он мне тут про математические модели втирает.

Lisp системы вполне доступны, как свободные, так и коммерческие.

>Lisp системы вполне доступны, как свободные, так и коммерческие.

Это ты про SBCL? К сожалению, ему еще до нормального состояния далеко, а остальным и подавно. А цена коммерческих измеряется исключительно в килобаксах.

Баклан ты, саныч. Любая программа - это мат. модель, по определению. Что программируемо, то формализуемо, и наоборот.

Гибкость и устойчивость в мат. модель легко закладывается при дизайне, но ОО-методы дизайна к устойчивым не относятся.

> Лисп тут рулит больше всех

Даже из Java легко делается мета-язык. Лисп конечно же рулит, но он не обязателен.

Ну построй мне мат. модель планирования кредитных операций? Какой формализм будешь использовать?

>Для весьма широкого класса задач мат. модель построить вообще нельзя, хотя бы в силу сложности исследуемой области.

Дело в том, что все остальные пути (в том числе, использование дешевой рабочей силы "миллиона обезьянок") будут еще труднее и дороже. И как раз таки - "в силу сложности исследуемой области".

Это ИМХО.

ps: что порекомендуешь из свободных реализаций лиспа?

При чем тут "обезьянки"? Сушествуют т.н. эвристические алгоритмы, для которых нельзя создать мат. модель (описать детерминированную последовательность действий), но можно использовать для решения задачи.

>При чем тут "обезьянки"?

При том. Есть вероятность того, что конечное количество обезьянок способно набрать осмысленный текст за конечное количество корм^W времени. Так говорят :)

>Сушествуют т.н. эвристические алгоритмы, для которых нельзя создать мат. модель (описать детерминированную последовательность действий), но можно использовать для решения задачи.

Вот мне только одно интересно: кто же в этом случае определяет последовательность тех действий, которые в конце концов выполняются компьютером?

Ведь не сводится же все "эвристические алгоритмы" к "ахуивознаить!"?

гм... или таки сводятся?

эвристические алгоритмы могут не давать решения, даже если оно очевидно, или давать неверные решения. Опять же программу можно обучать, с учетом совершенных ошибок или неполных знаний. Например, шахматные программы.

Чудило саныч, я же тебе русским по белому сказал - что программируемо, то формализуемо. Эта херовина не формализуется, тут только анальные эвристики и работают, так что оно и не программируется никаким образом.

> Дело в том, что все остальные пути (в том числе, использование дешевой рабочей силы "миллиона обезьянок") будут еще труднее и дороже.

Тут только один путь известен науке: использование живого эксперта с хорошо развитым жопочуянием.

>эвристические алгоритмы могут не давать решения, даже если оно очевидно, или давать неверные решения. Опять же программу можно обучать, с учетом совершенных ошибок или неполных знаний. Например, шахматные программы.

вот наверно оч круто это - с умным видом нести чушь.

все равно - модель вывода определена, и есть какой-то алгоритм,дающий вероятностную оценку решению.

давай лучче про экономически достижимое качество.

А, так вот о чем дурак саныч вещает. Саныч, эвристический алгоритм - это тоже мат. модель. Байессовская сетка та же. У тебя какие-то совершенно стрёмные представления о том, что такое мат. модель.

> А, так вот о чем дурак саныч вещает. Саныч, эвристический алгоритм - это тоже мат. модель. Байессовская сетка та же. У тебя какие-то совершенно стрёмные представления о том, что такое мат. модель.

но есть же плохо-формализуемые и неформализуемые задачи, к коим относится большое кол-во задач имеющих дело с реальными данными. все естественные науки сюда попадают, да и построение самой мат модели в большинстве случаев неформализуемая задача, иначе бы в частности разработчиков ПО давно поувольняли заменив мат моделями :D