Здравствуйте, Temoto, Вы писали:

T>Полиморфизм на указателях на функции? я здесь не совсем понял.

Сравни:

class A
{
  abstract void Foo();

  void Bar()
  {
        Foo();
  }
}

class B
{
    Func _foo;
    
    B(Func foo)
    {
        _foo = foo;
    }
    
    void Bar()
    {
        _foo();
    }
}

T>>>>Откуда это убеждение?

LP>>>А ты с ним не согласен?

T>>Да. И я очень точно могу обосновать. Смысл ООПа не в объектах и состоянии (это легко делается на любых языках). Смысл в том, что оно предлагает некоторые абстракции, методики построения программ. Эти, заезженные до дыр, инкапсуляцию и полиморфизм и лалала. Так вот, функциональные языки не забирают эти абстракции. И инкапсуляция везде есть, и все остальные. ООПа нет, а все фичи ООПа есть, понимаете?

LP>Полиморфизм это свойство системы типов, не связанное неразрывано с ООП, согласен. Но вот инкапсуляция, способствует ли ей функциональный подход? Если разделе CTM, на который я ссылался в предыдущем сообщении, показан пример, как функциональная декомпозиция приводит к неустойчивому интерфейсу. Если нет состояния, приходится данные протаскивать через параметры если ты понимаешь о чем я, в результате чего от состава этих данных зависит интерфейс. То есть реализация выплывает из объекта наружу, в параметры функции. Нарушение инкапсуляции, расстрел на месте.

Вот мне щас не хотелось бы показывать на конкретный язык, но в хаскеле есть инструмент, который в частности используется для "протаскивания" данных не через параметры. Через параметры можно сделать некрасиво, понимаю о чём вы, да. А можно и нормально, если тип абстрактный и состав данных снаружи неизвестен, это подход Си с typedef.

LP>>>Программирование в своем развитии прошло долгий путь, оставив позади те парадигмы, которые некоторые предлагают сегодня в качестве альтернативы ООП.
T>>Давайте не будем словоблудить про долгий путь. Это исключительно субъективная позиция.
LP>Это не словоблудие, это диалектика. Если ФП за пятьдесят лет не нашел широкого промышленного применения в качестве отдельной парадигмы (как ООП), значит оно не самодостаточно.

На одних функциях, если вы об этом, далеко не уедешь, тут глупо спорить. С другой стороны, ООЯ без модулей (в смысле отдельно компилируемые файлы), процедур и прочих парадигм (а они не входят в ООП) был бы тоже ужасен. Поэтому вы сравниваете воображаемый язык с одной ФП парадигмой против языка с ООП и другими. В этом и словоблудие, или диалектика, если вам так угодно.

T>>Любой человек из микрософта скажет, что ОС прошли долгий путь и винда победно оставила на обочине всех. И как он может быть неправ, если у него кругом одна винда? Конечно он прав. А другой человек через дорогу винду видит два раза в неделю, у него "своя правда". Оба правы. Лично мне более интересен разговор об объективных, которые для всех одинаковы.

LP>Правильно, оставила. Спорить с этим тяжело. Есть ведь объективные данные, позволяющие судить о популярности операционных систем. В данном споре ты как раз выступаешь в роли того самого "человека через дорогу".

Я знаю один хостинг с виндой. И сотни с линупсом и freebsd. Вот такие данные. На десктопе всё наоборот. Кто кого оставил? В среднем смотреть бессмысленно, надо смотреть по отраслям. К этому я и призывал изначально.

T>>Потому что вы строго не описали что именно подразумевается по ФП. Но объективно в реально существующих языках, которые все называют ФЯП, есть те же самые инструменты проектирования, что и в реально существующих ООП языках. А вот это уже факт, который можно проверить, тут неоднозначности быть не может.

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

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

LP>>>Без изменяемого состояния модульность в самом деле труднодостижима. ООП же позволяет максимально эффективно использовать это самое состояние, вводя концепцию объектов, в которые состояние заворачивается.
T>>При *проектировании* я не оперирую понятием "состояние", до тех пор, пока в бизнес-логике не нужно будет это самое состояние надёжно сохранить (на диск, например). У любой программы есть что-то на входе и что-то на выходе.

LP>Ты только и делаешь, что пишешь утилиты командной строки? В практическом программировании от состояния никуда не деться, оно буквально нас окружает. Но я (и Ван Рой в своем примере) имели ввиду не состояние, обусловленное предметной областью как таковой, а о том, как намеренное введение состояния способствует повышению модульности. Даже консольную программу можно сделать модульнее, сделав связку отдельных кусков через состояние. Ибо при этом увеличивается инкапсуляция отдельных модулей.

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

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

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

Желаю вам познакомиться с ними поближе и чтоб это знакомство доставило радость.

T>>Полиморфизм на указателях на функции? я здесь не совсем понял.

AVK>Сравни:
[урезано]

В вырожденном случае второй пример сводится к просто bar_not_class(Func foo) { foo(); }. Это пригодится, чтобы foo вызывать с хитрыми параметрами или ещё что, но не понял причём тут полиморфизм.
А первый так и не понял зачем он нужен. Похоже на то, что сигнатуру и реализацию Foo спрятали за другой функцией (Bar), но как это относится к полиморфизму неясно.

Вы не могли бы привести примеры использования этих классов?

Здравствуйте, Temoto, Вы писали:

