การเขียนโปรแกรมความรู้วิธีการออกแบบที่ดี / ไม่ดี


10

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

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

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

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

ดังนั้นฉันจึงต้องการรับข้อเสนอแนะว่าทำไมจึงควรพิจารณาวิธีการออกแบบที่ไม่ดี / ดี?


2
Zeroth ฉันสร้างแท็กการเขียนโปรแกรมความรู้และเพิ่มการสรุปตามบทความ Wikipedia โปรดช่วยขยายแท็ก wiki ด้วยข้อมูลที่เกี่ยวข้อง
yannis

@YannisRizos ฉันจะเพิ่มที่นี่ฉันไม่มีสิทธิ์แก้ไข
zeroth

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

1
ฉันอยากจะแนะนำผู้เขียนเว็บไซต์ Literate Programming เพื่อเยี่ยมชมไซต์ UX stackexchange - สีที่แย่มากสำหรับการอ่าน
Danny Varod

1
FYI มีliterate-programmingแท็กใน StackOverflow เช่นกัน มีเนื้อหาเพิ่มเติมอยู่ที่นั่นแม้ว่าจะยังไม่มากนัก
Ross Patterson

คำตอบ:


9

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

สิ่งนี้ไม่เกี่ยวข้อง ได้รับมานานหลายทศวรรษ คุณสามารถลบมันออกจากคำถามเนื่องจากมันไม่มีเหตุผลที่คอมไพเลอร์สมัยใหม่จะล้มล้างเครื่องมือเพิ่มประสิทธิภาพ

ดังนั้นฉันจึงต้องการรับข้อเสนอแนะว่าทำไมจึงควรพิจารณาวิธีการออกแบบที่ไม่ดี / ดี?

ไม่มีข้อเสียในการเขียนโปรแกรมความรู้ (ฉันคาดหวังหลายสิบ -1 คะแนนสำหรับความเชื่อมั่นนั้น) ในฐานะผู้ประกอบการฉันไม่เคยเห็นปัญหาใด ๆ เลย

มีข้อโต้แย้งบางประการที่จำนวนทั้งหมดที่ "การเขียนโปรแกรมในภาษาระดับสูงกว่าจะถูกคว่ำโดยการปรับแต่งรหัสผลลัพธ์" ขวา. ในทำนองเดียวกันการเขียนโปรแกรมใน C ++ จะถูก subverted โดย tweaking .oไฟล์ที่ได้รับการผลิต มันเป็นเรื่องจริง แต่ไม่เกี่ยวข้อง

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

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

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

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

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

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


7
โปรแกรมเมอร์จำนวนมากแทบจะไม่เชื่อมโยงกันเมื่ออธิบายบางอย่างในสื่อใด ๆ ก็ตามไม่ว่าจะเป็นทางการหรือไม่เป็นทางการไม่ว่าจะเป็นการเขียนโปรแกรมเชิงวิชาการเขียนความคิดเห็นหรือแม้แต่อีเมลก็ตาม มันเป็นซอฟต์แวร์ที่น่าอัศจรรย์ใช้งานได้ดี :)
Andres F.

3

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

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

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


1

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

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

สำหรับฉันแล้วความคิดเดียวกันหรืออย่างน้อยก็พื้นฐานที่สำคัญของมันก็คือความสัมพันธ์ที่เหมือนกันหรืออย่างน้อยก็เกี่ยวข้องกับการเขียนโปรแกรมความรู้

ยกตัวอย่างเช่นในโลกที่มีแรงสั่นสะเทือนมีการผลักดันให้ใช้ DSL อย่างสม่ำเสมอมากขึ้นและสร้าง DSL ใหม่เพื่อแก้ไขปัญหาที่พบบ่อย การผลักดันนี้มาจากเครื่องมือทั้งสองในภาษา (ผู้สร้างง่าย) รวมถึงไลบรารีหลักที่สนับสนุน API ที่ใช้ DSL

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

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

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


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

ในเวอร์ชั่น 1.8 ของ groovy ความสามารถในการใช้ภาษาธรรมชาติของ DSL ได้รับการปรับปรุงอย่างมากด้วยการเพิ่มสายการบังคับบัญชาที่มีประสิทธิภาพมากขึ้น

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

drink tea with sugar and milk
move left by 30.centimeters
sendFrom "Guillaume" to "Jochen"
send from: "Jochen" to "Lidia"
Email.from "Lidia" to "Guillaume" withBody "how are you?"
contact.name "Guillaume" age 33
move left by 30.centimeters
sell 100.shares of MSFT
take 2.pills of chloroquinine in 6.hours
blend red, green of acrylic
artist.paint "wall" with "Red", "Green", and: "Blue" at 3.pm
wait 2.seconds and execute { assert true }
concat arr[0] with arr[1] and arr[2]
developped with: "Groovy" version "1.8-beta-2"

