Мрія про декларативне програмування [закрито]

Чому не здійснилася мрія про декларативне програмування? Які конкретні перешкоди стають на шляху? Напростий приклад, чому я не можу сказати

sort(A) is defined by sort(A) in perm(A) && asc(sort(A))

і автоматично отримувати з нього алгоритм сортування. permозначає перестановки та ascзасоби висхідної.

Є кілька дуже хороших відповідей. Я спробую внести свій внесок у дискусію.

На тему декларативного, логічного програмування в Пролозі виходить чудова книга Річарда О'Кіф "Ремесло Пролога" . Йдеться про написання ефективних програм за допомогою мови програмування, яка дозволяє писати дуже неефективні програми. У цій книзі, обговорюючи ефективні реалізації декількох алгоритмів (у розділі "Методи програмування"), автор застосовує такий підхід:

• визначте проблему англійською мовою
• написати робоче рішення, яке є максимально декларативним; зазвичай це означає саме те, що ви маєте у своєму питанні, просто виправте Пролог
• звідти вживайте заходів, щоб удосконалити реалізацію, щоб зробити її швидшою

Найяскравіше (для мене) спостереження, яке я зміг зробити під час роботи над цим:

Так, остаточна версія реалізації набагато ефективніша, ніж "декларативна" специфікація, з якої розпочався автор. Це все ще дуже декларативно, лаконічно і легко зрозуміти. Між тим, що сталося між ними, це те, що остаточне рішення фіксує властивості проблеми, про яку початкове рішення не було в курсі.

Іншими словами, впроваджуючи рішення, ми використали якомога більше наших знань про проблему. Порівняйте:

Знайдіть перестановку списку таким чином, щоб усі елементи знаходились у порядку зростання

до:

Об'єднання двох відсортованих списків призведе до відсортованого списку. Оскільки можуть бути вже відсортовані підсписи, використовуйте їх як вихідну точку замість списків довжиною 1.

Невелика сторона: таке визначення, як те, що ви дали, є привабливим, оскільки воно дуже загальне. Однак я не можу уникнути відчуття, що цілеспрямовано ігнорує той факт, що перестановки є, ну, комбінаторною проблемою. Це те, що ми вже знаємо ! Це не критика, а лише спостереження.

Щодо справжнього питання: як рухатись вперед? Ну, один із способів - дати якомога більше знань про проблему, яку ми декларуємо на комп’ютері.

Найкраща мені спроба реально вирішити проблему представлена ​​в книгах Олександра Степанова в співавторстві «Елементи програмування» та «Від математики до загального програмування» . Мені, на жаль, не підходить підсумовувати (або навіть повністю розуміти) все, що є в цих книгах. Однак підхід існує для визначення ефективних (або навіть оптимальних) бібліотечних алгоритмів та структур даних, за умови, що всі відповідні властивості вводу відомі заздалегідь. Кінцевий результат:

• Кожна чітко визначена трансформація - це уточнення обмежень, які вже існують (властивості, які відомі);
• Ми дозволяємо комп'ютеру вирішити, яке перетворення оптимальне виходячи з існуючих обмежень.

Що стосується того, чому це ще не зовсім сталося, ну, інформатика - це справді молода сфера, і ми все ще справляємося з по-справжньому цінуючи новизну більшості.

PS

Щоб дати вам смак того, що я маю на увазі під «вдосконаленням реалізації»: візьміть, наприклад, просту проблему отримання останнього елемента списку, в Prolog. Канонічне декларативне рішення полягає в тому, щоб сказати:

last(List, Last) :-
    append(_, [Last], List).

Тут декларативне значення append/3:

List1AndList2є конкатенація List1іList2

Оскільки у другому аргументі у append/3нас є список лише з одним елементом, а перший аргумент ігнорується (підкреслення), ми отримуємо розкол вихідного списку, який відкидає передню частину списку ( List1у контексті append/3) та вимагає зворотна List2частина ( в контексті append/3) - це справді список із лише одним елементом: значить, це останній елемент.

Фактична реалізація забезпечується SWI-Prolog , однак, каже:

last([X|Xs], Last) :-
    last_(Xs, X, Last).

last_([], Last, Last).
last_([X|Xs], _, Last) :-
    last_(Xs, X, Last).

Це все ще гарно декларативно. Прочитайте зверху донизу, там написано:

Останній елемент списку має сенс лише для переліку щонайменше одного елемента. Останнім елементом пари хвоста та головки списку є: голова, коли хвіст порожній, або останній із непустого хвоста.

Причиною, по якій надається така реалізація, є обхід практичних питань, пов'язаних із моделлю виконання Prolog. В ідеалі він не повинен змінювати, яка реалізація використовується. Так само ми могли б сказати:

last(List, Last) :-
    reverse(List, [Last|_]).

Останній елемент списку - це перший елемент зворотного списку.

Якщо ви хочете отримати непереконливу дискусію про те, що добре, декларативний Prolog, просто перегляньте деякі питання та відповіді в тезі Prolog на стеку Overflow .

