เหตุใดการเขียนโปรแกรมหลักจึงไม่สำคัญ [ปิด]

32

การเขียนโปรแกรมวรรณกรรมมีอุดมคติที่ดี ทำไมคุณถึงคิดว่าสิ่งนี้ไม่สำคัญ เป็นเพราะมันล้มเหลวในการส่งมอบ?

programming-practices literate-programming

2

เพราะเครื่องมือที่พัฒนาขึ้นมาสำหรับมันยังคงอ่อนแออยู่ Microsoft อาจมีโอกาสเป็นผู้นำในเรื่องนี้

— งาน

3

เมื่อใกล้ถึงปัญหาใหม่ฉันมักจะใช้ชวเลข 'การเขียนโปรแกรมวรรณกรรม' ของตัวเองโดยใช้ดินสอและกระดาษ มันช่วยให้ฉันไม่สนใจความหมายของภาษาและผสมผสานในภาษามนุษย์เพื่ออธิบายสิ่งต่าง ๆ ที่จะเรียกว่าฟังก์ชั่น ฯลฯ

— oosterwal

1

แม้แต่ Knuth ก็ไม่เชื่อในแนวคิดนี้อีกต่อไป: "และเรากำลังละทิ้งแนวคิดเก่า ๆ ของ" การเขียนโปรแกรมเชิงความรู้ "ที่ฉันใช้เมื่อพัฒนา TEX82 เพราะเอกสารได้พิสูจน์แล้วว่าเจ็บปวดมากเกินไป" tug.org/TUGboat/tb31-2/tb98knut.pdf

— h0b0

6

สำหรับผู้ที่ไม่คุ้นเคยกับ TeX และปรัชญาของมันควรได้รับการกล่าวถึงว่าการอ้างอิงของ Knuth นั้นมีความหมายอย่างน่าขัน

3

@ h0b0 & user1249: บทความทั้งหมดโดย Knuth นั้นเป็นเรื่องประชดเนื่องจากคุณสามารถอ่านได้โดยอ่านแบบสกิมเท่านั้น นอกจากนี้เขายังล้อเลียน Steve Jobs, เว็บ, Agile, refactoring, OOP, AOP และอื่น ๆ อีกมากมาย มันเป็นเรื่องตลก!

— Andres F.

35

ครั้งแรกที่ฉันเห็นมันในหนังสืองานเขียนของ Knuth และคิดว่ามันดูเรียบร้อย จากนั้นฉันพยายามใช้การแสดงการเขียนโปรแกรมวรรณกรรมเพื่อทำความเข้าใจกับสิ่งที่เกิดขึ้นในโปรแกรมและพบว่ามันยากกว่าที่คิด อาจเป็นได้ว่าฉันคุ้นเคยกับการทำรายการโปรแกรมมากเกินไป แต่มันก็ดูสับสน

จากนั้นฉันก็ดูที่ซอร์สโค้ดและนั่นทำให้ฉันปิดไปแล้ว ฉันต้องเรียนรู้ที่จะเขียนโปรแกรมด้วยวิธีการใหม่ทั้งหมดโดยมีการโต้ตอบน้อยลงระหว่างข้อความในโปรแกรมและสิ่งที่คอมไพเลอร์เห็นและไม่เห็นประโยชน์ที่ตรงกัน

นอกจากนี้ผู้คนสามารถเขียนข้อโต้แย้งที่ยาวนานและน่าเชื่อถือได้ว่ารหัสนั้นกำลังทำ X เมื่อจริง ๆ แล้วทำ Y และฉันก็พบความคิดเห็นที่ทำให้เข้าใจผิด ฉันพัฒนาความชื่นชอบในการอ่านรหัสเพื่อดูว่ามันทำอะไรเร็วพอสมควร การเขียนโปรแกรมทางวรรณกรรมนั้นเป็นสิ่งที่ตรงกันข้าม

— เดวิด ธ อร์นลีย์
แหล่งที่มา

4

