Tại sao không biết chữ lập trình chính thống? [đóng cửa]

Lập trình văn học có lý tưởng tốt. Tại sao bạn nghĩ rằng đây không phải là chủ đạo? Đó là bởi vì nó đã thất bại để cung cấp?

Lần đầu tiên tôi nhìn thấy nó trong một cuốn sách của Knuth, và nghĩ rằng nó trông gọn gàng. Sau đó, tôi đã cố gắng sử dụng màn hình lập trình văn học để hiểu những gì đang diễn ra trong chương trình, và thấy nó khó hơn so với vẻ ngoài của nó. Có thể là tôi đã quá quen với việc xem qua các danh sách chương trình, nhưng có vẻ khó hiểu.

Sau đó, tôi nhìn vào mã nguồn, và điều đó đã tắt tôi ở đó và ở đó. Tôi phải học cách viết chương trình theo một cách hoàn toàn mới, với ít sự tương ứng giữa văn bản chương trình và những gì trình biên dịch đã thấy, và không thấy lợi ích tương ứng.

Ngoài ra, mọi người có thể viết các lập luận dài và thuyết phục rằng mã đang thực hiện X khi nó thực sự làm Y và tôi đã gặp phải những chia sẻ sai lệch của mình. Tôi đã thích đọc mã để xem những gì nó đang làm khá sớm. Lập trình biết chữ là phản đề của điều đó.

Tôi sẽ đổ lỗi cho hiệu ứng mạng . Đối với những người khác để chỉnh sửa mã và tài liệu của bạn, họ phải có khả năng hiểu nó.

Điều này đẩy mọi người ra khỏi một cái gì đó như cweb / noweb, bởi vì sử dụng chúng sẽ yêu cầu bạn học TeX và cú pháp dành riêng cho chương trình trên ngôn ngữ lập trình bạn đang sử dụng cho dự án. Điều này có thể được coi là một sự lãng phí rất lớn thời gian, đặc biệt là nếu họ không cần bất kỳ kiểu sắp xếp toán học nào là một lợi thế lớn cho TeX ngay từ đầu. (Và đối với nhiều lập trình viên ứng dụng, họ thực sự sẽ không cần đến nó.) Thay vào đó họ thích những thứ như nhận xét XML của Visual Studio, bởi vì điều đó đã phổ biến và được thiết lập tốt.

Những nơi tôi đã thấy lập trình biết chữ cất cánh là trong máy tính khoa học / thống kê, nơi hầu hết các lập trình viên được đào tạo đáng kể (còn gọi là tiến sĩ) về toán, CS, hoặc thống kê, và do đó đã quen thuộc với LaTeX. Tài liệu họ viết có nhiều khả năng bao gồm rất nhiều công thức phức tạp được viết tốt nhất bằng TeX và họ có nhiều khả năng lập trình trong R. Tỷ lệ lập trình viên R biết về SWeave chắc chắn cao hơn nhiều so với, nói, tỷ lệ lập trình viên C biết về cweb.

Tôi đã bị cuốn hút bởi khái niệm Lập trình Văn học vào cuối những năm 90 trong khi học, và tôi vẫn bị thu hút bởi cách tiếp cận của Knuths về lập trình và sắp chữ. Không có gì nhưng tốt nhất sẽ làm.

Hệ thống Lập trình Văn học mà Knuth thiết kế đã làm được rất nhiều, ngay lập tức bắt mắt, cụ thể là nó khắc phục được nhiều thiếu sót trong ngôn ngữ lập trình cơ bản mà công cụ tạo mã được tạo từ tài liệu nguồn Knuths, cụ thể là Pascal tiêu chuẩn.

Đối với những người may mắn chưa thử Standard Pascal, đây là một số điểm nổi bật.

• Để làm cho nó dễ dàng hơn để có một trình biên dịch một lượt, đặc tả ngôn ngữ nói rằng tất cả các khai báo phải đi theo một thứ tự nhất định. Từ trang wikipedia: "Mỗi thủ tục hoặc hàm có thể có các khai báo riêng về nhãn goto, hằng, loại, biến và các thủ tục và hàm khác, tất cả phải theo thứ tự đó." Điều này có nghĩa là bạn không thể nhóm các thứ của bạn một cách hợp lý với nhau trong tệp nguồn.
• Xử lý chuỗi là tẻ nhạt hơn ở đồng bằng C.
• Định danh không thể có chiều dài tùy ý.
• Nhiều điều nữa tôi không thể nhớ được nữa.

Tất cả những điều này về cơ bản có nghĩa là Knuth cần một ngôn ngữ lập trình tốt hơn (vì vậy ông đã phát minh ra một ngôn ngữ) và nó đã sử dụng Pascal làm ngôn ngữ lắp ráp.

