Alan Perlis có ý nghĩa gì về cách viết chương trình không có lỗi? [đóng cửa]

Có một trích dẫn của Alan J. Perlis nói rằng:

Có hai cách để viết chương trình không có lỗi; chỉ có cái thứ ba hoạt động.

Gần đây tôi đã nghe câu nói này từ bạn tôi, và không thể hiểu ý nghĩa sâu xa hơn đằng sau nó.

Perlis đang nói gì ở đây?

Nó có nghĩa là thực sự không có chương trình không có lỗi. Một trích dẫn sâu sắc về các cách để tránh lỗi với chính lỗi là nhại lại.

Không có cách thứ ba.

Không có cách nào để viết chương trình không có lỗi

Tôi sẽ trả lời bằng một trích dẫn khác ...

Một trò chơi lạ. Động thái chiến thắng duy nhất là không chơi.

;-)

Như nhiều câu trả lời khác đã chỉ ra, không có cách nào để viết một chương trình không có lỗi .

Nhưng điều tôi muốn chỉ ra là bản chất meta tiềm năng của trích dẫn. Đó thực chất là một lỗi ngoài giới hạn. Trong tuyên bố đầu tiên, ông định nghĩa vũ trụ hoặc "danh sách" chỉ có hai khả năng hoặc yếu tố. Tuy nhiên, trong tuyên bố thứ hai, ông đưa ra tham chiếu đến một phần ba. Thật là vô lý! Thậm chí bất hợp pháp! Một phần tử thứ ba được đưa ra một ranh giới hai phần tử tự nó là một lỗi.

Thực sự sâu sắc ở chỗ trích dẫn có thể chứng minh chính bản chất mà nó được đề cập.

Điều này có nghĩa là tất cả các chương trình không tầm thường sẽ có lỗi. Đó chỉ là một cách thú vị để nói rằng không có cách nào để viết một chương trình không có lỗi.

Có thể viết các chương trình không có lỗi, ngay cả những chương trình không tầm thường và thậm chí chứng minh chúng đúng. Ví dụ, hãy xem xét các ngôn ngữ như Coq, Epigram hoặc Agda nơi điều này được thực hiện.

Các vấn đề ngăn chặn khẳng định rằng nó không thể làm điều này cho các chương trình chung .

Điều này làm tôi nhớ đến một chiếc áo mọt sách mà tôi đã thấy: Có 10 loại người trên thế giới. Những người biết nhị phân và những người không biết.

Nó cũng có thể là một trò chơi trên thực tế là đôi khi các danh sách được lập chỉ mục 0. $ var = mảng ('Đầu tiên', 'Thứ hai', 'Thứ ba'); Và bạn có thể truy cập danh sách này như sau: $ var [0] = 'First' $ var [1] = 'Second' $ var [2] = 'Thứ ba'

Vì vậy, chỉ số mảng bằng chữ 2 chỉ đến chỉ số "Thứ ba".

Điều này đã được giải thích bằng những từ khác, nhưng không rõ ràng như tôi nghĩ nó nên được. Nó đơn giản có nghĩa là bạn sẽ thử cả hai cách, chúng sẽ có lỗi và cuối cùng bạn sẽ sửa lỗi của mình và có một chương trình không có lỗi. So sánh với một trích dẫn khác:

Cách duy nhất để các lỗi xảy ra trong một chương trình là được đặt bởi tác giả. Không có cơ chế khác được biết đến. Các chương trình không thể có lỗi bằng cách ngồi xung quanh với các chương trình lỗi khác. --Harlan Mill

(Ngoài ra, bạn có thể đọc điều này như Pierre đã nói (mà tôi nghĩ là một sự kéo dài). (Cách thứ ba, không tồn tại trong miền, hoạt động.) Giống như tôi đã nói, đó là một sự kéo dài, nhưng đúng.

Đây là cùng một câu trích dẫn mà cha tôi sử dụng để nói với tôi khi tôi kiếm cớ. Câu nói có xu hướng như sau: "Có 3 mặt cho một câu chuyện. Phía của họ, Phía của bạn và phía bên phải / đúng / đúng".

Đặt điều này vào bối cảnh với sự phát triển (và là một người kiểm thử phần mềm bởi giáo sư), tôi sẽ nói vì có rất nhiều cách để mã hóa một cái gì đó có ý nghĩa với "Có 3 mặt để mã hóa. Mã của bạn, Mã của họ, và mã tái cấu trúc. "

Tôi nghĩ điều này là do các lập trình viên / nhà phát triển có xu hướng tái cấu trúc một khi sản phẩm đã ổn định, điều này hầu như quá muộn, nhưng phần lớn thời gian của công cụ tái cấu trúc được thực hiện để cải thiện điều gì đó mà bạn và bạn thân đã không làm tốt ngay từ đầu.

Hi vọng điêu nay co ich.

Tôi nghĩ, về mặt kỹ thuật, bạn có thể viết một chương trình không tầm thường không có lỗi, nhưng do Sự cố Dừng, không thể chứng minh rằng nó không có lỗi. Vì vậy, người ta phải làm việc theo giả định rằng tất cả các chương trình đều có lỗi vì không thể chứng minh bằng cách khác.

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

Cập nhật: Bạn có thể chứng minh một thuật toán cụ thể sẽ trả về các câu trả lời đúng, nhưng điều đó không giống với việc chứng minh nó hoàn toàn chính xác. http://en.wikipedia.org/wiki/C chính xác_(computer_science )

Tuy nhiên, quan điểm của tôi là trích dẫn đề cập đến thực tế là người ta phải cho rằng một chương trình luôn có lỗi và cố gắng giải thích tại sao lại như vậy. http://en.wikipedia.org/wiki/Software_orms#Bug_man Quản lý

Như một cái nhìn sâu sắc bổ sung, "hai cách" có thể là một tham chiếu đến trích dẫn này của Tony Hoare :

Có hai cách để xây dựng một thiết kế phần mềm: Một cách là làm cho nó đơn giản đến mức rõ ràng là không có thiếu sót, và cách khác là làm cho nó phức tạp đến mức không có thiếu sót rõ ràng. Phương pháp đầu tiên là khó khăn hơn nhiều. Nó đòi hỏi cùng một kỹ năng, sự tận tâm, sự thấu hiểu và thậm chí là cảm hứng khi khám phá ra các quy luật vật lý đơn giản làm nền tảng cho các hiện tượng phức tạp của tự nhiên.

Suy ngẫm về điều đó một chút và bạn sẽ thấy anh ấy nói điều tương tự: nếu phần mềm của bạn không tầm thường, nó có lỗi (nhưng làm phức tạp nó đủ và chúng sẽ không phải là lỗi rõ ràng ).