หมายเหตุ: ตัวอย่างโค้ดมาจากบล็อกของ Guillaume Laforge

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

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

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

สำหรับตัวอย่างเพิ่มเติมของการดำเนินการนี้ (ในลำดับที่ไม่เจาะจง):


2
มุมมองที่น่าสนใจ จากมุมมองของฉันมันไม่เข้ากันได้ดีกับ DSL ตั้งแต่การเขียนโปรแกรมความรู้คือในบางภาษาที่ไม่ใช่ DSL และเครื่องมือต่าง ๆ ก็ไม่ค่อยเหมือน DSL เช่นกัน พวกเขาไม่ได้มุ่งเน้นไปที่โดเมนปัญหา คุณสามารถให้ตัวอย่างของวิธีการคิดว่าการเขียนโปรแกรมความรู้เป็นเหมือน DSL หรือไม่? ลิงค์หรือการอ้างอิงถึงตัวอย่างอาจช่วยชี้แจงคำตอบของคุณ
S.Lott

ตัวอย่างหนึ่งของสิ่งนี้คือกลุ่มคำสั่งใน Groovy 1.8 ที่ให้คุณ "โปรแกรม" กับสิ่งต่าง ๆ เช่นturn left then rightหรือpaint wall with red, green and yellow: docs.codehaus.org/display/GROOVY/ ......
cdeszaq

@ S.Lott - ฉันยอมรับว่ามีความแตกต่างอย่างแน่นอนระหว่าง DSL และการเขียนโปรแกรมความรู้ แต่ฉันคิดว่า DSL อาจเป็นเครื่องมือสำหรับการเขียนโปรแกรมความรู้ที่แท้จริงซึ่งคุณสามารถพิมพ์ภาษาธรรมชาติ - ish และแสดงอัลกอริทึมที่ต้องการ สำหรับฉันการผสมภาษาธรรมชาติและรหัสเป็นรูปแบบการอ่านออกเขียนได้
cdeszaq

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

1
"คำอธิบายของตรรกะของโปรแกรม". ไม่ใช่ตรรกะเอง แต่คำอธิบาย ตรรกะนั้นไม่ค่อยอธิบายตัวเอง มันไม่เคยมีหลักฐานของความถูกต้อง (มันยากและเป็นไปไม่ได้ในบางครั้ง) มันไม่ค่อยมีเหตุผลของความซับซ้อนใหญ่ -O และมันไม่ค่อยอธิบายทางเลือกที่มีประสิทธิภาพต่ำกว่าหรือมีหน่วยความจำมากขึ้น ดังนั้นฉันขอแนะนำว่า DSL สั้นเกินกว่า "คำอธิบาย"
S.Lott

-2

ฉันคิดว่านี่เป็นข้อผิดพลาดที่จะคิดว่า LP เป็น DSL บางประเภท เนื่องจาก LP คือ - สมุดรายวัน (พร้อมไดอะแกรมแผนการชิ้นส่วนหลอกรหัส) ของโปรแกรมที่พัฒนาแล้วมันเป็นสถาปัตยกรรมและอื่น ๆ ... มันเป็นแบบอะนาล็อกของสมุดบันทึกกระดาษ - นักพัฒนาจำนวนมากใช้พวกเขา แต่หลังจากจบโปรแกรม - ดร็อปโน้ตบุ๊กเอกสารของคุณ ...

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

วันนี้โปรแกรมเมอร์หลายคนเขียนรหัสและบางครั้งพวกเขาก็เพิ่มความคิดเห็น! โปรแกรม Byt ไม่ได้เป็นเพียงรหัส - มันเป็นความคิดความคิดจินตนาการแนวคิดและเมื่อนักพัฒนาใหม่ได้รับรหัสต่างด้าว - เขาทำลายความคิดและแนวคิดทั้งหมดบ่อยครั้งทำให้ "ช่องโหว่" และ "แบ็คนอก" แตกต่างกันฉันหวังว่าคุณจะเข้าใจฉัน :)

ดังนั้นข้อกำหนดหลักสำหรับ LP (เป็นเครื่องมือ!) ก็อนุญาตทั้งหมดเหล่านี้ด้วยไวยากรณ์ที่ง่ายน้ำหนักเบาและสามารถอ่านได้ ฉันลองใช้เครื่องมือ LP หลายตัว แต่วันนี้ฉันกำลังพัฒนาตัวเอง - NanoLP ( http://code.google.com/p/nano-lp/ ) ซึ่งมีวัตถุประสงค์เพื่อสนองความต้องการนี้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.