การเขียนโปรแกรมความรู้รวมถึงความคิดเห็นทั่วไปไม่เกี่ยวกับสิ่งที่โค้ดของคุณกำลังทำอยู่ คุณสามารถอ่านได้จากรหัสนั้น มันคือทั้งหมดที่เกี่ยวกับสาเหตุและวิธีการและข้อมูลที่สำคัญนี้มักจะหายไปโดยไม่มีการเขียนโปรแกรมที่เหมาะสม จำเป็นต้องพูดถึงว่า " ทำไม? " ส่วนที่ค่อนข้างบ่อยจะเกี่ยวข้องกับคณิตศาสตร์ที่ซับซ้อนและซับซ้อนบางครั้งแปลงและตารางบางครั้งไดอะแกรม เครื่องมือการเขียนโปรแกรมความรู้จำเป็นต้องรักษาความคิดเห็นดังกล่าวในวิธีที่อ่าน

— SK-logic

1

@ SK-logic ยุติธรรม แต่ประเด็นที่เดวิด ธ อร์นลีย์กำลังทำอยู่ก็คือแม้แต่ทำไมที่จะกลายเป็นเรื่องโกหกที่ทำให้เข้าใจผิด

— MrFox

1

+1 Knuth กำลังเขียนกลับในวันที่เขียนโปรแกรม (ใจความ) ในการใช้ภาษา "ขั้นสูง" หมายถึงการเขียน "C" เกือบจะอยู่ด้านบนของโลหะแทนที่จะใช้รหัสเครื่อง หน่วยความจำเป็นตัวแปรที่เข้มงวดมากและชื่ออื่น ๆ มักจะเป็นเพียงตัวอักษรเดียวมักจะนำมาใช้ใหม่จากขอบเขตขอบเขต โปรแกรมส่วนใหญ่ที่เปิดใช้งานคีย์เดียวหนึ่งช็อตที่เขียนและดูแลโดยแต่ละคนด้วยสไตล์ที่แปลกประหลาดของเขาเอง การยึดฐานรหัสเป็นการถอดรหัสมากกว่าการอ่าน ไม่มีการควบคุมแหล่งที่มา ฯลฯ เพื่อช่วยเหลือ

— TechZen

1

วันนี้ Knuth มองลงไปที่ถนนเมื่อ 30 ปีก่อน เขารู้ว่าโปรแกรมจะใหญ่ขึ้นซับซ้อนกว่าเขียนโดยทีมที่มีสมาชิกเปลี่ยนจะทำงานมาหลายปีหรือหลายสิบปีและต้องการข้อมูลการประเมินและการยอมรับในที่สุดจากผู้ที่ไม่ใช่โปรแกรมเมอร์ การเขียนโปรแกรมความรู้เป็นแนวคิดสำหรับการจัดการทั้งหมด เขาคร่ำครวญในสิ่งที่เราเรียกว่าตรรกะทางธุรกิจและ BDD แนวคิดหลักคือการที่โปรแกรมเมอร์รู้ว่าต้องทำอะไรและโปรแกรมเมอร์ที่ไม่สามารถทำตามได้ แนวคิดดังกล่าวล้มเหลวเนื่องจากไม่มีกลไกบังคับใช้การเชื่อมโยงระหว่างข้อความ "รู้" และรหัส

— TechZen

BTW: นี่คือเหตุผลที่ฉันชอบภาษา "เอกสารด้วยตนเอง" เช่น Objective-C ในตอนแรกโค้ดดูเหมือนจะมีวิธีการที่ยุ่งเหยิงด้วยชื่อของเมธอดที่ยาวอย่างไร้เหตุผล แต่แม้แต่โปรแกรมเมอร์ที่ไม่รู้ภาษาหรือ API ก็สามารถไขปริศนาได้อย่างรวดเร็วว่าโค้ดนั้นทำอะไรอยู่ เหนือสิ่งอื่นใดเปลี่ยนรหัสและการเปลี่ยนแปลง "ความคิดเห็น" ในการซิงค์โดยอัตโนมัติ แน่นอนว่าเป็นเหตุผลที่ Objective-C เขียนด้วยระบบเติมข้อความอัตโนมัติในตัวโดยที่ไม่เขียน Objective-C นั้นค่อนข้างน่ากลัว

— TechZen

13

ฉันจะตำหนิผลเครือข่าย เพื่อให้ผู้อื่นแก้ไขรหัสและเอกสารของคุณพวกเขาจะต้องสามารถเข้าใจได้

