Новое сообщение в форум Компьютерные священные войны

Форум	Компьютерные священные войны
Тема	Как правильно задавать вопросы

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

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

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

S>>>А пример, который ты просишь - ровно то, что мы и обсуждаем: equal_to, который единым образом для разных типов вызывает совершенно различный код, определенный в совершенно разных мономорфных функциях.

_>>А, я кажется понял чем вызваны твои странные интерпретации и выводы. Вот смотри, у нас есть некая функция f. А так же функция g, которая вызывает внутри себя функцию g. Правильно ли я понял, что в такой ситуации ты в какой-то степени относишь код функции f к функции g (не говорим сейчас про всякие низкоуровневые вопросы типа инлайнинга и т.п., а обсуждаем только исходные коды)? Если да, то тогда конечно понятно, что ты переносишь особенности реализации функции f на функцию g. Однако в моём понимание к коду функции g в связи с f относится исключительно сама процедура вызова (грубо говоря ассемблерная инструкция call), а как там реализована f вообще не важно.

S>Хорошо, давай оторвемся от низкоуровневых вопросов, хотя я к ним не тяготел. Но недалеко. Представим, что у нас есть идеальный исполнитель программы на неком языке, у которого нет проблем с раздувом кода, скоростью выполнения и т.п. И задача, не требующая новых типов и специальных приседаний с ними. Только комбинация. Тогда в принципе пофигу на классификацию. Полиморфно и хрен с ним. И тогда я не против твоего понимания того как устроена g, каким образом она обращается к f, сколько реализаций у f, как их g будет вызывать - чихать. Никаких возражений.

S>А теперь возвращаемся в реальную жизнь. Одна специально полиморфная функция заражает другую, которая параметризуется ей, третью и далее. Кстати, я определение equal_to не рассматриваю как функцию (с адресом вызова). А вот equal_to<int> и equal_to<float> - вполне себе функции с адресами. И когда ты параметризуешь с помощью equal_to transform, то код transform раздувается по числу используемых типов (адресов операторов). Вот Wadler (или Blott) привел тупой пример, где нужна функция, вычисляющая тройку квадратов по тройке значений. Учитывая что каждое из значений может быть либо целое, либо плавающее, требуется 9 перегрузок что бы обслужить все случаи всего лишь для такого тупого примера.
S>(Не знаю, видел ли ты статью "How to make ad-hoc polymorphism less ad hoc". Погляди по диагонали, она короткая. И она именно о том, почему появились классы типов, какие проблемы они решают. Кстати, там был упомянут подход, при котором равенство для типов должно было быть полностью полиморфным для любого типа (==):: a -> a -> Bool. Что наводит на мысль о том что equal_to все-таки ad hoc)
S>Так вот, ad hoc - это все о том, как пухнет код при топорном подходе к компиляции. А проблема распухания - она более касается функции g, которая комбинирована f-ом, и вообще, чем больше комбинирования ad-hoc-ов, тем больше разбухание. Т.е. когда Wadler писал об этой проблеме, я полагаю что он подразумевал именно это. Будут другие мысли - охотно выслушаю, но только после прочтения "How to make ad-hoc less ad hoc".
S>Ну и, собственно, к equal_to - какой бы он не был красивый и удобный для программиста, он не препятствует разбуханию. Все что он делает - удобненько подставляет адресок мономорфного сравнения. Таким образом, специальная природа сравнения расползается по всему коду, который использует этот equal_to (без дополнительной косвенности). В итоге, и transform становится как вирус.
S>Знал бы Wadler в 88м году что у transform в 2017м будет параметризован 5ю типами...

_>>>>diff то как раз разницу покажет. А вот любой вменяемый программист скажет что разницы в данных двух примерах кода нет.
S>>>Не уверен. Давай спросим любого вменяемого? Как будем определять вменяемость?

_>>Давай начнём с тебя) Хочешь сказать, что видишь разницу в коде реализации этого примера на Хаскеле и на C++? )
S>Ок, если забить на особенности выполнения и компиляции, то для абстрактного исполнителя семантика apply-ев в C++ и Haskell одинакова.

_>>ОК, т.е. ты в принципе признаёшь возможность нормального параметрического полиморфизма в C++ (тогда наша дискуссия снова возвращается на конструктивное русло из холливарной области), но при этом имеешь возражения в принадлежности к нему конкретного кода (equal_to), правильно?
S>Правильно. Я не отрицал возможность нормального параметрического полиморфизма в C++.

S>>>И как возможность оптимизации влияет на классификацию?

_>>Я поясняю разницу в реализации Хаскеля и C++. На уровне исходного кода её нет. А на уровне генерируемого машинного разница заметная (обмен возможности модульности на производительность).
S>То есть ты ушел от ответа на вопрос "как" возможность оптимизации влияет на классификацию, а я нечаянно на него ответил (или попытался).

S>>>Лично я в плане удобства С++ -у предпочитаю C#. А быстродействие меня (и не только) пока устраивает.

_>>В C# не удобство, а простота (тривиальность). Это большая разница. Если бы было реальное удобство, то не было бы никаких проблем повторить простейший код (записываемый в лоб и на Хаскеле и на C++ и на Python'е и на множестве других языков) из трёх строчек.
S>А мне не нужно повторять простейший код за C++ на C#. У меня почему-то наоборот. Если я захочу повторить 20К C# строк бизнес логики на C++, то получу 40К строк.

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail