Що мав на увазі Алан Перліс щодо способів написання програм без помилок? [зачинено]

Є цитата Алана Дж. Перліса, яка говорить:

Є два способи написання програм без помилок; працює лише третя.

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

Про що тут говорить Перліс?

Це означає, що дійсно немає програм без помилок. Поглиблена цитата про способи уникнення помилок із самою помилкою - пародія.

Третього шляху немає.

Немає можливості писати програми без помилок

Я відповім ще однією цитатою ...

Дивна гра. Єдиний виграшний хід - це не грати.

;-)

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

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

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

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

Можна писати програми без помилок, навіть нетривіальні, і навіть доводити їх правильними. Розглянемо, наприклад, такі мови, як Coq, Epigram або Agda, де це робиться.

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

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

Також це може бути гру за те, що іноді списки індексуються 0. $ var = масив ("Перший", "Другий", "Третій"); І ви можете отримати доступ до цього списку як такий: $ var [0] = 'Перший' $ var [1] = 'Другий' $ var [2] = 'Третій'

Так індекс буквального масиву 2 вказує на індекс "Третій".

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

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

(Крім того, ви можете прочитати це так, як сказав П'єр (що, на мою думку, є розтяжкою). (Третій спосіб, який не існує в домені, працює.) Як я вже сказав, це розтягнення, але це правда.

Це та сама цитата, яку мій тато використовує, щоб сказати мені, коли я виправдовуюся. Приказка має тенденцію виглядати так: "У історії є 3 сторони. Їхня сторона, Твоя сторона та права / правдива / правильна сторона".

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

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

Сподіваюся, це допомагає.

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

http://en.wikipedia.org/wiki/Halting_problem

Оновлення: Ви можете довести, що певний алгоритм поверне правильні відповіді, але це не те саме, що довести, що це абсолютно правильно. http://en.wikipedia.org/wiki/Correctness_(computer_science )

Однак моя думка полягала в тому, що цитата посилається на той факт, що треба вважати, що програма завжди має помилки і намагається пояснити, чому це так. http://en.wikipedia.org/wiki/Software_bug#Bug_management

Як додаткове розуміння, "два способи" можуть бути посиланням на цю цитату Тоні Хоара :

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

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