สิ่งนี้จะผลักดันผู้คนให้อยู่ห่างจากสิ่งอื่นเช่น cweb / noweb เพราะการใช้พวกเขาจะทำให้คุณต้องเรียนรู้ TeX และไวยากรณ์ของโปรแกรมเฉพาะด้านบนของภาษาโปรแกรมที่คุณใช้สำหรับโครงการ สิ่งนี้สามารถมองเห็นได้ว่าเป็นการเสียเวลามากโดยเฉพาะอย่างยิ่งหากพวกเขาไม่ต้องการการเรียงพิมพ์ทางคณิตศาสตร์ใด ๆ ที่เป็นการจับรางวัลครั้งใหญ่สำหรับ TeX ในตอนแรก (และสำหรับโปรแกรมเมอร์แอปพลิเคชั่นจำนวนมากพวกเขาไม่ต้องการมันจริงๆ) แทนที่จะชอบความเห็น XML ของ Visual Studio เพราะมันได้รับความนิยมและเป็นที่ยอมรับ

สถานที่ที่ฉันได้เห็นการเขียนโปรแกรมความรู้ออกไปอยู่ในการคำนวณทางวิทยาศาสตร์ / สถิติที่โปรแกรมเมอร์ส่วนใหญ่มีการฝึกอบรมที่สำคัญ (ปริญญาเอกหรือที่รู้จัก) ในวิชาคณิตศาสตร์ CS หรือสถิติและจึงเป็น famliiar กับ LaTeX เอกสารที่พวกเขาเขียนมีแนวโน้มที่จะรวมสูตรที่ซับซ้อนจำนวนมากซึ่งเขียนได้ดีที่สุดใน TeX และพวกเขามีแนวโน้มที่จะเขียนโปรแกรมใน R สัดส่วนของโปรแกรมเมอร์ R ที่รู้เรื่อง SWeave นั้นสูงกว่าแน่นอนมาก สัดส่วนของโปรแกรมเมอร์ C ที่รู้เกี่ยวกับ cweb

— แลร์รี่หวาง
แหล่งที่มา

2

คำตอบนี้ดูเหมือนว่าจะถือว่าเครื่องมือการเขียนโปรแกรมความรู้ทั้งหมดใช้ LaTeX มันเป็นเรื่องจริงเหรอ? ดูเหมือนจะไม่มีอะไรเกี่ยวกับแนวคิดที่ต้องการ

— AShelly

@Ashelly: มันไม่จำเป็นต้อง - ฉันรู้ว่าอย่างน้อยตอนนี้อย่างน้อยช่วยให้คุณใช้ HTML แต่ในทางปฏิบัติผู้ที่เขียนเอกสาร HTML จะใช้ javadoc และไม่ชอบแทนเครื่องมือการเขียนโปรแกรมความรู้

— Larry Wang

1

@ AShelly เพื่อให้การเขียนโปรแกรมรู้หนังสือทำงานได้คุณจะต้องสามารถสร้างเอกสารที่จะพิมพ์ได้ นี่เป็นเรื่องง่ายกว่ามากเมื่อรูปแบบเป็นข้อความและสำหรับความรู้ของฉันฟอร์แมตเอกสารข้อความที่ทรงพลังที่สุดคือ TeX และวิธีที่ง่ายที่สุดในการทำงานกับ TeX คือใช้ LaTeX

@AShelly คุณอาจต้องการที่จะดูที่การสนับสนุนของการเขียนโปรแกรมความรู้org-mode มันมีประโยชน์มากและฉันคิดว่ามันมากง่ายต่อการเข้าใจ (ไม่พูดถึงการจัดการ ) มากกว่าเว็บหรือ NOWEB เพียงอย่างเดียว ส่วนที่สำคัญของรหัสคือความสามารถในการอ่านและสามารถอ่านได้ (cf github.com/vermiculus/stack-mode )

— Sean Allred

12

ฉันรู้สึกทึ่งกับแนวคิดของการเขียนโปรแกรมวรรณกรรมในช่วงปลายยุค 90 ในขณะที่เรียนอยู่และฉันก็ยังรู้สึกทึ่งกับวิธีการเขียนโปรแกรม Knuths และการเรียงพิมพ์ ไม่มีอะไรนอกจากจะทำดีที่สุด

ระบบการเขียนโปรแกรมวรรณกรรมที่ Knuth ได้ออกแบบนั้นมีมากเกินกว่าที่จะพบได้ทันทีคือมันเอาชนะข้อบกพร่องมากมายในภาษาการเขียนโปรแกรมพื้นฐานซึ่งเครื่องมือสร้างรหัสที่สร้างขึ้นจากเอกสารต้นฉบับของ Knuths คือ Pascal มาตรฐาน

สำหรับผู้ที่โชคดีพอที่จะไม่ลอง Standard Pascal นี่เป็นไฮไลท์บางส่วน

เพื่อให้ง่ายขึ้นในการมีคอมไพเลอร์ผ่านครั้งเดียวข้อมูลจำเพาะของภาษากล่าวว่าการประกาศทั้งหมดต้องมาในลำดับที่แน่นอน จากหน้าวิกิพีเดีย: "แต่ละขั้นตอนหรือฟังก์ชั่นสามารถมีการประกาศของตัวเองของฉลาก goto, ค่าคงที่, ประเภท, ตัวแปรและขั้นตอนและฟังก์ชันอื่น ๆ ซึ่งทั้งหมดจะต้องอยู่ในลำดับนั้น" หมายความว่าคุณไม่สามารถจัดกลุ่มสิ่งต่าง ๆ ของคุณอย่างมีเหตุผลในไฟล์ต้นฉบับได้
การจัดการสตริงน่าเบื่อกว่าใน C ธรรมดา
ตัวระบุอาจมีความยาวไม่ได้
หลายสิ่งหลายอย่างที่ฉันจำไม่ได้อีกต่อไป

ทุกสิ่งเหล่านี้โดยทั่วไปหมายความว่า Knuth ต้องการภาษาโปรแกรมที่ดีกว่า (ดังนั้นเขาจึงคิดค้นภาษาหนึ่ง) และใช้ภาษา Pascal เป็นภาษาแอสเซมบลี

ภาษาสมัยใหม่ส่วนใหญ่สามารถทำสิ่งเหล่านี้ได้โดยไม่ต้องใช้ความพยายามมากนักดังนั้นการลบส่วนใหญ่ของงานที่ Literate Programming ต้องแก้ไข

นอกจากนี้ภาษาสมัยใหม่ยังมีความหมายที่ชัดเจนซึ่งทำให้สามารถใส่รหัสลงไปได้

ดังนั้นสิ่งที่เหลืออยู่? ความสามารถในการสร้างรูปแบบเรียงพิมพ์ของเอกสารจากซอร์สโค้ดและที่มีอยู่ในปัจจุบัน

แค่คิดว่า JavaDoc - Java runtime API อาจเป็นชิ้นส่วนที่ใหญ่ที่สุดของการเขียนโปรแกรม Literate ที่มีอยู่ในวันนี้ (ยกเว้นว่ารหัสไม่ได้นำเสนอจริง แต่ COULD ได้รับถ้า Java ถูกเปิดแหล่งที่มาจากจุดเริ่มต้น) ดูตัวอย่างการนำเสนอของเฟรมเวิร์กคอลเล็กชันบนhttp://download.oracle.com/javase/6/docs/api/java/util/Collection.html

ฉันเชื่อว่ามีระบบที่คล้ายกันสำหรับ. NET และโปรแกรมหลักอื่น ๆ

To make it possible to have a single-pass compiler, all declarations had to come in a certain order. คำสั่งการประกาศเช่นนั้นจะทำให้การออกแบบคอมไพเลอร์ง่ายขึ้น แต่ก็ไม่ได้เปิดใช้งาน / ป้องกันการคอมไพล์แบบพาสครั้งเดียว ตัวอย่างเช่น Delphi ไม่มีข้อ จำกัด ในการสั่งซื้อ แต่ก็ยังคงเป็นคอมไพเลอร์ Pascal แบบพาสด์เดียวอย่างเคร่งครัด

— Mason Wheeler

ตกลง Turbo Pascal ไม่มีข้อ จำกัด เช่นกัน อย่างไรก็ตามโปรดทราบว่าข้อ จำกัด นี้อยู่ในคำจำกัดความของ Pascal ตั้งแต่เริ่มต้น

1

Nope, Knuth เปลี่ยนเป็น CWEB นานมาแล้วไม่ใช่เกี่ยวกับการแก้ไขข้อบกพร่อง Pascal Nope, JavaDoc ไม่มีส่วนเกี่ยวข้องกับ "การเขียนโปรแกรมการรู้หนังสือ" ของ Knuth - เขากำลังพูดถึงการเปลี่ยนวิธีการสร้างรหัสและการอ้างว่ามันช่วยให้เขาสามารถจัดการกับความซับซ้อนที่เขาอ้างว่าไม่สามารถทำได้สำหรับเขาหรือคนอื่น ๆ

— Ron Burk

@RonBurk CWEB เพียงคอมไพล์กับ "ภาษาแอสเซมบลี" ที่ดีขึ้น สิ่งนี้ไม่ทำให้การตัดสินใจการออกแบบเริ่มต้นเป็นโมฆะ

— Thorbjørn Ravn Andersen

5

สิ่งหนึ่งที่ฉันค้นพบเมื่อฉันอ่านบทเขียนในยุค 90 คือว่ามันดึงดูดผู้คนที่มีความปรารถนาอย่างแรงกล้าที่ต้องการจะทำสิ่งที่ถูกต้องอย่างแน่นอน - และนั่นก็เกี่ยวข้องกับการเขียนระบบการเขียนโปรแกรมด้วยตนเอง noweb เป็นความพยายามที่ดีที่จะตัดสิ่งนั้นออกโดยการจัดหาตัวหารร่วมน้อยที่สุดให้ทุกคนถึงแม้ว่าฉันจะใช้เวลาส่วนใหญ่ในการพัฒนาเครื่องพิมพ์ที่น่ารักสำหรับมัน ...

ปัญหาอีกอย่างก็คือมันต่อต้านการว่องไวจริงๆ ในบางวิธีการชะลอตัวเป็นสิ่งที่ดีเพราะมันบังคับให้คุณคิดล่วงหน้าและทำสิ่งต่างๆให้ถูกต้องตั้งแต่ครั้งแรก ในทางกลับกันการจัดทำเอกสารอย่างพิถีพิถันในขณะที่คุณไปหมายความว่ามีอุปสรรคขนาดใหญ่เพื่อ refactoring รหัสของคุณ และถ้าคุณรอจนกว่ารหัสของคุณจะแข็งตัวก่อนที่คุณจะ LP-ify คุณจะได้งานเอกสารที่ใช้เวลาหลายวันซึ่งสามารถหยุดคุณในแทร็กได้

— dfan
แหล่งที่มา

หลังจากการทดลองฉันพบว่าจุดที่น่าสนใจของ LP สำหรับพวกเราที่เหลืออาจอยู่ในเอกสารการตัดสินใจการออกแบบและรายละเอียดสถาปัตยกรรมถัดจากโค้ดจริง ฉันเห็นด้วยกับ LP ว่าการปรับโครงสร้างทำได้ยากขึ้น มันเป็นความเข้าใจของฉันที่ Knuth ทำการออกแบบเริ่มต้นบนกระดาษและเฉพาะเมื่อพอใจเริ่มใช้งานจริง นี่น่าจะเป็นสถานการณ์เดียวกันกับที่ฉันพบว่าเหมาะกับฉัน

— Thorbjørn Ravn Andersen

3

ในความคิดเห็นที่ต่ำต้อยของฉัน บริษัท หลายแห่งมีวัฒนธรรมที่ตรงข้ามกับวัตถุประสงค์ของการเขียนโปรแกรม: พวกเขาต้องการผลลัพธ์ที่เร็วขึ้น (พวกเขาจะร้องไห้เกี่ยวกับคุณภาพเมื่อแอปอยู่ในการผลิต) จากประสบการณ์ของฉันเจ้านายของฉันปฏิเสธที่จะเข้าใจว่าผลลัพธ์ที่เร็วขึ้นไม่ได้หมายความว่า "โปรแกรมที่ทำงานได้ในวันรุ่งขึ้นหลังจากที่ฉันขอ" สำหรับพวกเขาหากนักพัฒนาไม่ได้ยุ่งกับการพิมพ์บนแป้นพิมพ์เขาจะไม่ทำงานคือ "เสียเวลาในการออกแบบโดยไม่รู้สึก" ใช่ฉันรู้ว่าเจ้านายของฉันเป็น arsehole

— Nisanio
แหล่งที่มา

จากนั้นด้วยการเขียนโปรแกรมวรรณกรรมพวกเขาอาจคิดว่าคุณไม่ว่างที่จะเขียน Sci-Fi Book แทนที่จะเป็นซอฟต์แวร์ตัวอื่น! : D

— Mahdi

บริษัท เช่นนั้นไม่เข้าใจว่าซอฟต์แวร์ที่ดีใช้งานได้นานมากและเอกสารที่ดีกว่าแหล่งที่มาก็คุ้มค่ามากกว่า

— Thorbjørn Ravn Andersen

2

ผู้เขียนโค้ดไม่ได้เป็นภาษาอังกฤษ

โคเดอร์ไม่ชอบเขียนเอกสารเพราะมันไม่ได้ช่วยให้โค้ดรันได้

โคเดอร์ไม่เก่งในการเขียนเอกสารเพราะมันเป็นสื่อที่ไม่ดีในการแสดงความคิดเห็น

ความรู้เกี่ยวกับการเขียนโปรแกรมดูเหมือนจะเป็นความคิดของการจัดทำเอกสารไปยังระดับถัดไปที่รหัสมีความคิดเพิ่มเติม อาจจะใช้งานได้ แต่สำหรับ coder ส่วนใหญ่ดูเหมือนว่าเอกสารที่น่ารังเกียจ

— Winston Ewert
แหล่งที่มา

29

ผู้เขียนที่ปฏิบัติตามจุดที่คุณอธิบายไม่ใช่ผู้เขียนที่ฉันต้องการทำงานกับฉัน

— พอลนาธาน

1

@ พอลได้รับ แต่นั่นคือสิ่งที่จริงมี แต่สำหรับฉันดูเหมือนว่าเอกสารเพิ่มเติมไม่จำเป็นต้องดีกว่า

— Winston Ewert

1

อาจจะดีพอ

— mlvljr

6

โปรแกรมเมอร์ที่มีประสบการณ์รู้ว่าพวกเขาจำเป็นต้องเขียนเอกสารเพราะนั่นคือสิ่งที่ "ทำไมฉันถึงทำแบบนั้น"

1

@ Thorbjørn Ravn Andersen ใช่จริง แต่การเขียนโปรแกรมตามตัวอักษร (ตามที่ฉันเข้าใจ) แนะนำให้คุณเขียนโค้ดด้วยเอกสารของคุณแทนที่จะเป็นเอกสารด้วยรหัสของคุณ เอกสารนั้นมีประโยชน์มากจริง ๆ ไหม?

— Winston Ewert

2

สาเหตุหลักมาจากคนที่โง่มาก ประจักษ์พยานที่ชัดเจนซึ่งเป็นกระแสที่ไม่รู้จบของการเดาและความเข้าใจผิดที่แสดงออกโดยคนหนุ่มสาวเกี่ยวกับธรรมชาติของเทคนิคง่าย ๆ นี้

ผู้คนใช้ LP เป็น: (a) วิธีการจัดทำเอกสาร (b) วิธีการเขียนเรียงความที่จำเป็นต้องใช้ทักษะหรือความสามารถพิเศษ (c) เพียงแค่ไม่มีเงื่อนงำ - ในฐานะผู้สร้างโปรแกรมแก้ไขการเขียนโปรแกรม Leo โดยการยอมรับของเขาเอง ฯลฯ เป็นต้น

LP คือ: (1) การเขียนโปรแกรมด้วยการผสมผสานของรหัสและวลีในภาษามนุษย์ (= ใด ๆ ) ซึ่งภายหลังจะยืนสำหรับส่วนอื่น ๆ ของรหัสและ / หรือวลีที่รวมอยู่ด้วย นี่คือสิ่งที่ผู้เขียนตำราการเขียนโปรแกรมจำนวนมากทำ .. และ (2) เป็นตัวประมวลผลง่าย ๆ ที่ขยายวลีเหล่านั้นในมนุษย์ (ซึ่งกลายเป็นชื่อของรูทีนย่อยที่รวมอยู่) เพื่อคลี่คลายผลลัพธ์ ล่าม). มิฉะนั้นจะสามารถขยายข้อความที่เขียนด้วยยูทิลิตี้ขนาดเล็กอีกอันเพื่อรวมสัญลักษณ์การจัดรูปแบบเพื่อเปลี่ยน "แหล่งข้อมูล" ให้เป็นข้อความที่อ่านได้ในรูปแบบที่ดี

คนหนุ่มสาวไม่เคยลองใช้ความคิดที่เรียบง่ายอย่างนี้และอาจจินตนาการหรือจินตนาการถึงเหตุผลปลอม ๆ ว่าทำไมพวกเขาถึงไม่ลองหรือทำมัน