Hầu hết các ngôn ngữ hiện đại có thể thực hiện những việc này mà không cần nỗ lực nhiều, do đó loại bỏ một phần LỚN của công việc mà Lập trình Văn học phải giải quyết.

Ngoài ra các ngôn ngữ hiện đại có nhiều biểu cảm hơn cho phép nhiều suy nghĩ được đặt vào chính mã.

Vì vậy, những gì còn lại? Khả năng tạo một dạng tài liệu sắp chữ từ mã nguồn và THAT tồn tại đến ngày nay.

Chỉ cần nghĩ rằng JavaDoc - API thời gian chạy Java có lẽ là phần Lập trình biết chữ lớn nhất hiện nay (ngoại trừ mã không thực sự được trình bày, nhưng COULD đã có nếu Java được mở nguồn từ đầu). Xem ví dụ: bản trình bày khung bộ sưu tập trên http://doad.oracle.com/javase/6/docs/api/java/util/Collection.html

Tôi tin rằng các hệ thống tương tự tồn tại cho .NET và các chương trình chính thống khác.

Một điều tôi phát hiện ra khi tôi bắt đầu lập trình biết chữ vào những năm 90 là nó đã thu hút những người rất đam mê muốn thực hiện Chính xác Điều đó - và liên quan đến việc viết hệ thống lập trình biết chữ của riêng họ bởi vì không có ai đủ khả năng cho họ. noweb là một nỗ lực tốt để cắt đứt điều đó bằng cách cung cấp mẫu số chung đủ tốt nhất cho mọi người, mặc dù sau đó, tôi đã dành phần lớn thời gian LP của mình để phát triển một máy in đẹp cho nó ...

Một vấn đề khác là nó thực sự chống nhanh nhẹn. Trong một số cách, bị chậm lại là tốt bởi vì nó buộc bạn phải suy nghĩ nhiều hơn và làm mọi thứ ngay lần đầu tiên. Mặt khác, ghi chép tỉ mỉ khi bạn đi có nghĩa là có một rào cản lớn để tái cấu trúc mã của bạn. Và nếu bạn đợi cho đến khi mã của bạn được làm cứng trước khi LP-ify, bạn sẽ kết thúc với một nhiệm vụ tài liệu nhiều ngày, điều này thực sự có thể ngăn bạn theo dõi.

Theo ý kiến ​​khiêm tốn của tôi, nhiều công ty có một nền văn hóa trái ngược với mục tiêu của Lập trình biết chữ: họ muốn kết quả nhanh hơn (họ chỉ khóc về chất lượng khi ứng dụng được sản xuất). Theo kinh nghiệm của riêng tôi, các sếp của tôi đã từ chối hiểu rằng kết quả nhanh hơn không có nghĩa là "một chương trình có thể chạy được ngay sau khi tôi yêu cầu." Đối với họ, nếu một nhà phát triển không bận gõ bàn phím, anh ta không làm việc, thì "lãng phí thời gian của mình vào thiết kế không có ý nghĩa". Vâng, tôi biết, ông chủ của tôi là một kẻ lừa đảo.

Coders viết mã không phải tiếng Anh.

Các lập trình viên không thích viết tài liệu vì nó không giúp mã chạy.

Coders không giỏi viết tài liệu vì nó là phương tiện kém để thể hiện ý tưởng của họ.

Lập trình biết chữ dường như là ý tưởng của việc đưa tài liệu lên cấp độ tiếp theo, nơi mã hơn là một suy nghĩ sau. Có thể nó sẽ hoạt động, nhưng với hầu hết các lập trình viên, nó trông giống như tài liệu đáng ghét.

Chủ yếu bởi vì mọi người RẤT STUPID. Bằng chứng rõ ràng là một luồng vô tận của những phỏng đoán và hiểu lầm được thể hiện bởi những người trẻ tuổi về bản chất của kỹ thuật đơn giản này.

Mọi người coi LP là: (a) một phương pháp tài liệu (b) một phương pháp viết một số bài luận được đánh bóng đòi hỏi một số kỹ năng hoặc tài năng đặc biệt (c) đơn giản là không có đầu mối - với tư cách là người tạo ra trình soạn thảo lập trình Leo, bằng cách thừa nhận của mình v.v.

Tuy nhiên, LP chỉ đơn giản là: (1) viết chương trình bằng hỗn hợp mã và cụm từ bằng ngôn ngữ con người (= bất kỳ), trong đó phần sau đại diện cho các đoạn mã khác và / hoặc cụm từ được bao gồm. Đây chính xác là những gì tác giả của vô số sách giáo khoa lập trình làm .. và (2) nó là một bộ tiền xử lý đơn giản mở rộng các cụm từ đó ở người (trở thành tên của các chương trình con được bao gồm) để làm sáng tỏ kết quả TRONG LỆNH YÊU CẦU B COMPNG MÁY TÍNH (hoặc thông dịch viên). Mặt khác, người ta có thể mở rộng văn bản bằng văn bản với một tiện ích nhỏ khác để bao gồm các biểu tượng định dạng để biến "nguồn biết chữ" thành một văn bản dễ đọc được định dạng tốt.