ВВ>>Является ли полиморфизм на указателях на ф-ции "плюшкой" или же эмуляцией? Можешь ответить утвердительно и обосновать? Я вот не вижу, где в общем случае заканчивается эмуляция и начинается плюшка.
T>Полиморфизм на указателях на функции? я здесь не совсем понял.

Не, не то. Подмена указателя на функцию в заранее описанной структуре это своего рода аналог виртуальной функции. Т.е. у нас есть, скажем, структура anyStream, которая может и представлять и memoryStream, и fileStream и т.д.
Нужно тебе добавить свою реализацию encryptedStream — объявляешь ф-ции, заполняешь anyStream указателями — и вперед. Очень даже полиморфно все.

Можно в принципе те же интерфейсы имитировать через переинтерпретацию памяти, но такой подход мне меньше нравится

Ну так короче. Эмуляция это или плюшка?

ВВ>>А что такое эти "плюшки" по сути? Ведь к ФП парадигме они никакого отношения не имеют, что доказывает хотя бы тот факт, что в "чистых ФП языках" их нет. Вот если бы ты пытался доказать, что в любом ФП языке... Но стоп, этот поезд уже уехал
T>А процедуры и лямбды не имеют отношения к ОО парадигме. Так что, они в C#, эмуляция или резиновая женщина или молоток гнутый? Нормально вместе живут разные фичи и подходы. Влад, кстати, правильно об этом сказал, что неплохо, когда язык поддерживает максимум разных полезностей.

В С#? А чем не гнутый молоток-то. Очень даже. Разница только в том, что никто не пытается утверждать, что ФП языки не нужны, раз в C# есть лямбды. Или что все задачи из ФП можно с той же легкостью решать на C# в ФП стиле (а это просто неправда). Почувствуй тут разницу, как говорится.
As of now С# вообще очень плохой пример, если речь идет о "высоком дизайне". Как тут кто-то пошутил, у МС что бы они не делали, все время получается си плюс плюс. Засунули в язык кучу, извините, "парадигм" в весьма укушенном к тому же виде, теперь от первоначальной концепции вообще ничего не осталось (если она, конечно, была, концепция эта).

T>Честно говоря, я не знаю ни одного языка, в котором была бы *только функциональная парадигма*. И вообще нет однопарадигменных языков, кроме эзотерики. Например, ассемлер. Там есть call/ret (процедуры) и он императивный. Всё! Уже две. Поэтому говорить о чисто функциональных или чисто процедурных или чисто <другой базворд> языках не конструктивно, ничем не вооружает. Если имелись в виду чистые функциональные языки в смысле, что там нет побочных эффектов, то это не имеет отношения к обсуждаемой теме, поэтому я не понимаю что имеется в виду.

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

ВВ>>А значит это какие-то дополнительные "плюшки", искусственно введенные в язык. А раз их нет в чистых ФЯ, значит эти плюшки представляют какую-то более другую парадигму, чем ФЯ. Ну и какую же парадигму они представляют?
T>Можно придумать слово парадигма полиморфизма. Но это бесполезно. Зачем приводить что-то к парадигмам? Мне больше нравится такой подход: перечислить фичи. Например, в языке L' есть классы, интерфейсы, объекты для решения таких-то задач; процедуры, модули для решения таких-то задач; и т.п. Всё понятно и без слова парадигма.

Да в том-то и проблема, что ничего непонятно.
Я еще раз повторюсь, независимо от того, что на многие из своих основополагающих принципов у ООП нет монополии, ООП единственная парадигма которая предлагает их все, причем в непротиворечивом виде.

Ты же, с одной стороны, соглашаешься, что эти принципы, они же плюшки, необходимы, с другой — начинаешь песню про ФЯ, где "все это есть" и "можно не хуже". Да в том-то и дело, что хуже. В ООП — это родное. В ФП — пришлое и вообще не особо-то сочетающееся с дизайном ФЯ.

ВВ>>Вопрос не в том, являются ли всякие инкапсуляции и полиморфизмы прерогативой именно ООП. Вопрос в том, что для ООП это ключевые понятия, на которых ООП строится. А вот для ФП это не так. И говоря, что ООП требуется для больших систем, видимо, и имеются в виду, что нужен некий стандартный набор инструментов, который в рамках ООП всегда полон, давно устоялся, проверен временем и т.п. и пр.
ВВ>>Ты же, говоря о "привычке к ООП" и новых "средствах передвижения" никаких новых на самом деле инструментов не предлагаешь. Вот и получается, что людей убеждают вместо привычного молотка использовать особый, изогнутый под ФП. Причем совершенно неясно, зачем нужна эта "изогнутость", кроме как, чтобы засунуть в язык "плюшку", которая туда на самом деле не слишком-то хорошо вписывается (когда ее отрывают от других родственных плюшек).

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

Зачем требуется наследование, виртуальные функции, интерфейсы, делегаты, лямбды, бла-бла-бла? У нас есть универсальный механизм — указатель на функцию. В тех случаях, когда требуется колл-бек — передаем просто указатель. В тех, когда требуется описать полиморфную структуру — описываем ее как "словарь" указателей на функции. Абсолютно универсальное и удобное средство. Проверьте.

ВВ>>А зачем гнуть молоток, если можно слить в ФП весь ООП? (подумал автор Немерле).
T>Ну раз у них получилось, это конструктивное доказательство что такой подход тоже вполне пригоден. А ещё есть другой подход, тоже конструктивно доказана пригодность.
T>А у ООПа, кстати, есть объективные недостатки по скорости поводу наследования реализации, связанные с затратами на подъём по дереву наследников.

