Я помітив, що мені набагато простіше записати математичні докази, не допускаючи помилок, ніж записати комп’ютерну програму без помилок.

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

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

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

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

Отже, це змусило мене задати питання: Що настільки відрізняється від написання бездоганних математичних доказів та написання безвідмовного комп’ютерного коду, що робить його таким, що перший є набагато більш простежуваним, ніж другий?

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

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

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

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

Це означає, що процедура перевірки помилок у математичному доведенні по суті лінійна за кількістю етапів доказування, але процедура перевірки помилок у комп'ютерному коді по суті є експоненціальною у кількості рядків коду.

Що ти думаєш?

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

Дозвольте запропонувати одну причину та одну помилкову думку як відповідь на ваше запитання.

Основна причина , що простіше писати ( по- видимому) правильні математичні докази, що вони написані на дуже високому рівні. Припустимо, ви могли написати програму так:

function MaximumWindow(A, n, w):
    using a sliding window, calculate (in O(n)) the sums of all length-w windows
    return the maximum sum (be smart and use only O(1) memory)

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

Справжній аналог коду математичних доказів - це комп'ютерні докази . Це набагато складніше розробити, ніж звичайні текстові докази, і часто можна виявити різні приховані куточки, які "очевидні" для читача (який зазвичай навіть не помічає їх), але не такі очевидні для комп'ютера. Крім того, оскільки комп’ютер може заповнити лише невеликі прогалини в даний час, докази повинні бути розроблені до такого рівня, що людина, що їх читає, пропустить ліс за деревами.

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

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

(Я, мабуть, ризикую тут декількома зворотними коментарями, оскільки у мене немає часу / інтересу зробити це належною відповіддю, але я вважаю, що цитований (і решта цитованої статті) нижче є досить проникливим, також враховуючи, що вони написані відомим математиком. Можливо, я можу вдосконалити відповідь пізніше.)

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

Стандарт правильності та повноти, необхідний для того, щоб комп'ютерна програма взагалі працювала, на пару порядків вища, ніж стандарт математичних спільнот, що підтверджують дійсні докази. Тим не менш, великі комп'ютерні програми, навіть коли вони були дуже ретельно написані і дуже ретельно перевірені, завжди здаються помилками. [...] Математика, як ми практикуємо, набагато формально повніша і точніша, ніж інші науки, але формально набагато менш повна і точна за своїм змістом, ніж комп'ютерні програми. Різниця стосується не лише кількості зусиль: вид зусиль якісно відрізняється. У великих комп'ютерних програмах необхідно витратити величезну кількість зусиль для безлічі питань сумісності: переконання у відповідності всіх визначень, вироблення "хорошого" структури даних, які мають корисну, але не громіздку спільність, вирішуючи "правильну" загальність для функцій тощо. Частка енергії, витраченої на робочу частину великої програми, на відміну від бухгалтерської частини, напрочуд мала. Через проблеми сумісності, які майже неминуче переживають нестабільність, оскільки «правильні» визначення змінюються в міру додавання загальності та функціональності, комп'ютерні програми, як правило, потрібно переписувати часто, часто з нуля.

ПРО ДОКАЗ І ПРОГРАМ В МАТЕМАТИКІ (с. 9-10), автор WILLIAM P. THURSTON https://arxiv.org/pdf/math/9404236.pdf

Дозвольте почати, цитуючи EW Dijkstra:

"Програмування - одна з найскладніших галузей прикладної математики; біднішим математикам краще залишатися чистими математиками". (від EWD498)

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

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

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

Отже, ви не повинні дивуватися, якщо правильні докази відносно відмовлені: це сенс усієї "вправи". (Все-таки це не означає, що помилки не існують або ледве існують. Помилка - це лише людина, - кажуть вони)

Тепер, якщо ми розглядаємо програмування, то яка наша мета? Ми не дуже шукаємо розуміння, хочемо чогось, що працює . Але коли щось "працює"? Щось працює, коли ми успішно створили щось, що дозволяє якійсь дивній машині виконати завдання, яке ми хочемо зробити, і, бажано, теж швидко.

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

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