Những người trẻ tuổi không bao giờ thử ý tưởng cực kỳ đơn giản này - và tưởng tượng hoặc tưởng tượng những lý do giả mạo tại sao họ sẽ không bao giờ thử hoặc thực hiện nó.

Về cơ bản, ý tưởng chính của lập trình "bằng mã giả" được viết bằng ngôn ngữ của con người và sau đó mở rộng nó với một tiện ích tiền xử lý đơn giản HPS TRỢ TẠO HẠN (hạn chế, một khó khăn chính cho bất kỳ chương trình dài nào), gần giống như việc gấp mã hoặc phân chia luồng chương trình của bạn vào các chức năng / chương trình con, cần thiết để bạn không bị mất chi tiết, nhưng hoàn toàn không cần thiết cho việc thực hiện máy.

Có 2 khía cạnh của lập trình biết chữ mà tôi làm điều ước đã được đưa vào chương trình chính - nhúng hình ảnh (ví dụ, sơ đồ thiết kế) và con trỏ đến những nỗ lực trước đây và thay thế (ví dụ, "Lý do đó là như thế này là bởi vì tôi đã cố gắng cách nào khác này và nó không hoạt động vì ... "). Cả hai khía cạnh này đều có thể được xử lý bằng các nhận xét doc và URI.

Bởi vì logic của các chương trình không hoạt động giống như chúng ta nói. Một chương trình có một luồng được xác định rõ, các điều kiện và các vòng lặp.

Sau khi có nhiều mã hóa, tôi nghĩ về các điều khoản này. Bộ não của tôi biến đổi các vấn đề thành miền mục tiêu của mã thực thi. Và nó hiệu quả hơn nhiều đối với tôi khi viết nó ra bằng ngôn ngữ lập trình thông thường, hơn là phải thực hiện bước biến đổi thêm để làm cho chương trình của tôi biết chữ.

Trên thực tế, tôi tin rằng các chương trình của tôi đã biết chữ ... nhận dạng nói, tên chức năng tốt, nhận xét khi tôi thực hiện một số tin tặc mà tôi sẽ không hiểu ngay lập tức sau vài tháng.

Để kết luận: Mã Java của tôi tự biết chữ hơn khi mọi chương trình "biết chữ" muốn có.

Tôi đã đến để biết chữ lập trình theo cách khác - tôi mơ ước có mã được tổ chức vì nó phù hợp với tâm trí của tôi, không phải như trình biên dịch yêu cầu. Tôi thấy Leo gần như lý tưởng cho mục đích này. Nó cũng hỗ trợ theo dõi các tập tin thay đổi bên ngoài. Các tệp này không phải chứa bất kỳ đánh dấu đặc biệt nào, vì vậy tôi có thể sử dụng Leo cho chính mình mà không cần bất kỳ ai khác trong nhóm biết. Tính năng này - "@shadow cây" - rất hứa hẹn, mặc dù vẫn còn một chút lỗi, cần nhiều nhãn cầu hơn. Và nó cũng khắc phục vấn đề "ồ không, mọi thứ trong một tệp lớn" bằng cách tổ chức mọi thứ thành phác thảo cây và hỗ trợ cho các tệp bên ngoài.

Đối với tôi, trái với tên gọi, "lập trình biết chữ" hoàn toàn không phải là về tài liệu. Tôi không có nhiều tài liệu hơn trước. Đó là về việc có cấu trúc giúp tôi không bị lạc . Tôi thề với điều đó đặc biệt là khi quản lý các tệp tin khổng lồ (và mặc dù Leo ban đầu chủ yếu dành cho Python và nó không hỗ trợ ngôn ngữ JSP - tôi phải tách tệp thành cây Leo theo cách thủ công!).

Tôi thấy nó là một công cụ giảng dạy có giá trị, trong đó có thể viết một bài luận văn về mã, và sau đó các đoạn mã làm việc xen kẽ trong đó để hướng dẫn người đọc về các mức độ, những gì và các đoạn mã.

Bên ngoài một môi trường giáo dục thuần túy, tôi nghĩ chỉ Knuth thực sự hiểu cách sử dụng nó tốt nhất.

Đó là điều tồi tệ nhất trong tất cả các thế giới - bạn phải viết một chương trình máy tính rất chính xác, đặc biệt cao bằng một ngôn ngữ không cụ thể = tiếng Anh. Vì vậy, bạn phải cẩn thận viết nó bằng cách sử dụng chính xác các cụm từ chính xác - vì vậy bạn cũng có thể chỉ cần viết mã.