Погоди, ты уверен, что в рамках обсуждения ФП, *действительно* хочешь говорить о скорости?

T>Понятно, что по сравнению с си/паскалем любой дурак с удовольствием будет платить эти накладные расходы. Я просто говорю, что есть ещё другие варианты, со своими достоинствами и недостатками; не говорю, что есть серебряная пуля.

Так какие варианты? Нету у тебя других вариантов. Ты все варианты взял из ООП и то, что они по отдельности присутствуют в ФЯ выдается за brave new world какой-то. Я говорю, исходя из твоих предпосылок, можно обосновать, что С — лучший язык на свете, поддерживает все парадигмы и позволяет писать как хочешь.

ВВ>Не, не то. Подмена указателя на функцию в заранее описанной структуре это своего рода аналог виртуальной функции. Т.е. у нас есть, скажем, структура anyStream, которая может и представлять и memoryStream, и fileStream и т.д.
ВВ>Нужно тебе добавить свою реализацию encryptedStream — объявляешь ф-ции, заполняешь anyStream указателями — и вперед. Очень даже полиморфно все.
ВВ>Можно в принципе те же интерфейсы имитировать через переинтерпретацию памяти, но такой подход мне меньше нравится
ВВ>Ну так короче. Эмуляция это или плюшка?

Я подумал и получается, что нет, это не полиморфизм, потому что он неконтроллируемый (я ведь могу указатель на любую функцию сунуть в эту структуру). А то получится, что инструкции x86 это убер язык, заранее поддерживающий все возможные парадигмы.

ВВ>Э, давай не уходить в сторону. Ты себе ФП без "процедурной парадигмы" представляешь? Может такое быть? А без ОО парадигмы ФП вполне может быть. Более того, ООП (вернее, те семые "плюшки") ФП скорее даже мешает (но, да, склеить их, конечно, можно, если очень хочется).

Да, есть лисп, который чисто функции и списки; всё остальное делается средствами самого языка. Во всех остальных языках такой чистоты нет но те же самые плюшки, которые есть в ООП, вряд ли мешают. (сейчас напишу почему)

(упорно кажется, что следущий параграф я уже где-то писал)
Все плюшки во всех языках направлены на увеличение качества программ (например, через уменьшение количества ошибок). Исходя из этого (теоретически) плюшки не могут мешать друг другу. Чем их больше — тем качественнее программы. А вот как они на практике сочетаются в конкретных языках, получается там гнутый молоток или нет, это не парадигмы виноваты, а конкретные люди. Ну это моё мнение, может быть есть какая-то мощная теория, которая логически доказывает как одни плюшки мешают другим, я не видел.

ВВ>Ты же, с одной стороны, соглашаешься, что эти принципы, они же плюшки, необходимы, с другой — начинаешь песню про ФЯ, где "все это есть" и "можно не хуже". Да в том-то и дело, что хуже. В ООП — это родное. В ФП — пришлое и вообще не особо-то сочетающееся с дизайном ФЯ.

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

ВВ>У нас есть универсальный механизм — указатель на функцию. В тех случаях, когда требуется колл-бек — передаем просто указатель. В тех, когда требуется описать полиморфную структуру — описываем ее как "словарь" указателей на функции. Абсолютно универсальное и удобное средство. Проверьте.

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

ВВ>Зачем требуется наследование, виртуальные функции, интерфейсы, делегаты, лямбды, бла-бла-бла?

Это очень простой вопрос. Всё это нужно для проверки кода на корректность и для оптимизаций (в т.ч. компиляции в машинный код).

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

ВВ>Погоди, ты уверен, что в рамках обсуждения ФП, *действительно* хочешь говорить о скорости?

Невероятно, но факт, есть функциональные языки, которые в отдельных тестах по скорости отстают от Си всего в 1-2 раза. (правда, по памяти отстают намного больше)
Да, в этом плане, за последние лет 10-15 они очень сильно продвинулись.

http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
Из 15 языков в таблице, я насчитал 5 функциональных. Там, правда Java три раза учавствует.

T>>Понятно, что по сравнению с си/паскалем любой дурак с удовольствием будет платить эти накладные расходы. Я просто говорю, что есть ещё другие варианты, со своими достоинствами и недостатками; не говорю, что есть серебряная пуля.

ВВ>Так какие варианты? Нету у тебя других вариантов. Ты все варианты взял из ООП и то, что они по отдельности присутствуют в ФЯ выдается за brave new world какой-то. Я говорю, исходя из твоих предпосылок, можно обосновать, что С — лучший язык на свете, поддерживает все парадигмы и позволяет писать как хочешь.

Про варианты это надо конкретные языки назвать?

Я уже говорил, что все составляющие ООПа существовали и до первых ООП языков. Поэтому нельзя сказать, что я оттуда что-то взял. И я не говорю, что это выдаётся за brave new world. Единственный мой посыл заключался в том, что хотеть надо средства для решения задач (в общем, не конкретное одно средство — ООП). Я могу напомнить с чего начался весь этот сыр-бор.

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

Си почти всё позволяет, но почти ничего не контроллирует. Мне кажется, что в ежедневной работе любому программисту более интересен язык, который ограждает от ошибок. В этом плане чистые функциональные языки (в смысле без побочных эффектов), такие как Agda, Clean, Haskell ограждают ещё и от ошибок вызванных произвольным изменением состояния.