โดยพื้นฐานแล้วแนวคิดหลักของการเขียนโปรแกรม "in pseudocode" ที่เขียนด้วยภาษามนุษย์แล้วขยายด้วยยูทิลิตี้ตัวประมวลผลอย่างง่าย HELPS MANAGE ATTENTION (จำกัด ซึ่งเป็นปัญหาหลักสำหรับโปรแกรม longish ใด ๆ ) เช่นการพับโค้ดหรือการแบ่งส่วนของโปรแกรม เป็นฟังก์ชั่น / รูทีนย่อยจำเป็นสำหรับคุณที่จะไม่สูญเสียรายละเอียด แต่ก็ไม่จำเป็นทั้งหมดสำหรับการดำเนินการของเครื่อง

3

คุณหายไปหนึ่งบิตที่สำคัญ: (3) วิธีการเรียงลำดับรหัสใหม่ในภาษาใด ๆ ในลำดับที่สามารถอ่านได้และเป็นธรรมชาติที่สุดซึ่งไม่จำเป็นต้องเป็นลำดับเดียวกันกับที่คอมไพเลอร์ต้องจัดการ มันรวมถึงการซ่อนรายละเอียดการใช้งานในเชิงอรรถหรือที่อื่น ๆ ที่ไกลจากเค้าร่างรหัส

— SK-logic

1

มี 2 แง่มุมของการเขียนโปรแกรมความรู้ที่ผมมีไม่ปรารถนาถูกรวมเข้าไปในการเขียนโปรแกรมหลัก - ภาพฝังตัว (เช่นแผนภาพการออกแบบ) และตัวชี้ความพยายามก่อนหน้านี้และอื่น (เช่น "เหตุผลที่มันเป็นเช่นนี้เป็นเพราะฉันพยายามวิธีอื่น ๆ นี้และ มันไม่ทำงานเพราะ ... ") ทั้งสองด้านสามารถจัดการได้กับความคิดเห็นของ doc และ URIs

— Larry OBrien
แหล่งที่มา

1

เพราะตรรกะของโปรแกรมไม่ทำงานเหมือนที่เราพูด โปรแกรมมีโฟลว์และเงื่อนไขและลูปที่ระบุไว้เป็นอย่างดี

หลังจากเขียนโค้ดเป็นจำนวนมากฉันคิดว่าในแง่เหล่านี้ สมองของฉันเปลี่ยนปัญหาเป็นโดเมนเป้าหมายของโค้ดที่สามารถเรียกทำงานได้ และมันมีประสิทธิภาพมากขึ้นสำหรับฉันที่จะเขียนลงในภาษาการเขียนโปรแกรมปกติกว่าต้องทำขั้นตอนการแปลงพิเศษเพื่อให้โปรแกรมของฉันรู้

ในความเป็นจริงฉันเชื่อว่าโปรแกรมของฉันมีความรู้แล้ว ... ตัวระบุการพูดชื่อฟังก์ชั่นที่ดีความคิดเห็นที่ฉันทำแฮ็กเกอร์บางอย่างซึ่งฉันจะไม่เข้าใจตัวเองทันทีหลังจากผ่านไปสองสามเดือน

เพื่อสรุป: โค้ด Java ของฉันมีความรู้มากกว่าตัวมันเองเนื่องจากการเขียนโปรแกรม "รู้แจ้ง" ทุกตัวต้องการที่จะเป็น

— แดเนียล
แหล่งที่มา

2

รหัส Java ไม่สามารถอ่านออกเขียนได้ "ตัวระบุการพูด" ของคุณจะไม่อธิบายว่าทำไมคุณเลือกอัลกอริธึมนี้เหนือสิ่งอื่น ๆ ข้อ จำกัด อะไรคือสิ่งที่คุณคาดหวังโปรไฟล์ประสิทธิภาพ ฯลฯ โปรแกรมการรู้หนังสือของฉันส่วนใหญ่ทำจากสูตรไดอะแกรมและกราฟ ข้อความภาษาอังกฤษ แต่ทั้งหมดนี้ไม่สามารถแสดงในรหัสและดูน่าเกลียดในความคิดเห็นง่าย ๆ

— SK-logic

1