Зауважте, що ваша гіпотеза писати докази без помилок простіше, ніж програми без помилок (які насправді різні твердження, як вказує @Ariel ) можуть насправді помилятися, оскільки докази часто будуються шляхом спроб та помилок на якомусь рівні. І все-таки я сподіваюся, що це проливає світло на питання, яке мається на увазі: "Яка насправді різниця між доведенням якоїсь теореми і написанням програми?" (На що недбайливий спостерігач листування Кері-Говарда може сказати: "Нічого!"

Як згадується в коментарях @wvxvw, наступні параграфи з "приміток про структуроване програмування" (EWD249, стор. 21) є дуже актуальними:

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

(...) У певному сенсі скласти програму важче, ніж створення математичної теорії: і програма, і теорія є структурованими, позачасовими об'єктами. Але хоча математична теорія має сенс, як вона є, програма має сенс лише через її виконання.

Лампорт дає певні підстави для розбіжностей щодо поширеності помилок у доказуванні в Як написати доказ (стор. 8-9) :

Десь двадцять років тому я вирішив написати доказ теореми Шредера-Бернштейна для вступного класу з математики. Найпростіший доказ, який я міг знайти, був у класичному тексті загальної топології Келлі. Оскільки Келлі писав для більш досконалої аудиторії, мені довелося додати багато пояснень до його доказу на півсторінках. Я написав п'ять сторінок, коли зрозумів, що докази Келлі були невірними. Нещодавно я хотів проілюструвати лекцію про свій стиль доказування переконливим неправильним доказом, тому я звернувся до Келлі. Я не міг знайти нічого поганого з його доказом; здавалося явно правильним! Читання та перечитування доказів переконувало мене, що або моя пам’ять вийшла з ладу, або я був дуже дурний двадцять років тому. Тим не менш, доказ Келлі був коротким і він послужив би приємним прикладом, тому я почав переписувати це як структурований доказ.

... Стиль вперше застосовано до доказів звичайних теорем у роботі, яку я написав з Мартіном Абаді. Він уже писав звичайні докази - докази, які були досить хорошими, щоб переконати нас і, імовірно, арбітрів. Переписуючи докази в структурованому стилі, ми виявили, що майже кожен мав серйозні помилки, хоча теореми були правильними. Будь-яка надія, що неправильні докази можуть не призвести до неправильних теорем, була знищена в нашій наступній співпраці. Раз і знову ми робимо домисел і пишемо на дошці доказний ескіз - ескіз, який легко можна було б перетворити на переконливий загальнодоказний доказ - лише щоб виявити, намагаючись написати структурований доказ, що гіпотеза була помилковою. З тих пір я ніколи не вірив результату без ретельного, структурованого доказу.

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

Порівняйте це з комп'ютерною програмою, яка повинна забезпечити «правильний» вихід для ряду можливих входів. Рідко можна перерахувати всі дані та спробувати їх усі. Що ще гірше, припустимо, що програма взаємодіє з людиною і дозволяє їх внеску змінити функціонування? Людські істоти, як відомо, непередбачувані, і кількість можливих внесків до досить великої програми з людською взаємодією зростає з величезними темпами. Вам потрібно спробувати передбачити всі різні способи використання програми та спробувати зробити так, щоб усі ці випадки використання або працювали, або принаймні виходили з ладу розумним способом, коли збій - єдиний варіант. І це припускаючи, що ви навіть знаєте, як це має працювати в усіх тих незрозумілих кутових випадках.

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

Вони кажуть, що проблема з комп’ютерами полягає в тому, що вони роблять саме те , що ви їм скажете.

Я думаю, це може бути однією з багатьох причин.

Зауважте, що з комп'ютерною програмою автор (ви) розумний, але читач (процесор) німий.
Але з математичним доказом письменник (ви) розумний, а читач (рецензент) також розумний.

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

Наприклад, скажімо, що це крок у доказ:

$x^2+4x+3$$x+3$$x = -3$

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

$n$$n!$

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

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

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

Я вважаю, що основними причинами є ідемпотенція (дає однакові результати для тих же входів) та незмінність (не змінюється).

Що робити, якщо математичний доказ може дати різні результати, якщо він був прочитаний у вівторок або коли рік поступив до 2000 року з 1999 року? Що робити, якщо частиною математичного доказу було повернутись на кілька сторінок, переписати кілька рядків і знову почати з цього пункту?

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

Я бачу й інші вторинні фактори:

1. Математики, як правило, набагато освіченіші, перш ніж намагатися написати вагомий / оприлюднений доказ. 1/4 однойменних професійних розробників почали кодувати менше 6 років тому (див. Опитування SO 2017 ), але я припускаю, що більшість математиків мають понад десятиліття формальної математичної освіти.
2. Математичні докази рідко тримаються на такому ж рівні уваги, як і комп'ютерний код. Один друкарський помилок може / порушить програму, але десятків помилок помилок може бути недостатньо, щоб знищити цінність доказу (лише його читабельність).
3. Чорт у деталях, а комп'ютерний код не може пропустити деталі. Докази можуть пропускати кроки, які вважаються простими / звичайними. Є кілька приємних синтаксичних цукрів, доступних у сучасних мовах, але вони жорстко кодовані та досить обмежені порівняно.
4. Математика старша і має більш міцну основу / ядро. Звичайно, в математиці є безліч нових і блискучих підполів, але більшість основних принципів використовуються десятиліттями. Це призводить до стабільності. З іншого боку, програмісти все ще не згодні з базовою методологією кодування (просто запитайте про розробку Agile та швидкість її прийняття).

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

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

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

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

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

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

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

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

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

1 Математичні докази, як правило, набагато простіші, ніж комп'ютерні програми. Розглянемо перші кроки гіпотетичного доказу:

Нехай ціле число

Нехай b - ціле число

Нехай c = a + b

Поки доказ чудовий. Давайте перетворимо це на перші кроки подібної програми:

Нехай a = вхід ();

Нехай b = вхід ();

Нехай c = a + b;

У нас вже безліч проблем. Припускаючи, що користувач дійсно ввів ціле число, ми повинні перевірити межі. Є чи більше , ніж -32768 (або що - то мінімальне ІНТ на вашій системі)? Є менш ніж 32767? Тепер ми повинні перевірити те саме, що і для b . І тому, що ми додали a і b, програма не є правильною, якщо не є bбільше -32768 і менше 32767. Це 5 окремих умов, що програміст повинен турбуватися з приводу того, що математик може ігнорувати. Мало того, що програміст повинен переживати за них, він повинен зрозуміти, що робити, коли одна з цих умов не виконаний, і написати код, щоб зробити той, хто вирішив, це спосіб вирішити ці умови. Математика проста. Програмування важко.

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

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

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

• Функції в Math чисті (весь результат виклику функції повністю інкапсульований у зворотному значенні, яке детерміновано та обчислюється повністю із вхідного значення).
• У математиці немає мутації чи переназначення (коли потрібно моделювати такі речі, використовуються функції та послідовності).
• Математика є референтно прозорою (наприклад, немає вказівників, не існує поняття "за назвою" ("call-by-name vs call-by-value"). Математичні об'єкти мають семантику розширення рівності (якщо "дві" речі однакові у кожному спостережуваному способі, то вони є насправді Те ж саме).

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

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

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

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

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

Існують проблеми з пам’яттю, продуктивністю та обладнанням, якими можна керувати. Я хотів би, щоб ми не могли думати про тих, коли писали алгоритми, щоб ми могли використовувати чисті та функціональні конструкції для управління цим, але комп'ютерні програми живуть у "реальному" світі апаратних засобів, тоді як математичне доказ лежить у "теорії".

Або, щоб бути більш лаконічним :

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

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

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

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

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

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

Я з таким настроєм хотів би звернути увагу читача на той факт, що "ясність" має яскраво виражені кількісні аспекти, що багато математиків, як ні цікаво, здається, не знають. Теорема, що вказує на обґрунтованість висновку, коли виконано десять сторінок, що переповнені умовами, навряд чи є зручним інструментом, оскільки всі умови повинні бути перевірені, коли теорема звертається до неї. В евклідовій геометрії теорема Піфагора дотримується для будь-яких трьох точок A, B і C таким чином, що через A і C пряму можна провести ортогональною до прямої через B і C. Скільки математиків оцінюють, що теорема залишається застосовною, коли деяка або всі точки A, B і C збігаються? але це здається значною мірою відповідальним за зручність використання теореми Піфагора.

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

Це трохи відредаговані останні три абзаци з першої глави Структурного програмування Дійкстри.

Щоб перефразувати це, краще застосувати до свого питання: правильність багато в чому залежить від розміру вашого доказу. Коректність довгих математичних доказів дуже важко встановити (багато опублікованих "доказів" живуть у кінцівці невизначеності, оскільки насправді їх ніхто не перевіряв). Але, якщо порівнювати правильність тривіальних програм з тривіальними доказами, різниці, ймовірно, немає. Однак автоматизовані помічники доказування (у більш широкому розумінні ваш компілятор Java також є помічником доказування), нехай програми виграють, автоматизуючи багато основної роботи.

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

Аналогічна ситуація була б, якби математик використовував існуючі докази та леми, не повністю розуміючи їх; їхні власні докази, ймовірно, будуть хибними. Хоча це може запропонувати рішення - ідеально вивчити кожну бібліотеку, якою користується; це практично забирає багато часу і може зажадати знань про домен у програміста (я знаю дуже мало послідовності ДНК / синтезу білка; але я можу працювати з цими концепціями за допомогою бібліотек).

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

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

Програми - докази

Ізоморфізм Каррі-Говарда говорить нам, типи в програмі є теореми і фактичний код є їх доказ.

Справді, це дуже абстрактний погляд на високому рівні. Ви, мабуть, маєте на увазі те, що писати типовий код важче, оскільки він стає занадто низьким. У більшості випадків вам потрібно "сказати машині, що робити". Або поглянути на це з іншого боку: математики справді добре абстрагуються.

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

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

$\pi$

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

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

І справді, математика може отримати BSOD! Це було б не перший раз!

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

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

Не будемо занадто шкодувати і Гільберта , він знав, в що потрапляє. Це просто бізнес.

Якщо ви хочете бути справді впевненими, візьміть все в кожному конкретному випадку і зробіть власні висновки!

Я бачу дві важливі причини, чому програми більше схильні до помилок, ніж математичні докази:

1: Програми містять змінні або динамічні об'єкти, що змінюються з плином часу, тоді як математичні об'єкти в доказах зазвичай є статичними. Таким чином, позначення з математики можна використовувати як пряму підтримку міркувань (і якщо a = b, це залишається у випадку), коли це не працює в програмах. Крім того, ця проблема стає набагато гіршою, коли програми паралельні або мають декілька потоків.

2: Математика часто передбачає відносно акуратно визначені об'єкти (графіки, колектори, кільця, групи тощо), тоді як програмування стосується дуже брудних та досить нерегулярних об'єктів: арифметики з обмеженою точністю, кінцевих стеків, перетворення символів на цілі числа, покажчики, сміття, яке потребує збору тощо. Тому колекцію умов, що стосуються правильності, дуже важко пам'ятати.

Вам слід розрізняти дві різні "категорії":

• псевдодокази (або псевдокоди) - ось що ви бачите в книгах. Він написаний природною мовою (наприклад, англійською). Саме це і слід використовувати для вивчення математики (або алгоритмів).
• формальні докази (або формальний код) - ви пишете їх, коли вам потрібно, щоб ваш доказ (або код) був механічно перевірений (або виконаний). Таке представництво не потребує ніякого «людського інтелекту». Це можна перевірити (або виконати) механічно, дотримуючись деяких заздалегідь визначених кроків (зазвичай це робиться на комп’ютерах сьогодні).

Ми використовуємо псевдо-код вже тисячі років (наприклад, алгоритм Евкліда). Написання формального коду (на формальних мовах, таких як C або Java) стало надзвичайно популярним і корисним після винаходу комп'ютерів. Але, на жаль, формальні докази (у формальних мовах, таких як Principia Mathematica або Metamath) не дуже популярні. І оскільки сьогодні всі псевдокази пишуть, люди часто сперечаються про нові докази. Помилки в них можна виявити через роки, десятиліття чи навіть століття після фактичного «доведення».

Я не можу знайти посилання, але я думаю, що Тоні Хоар одного разу сказав щось наступним чином: Відмінність перевірки програми та перевірки доказу полягає в тому, що доказ можна перевіряти два рядки одночасно.

Одним словом: місцевість.

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

Розглянемо цю програму, де x - лише для читання

    assume x >= 0
    p := 0 ;
    var pp := 0 ;
    while( x >= pp + 2*p + 1 ) 
    {
        var q := 1 ;
        var qq := q ;
        var pq := p ;
        while(  pp + 4*pq + 4*qq <= x )
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

Це легко виконати, але важко перевірити.

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

    assume x >= 0
    p := 0 ;
    var pp := 0 ; 
    while( x >= pp + 2*p + 1 ) 
        invariant p*p <= x 
        invariant pp == p*p
        decreases x-p*p 
    {
        var q := 1 ;
        var qq := q ; 
        var pq := p ; 
        while(  pp + 4*pq + 4*qq <= x )
            invariant (p+q)*(p+q) <= x
            invariant q > 0 
            invariant qq == q*q 
            invariant pq == p*q 
            decreases x-(p+q)*(p+q)
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        assert (p+q)*(p+q) <= x and pp==p*p and pq==p*q and qq==q*q and q>0
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

Повертаючись до початкового запитання: Чому записування математичних доказів є більш відмовними, ніж написання комп'ютерного коду? Оскільки докази призначені для того, щоб їх читачі легко перевірили, їх автори легко перевіряють, і таким чином попереджають авторів, як правило, не допускають (або принаймні зберігають) логічних помилок у своїх доказах. Програмуючи, ми часто не можемо записати причину правильності нашого коду; результат полягає в тому, що і читачам, і автору програми важко перевірити код; результат полягає в тому, що автори роблять (а потім зберігають) помилки.

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

Ми могли б запитати, чи складніше на практиці чи в принципі писати докази чи писати код.

На практиці довести набагато важче, ніж кодування. Дуже мало людей, які пройшли два роки математики на рівні коледжу, можуть написати докази, навіть тривіальні. Серед людей, які пройшли два роки навчання на рівні коледжу, мабуть, принаймні 30% можуть вирішити FizzBuzz .

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

Лише невелика частина математичних тверджень, які є правдивими, може бути практично доведена. Більш суттєво неможливо побудувати нетривіальну (*) множину математичних аксіом, яка дозволила б довести всі справжні твердження. Якщо потрібно лише написати програми, щоб зробити невелику частину речей, які можна було б зробити з комп’ютерами, можна було б написати програмно-коректно програмне забезпечення, але комп'ютери часто закликають робити речі, що виходять за рамки того, що доказово правильно програмне забезпечення може виконати.

(*) Можна визначити набір аксіом, який дозволив би перерахувати і таким чином довести всі справжні твердження, але вони, як правило, не дуже цікаві. Хоча офіційно можна класифікувати набори аксіом на ті, які є, чи ні, відносно кажучи, нетривіальними, ключовим моментом є те, що доказове існування тверджень, які є правдивими, але неможливо довести, не є вадою набору аксіом. Якщо додати аксіоми, щоб зробити будь-які існуючі правдиві, але неперевірені твердження, виправданими, інші твердження ставатимуть правдивими, але без них можна довести.

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

2. Комп'ютерні програми виконують корисні функції реального світу. Вони не повинні бути на 100% правильними, щоб зробити це, а високі норми коректності досить дорогі. Докази корисні лише в тому випадку, якщо вони насправді щось доводять, тому пропуск частини «100% правильної» не є можливим для математиків.

3. Математичні докази чітко визначені. Якщо доказ хибний, автор допустив помилку. Багато помилок у комп’ютерних програмах виникають через те, що вимоги не надто належним чином передані, або виникає проблема сумісності з тим, про що програміст ніколи не чув.

4. Багато комп'ютерних програм не можуть бути доведені правильними. Вони можуть вирішити неофіційно визначені проблеми, як-от розпізнавання облич. Або вони можуть бути схожими на програмне забезпечення для прогнозування фондового ринку і мають формально визначену мету, але передбачають занадто багато змінних у реальному світі.

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

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

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

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

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

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

Ви тут чесно порівнюєте яблука та апельсини. Несправність і помилка - це не одне і те ж.

Якщо програма порівнює числа, 2і 3це говорить про це 2 is greater than 3, то це може бути через помилку реалізації:

# Buggy implementation
function is_a_greater_than_b(a,b):
  return b > a

Програма все ще залишається без помилок. Якщо порівнювати два числа aі b, він завжди зможе сказати вам, чи bє більший за a. Це просто не те, що ви (програміст) повинні були попросити комп’ютер зробити.

а) Через те, що комп'ютерні програми більше, ніж математичні докази

a.1) Я вважаю, що під час написання складної комп’ютерної програми використовується більше людей, ніж під час написання математичного підтвердження. Це означає, що маржа помилок вище.

b) Оскільки керівники / акціонери більше піклуються про гроші, ніж виправлення невеликих помилок , тим часом ви (як розробник) повинні виконувати свої завдання, щоб відповідати деяким вимогам / термінам / демонстраціям

в) Оскільки ви можете бути програмістом без "глибоких" знань у галузі comp sci, тим часом це важко буде робити в математиці (я вважаю)

Додатково:

НАСА:

Це програмне забезпечення без помилок. Це ідеально, так само досконало, як досягли люди. Розглянемо цю статистику: в останніх трьох версіях програми - кожна 420 000 рядків - мала лише одна помилка. В останніх 11 версіях цього програмного забезпечення було загалом 17 помилок.

Оновіть програмне забезпечення, щоб шаттл мав змогу орієнтуватися на супутники Global Positioning Satelites, що змінює лише 1,5% програми або 6,366 рядків коду. Технічні умови для однієї зміни містять 2500 сторінок, об'єм товщі, ніж телефонна книга. Технічні умови для поточної програми заповнюють 30 томів та містять 40 000 сторінок.

https://www.fastcompany.com/28121/they-write-right-stuff

Основні рівні:

Для математики маємо:
2 + 3 = 5

Я дізнався про це, коли був дуже-дуже молодим. Я можу переглянути найосновніші елементи: два об’єкти та три об’єкти. Чудово.

Для комп'ютерного програмування більшість людей, як правило, використовують мову високого рівня. Деякі мови високого рівня можуть навіть "скластись" в одну з нижчих мов високого рівня, наприклад C. C потім може бути переведена на мову складання. Мова збірки потім перетворюється в машинний код. Багато людей думають, що на цьому складність закінчується, але це не так: Сучасні процесори приймають машинний код як інструкцію, а потім виконують "мікрокод", щоб фактично виконати ці інструкції.

Це означає, що на самому базовому рівні (маючи справу з найпростішими структурами) ми зараз маємо справу з мікрокодом, який вбудований в апаратне забезпечення і який більшість програмістів навіть не використовує безпосередньо, не оновлює. Насправді, не тільки більшість програмістів не торкаються мікрокоду (0 рівнів вище мікрокоду), більшість програмістів не торкаються машинного коду (на 1 рівень вище мікрокоду), навіть навіть складання (2 рівня вище мікрокоду) ( крім, мабуть, для трохи офіційного навчання під час коледжу). Більшість програмістів витратять час лише на 3 і більше рівні.

Крім того, якщо ми подивимось на збори (які настільки ж низькі, як зазвичай отримують люди), кожен окремий крок, як правило, зрозумілий людям, які пройшли навчання та мають ресурси для тлумачення цього кроку. У цьому сенсі збірка набагато простіша, ніж мова вищого рівня. Однак складання настільки просте, що виконання складних завдань або навіть посередніх завдань дуже стомлююче. Мови верхнього рівня звільняють нас від цього.

У законі про "зворотну інженерію" суддя заявив, що навіть якщо кодом теоретично можна обробляти один байт, сучасні програми включають мільйони байтів, тому для подібних записів (наприклад, копії коду) потрібно робити саме такі намагання бути здійсненним. (Тому внутрішня розробка не вважалася порушенням узагальненої норми закону про авторське право "не роби копій".) (Я, мабуть, думаю про створення несанкціонованих картриджів Sega Genesis, але, можливо, я думаю про щось, що було сказано під час справи "Ігровий джин". )