T>>>Из тысяч языков можно по пальцам одной руки посчитать сколько имеют зависимые типы. Вкусная фича, ничего не скажешь. Но нигде нет.
WH>>Это вопрос времени.

LP>А нефункциональные языки могут иметь такую систему типов? По-моему, не могут. А раз так, то время не поможет.

Кстати, может быть, вам будет интересно, я в википедии нашёл ссылку на исследование по поводу GADT (это как бы подмножество зависимых типов) в C# и Java.

http://research.microsoft.com/~akenn/generics/gadtoop.pdf

Здравствуйте, Temoto, Вы писали:

T>Я подумал и получается, что нет, это не полиморфизм, потому что он неконтроллируемый (я ведь могу указатель на любую функцию сунуть в эту структуру).

Объяви да засовывай только то, что нужно:

struct anyStream {
  int (*xReadByte) (int /*offset*/, hren* /*какая-нибудь еще хрень*/);
};

T>(упорно кажется, что следущий параграф я уже где-то писал)
T>Все плюшки во всех языках направлены на увеличение качества программ (например, через уменьшение количества ошибок). Исходя из этого (теоретически) плюшки не могут мешать друг другу. Чем их больше — тем качественнее программы. А вот как они на практике сочетаются в конкретных языках, получается там гнутый молоток или нет, это не парадигмы виноваты, а конкретные люди. Ну это моё мнение, может быть есть какая-то мощная теория, которая логически доказывает как одни плюшки мешают другим, я не видел.
ВВ>>Ты же, с одной стороны, соглашаешься, что эти принципы, они же плюшки, необходимы, с другой — начинаешь песню про ФЯ, где "все это есть" и "можно не хуже". Да в том-то и дело, что хуже. В ООП — это родное. В ФП — пришлое и вообще не особо-то сочетающееся с дизайном ФЯ.
T>Я говорю не хуже, потому что я пробовал и мне понравилось. А вам?

Ну начнем с того, что "не хуже" по крайней мере недостаточно.

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

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

Но, погодите, ведь это означает, что язык *изначально проектировался* как "гибридный", а не как ФЯ? Т.е. о нем уже некорректно говорить как просто об ФЯ. Это гибридный язык. Поддерживающий ФП и ООП. Вот опять немерле в голову лезет.

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

ВВ>>У нас есть универсальный механизм — указатель на функцию. В тех случаях, когда требуется колл-бек — передаем просто указатель. В тех, когда требуется описать полиморфную структуру — описываем ее как "словарь" указателей на функции. Абсолютно универсальное и удобное средство. Проверьте.
T>Ну да, если убрать слово указатель, то это лямбда исчисление. Всё из функций, даже рыбы и медузы.

Вот чем такая позиция отличается от вашей? ИМХО налицо определенное сходство.

ВВ>>Зачем требуется наследование, виртуальные функции, интерфейсы, делегаты, лямбды, бла-бла-бла?
T>Это очень простой вопрос. Всё это нужно для проверки кода на корректность и для оптимизаций (в т.ч. компиляции в машинный код).

Проверку кода на корректность можно делать и без этого. А по поводу оптимизаций — извините, что из перечисленного используется для *оптимизации*? Вы ничего не путаете? Скорее всего, наоборот. Подлинный сишник, например, скажет, что это все мега-зло и мешает ему писать заоптимизированные до смерти "большие системы". И в чем-то будет прав, кстати. Если речь идет, скажем, о ядре ОС.

T>http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
T>Из 15 языков в таблице, я насчитал 5 функциональных. Там, правда Java три раза учавствует.

Ну насколько там F# от C# отстает
А вообще нуна эту вашу табличку Это тест компиляторов по большей части. Добавьте туда "взрослый" промышленный компилятор C++ вроде VC или Intel CPP, и он порвет всех остальных как тузик грелку.

ВВ>>Так какие варианты? Нету у тебя других вариантов. Ты все варианты взял из ООП и то, что они по отдельности присутствуют в ФЯ выдается за brave new world какой-то. Я говорю, исходя из твоих предпосылок, можно обосновать, что С — лучший язык на свете, поддерживает все парадигмы и позволяет писать как хочешь.
T>Про варианты это надо конкретные языки назвать?

Другие варианты построения "больших систем". Без ОО. А так получается, что ОО вроде бы и нет, а вроде он и есть. Я разницы не вижу. В упор.

T>Я уже говорил, что все составляющие ООПа существовали и до первых ООП языков. Поэтому нельзя сказать, что я оттуда что-то взял. И я не говорю, что это выдаётся за brave new world. Единственный мой посыл заключался в том, что хотеть надо средства для решения задач (в общем, не конкретное одно средство — ООП). Я могу напомнить с чего начался весь этот сыр-бор.

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

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

Если речь идет о том, можно ли вообще, т.е. в принципе, писать большие системы на не-ОО языках, то да — можно. На Си же пишут. И даже не в ОО-стиле пишут.

А так, ну да, нужны части. А часто нужны все части. А часто еще нужно, чтобы все эти части хорошо вписывались в дизайн языка. И так далее. И если у вас все это есть — значит язык поддерживает ОО-парадигму. Разве нет?

Здравствуйте, Temoto, Вы писали:

T>>>Ладно, частей не бывает. Но задачи, которые решает ООП вы выделить можете? Типа "прячет реализацию за интерфейсом", "предоставляет однотипный интерфейс для разных реализаций". Вот эти задачи я и называю частями.
VD>>Мне пересказать все что я знаю об ООП? Или нужно изложить теорию ООП?

T>Я задал конкретный вопрос про задачи. Можно в двух словах ответить какую задачу решает разбиение одной километровой программы на процедуры, правда? С ООПом это будет больше слов, но список решаемых задач не включает в себя толстую теорию. И не нужно ничего пересказывать. Я просто делаю ссылку, что вот, мол, вот их я называю частями ООП.

Так не надо выделять какие-то части. Никто же говоря об ФП какие-то части не выделяет, правда?

ООП — это цельная парадигма. Она позволяет проектировать ПО большого размера. Раз тебе не нужно объяснять теорию ООП, то должен знать что такое объектная декомпозиция и что такое ОО-дизайн.
Ну, и чтобы это все можно было легко использовать на практике, плюс не увязнуть в море не относящегося к задаче склеивающего кода в ЯП нужна прямая и удобная поддержка некоторого набора фич который и дает право называть язык ООЯ.

Отдельные ООП-фичи можно эмулировать даже на С или Хаскеле. Только это дико не удобно и лишняя объязка начинает усложнять свою задачу. В прочем, те же Виндовс и Линукс написаны во многом в именно так. Только это очень дорого. Так что позволить себе такое может только богатая контора (вроде МС) или огромное сообщество (вроде линуксового, которое тоже состоит из множества контор, в том числе и богатых).

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

T>Я не говорю, что какая-то технология самодостаточна. Я говорил о том, что несмотря на отсутствие классов и объектов в функциональных языках решаются те же самые задачи (полиморфизм и бла бла), что и в ООЯ.

А я говорю, что это чушь высосанная из пальца. И что?

T>Вот товарищ сказал, что ООП необходим для больших проектов, а я говорю что не именно ООП необходим, а средства решения определённых задач; и эти средства есть во всех ООЯ, потому что эти задачи решает ООП, и эти средства есть в *некоторых* функциональных языках.

Ну, назови это "средства". Без разницы. В некоторых ФЯ они может и есть. Но конеретно в Агде, в которой есть поддержка ЗТ, нет.

Так о чем спич?

T> То есть для привычки ООП хотеть — понятно, а для решения проблем — нет.

А вот это уже никак не вписывается в предыдущие рассуждения и опять же смахивает на необоснованную чушь.

VD>>Лично для меня ООП и МП (метапрограммирование) — это парадигмы позволяющие вырваться из мира декомпозиции на уровне функций/процедур.

T>Вот, супер. Уже речь идёт о задачах.

Не речь идет о проектировании и методах решения совершенно разных задач.

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

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

С первым тезисом спорить не хочу. Наверно не дураки. А вот со вторым... На мой взгляд именно в паскаль возвратиться и предлагается. Точнее в эдакий нют-паскаль в котором синтаксис изувечен как черепаха Богом, и есть множество мощных решений для сокращения кода внутри процедур. Но так ничего и не предлагается для того чтобы можно было упростить решение задач в ОО-стиле.

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

В Хаскеле и Агде нет главного. Там нет объектов. В Хаселе же еще нет удобного средства императивного программирования которое зачастую нужно организации объектов. Так что попытка мыслить в терминах ООП программируя на хаскеле приведет к жудким результатам. Даже худщим чем если тоже самое делать на С.

VD>> И если ваш язык не умеет это делать, но вы его считаете крутым, то это ваши проблемы. Мне нужен более гибкий инструмент. Просто наличие ЗТ мне не нужно. Мне нужно чтобы это была одна из дополнительных возможностей. И чтобы она не вставляла мне палки в колеса.

T>Полностью здесь согласен. Только любая фича будет вставлять палки в колёса.

Это голословное утверждение. Я вот программирую на языке который отличным образом соединяет классический ООП с ФП и МП. Думаю, встроить ЗТ туда же было бы не так уж и сложно. ООП, ФП и МП не противоречат друг-другу, а отлично друг-друга дополняют. Возможно ЗТ тоже можено как-то красиво сюда встроить. У меня пока что нет полного понимания проблемы, чтобы ответить на этот вопрос утвердительно или отрицательно. Но общая посылка "любая фича будет вставлять палки в колёса" явно ложная.

T> В этом смысл всех фич в языках. Вот раньше не было типов, ассемблерщики прямо с памятью работали как хотели. А в си уже нельзя так вольно.

Да, можно, в общем-то. С регистрами может и нельзя, а с памятью запросто.

T>А в Java вообще систему типов не обойдёшь.

На то и проектировалась.

T>Написал какой-то дурачок в своей библиотеке, что здесь нужен не IEnumerable, а именно объект класса List и всё, свой Tuple никуда не сунешь.

Причем тут какой-то Tuple? Как ему может поменять List? Да, и что такое IEnumerable в Яве?
Вы, уважаемый, о чем вообще?

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

Опять пошла голимая софистика. Мне это не интересно. Мы говорили о высокоуровневых языках. Приплетать сюда С и ассемблер бессмысленно. Так что рассуждения о конфликте типобезопасной системы типов с возможностью ручной работы с памятью просто не к месту.

