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

_>А вообще да, похоже что они наконец то постепенно осознают реальность и начинают сдвигать вектор развития в правильном направление. Только вот это надо было делать лет 10 назад, а не сейчас. Ну MS как всегда в своём стиле... )))

Проблема большого .Net в совместимости с анахронизмами, чего нет в .Net Core.
.Net Core это новое осмысление, взят курс на опен сорс, кроссплатформенность. Все перспективные направления UWP (.Net Native), Xamarin, Asp.Net Core используют Core.

Нужно набрать некую критическую массу, что бы двигаться вперед. Плюс новый менеджмент взял курс на облака.
Скоро выйдет NetStandard
https://github.com/dotnet/standard/blob/master/docs/netstandard-20/README.md

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

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

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

S>>То есть, никаких базовых знаний о "функционировании современных ЦПУ". Специальность есть, а знаний — нет. Уже только этим опровергается твой тезис о том что должно быть известно каждому студенту, даже подразумевая мнимую часть "студенту специальности программист". Куда уж там про пролог и эпилог функции, реализация каррирования в машинных кодах. И устройства современных компьютеров там тоже нет.

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

Слабый курс или нет — не знаю, но отлично демонстрирует ущербность твоего тезиса.

S>>Т.е. 010200 все-таки профильное, отъехал таки? Отлично. Но вот почему студент, обладая дипломом по профильной специальности 010200, не осилил прийти в профессию — я так и не догнал.

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

Не сошлешься на документ, где указаны необходимые и базовые знания? Или ты уже сам со своей колокольни это решаешь? Скоро начнешь лицензии у ВУЗ-ов отбирать?

_>Единственное, что слегка удивляет в данной ситуации, это то, что ты приходишь на программистский форум и начинаешь там доказывать, что программисту не нужны знания архитектуры ЭВМ. Причём делаешь это сразу после откровенного косяка, вызванного твоим незнанием именно данного вопроса. Это конечно уже редкое явление... )))

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

S>>Ну вот от того что тебе со мной настолько сложно, я предлагаю для начала разобраться с чистотой функции map. Определяется ли по-твоему чистота функции map функцией, переданной параметром? Да/нет/не знаю?

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

S>>Это зависит от фукнции. Функция apply не выполняет никаких специальных для типа T действий, если их не выполняет переданная функция f. В то время как выполнение функции my_equal_to не может обойтись без выполнения специальных для типа T действий.

_>Но в коде функции my_equal_to нет никаких специальных для типа T действий. Там есть только вызов оператора равенства для типа eq. А что там уже в нём (ad hoc или что-то ещё) мы не можем узнать без анализа кода типа eq (т.е. уже другого, стороннего кода).
Если ты вызов оператора равенства (специального для типа T) не считаешь специальным для типа T действием, то что же ты тогда вообще считаешь специальным?

S>>>>Действительно, ПП не требует модифицировать и дополнять код. Не наш, не чей-то, а вообще код.
_>>>Ой, я смотрю у тебя совсем забавные проблемы с логикой... Ну расскажи мне как ты добавишь новый тип в проект, не модифицировав никак код этого проекта? )
S>>1) что такое код проекта и каким образом он относится к определению ПП?

_>Это исходники необходимые для сборки проекта.
А, т.е. ты так передернул. Ну что ж, я тоже могу. Что такое сборка проекта и каким образом она относится к определению ПП?

S>>2) возможно у меня в проекте уже есть такой тип, который не работает с твоей my_equal_to. Что с ним делать?

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

_>>>Оператор равенства в языке (во всяком случае таком как C++) — это безусловно специальный полиморфизм. Только вот это не имеет никакого отношения к нашей функции, в ней же никаких специализаций нет. Более того, в ней даже прямого вызова этого оператора нет — только вызов некой функции, переданной как указатель (внутри типа eq).
S>>Специальный код сравнения будет выполнен во время выполнении функции my_equal_to?

_>1. Может да, а может нет — по коду my_equal_to это понять невозможно.
Что говорит об отсутствии эквивалентности следующей классификации "In terms of implementation, a
universally polymorphic function will execute the same code for arguments of any admissible type, while
an ad-hoc polymorphic function may execute different code for each type of argument."
_>2. Даже если и будет, то этот код не будет относится к анализируемому на предмет полиморфизма куску кода.
По Пирсу куски кода характеризуются поведением, а не включением текста. А поведение my_equal_to будет полностью отражать поведение сравнения для соответствующих типов.

S>>Это из работы Карделли. Если функция может вести себя по-разному на нескольких разных типах, которые могут не представлять общую структуру, то это AH.

_>Всё верно. Но причём тут это? Какое имеет отношение ситуация с разными определениями под разные типы к ситуации когда у нас есть ровно одно определение, но действующее для не для всех возможных (но при этом для бесконечного потенциального множества) типов.
И в чем же отличие от возможности определить бесконечное кол-во перегрузок, которые по-твоему AH?

S>>А то, что я там 5 лет назад доказывал — это ты решил себе такую подмену сделать? Извини, я не могу спорить с тем собой, который был 5 лет назад.

_>Да у тебя тут уже начинаются споры не только с собой 5-и летней давности, но и с собой "на пару сообщений раньше". )))
В чем именно?

_>>>Ну так ты же назвал оператор равенства расширением функции my_equal_to даже за более безобидный факт (за вызов этого оператора через переданный указатель), чем просто прямое использование. Собственно да, у тебя изначальная идея была даже более бредовой, чем показанная мною аналогия. Скорее правильнее говорить что ты считаешь printf расширением функции apply, если где-то в коде встречается вызов типа "apply(printf, "");".
S>>Я назвал расширением оператор равенства? Не думаю, что бы я мог использовать такой термин осмысленно. Я не знаю, что он означает. А говорить что я считаю оператор равенства или printf расширением чего-то можно будет лишь после того, как ты уточнишь термин расширение, я пойму о чем речь, и подтвержу, что я так считаю. А до тех пор — я считаю что это твоя демагогия.

_>Ну так для этого надо обратиться в первую очередь к тебе, потому как изначально в данном контексте употребил данное слово именно ты:
На самом деле было так

Автор: alex_public
Дата: 06.03.17

:

_>Не верно. Вводя дополнительные перегрузки мы модифицируем (расширяем) код нашей функции. Собственно это и есть основной минус ad hoc полиморфизма — для добавление поддержки нового типа требуется расширение кода функции.
О, т.е. по-твоему выходит что все перегруженные по типу функции — это код одной и той же функции?

_>А в обсуждаемом случае функция f будет подхватывать новые типы сама, без всякой её модификации (можешь даже скомпилировать её в отдельный бинарный модуль для полной чистоты эксперимента, а потом добавлять новые типы — всё будет работать).
А функции сравнения для разных типов при этом не являются расширением одной и той же функции? Или их не нужно писать вместе с новыми типами?

S>>Рад, что тебе понравилось. Но определение ПП действительно явно не требует бесконечность.

_>Ой, а кто же это несколько сообщений назад так настаивал на необходимости работы с бесконечным числом типов? )
На необходимости? У тебя не только с кванторами проблемы, а еще и с необходимостью? Ну МГУ дает.

S>>А вот по поводу гитхаба я что-то не очень понял. Боюсь, это у меня такой юмор был. Юмор мой и сейчас недалеко ушел, но я сейчас ту шутку не могу оценить по достоинству. Если это была шутка, конечно.

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