ฉันมาเขียนโปรแกรมด้วยวิธีอื่น ๆ - ฉันฝันว่าจะมีการจัดระเบียบโค้ดให้เหมาะกับความคิดของฉันไม่ใช่ตามที่คอมไพเลอร์ต้องการ ฉันพบว่าลีโอเกือบจะเหมาะสำหรับจุดประสงค์นี้ นอกจากนี้ยังรองรับการติดตามการเปลี่ยนแปลงของไฟล์ภายนอก ไฟล์เหล่านี้ไม่จำเป็นต้องมีมาร์กอัปพิเศษใด ๆ ดังนั้นฉันสามารถใช้ Leo สำหรับตัวเองโดยไม่จำเป็นต้องให้ผู้อื่นในทีมรู้ คุณลักษณะนี้ - "@ ต้นไม้เงา" - มีแนวโน้มดีมากถึงแม้จะเป็นรถบั๊กกี้ แต่ก็ต้องการลูกตามากขึ้น และมันยังแก้ไขปัญหา "โอ้ไม่ทุกอย่างในไฟล์เดียว" ด้วยการจัดระเบียบทุกอย่างให้เป็นโครงร่างแบบต้นไม้และรองรับไฟล์ภายนอก

สำหรับฉันตรงกันข้ามกับชื่อ "การเขียนโปรแกรมความรู้" ไม่เกี่ยวกับเอกสารเลย ฉันไม่มีเอกสารมากกว่านี้มาก่อน มันเกี่ยวกับการมีโครงสร้างที่ช่วยให้ฉันไม่หลงทาง ฉันขอสาบานโดยเฉพาะอย่างยิ่งเมื่อจัดการไฟล์ JSP behemoth (และแม้ว่า Leo จะมีจุดประสงค์เบื้องต้นสำหรับ Python เป็นหลักและไม่สนับสนุนภาษา JSP - ฉันต้องแยกไฟล์ไปที่ Tree Leo ด้วยตนเอง!)

— ไรย์
แหล่งที่มา

0

ฉันเห็นว่ามันเป็นเครื่องมือการสอนที่มีค่าซึ่งสามารถเขียนวิทยานิพนธ์ลงบนโค้ดได้และจากนั้นเกร็ดเล็กเกร็ดน้อยของรหัสการทำงานสอดแทรกอยู่ในนั้นเพื่อสั่งให้ผู้อ่านรู้ว่าอะไรคืออะไร

นอกสภาพแวดล้อมทางการศึกษาล้วนๆฉันคิดว่ามีเพียง Knuth เท่านั้นที่เข้าใจวิธีใช้งานได้ดีที่สุด

— greyfade
แหล่งที่มา

-4

มันเลวร้ายที่สุดในโลก - คุณต้องเขียนโปรแกรมคอมพิวเตอร์ที่ถูกต้องและเจาะจงสูงในภาษาที่ไม่เฉพาะเจาะจง = อังกฤษ ดังนั้นคุณต้องเขียนมันอย่างระมัดระวังโดยใช้วลีที่ถูกต้องดังนั้นคุณอาจจะแค่เขียนโค้ด

— Martin Beckett
แหล่งที่มา

3

คุณไม่ควรทำซ้ำรหัสของคุณในภาษาอังกฤษ ความคิดเห็นต้องอธิบายเหตุผลว่าทำไมจึงมีรหัสไม่ใช่สิ่งที่ทำ ฉันมักจะทำกราฟกราฟและพล็อตลงในความคิดเห็นที่รู้หนังสือของฉันและมันช่วยให้เข้าใจรหัสได้อย่างแท้จริง

— SK-logic

หากความคิดเห็นไม่ได้บอกว่ารหัสกำลังทำอะไรอยู่แล้วมันเป็นอย่างไรการเขียนโปรแกรมความรู้ - มันเป็นเพียงการเขียนโปรแกรมปกติท ฉันคิดว่าจุดทั้งหมดของการเขียนโปรแกรมความรู้คือการอธิบายโปรแกรมในเอกสารและมีระบบสร้างรหัสจากเอกสาร?

— Martin Beckett

3

ลองอ่าน "TeX โปรแกรม" รหัสจะไม่ซ้ำในความคิดเห็นที่นั่น ความคิดเห็นอธิบายว่าทำไมโค้ดจึงถูกเขียนขึ้นในลักษณะนั้นและอธิบายสถาปัตยกรรม

— SK-logic

3

@MartinBeckett สิ่งที่คุณอธิบายไม่ใช่ LP

— Andres F.