Меж тем я не заметил ни одного конфликта между ООП и ФП. Сдается мне, что конфликт в мозгу у пуристов от обоих конфессий. Всех же для кого ООП или ФП не является религией я приглашаю в мир Nemerle, C# 3.0, да и в общем, то Комон Лиспа. А те кто подсел на одну из игл может и дальше рекламирвоать свои любимые пуриские языки вроде Хаскеля.

Здравствуйте, Temoto, Вы писали:

T>Вот мне щас не хотелось бы показывать на конкретный язык, но в хаскеле есть инструмент, который в частности используется для "протаскивания" данных не через параметры. Через параметры можно сделать некрасиво, понимаю о чём вы, да. А можно и нормально, если тип абстрактный и состав данных снаружи неизвестен, это подход Си с typedef.

Это подход и привел к появлению ООЯ, так как писать так попросту не удобно.

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

T>На одних функциях, если вы об этом, далеко не уедешь, тут глупо спорить. С другой стороны, ООЯ без модулей (в смысле отдельно компилируемые файлы), процедур и прочих парадигм (а они не входят в ООП) был бы тоже ужасен. Поэтому вы сравниваете воображаемый язык с одной ФП парадигмой против языка с ООП и другими. В этом и словоблудие, или диалектика, если вам так угодно.

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

Так о чем речь?

Здравствуйте, Temoto, Вы писали:

T>Кстати, может быть, вам будет интересно, я в википедии нашёл ссылку на исследование по поводу GADT (это как бы подмножество зависимых типов) в C# и Java.

Я плохо понимаю что такое GADT и чем они отличаются от AlgDT, но сдается мне, что к ЗТ приминительно к данному разговору это не имеет отношения.
В данном разговоре речь о ЗТ пошла потому, что они дают теоретическую основу для проверки корректности индексов массивов.

Каким образом GADT помогут контролировать индексы массивов?

Здравствуйте, Temoto, Вы писали:

T>В вырожденном случае второй пример сводится к просто bar_not_class(Func foo) { foo(); }.

Верно. Но я специально максимально одинаковые варианты привел.

T> Это пригодится, чтобы foo вызывать с хитрыми параметрами или ещё что, но не понял причём тут полиморфизм.

Первый пример — полиморфизм? А второй по внешним эффектам практически первому идентичен.

T>А первый так и не понял зачем он нужен.

Зачем нужны абстрактные методы в ООП? Это ж очевидно — чтобы можно было перекрыть в наследниках и потом использовать полиморфизм.

T>Вы не могли бы привести примеры использования этих классов?

Да пожалуйста. Думаю, они абсолютно очевидны, это ж хрестоматийный пример ОО полиморфизма.

1)
class AA
{
    override void Foo()
    {
        Console.WriteLine("AA");
    }
}

class AB
{
    override void Foo()
    {
        Console.WriteLine("AB");
    }
}

...

foreach (var a in new {(A)new AA(), (A) new AB()})
    a.Bar();
    
2)
foreach (var b in new {new B(() => Console.WriteLine("BA")), new B(() => Console.WriteLine("BB"))})
    b.Bar();

T>>Я не говорю, что какая-то технология самодостаточна. Я говорил о том, что несмотря на отсутствие классов и объектов в функциональных языках решаются те же самые задачи (полиморфизм и бла бла), что и в ООЯ.
VD>А я говорю, что это чушь высосанная из пальца. И что?

Пример кода на агде/хаскеле

reduce fun start [] = start
reduce fun start (x:xs) = reduce fun (fun start x) xs

> reduce (+) 0 [1,2,3]
6
> reduce (++) "" ["a", "b", "c"]
"abc"

Это, не высосанный из пальца, полиморфизм вне ООП. Вот что. Уже два или три человека в этом обсуждении согласились, как минимум с тем, что определенные задачи в C#/Java решаются через классы и объекты, а в некоторых функциональных языках без ООП тоже решаются, теми же способами, но это не ООП. Только с вами этот фокус (понимание) не проходит. Очень жаль, правда.

T>>Вот товарищ сказал, что ООП необходим для больших проектов, а я говорю что не именно ООП необходим, а средства решения определённых задач; и эти средства есть во всех ООЯ, потому что эти задачи решает ООП, и эти средства есть в *некоторых* функциональных языках.

VD>Ну, назови это "средства". Без разницы. В некоторых ФЯ они может и есть. Но конеретно в Агде, в которой есть поддержка ЗТ, нет.
VD>Так о чем спич?

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

VD> Но так ничего и не предлагается для того чтобы можно было упростить решение задач в ОО-стиле.
VD>В Хаскеле и Агде нет главного. Там нет объектов. В Хаселе же еще нет удобного средства императивного программирования которое зачастую нужно организации объектов. Так что попытка мыслить в терминах ООП программируя на хаскеле приведет к жудким результатам. Даже худщим чем если тоже самое делать на С.

Правильно! Потому что не надо всегда мыслить в ОО-стиле и решать задачи в ОО-стиле. Можно решать задачи с помощью модулей, функций, типов, групп типов (интерфейсы) и (сюрприз!) без объектов. И это только агда/хаскель. А в лиспе и без типов и интерфейсов. А в другом языке ещё как-то иначе. Хорошо быть открытым для новых подходов, а не замыкаться на объектах. Теперь я знаю, что вы читаете в этих строках совсем другое, но на самом деле тут *не* написано, что ваш любимый и единственный ООП с чем-то конфликтует, что он плохой, ничего негативного тут не написано.

VD>Меж тем я не заметил ни одного конфликта между ООП и ФП. Сдается мне, что конфликт в мозгу у пуристов от обоих конфессий.