Модернізація:

Ви запускаєте код, призначений для 286? Або ви запускаєте 64-бітний код?

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

Стандарти використовуваних інструментів:

Мене навчили (товариш, який пройшов більш офіційне навчання комп'ютерному програмуванню, ніж я), що немає такого поняття, як компілятор C, що не потребує помилок, який би відповідав специфікаціям C. Це тому, що мова С в основному передбачає можливість використання нескінченної пам'яті для цілей стека. Очевидно, від такої неможливої ​​вимоги довелося відхилитися від того, коли люди намагалися зробити корисні компілятори, які працювали з фактичними машинами, які мають трохи більш обмежений характер.

На практиці я виявив, що за допомогою JScript у Windows Script Host я зміг досягти багато хорошого, використовуючи об’єкти. (Мені подобається середовище, тому що набір інструментів, необхідний для випробування нового коду, вбудований у сучасні версії Microsoft Windows.) Під час використання цього середовища я виявив, що іноді немає легкодоступної документації про те, як працює об’єкт. Однак використання об’єкта настільки вигідно, що я так чи інакше роблю. Тож, що я б робив, це написати код, який може бути баггі як гніздо шершнів, і робити це в чудово пісочне середовищі, де я можу побачити ефекти та дізнатися про поведінку об'єкта під час взаємодії з ним.

В інших випадках, іноді лише після того, як я з'ясував, як поводиться об'єкт, я виявив, що об'єкт (в комплекті з операційною системою) є помилковим, і що це відома проблема, яку Microsoft навмисно вирішив, що не буде виправлена .

У таких сценаріях я покладаюся на OpenBSD, створений майстерними програмістами, які регулярно (двічі на рік) створюють нові випуски за розкладом, із відомим записом безпеки "лише два віддалені дірки" за 10+ років? (Навіть у них виправлені помилки для менш важких питань.) Ні, ні в якому разі. Я не покладаюся на такий продукт з такою вищою якістю, тому що я працюю в бізнесі, який підтримує бізнес, який постачає людей машинами, які використовують Microsoft Windows, тому над цим повинен працювати мій код.

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

Підсумок

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

Я, нагадаю, здивувався тому, наскільки короткими були дуже корисні та популярні функції, коли я побачив якийсь вихідний код для strlen та strcpy. Наприклад, strlen, можливо, був на кшталт "int strlen (char * x) {char y = x; while ( (y ++)); return (yx) -1;}"

Однак типові комп’ютерні програми значно довші. Також багато сучасних програмувань використовуватимуть інший код, який може бути менш ретельно перевірений або навіть відомий як баггі. Сьогоднішні системи набагато досконаліші, ніж те, що легко можна продумати, за винятком того, як відмахуючи рукою багато деталей, як "деталі, оброблені нижчими рівнями".

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

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

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

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

Математичні докази описують "що" знання та програми описують "як" знання ".

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

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

У доказі не змінюється стан. Визначено визначення та об'єкти обговорення. Доведення вимагає загальної думки про проблему та розгляду багатьох випадків, але ці випадки фіксуються визначеннями.