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

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

I>>Например попробуй реализовать такое — вызвать несуществующий метод у объекта. Разумеется, безо всяких исключений и тд и тд.

I>>То есть, всё как завещал изобретатель ООП сэр Алан Кей (у которого ООП в с++ вызвало глубокое недоумение).

_>И?

_>В C++ будет ошибка времени компиляции, а в Питоне будет ошибка времени исполнения. В чём разница? )

Не угадал. Подсказка — в С++ нужна генерация кода, а в Питоне — работает само.

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

I>>>Например попробуй реализовать такое — вызвать несуществующий метод у объекта. Разумеется, безо всяких исключений и тд и тд.
I>Не угадал. Подсказка — в С++ нужна генерация кода, а в Питоне — работает само.

Эврика! Только что проверил. Сделал на Питоне класс, у которого нет методов prove_P_equals_NP, print_money, get_meaning_of_life, do_everything_user_wanted, попробовал их вызвать — все отлично работают! Это прорыв!

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

DM>Эврика! Только что проверил. Сделал на Питоне класс, у которого нет методов prove_P_equals_NP, print_money, get_meaning_of_life, do_everything_user_wanted, попробовал их вызвать — все отлично работают! Это прорыв!

А сказать что хотел ?

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

I>Не угадал. Подсказка — в С++ нужна генерация кода, а в Питоне — работает само.

Это ты вообще о чём? )

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

I>>Не угадал. Подсказка — в С++ нужна генерация кода, а в Питоне — работает само.

_>Это ты вообще о чём? )

Все о том же.
У тебя варианты
1. ты не в курсе, как такое делается — твоя компетенция недостаточна для продолжения разговора
2. не можешь признать фактическое положение дел — нет смысла с тобой продолжать
3. написать как есть

если ты выбираешь п.3, можно продолжить про область применения этой фичи, если у тебя есть какие то сомнения.
Итого, если таки п.3, то от тебя требуется или краткое описание или ссылка.

Вообще, судя по тому, как быстро ты прекратил тему мультиметодов, уже все ясно — уровень питона намного выше, чем С++.

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

DM>>Эврика! Только что проверил. Сделал на Питоне класс, у которого нет методов prove_P_equals_NP, print_money, get_meaning_of_life, do_everything_user_wanted, попробовал их вызвать — все отлично работают! Это прорыв!

I>А сказать что хотел ?

Хотел намекнуть, что в языках вроде питона можно вызвать некоторый специальный метод вместо несуществующего, но нельзя вызвать сам несуществующий, ему взяться неоткуда. Кстати, в D тоже есть такая фишка. А в С++ "вы не должны этого хотеть", там это ошибка времени компиляции, как и было сказано выше.

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

I>С того, что там динамический полиморфизм, мультиметоды и много чего еще.

Нормальных мультиметодов в питоне нет (да и вообще нигде хорошей реализации нет).

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

I>Например попробуй реализовать такое — вызвать несуществующий метод у объекта. Разумеется, безо всяких исключений и тд и тд.
I>То есть, всё как завещал изобретатель ООП сэр Алан Кей (у которого ООП в с++ вызвало глубокое недоумение).

При всем уважении к Кею и Smalltalk, конкретно эта фича совершенно бесполезна и, более того, вредна.

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

I>Все о том же.
I>У тебя варианты
I>1. ты не в курсе, как такое делается — твоя компетенция недостаточна для продолжения разговора
I>2. не можешь признать фактическое положение дел — нет смысла с тобой продолжать
I>3. написать как есть

I>если ты выбираешь п.3, можно продолжить про область применения этой фичи, если у тебя есть какие то сомнения.
I>Итого, если таки п.3, то от тебя требуется или краткое описание или ссылка.

Я пока вообще не понял решение какой задачи ты хочешь получить. Поставь уже задачу и обсудим. )

I>Вообще, судя по тому, как быстро ты прекратил тему мультиметодов, уже все ясно — уровень питона намного выше, чем С++.

Так с мультиметодами же всё очевидно. Их нет ни в C++ ни в Питоне. Но они легко реализуются с помощью библиотеки и в C++ и в Питоне. ) Или ты хочешь с этим поспорить? )

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

I>>Итого, если таки п.3, то от тебя требуется или краткое описание или ссылка.

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

Пока речь про языковую фичу, именно о ней идет речь в ООП по Алану Кею. Сходи вверх по треду и посмотри, если забыл про что речь.

I>>Вообще, судя по тому, как быстро ты прекратил тему мультиметодов, уже все ясно — уровень питона намного выше, чем С++.

_>Так с мультиметодами же всё очевидно. Их нет ни в C++ ни в Питоне. Но они легко реализуются с помощью библиотеки и в C++ и в Питоне. )

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

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

ARK>При всем уважении к Кею и Smalltalk, конкретно эта фича совершенно бесполезна и, более того, вредна.

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

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

I>>С того, что там динамический полиморфизм, мультиметоды и много чего еще.

ARK>Нормальных мультиметодов в питоне нет (да и вообще нигде хорошей реализации нет).

Около десятка строчек дают вполне нормальную реализацию.

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

I>>А сказать что хотел ?

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

Это несущественная разница. Если я пишу y = x.getNotExistedValue() и получаю в y ожидаемое значение, то совершенно неинтересно, существует ли реально такой метод или нет.

>Кстати, в D тоже есть такая фишка. А в С++ "вы не должны этого хотеть", там это ошибка времени компиляции, как и было сказано выше.

"не должны этого хотеть" это ограничение возможностей ООП.

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

I>Пока речь про языковую фичу, именно о ней идет речь в ООП по Алану Кею. Сходи вверх по треду и посмотри, если забыл про что речь.