Ура! Конфликт у вас в голове. Я уже неделю говорю, что средства, которые используются в ООЯ, также используются для тех же целей и в других, не-ОО языках. Я не вкладывал в это предложение конфликта, это вы его придумали.

T>>Кстати, может быть, вам будет интересно, я в википедии нашёл ссылку на исследование по поводу GADT (это как бы подмножество зависимых типов) в C# и Java.

VD>Я плохо понимаю что такое GADT и чем они отличаются от AlgDT, но сдается мне, что к ЗТ приминительно к данному разговору это не имеет отношения.
VD>В данном разговоре речь о ЗТ пошла потому, что они дают теоретическую основу для проверки корректности индексов массивов.

VD>Каким образом GADT помогут контролировать индексы массивов?

Поскольку, любую информацию от меня вы воспринимаете как враждебную (такое впечатление сложилось), я предлагаю вам восполнить пробел по обобщённым алгебраическим типам и всё-таки прочитать статью

самостоятельно.

AVK>Зачем нужны абстрактные методы в ООП? Это ж очевидно — чтобы можно было перекрыть в наследниках и потом использовать полиморфизм.

Нет, зачем нужен первый класс вообще.
Точно! Наследники! Я совсем про них забыл.

T>>Вы не могли бы привести примеры использования этих классов?
AVK>Да пожалуйста. Думаю, они абсолютно очевидны, это ж хрестоматийный пример ОО полиморфизма.

Ну понятно, в общем, там в другом ответе я [для себя] сформулировал это так, что передача аргументов разных типов и при этом контроллируемая системой типов, а не if-ами программиста, это да, поддержка полиморфизма в языке.
А если void *func, то это не полиморфизм, а просто отсутствие ограничений. Вот думаю над разными примерами, пока что меня такое разделение устраивает.

Здравствуйте, Temoto, Вы писали:

T>Ну понятно, в общем, там в другом ответе я [для себя] сформулировал это так, что передача аргументов разных типов и при этом контроллируемая системой типов, а не if-ами программиста, это да, поддержка полиморфизма в языке.
T>А если void *func, то это не полиморфизм, а просто отсутствие ограничений. Вот думаю над разными примерами, пока что меня такое разделение устраивает.

Т.е. полиморфизм это или нет зависит от кривизны рук программиста? Да, не укажешь явно список параметров — проверки не будет. Так не делайте так. За объявление указателя на функцию в виде void* вообще-то бьют по рукам линейкой.

А в C# вообще-то тоже можно говно написать:

interface IStream {
  object Read(params object[] args);
}

Здравствуйте, Temoto, Вы писали:

T>Точно! Наследники! Я совсем про них забыл.

А что, без наследников зачем то нужны абстрактные методы?

T>Ну понятно, в общем, там в другом ответе я [для себя] сформулировал это так, что передача аргументов разных типов и при этом контроллируемая системой типов, а не if-ами программиста, это да, поддержка полиморфизма в языке.

Ты просил показать, как можно обеспечить полиморфизм указателем на функцию. Я тебе и привел пример.

T>А если void *func, то это не полиморфизм

Разница только в типизации. Принципиально ничего не меняется.

Здравствуйте, Temoto, Вы писали:

T>>>Я не говорю, что какая-то технология самодостаточна. Я говорил о том, что несмотря на отсутствие классов и объектов в функциональных языках решаются те же самые задачи (полиморфизм и бла бла), что и в ООЯ.
VD>>А я говорю, что это чушь высосанная из пальца. И что?

T>Пример кода на агде/хаскеле
T>

T>reduce fun start [] = start
T>reduce fun start (x:xs) = reduce fun (fun start x) xs

>> reduce (+) 0 [1,2,3]
T>6
>> reduce (++) "" ["a", "b", "c"]
T>"abc"
T>

Офигенный пример! Практически ООП как он должен быть в идеале!

T>Это, не высосанный из пальца, полиморфизм вне ООП.

В Виндовсе даже на С смогли добиться полиморфизма и инкапсуляции. Только причем тут ООЯ?
Писать код в ОО-стиле ведь совершенно неудобно!

Я и на Яве видел эмуляцию ФП. Весьма себе успешная. Это же не значит что Ява — это ФЯ?

T> Вот что. Уже два или три человека в этом обсуждении согласились, как минимум с тем, что определенные задачи в C#/Java решаются через классы и объекты, а в некоторых функциональных языках без ООП тоже решаются, теми же способами, но это не ООП. Только с вами этот фокус (понимание) не проходит. Очень жаль, правда.

Если речь не идет о том, что все языки равны по Тьюрингу, то я таких людей не заметил.

Со мной же фокусы вообще не проходят. Или вы предъявляете реальные доказательства, или для меня Вы переходите в класс религиозных фанатиков стоящих на своем просто ради религии.

VD>>Ну, назови это "средства". Без разницы. В некоторых ФЯ они может и есть. Но конеретно в Агде, в которой есть поддержка ЗТ, нет.
VD>>Так о чем спич?

T>Полиморфизм