Логічні мови вже роблять це. Ви можете визначити сортування аналогічно тому, як ви це робите.

Основна проблема - продуктивність. Комп'ютери можуть бути чудовими в обчисленні багатьох речей, але вони по суті німі. Кожне "розумне" рішення, яке може прийняти комп'ютер, програмувало в нього програміст. І це рішення зазвичай описується не тим, як виглядає кінцевий результат, а тим, як досягти, крок за кроком, цього кінцевого результату.

Уявіть історію про Голема . Якщо ви спробуєте дати йому абстрактну команду, то в кращому випадку він зробить це неефективно і в гіршому випадку завдасть шкоди собі, вам чи комусь іншому. Але якщо ви опишите те, що хочете, якомога детальніше, ви гарантуєте, що завдання буде виконано ефективно та ефективно.

Завдання програміста вирішувати, який рівень абстракції використовувати. За додаток, яке ви робите, збираєтесь вийти на високий рівень і описати його абстрактним чином і приймати хіт продуктивності або знизитись та забруднити, витратити на це в 10 разів більше часу, але отримаєте алгоритм, який на 1000 разів ефективніший?

На додаток до чудового моменту Euphoric , я хотів би додати, що ми вже використовуємо декларативні мови в багатьох місцях, де вони працюють добре, тобто описують стан, який, мабуть, не зміниться або запитає те, для чого комп'ютер насправді може генерувати ефективний код самостійно:

• HTML оголошує, який вміст веб-сторінки.

• CSS оголошує, як мають виглядати різні типи елементів на веб-сторінці.

• Кожна реляційна база даних має мову визначення даних, яка декларує структуру бази даних.

• SQL набагато ближче до декларативного, ніж імперативного, оскільки ви розповідаєте, що ви хочете бачити, і планувальник запитів бази даних з'ясовує, як насправді це зробити.

• Можна стверджувати, що більшість файлів конфігурації (.vimrc, .profile, .bashrc, .gitconfig) використовують мову, що залежить від домену, яка значною мірою є декларативною.

Абстракції є герметичними

Ви можете реалізувати декларативну систему, де ви заявляєте, що хочете, а упорядник чи тлумач визначає порядок виконання. Теоретична перевага полягає в тому, що це звільняє вас від думки про "як", і вам не потрібно деталізувати цю реалізацію. Однак на практиці для загальних обчислень потрібно все-таки думати про "як" і писати всілякі хитрощі, маючи на увазі, як це буде реалізовано, оскільки в іншому випадку компілятор може (і часто буде) обирати реалізацію, яка буде дуже, дуже, дуже повільно (наприклад, n! операцій, де n вистачить).

У вашому конкретному прикладі, ви отримаєте A алгоритму сортування - це не означає , що ви отримаєте хороший або навіть кілька корисних один. Ваша задана дефініція, якщо вона буде реалізована буквально (як це можливо), призводить до http://en.wikipedia.org/wiki/Bogosort, яка непридатна для великих наборів даних - це технічно правильно, але їй потрібно вічність, щоб сортувати тисячу чисел .

Для деяких обмежених доменів ви можете написати системи, які майже завжди добре допомагають з'ясувати хорошу реалізацію, наприклад, SQL. Для обчислень загального призначення, які не працюють особливо добре - ви можете записувати системи в, скажімо, Prolog, але ви повинні візуалізувати, як саме ваші декларації будуть зрештою перетворені на імперативне замовлення виконання, і це втратить велику частину очікуваного декларативного переваги програмування.

Обчислювальна здатність - це найважливіша причина, чому декларативне програмування не виявилося таким простим, як здається.

Багато проблем, які досить легко констатувати, виявилися невирішеними або мають складну комплексну проблему для вирішення. Це часто трапляється, коли ми враховуємо негативні класи та класифікацію, підрахунковість та рекурсію.

Я хотів би пояснити це деякими доменами, які добре відомі.

Рішення про те, який клас CSS використовувати, потребує знання та врахування всіх правил CSS. Додавання нових правил може визнати недійсними всі інші рішення. Негативні класи CSS навмисно не додаються до мови через неповні проблеми, але відсутність негативних класів ускладнює дизайнерські рішення CSS.

У оптимізаторі запитів (SQL) існує непросте завдання вирішити, в якому порядку приєднатися, які індекси використовувати та яку пам'ять виділити тимчасовим результатам. Це відома NP-повна проблема і ускладнює розробку баз даних та формулювання запитів. Щоб сформулювати це по-іншому: розробляючи базу даних або запит, дизайнеру необхідно знати дії та порядок дій, які, скоріш за все, здійснює оптимізатор запитів. Досвідченому інженеру потрібні знання евристики, що використовується великими постачальниками баз даних.

Файли конфігурації декларативні, але певні конфігурації важко оголосити. Наприклад, для правильної настройки функцій потрібно враховувати версії, розгортання (та історію розгортання), можливі зміни вручну та можливі конфлікти з іншими налаштуваннями. Правильна перевірка конфігурації може стати проблемою, що не стосується NP.