Угу. Просто ты так её обозвал, что фиг поймёшь о чём была речь. Другие участники подсказали уже, что ты про возможность перегрузки операции вызова методов. Как раз то, что я демонстрировал в этой темке на языке D, для реализации автоматического использования обычных функций и операторов с монадами. Это полезная возможность и жаль что в C++ её нет. Но не думаю, что она имеет какое-то отношение к уровню языка. Кстати, а C++ и D с твоей точки зрения языки одного уровня или нет?)))

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

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

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

ARK>>При всем уважении к Кею и Smalltalk, конкретно эта фича совершенно бесполезна и, более того, вредна.

I>Наоборот, она очень полезна и именно по этому её вводят с JavaScript. Сделай это 10 лет назад, сегодняшняя вебразработка выглядела бы намного иначе.

В чем же состоит полезность?
Вредность очевидна — банальные опечатки не дают ошибок даже в рантайме.
Не знаю, как для веб-разработки, но для general purpose programming это ужасно.

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

I>Около десятка строчек дают вполне нормальную реализацию.

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

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

_>Интересно, тогда что это у нас, например здесь http://ru.wikipedia.org/wiki/Singleton#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80_.D0.BD.D0.B0_C.23?)

То, про что я сказал двумя ответами выше. "Без метапрограммирования никаких шаблонов проектирования в коде нет — только результат их применения в голове программиста. Поэтому к уровню кода они никакого значения не имеют."

В приведенном вами примере по ссылке метапрограммирование используется, так о чем мы все-таки говорим?

_>Хы, ну если заменить слово монада на слово процедура, то классический ООП код тоже спокойно будет попадать под такое определение. )))

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

_>Угу, угу. аналога написать нельзя, но пользы от этого не имеющего аналогов нет. Я приблизительно так себе и представлял... )

В данном случае разговор о том, что аналог написать нельзя — только и всего.

_>Польза в виде борьбы с проблемами, вызванными неудачным дизайном язык — это конечно очень интересно. )))

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

_>Ууу, там много всего. Хотя первоисточник проблемы общий. Ну если взять этот наш конкретный код... Как насчёт записать его в виде чего-то типа "M.write a 1 (M.read a 1)^2"? )

Вы все таки имеете в виду

M.write a 1 (M.read a 1 ^2)
-- или
M.write a 1 $ M.read a 1 ^2

ну, как сделать ^2 я уже писал в соседних ветках, а $ заменяется на =<< и получаем

M.write a 1 =<< M.read a 1 ^2

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

over v i f = M.write v i =<< f (M.read v i)

и писать

over v 1 (^2)

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

_>Фокус в том, что изначальный мой код, который мы и оптимизировали, был вообще без императивных кусков.

Мое решение тоже императивных кусков не имеет. Строго говоря, даже код, лежащий в фундаменте такого решения не имеет императивных кусков, просто у вас специальное определение для слова "императивный".

_>Естественно очевидно, что можно было легко оптимизировать тот мой код, переписав его целиком на императивном (монадном) подвиде Хаскеля. Однако это никому не интересно.

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

_>Это было интересно.

Эти техники (устранение промежуточных структур данных) уже лет двадцать назад были впервые использованы в стандартной библиотеке ФЯ, так что самое любопытное тут не они, а способность видеть "ручную оптимизацию" на месте автоматической.

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

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

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

_>Причём в данном случае это особо чувствуется, т.к. сам код преобразования массива явно безопасный (никаких там системных вызовов и т.п.)

у вас какое-то странное представление о системе контроля за эффектами. Что значит "явно безопасный"? Вот почему строки часто делают иммутабельными. Их изменять же полностью безопасно — никаких "системных вызовов" при этом?

_> и необходимость добавления монад обусловлена исключительно проблемами в дизайне языка.

И что это за проблемы?

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

_>Это ещё зачем? ) Если такой подход уменьшает наши возможности (Евгений приводил пример где и Хаскель пасует, а про Java/C# вообще можно смешно упоминать) в написание кода, при ровно тех же гарантиях отсутствия ошибок в создаваемом ПО? )

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

Автор: MigMit
Дата: 16.02.12

, где C++ пасует, а Java/C# — нет, не говоря уже о Хаскеле.
Я считаю, что интегрально, по совокупности плюсов и минусов, типизация лучше ее отсутствия.

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

_>>Интересно, тогда что это у нас, например здесь http://ru.wikipedia.org/wiki/Singleton#.D0.9F.D1.80.D0.B8.D0.BC.D0.B5.D1.80_.D0.BD.D0.B0_C.23?)

K>То, про что я сказал двумя ответами выше. "Без метапрограммирования никаких шаблонов проектирования в коде нет — только результат их применения в голове программиста. Поэтому к уровню кода они никакого значения не имеют."

K>В приведенном вами примере по ссылке метапрограммирование используется, так о чем мы все-таки говорим?

Какое ещё метапрограммирование в C#?

K>В данном случае разговор о том, что аналог написать нельзя — только и всего.

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

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

Не стоит путать факультативную иммутабельность (есть почти во всех языках) и обязательную (типа как в Хаскеле). Так же как не стоит путать факультативную чистоту (как в D) и обязательную (как в Хаскеле). Я весьма интенсивно использую первое во всех языках, если оно доступно. А вот обязательный вариант мне кажется бредовым и только мешающим. Точнее я вполне могу допустить вариант когда мы будем писать не const у иммутабельных, а наборот mutable у мутабельных (а остальные будут по дефолту иммутабельными) — тоже вполне себе вариант. Но в Хаскеле то даже такого нет.

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

Ну так я нигде и не возражал тому, что классический (вне монад) Хаскель является вполне симпатичным языком. Только вот он как бы не для реального применения такой... )))