Да Вы, уважаемый, уже достали со своим полиморфизмом. То что полиморфизм есть еще не значит, что он удобен для программирования в ОО-стиле. Да и одного полиморфизма вообще не достаточно. Для удобного ОО-программирования нужен целый ряд удобных фич языка которые делаю это программирование простым и удобным.
Для ООП мало полиморфизма класса перегрузки который эмулируют хаскелевсеие классы типов. Для него нужен полиморфизм уровня классов. Так чтобы проектируя приложение я мог думать в терминах классов и наиболее естественным образом выражать свои мысли. Стало быть мне нужны или классы, виртуальные методы и модификаторы доступа, прототипная система предоставляющая то же самое но основанная на сообщениях. Кстати, мне так же нужно средство прозрачного управления состоянием. Оно должно быть простым и понятным. В общем, если я думаю о системе в терминах симуляции, то и описывать я ее хочу в подходящих терминах.


VD>> Но так ничего и не предлагается для того чтобы можно было упростить решение задач в ОО-стиле.
VD>>В Хаскеле и Агде нет главного. Там нет объектов. В Хаселе же еще нет удобного средства императивного программирования которое зачастую нужно организации объектов. Так что попытка мыслить в терминах ООП программируя на хаскеле приведет к жудким результатам. Даже худщим чем если тоже самое делать на С.

T>Правильно! Потому что не надо всегда мыслить в ОО-стиле

Мне это уже надоело. Всегда не надо. Иногда надо. Кому? Ну, лично мне.

T> и решать задачи в ОО-стиле.

Я считаю, что сам способен понять каким образом мне лучше решать стоящие передо мной задачи.
У Вас по этому поводу другое мнение?

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

Ой какой сюрприз! А мужики то 30 лет назад и не знали! Вау!

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

И главное! Там есть полиморфизм, так нужный для ФП!

T> И это только агда/хаскель. А в лиспе и без типов и интерфейсов.

Ну, тему лиспа я бы пожалуй опустил, так как по гибкости до него аде и хаскелю ой как далеко. А ООП у него (у Комон Лисп, по крайней мере) есть прямо из коробки. В прочем тут рядом есть много фанатов Лисп. Могу свести по дружбе. Поспорите с ними в удовольствие .

T> А в другом языке ещё как-то иначе.

Ага. Есть даже "сумасшедшие" которые тупо встраивают поддержку классов. И есть многие кто уже понял, что это очень удобно. Только с вами этот фокус (понимание) не проходит. А жаль (с).

T>Хорошо быть открытым для новых подходов, а не замыкаться на объектах.

Да, да. Быть замкнутым в функциях намного более кошернее. Это сегодня новых трэнд! (с)

T>Теперь я знаю, что вы читаете в этих строках совсем другое, но на самом деле тут *не* написано, что ваш любимый и единственный ООП с чем-то конфликтует, что он плохой, ничего негативного тут не написано.

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

VD>>Меж тем я не заметил ни одного конфликта между ООП и ФП. Сдается мне, что конфликт в мозгу у пуристов от обоих конфессий.

T>Ура! Конфликт у вас в голове.

Нет, уважаемый. Не у нас, у вас. Причем в данном случае именно с маленькой буквы, так как под "вы" понимается лагерь ФП-пуристов.

T>Я уже неделю говорю, что средства, которые используются в ООЯ, также используются для тех же целей и в других, не-ОО языках. Я не вкладывал в это предложение конфликта, это вы его придумали.

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

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

Здравствуйте, Temoto, Вы писали:

VD>>Каким образом GADT помогут контролировать индексы массивов?

T>Поскольку, любую информацию от меня вы воспринимаете как враждебную (такое впечатление сложилось), я предлагаю вам восполнить пробел по обобщённым алгебраическим типам и всё-таки прочитать статью

Статьи я читал. Только вот ответа на поставленный вопрос не нашел.

Не, серьезно. С удовольствием послушаю доходчивое объяснение. Особенно если оно не будет сопровождаться внушением, а будет чисто информативным.

T>>Ну понятно, в общем, там в другом ответе я [для себя] сформулировал это так, что передача аргументов разных типов и при этом контроллируемая системой типов, а не if-ами программиста, это да, поддержка полиморфизма в языке.
T>>А если void *func, то это не полиморфизм, а просто отсутствие ограничений. Вот думаю над разными примерами, пока что меня такое разделение устраивает.

ВВ>Т.е. полиморфизм это или нет зависит от кривизны рук программиста? Да, не укажешь явно список параметров — проверки не будет. Так не делайте так. За объявление указателя на функцию в виде void* вообще-то бьют по рукам линейкой.

Не, я имел в виду, позволяет ли язык контролировать набор типов, который можно сунуть в функцию или нет. Вот Си позволяет, а лисп и питон — нет, вот о чём речь.

ВВ>А в C# вообще-то тоже можно говно написать:

ВВ>

ВВ>interface IStream {
ВВ>  object Read(params object[] args);
ВВ>}
ВВ>

И FooStream.Read(10) нельзя, потому что int — не объект, да?

T>>Точно! Наследники! Я совсем про них забыл.
AVK>А что, без наследников зачем то нужны абстрактные методы?

Просто я давно не читал код с абстрактными классами и методами. Вот и забыл.

T>>Ну понятно, в общем, там в другом ответе я [для себя] сформулировал это так, что передача аргументов разных типов и при этом контроллируемая системой типов, а не if-ами программиста, это да, поддержка полиморфизма в языке.

AVK>Ты просил показать, как можно обеспечить полиморфизм указателем на функцию. Я тебе и привел пример.

Да, я понял, спасибо.

T>>А если void *func, то это не полиморфизм
AVK>Разница только в типизации. Принципиально ничего не меняется.

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