Результат полягає в тому, що ці ускладнення сприймають початківців несподівано, вони порушують «красу» декларативного програмування і змушують деяких інженерів шукати інші рішення. Міграція недосвідчених інженерів із SQL в NoSQL могла бути спровокована основними складностями реляційних баз даних.

Ми маємо різницю в декларативності мов програмування, яка корисно використовується для перевірки цифрової логіки.

Зазвичай цифрова логіка описується на рівні передачі регістра (RTL), де визначається логічний рівень сигналів між регістрами. Щоб перевірити, чи ми все більше додаємо властивості, визначені більш абстрактно та декларативно.

Однією з декларативних мов / підмножин мови називається PSL для мови властивостей властивостей. При тестуванні RTL-моделі множника, в якій, наприклад, потрібно вказати всі логічні операції зсуву та додавання протягом декількох тактових циклів; ви можете записати властивість в образі assert that when enable is high, this output will equal the multiplication of these two inputs after no more than 8 clock cycles. Опис PSL може потім перевірятися разом з RTL в рамках моделювання, або PSL може бути офіційно доведено, що він відповідає опису RTL.

Більш декларативна модель PSL змушує описати таку ж поведінку, що й опис RTL, але досить іншим способом, який можна автоматично перевірити проти RTL, щоб побачити, чи вони згодні.

Переважно проблема полягає в тому, як ви моделюєте дані; і декларативне програмування тут не допомагає. Імперативними мовами у вас вже є багато бібліотек, які роблять для вас багато матеріалів, тому вам потрібно лише знати, як зателефонувати. Особливо можна розглянути це декларативне програмування (мабуть, найкращий приклад для цього - Stream API на Java 8 ). Маючи це, абстракція вже вирішена, а декларативне програмування не потрібне.

Крім того, як було сказано, мови логічного програмування вже роблять саме те, що ви хочете. Можна сказати, що проблема полягає в продуктивності, але з сьогоднішнім обладнанням та дослідженнями в цій галузі все можна покращити, щоб бути готовим до використання у виробництві; насправді Prolog використовується для ШІ, але я вірю лише академіям.

Слід зазначити, що він застосовується для мов програмування загального призначення. Для доменних мов декларативні мови значно кращі; SQL, мабуть, найкращий приклад.

Це виглядатиме приблизно так .. {(що-небудь => читати файл і викликати URL) | зателефонуйте за URL-адресою та прочитайте файл} Однак це виконання, і стан системи в результаті змінюється, але це не очевидно з джерела.

Декларації можуть описати машину з кінцевим станом та її переходи. FSM - це як протилежність декларацій без дій, навіть якщо єдиною дією є зміна стану на наступний стан.

Перевага використання цього методу полягає в тому, що переходи та дії можуть бути визначені предикатами, які застосовуються до декількох переходів, а не лише до одного.

Я знаю, що це звучить трохи дивно, але в 2008 році я написав генератор програм, який використовує цей метод, і сформований C ++ в 2–15 разів більше, ніж джерело. Зараз у мене понад 75 000 рядків C ++ з 20 000 рядків введення. З цим ідуть дві речі: послідовність і повнота.

Послідовність: Жоден два предикати, які можуть бути істинними одночасно, не можуть означати непослідовних дій, як і x = 8, і x = 9, ні різні наступні стани.

Повнота: Логіка кожного переходу стану задана. Це може бути важко перевірити для систем з N підзаголовок із станами> 2 ** N, але є цікаві комбінаторні методи, які можуть все перевірити. У 1962 році я написав фазу 1 сортування системи для машин 7070, використовуючи цей тип генерації умовного коду та комбінаторну налагодження. З 8000 рядків у своєму роді кількість помилок з дня першого випуску назавжди дорівнювала нулю!

Друга фаза, 12000 рядків, мала понад 60 помилок за перші два місяці. Про це можна сказати набагато більше, але це працює. Якби виробники автомобілів використовували цей метод для перевірки прошивки, ми не побачили б збоїв, які ми бачимо зараз.

Не все можна представити декларативно.

Часто ви точно хочете контролювати хід виконання

Наприклад, наступний псевдо-код: if whatever read a file call an URL else call an URL write a file Як би ви це декларативно представляли?

Звичайно, є, мабуть, деякі екзотичні способи зробити це. Як монади . Але вони, як правило, більш громіздкі, складні та набагато менш інтуїтивні, ніж їхня процесуальна частина.

Все зводиться до того, що "взаємодія" з вашим оточенням / системою не є декларативним. Все, що стосується вводу-виводу, є по суті процедурним. Ви повинні точно сказати, коли і що повинно відбутися, і в якому порядку.

Декларатив чудово підходить для всього, що суто пов'язане з обчисленням. Як гігантська функція, ви ставите X і отримуєте Y. Це чудово. Прикладом цього є HTML, введення - текст, вихід - те, що ви бачите у своєму браузері.