Почему полиморфные сообщения гораздо более эффективны на практике, чем сочетание унификации и обратного отслеживания?

Ответ 1

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

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

Ответ 2

Я проделал много программирования в Prolog, и, хотя мне нравится язык для его выразительной силы, я должен согласиться с svenningsson, что, как только вы попытаетесь сделать что-то не декларативное, это станет загадкой для использования! оператор (вырезать, отбрасывает варианты возврата) в правильных местах, что крайне подвержено ошибкам.

Хотя он не идеален, одним языком, который элегантно удается комбинировать обратный трафик и не декларативный (обязательный/побочный эффект) код, является Icon. Он в основном изолирует выражения, которые могут естественным образом отступить от общей структуры программы (например, операторов), так что относительно легко понять, что обратное отслеживание не приведет к неожиданным результатам, как в Prolog. Я не уверен, почему не все языки основаны на этой модели исполнения, я предполагаю, что большинство программистов действительно застряли в последовательном мышлении, а обратное отслеживание запутывает.

Я не уверен, что обратное слежение сравнивается с полиморфизмом напрямую. Для меня это скорее альтернатива закрытию, так как использование # 1 для закрытия на большинстве языков - это обычная итерация (думаю, карта/фильтр/сгиб и т.д.). Например, в Icon я могу сказать:

every write 10<(1..10)*2

Который берет последовательность чисел, умножает их на два, отфильтровывает их > 10 и печатает результат ( "каждый" бит, как цикл повторения в Prolog). В языке, основанном на списке/закрытии, я должен написать:

for (filter (map [1..10] \x.x*2) \x.x>10) \x.(write x)

предоставлено, это немного связано с пониманием списков, и каррирование может упростить это, и не весь код значка является настолько кратким, но вы получаете идею. Версия Icon не только более выразительна, но также имеет то преимущество, что она не использует промежуточные списки и "ленива" в обычном смысле, то есть она выпишет первое число перед тем, как сделать * 2 на второй элемент. Это означает, что он позволяет вам писать код, который одинаково эффективен, даже если вы не используете все полученные результаты.

Ответ 3

Угадайте: передача сообщений была более легко привязана к тогдашним популярным практикам и постепенно поглощалась. Постепенное принятие идей Пролога привлекло бы автомобиль, как Oz, только изобретенный в 90-х годах, что-то вроде 20-ти лет назад за Smalltalk. Поскольку Оз утверждает, что поддерживает как процедурное, так и логическое программирование в одном чистом пакете, я не вижу принципиальной причины, по которой мир не мог бы принять этот путь, если бы знал, как в нужное время. Вместо этого парадигма была привязана к более ожоговому типу и разочарованию пятого поколения.

(Я еще не пробовал Моцарта/Оза до сих пор. Я играл с Prolog.)

Ответ 4

Сразу после этого оператор cut пришел мне на ум: Prolog красив и лаконичен так долго, как вы хотите, и может программировать декларативно. После того, как вы начнете использовать оператор вырезания (т.е. Вырезать все обратные трассировки в этом положении), вам нужно подумать о слишком сложных ситуациях, чтобы найти хорошее решение или понять код от других/вашего старого кода.

Таким образом, проблемы с оптимизацией обратного отсчета, по-видимому, являются консенсусом здесь, причем 3 из 4 ответов (по состоянию на 12 августа 2011 года), в которых говорится (+1 к Aardappel и svenningsson).

Ответ 5

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

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

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

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