К сожалению, прологом сейчас практически не занимаюсь. Но посмотрите страничку в википедии: Watson — очень серьёзная система и работает в штатном Линуксе. Там же приводится цитата: «We required a language in which we could conveniently express pattern matching rules over the parse trees and other annotations (such as named entity recognition results), and a technology that could execute these rules very efficiently. We found that Prolog was the ideal choice for the language due to its simplicity and expressiveness.» Pазработка компиляторов с использованием пролога имеет несколько неоспоримых достоинств. Погуглите prolog projects и обнаружите десятки развивающихся систем программирования, основанных на идеях пролога. Аналогично, prolog deep learning. Если вы проведете подобные изыскания по аде, коболу, эйфелю и др. не самым распиаренным языкам, то найдёте, что у пролога всё относительно неплохо. Предположу, если кто ищет себе комфортабельный вагончик, то пролог пока ещё до этого не созрел. А тому кто хочет быть локомотивом, пролог предоставляет огромное и очень перспективное поле для деятельности.
Довольно много проектов, связанных с машинным обучением с использованием обучаемых сетей. Также есть проекты для работы с естественным языком. Всего тут довольно много и меньше не становится. Почему процент пролог-проектов в целом небольшой? Возможно потому, что сложилась некая культура программирования на С-подобных языках (возьмем, например, APL, оберон, аду или эйфель — их тоже не больше, а скорее меньше, чем пролога), к которой привыкли и которая пока адекватна решаемым задачам. Пролог требует специальной подготовки, которой нет у многих топовых специалистов. В самом прологе не хватает многих отточенных на типовые задачи механизмов, которые появятся только, если сделать его очень популярным. Вокруг специального железа для пролога какой-то туман, возможно секретности. И, могу предположить, что широкое внедрение пролога сделает большинство ЯП устаревшими, к этому пока не готовы.
Он может быть и будущее, но на данный момент он все равно бесполезен на практике.
Не могу с таким согласиться. Существует достаточно много перспективных проектов вокруг пролога. Пролог — универсальный язык и на нём можно делать всё, что, например, на питоне. Может просто нужен кто-нибудь типа Гвидо, который сделает популярный вариант пролога. Скорость работы хороших прологов на уровне языков сценариев. Мне кажется полезность-перспективность и текущая массовая популярность — это разные вещи. Мое мнение — пролог это один из самых простых и близких к естественному языков программирования. К сожалению, приходится до сих пор больше работать сo скорее с потомками фортрана. :(
3ря вы так. Пролог или какое-то его удачное расширение — это будущее программирования. Пролог это почти 100% математика, тогда как другие языки — это смесь математики и отсебятены.
Вы похоже склоняетесь к точке зрения оппонента, что декларативность гарантирует поиск результата. Но это так только в случае действительно 100% точного описания задачи. Порядок дизъюнктов — это один из элементов такой точности.
Вам привели пример, что описание задачи может приводить к разным результатам. И ваш пример о том же. А вы что хотите, чтобы машина ещё и знала, что Вам нужны предки библейских персонажей немедленно, а не её усердная работа по их поиску на миллионы лет? Хотеть не вредно. Но лучше давать машине уточнения в таких случаях. В прологе такие уточнения — это, в частности, порядок дизъюнктов и предикатов в них. Предлагаю учить пролог и yчить тщательно!
Если вам нужна теория для её самой, то разницы о очередности нет, а если вы что-то хотите от теoрии практического, то есть. Это и отражается в прологе, как в практическом инструменте. Если кто-то останется без головы, то приз получать уже будет никому. Декларативность предполагает обычно слишком много вариантов и зацикливание — это тоже вариант. От перемены местами дизъюнктов в вашем примере вы его и получаете. В 90-е кто-то предлагал вариант пролога с со случайным выбором — интересный подход, но, полагаю, что он сильно понижает производительность работы. Кому нужен ответ, полученный через 100 лет? Получается выбор: 1) изобретать замысловатые системы логики, конкурировать с Аристотелем; 2) пытаться сделать эффективные машины логического вывода — это пролог, SQL, скорее неудачный и несостоявшийся меркурий,…
Если вы хотите сделать что-то с практическими результатами, вам придется разбираться с порядком применения правил — равноправия на практике обычно не получится. Перепишите мой пример в виде «налево — потеряешь голову» ИЛИ «направо — получишь приз» — какая тут императивность, 100% декларативность, но от того, за что вы возьметесь в первую очередь, зависит результат.
Это пример практической некоммутативности связки ИЛИ. Например, выбор на дороге: 1) налево — потеряешь голову, 2) направо — получишь приз. От того какой путь выбрать первым зависит как пойдут дела. :) Так и и пролог. Проблема не в нем, а в природе логики.
Неновые языки тоже иногда задают очень непростую связь с peaльнocтью. Например, на языке APL согласно википедии всего в одну строчку можно напиcать игpу Жизнь Kонвeя — life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵} — нечто.
Язык TeX, будучи универсальным, порождает весьма интересные кoды даже для самых простых задач, например, расчета чисел Фибоначчи.
Вроде бы должно быть каждому понятно, что из описания нетривиальной задачи её эффективное решение не следует. Или, например, что связки И/ИЛИ на практике не коммутативны.
> А в выхлопе современных компиляторов, если вы найдёте использование регистров типа ah, bh, то это специальные готовые вставки на редчайшие особые случаи.
Это не так. Вот пример кода, где GCC генерирует использование второго байта регистра, например, BH.
char c;
register union {
int a;
char b[4];
} a;
c = a.b[1];
Есть результат: x86 — самые быстрые и с лучшим ПО (Linux на x86 также лучший) — всё остальное лирика. Поклоники VAX очень их и ARM не любят — сломали их малину. Когда-то и восстания луддитов были.:) ARM сейчас лучше только по энергопотреблению. Если бы у Acorn когда-то был посильнее менеджмент, то у них был шанс опрокинуть x86. Когда-то они также в СССР позорно проиграли с ICL 1900 в пользу IBM/360 — у нас решили лучше у американцев воровать, чем с честными англичанами иметь дело — нашли подход к «загадочной» русской душе. :) ARM-64 как и RISC-V какой-то более выхолощенный — не догнать с этим x86. Повторю, современный ARM развивается с оглядкой на Intel.
Это я неудачный пример взял, наспех. Там нужна константа более 255, а не 5. Со сложением как раз проблем (почти?) никогда нет — продумали они тут неплохо. Проблема в знаковом расширении, которое иногда сильно всё запутывает, например, при работе с таблицами. И, конечно, BISB, а не ORB. :) В PDP-11 ассемблере много хорошего и сделали его ещё в 60-х!
x86 до сих пор в лидерах и частично потому, что более гибко, чем многие другие архитектуры умеет работать с байтами. 3ачем им быть на что-то ещё похожими? Сравните, например, 8086 и 68000. У ARM-32 встоенный в почти каждую команду barrel shifter, который даёт мгновенный доступ к каждому байту слова. У ARM-64 с этим хуже и, возможно, что так Intel ослабляет конкуренцию c x86. ARM смог перегнать х86 в 80-х и в 1996. После второго успеха Intel просто купила эту технологию и стала во-многом её определять.
Eщё пример вспомнил про неуклюжесть PDP-11 с байтами. Нужно считать байт из памяти и добавить к нему, например, 5. Число в памяти целое беззнаковое, может быть более 127. Самое лучшее, что придумал, — это CLR R1; ORB mem,R1; ADD data,R1
[6502] С фортом это не я придумал, так лучшие в мире 6502-программисты решили. Можете посмотреть конкретные коды по ссылке (там можно поискать слово fetch).
[PDP-11] Рассмотрим, например, CMPB #2,R1. Для байтовой константы 2 будет выделено слово (а не байт) и так будет верно для всех операций с байтовыми константами. В самом ассемблере неуклюжести это не вызывает, но если смотреть на машинные коды, то лишний 0 — это как пятое колесо. И когда памяти так мало, всего 32КБ — этот ноль чувствуется сильно. Не получится ещё без неуклюжести сравнить старший байт R1 с той же 2.
Промежуточные коммиты? Но они же все равно потом пойдут в общий репозиторий, если это коммиты, а не сташи. Штучек, ломающих репозитории, ради поправок в «неправильных» коммитах немало везде. Извините, но у меня представление такое, если не работает сервер, то это в 99% случаях не работает сеть. Никакой нормальной работы сегодня или даже 5 лет назад без сети не представить. Но если случится 1%, когда именно просел на часок-другой только сервер, и очень хочется сделать коммит, то из-за редкостной диковинности такой ситуации можно чуть-чуть побольше сделать, а именно скопировать каталог для его дальнейшей отправки на сервер, когда тот заработает, — неудобство, но редкое и незначительное. GIT интересный инструмент, действительно, учитывающий очень много тонкостей, но это не значит, что другие VCS как-то хуже, они — другие. DVCS реально повышают надежность, особенно больших проектов типа ядра Linux и это очень существенно, но есть и другие способы повышать надёжность.
Извинит, но зачем нужна бумажная, если только не на подарок под старину?
Не могу с таким согласиться. Существует достаточно много перспективных проектов вокруг пролога. Пролог — универсальный язык и на нём можно делать всё, что, например, на питоне. Может просто нужен кто-нибудь типа Гвидо, который сделает популярный вариант пролога. Скорость работы хороших прологов на уровне языков сценариев. Мне кажется полезность-перспективность и текущая массовая популярность — это разные вещи. Мое мнение — пролог это один из самых простых и близких к естественному языков программирования. К сожалению, приходится до сих пор больше работать сo скорее с потомками фортрана. :(
Вы похоже склоняетесь к точке зрения оппонента, что декларативность гарантирует поиск результата. Но это так только в случае действительно 100% точного описания задачи. Порядок дизъюнктов — это один из элементов такой точности.
Язык TeX, будучи универсальным, порождает весьма интересные кoды даже для самых простых задач, например, расчета чисел Фибоначчи.
Это не так. Вот пример кода, где GCC генерирует использование второго байта регистра, например, BH.
char c;
register union {
int a;
char b[4];
} a;
c = a.b[1];
Есть результат: x86 — самые быстрые и с лучшим ПО (Linux на x86 также лучший) — всё остальное лирика. Поклоники VAX очень их и ARM не любят — сломали их малину. Когда-то и восстания луддитов были.:) ARM сейчас лучше только по энергопотреблению. Если бы у Acorn когда-то был посильнее менеджмент, то у них был шанс опрокинуть x86. Когда-то они также в СССР позорно проиграли с ICL 1900 в пользу IBM/360 — у нас решили лучше у американцев воровать, чем с честными англичанами иметь дело — нашли подход к «загадочной» русской душе. :) ARM-64 как и RISC-V какой-то более выхолощенный — не догнать с этим x86. Повторю, современный ARM развивается с оглядкой на Intel.
[PDP-11] Рассмотрим, например, CMPB #2,R1. Для байтовой константы 2 будет выделено слово (а не байт) и так будет верно для всех операций с байтовыми константами. В самом ассемблере неуклюжести это не вызывает, но если смотреть на машинные коды, то лишний 0 — это как пятое колесо. И когда памяти так мало, всего 32КБ — этот ноль чувствуется сильно. Не получится ещё без неуклюжести сравнить старший байт R1 с той же 2.