เหตุใดจึงมีการสนับสนุนที่ จำกัด สำหรับ Design by Contract ในภาษาการเขียนโปรแกรมที่ทันสมัยที่สุด?

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

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

ค่าใช้จ่ายในการเปรียบเทียบดูเหมือนจะค่อนข้างเล็ก:

• พิมพ์ลายนิ้วมือพิเศษ เนื่องจากสัญญาต้องถูกสะกดออกมา
• ใช้เวลาฝึกอบรมจำนวนหนึ่งเพื่อให้คุ้นเคยกับสัญญาการเขียน

ตอนนี้การทำความคุ้นเคยกับ Python เป็นหลักฉันตระหนักว่าในความเป็นจริงเป็นไปได้ที่จะเขียนเงื่อนไขเบื้องต้น (เพียงแค่โยนข้อยกเว้นสำหรับอินพุตที่ไม่เหมาะสม) และเป็นไปได้ที่จะใช้การยืนยันเพื่อทดสอบ postconditions อีกครั้ง แต่มันเป็นไปไม่ได้ที่จะจำลองคุณสมบัติบางอย่างเช่น 'เก่า' หรือ 'ผลลัพธ์' โดยไม่ต้องใช้เวทมนตร์พิเศษที่ในที่สุดจะได้รับการพิจารณาว่าไม่เป็น Pythonic (นอกจากนี้ยังมีห้องสมุดเพียงไม่กี่แห่งที่ให้การสนับสนุน แต่ท้ายที่สุดฉันได้รับความรู้สึกว่ามันผิดที่จะใช้พวกเขาเนื่องจากนักพัฒนาส่วนใหญ่ทำไม่ได้) ฉันคิดว่ามันเป็นปัญหาที่คล้ายกันสำหรับภาษาอื่น ๆ ทั้งหมด (ยกเว้นแน่นอน ไอเฟล)

สัญชาตญาณของฉันบอกฉันว่าการขาดการสนับสนุนต้องเป็นผลมาจากการปฏิเสธการฝึกฝน แต่การค้นหาทางออนไลน์นั้นไม่ประสบผลสำเร็จ ฉันสงสัยว่าบางคนสามารถอธิบายได้ว่าทำไมภาษาสมัยใหม่ส่วนใหญ่จึงให้การสนับสนุนเพียงเล็กน้อย DbC มีข้อบกพร่องหรือมีราคาแพงเกินไป? หรือเป็นเพียงล้าสมัยเนื่องจาก Extreme Programming และวิธีการอื่น ๆ ?

สามารถรองรับได้ในแทบทุกภาษาโปรแกรม

สิ่งที่คุณต้องการคือ "การยืนยัน"

รหัสเหล่านี้เขียนง่าย ๆ ว่า "ถ้า" คำสั่ง:

if (!assertion) then AssertionFailure();

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

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

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

if (checking & !Assertion) then AssertionFailure();

หากคุณไม่ชอบไวยากรณ์คุณสามารถหันไปใช้เทคนิคการใช้ภาษาที่หลากหลายเช่นมาโคร

ภาษาสมัยใหม่บางภาษาให้ไวยากรณ์ที่ดีแก่คุณและนั่นคือสิ่งที่ฉันคิดว่าคุณหมายถึงโดย "การสนับสนุนภาษาสมัยใหม่" สนับสนุน แต่มันก็ค่อนข้างบาง

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

ดังที่คุณพูด Design by Contract เป็นคุณลักษณะใน Eiffel ซึ่งเป็นหนึ่งในภาษาการเขียนโปรแกรมที่ได้รับการยอมรับอย่างดีในชุมชน แต่ไม่เคยมีใครสนใจ

DbC ไม่ได้อยู่ในภาษาที่นิยมมากที่สุดเพราะเมื่อเร็ว ๆ นี้ชุมชนการเขียนโปรแกรมหลักได้ยอมรับว่าการเพิ่มข้อ จำกัด / ความคาดหวังในรหัสของพวกเขาเป็นสิ่งที่ "สมเหตุสมผล" ที่คาดหวังจากโปรแกรมเมอร์ เป็นเรื่องปกติในขณะนี้ที่โปรแกรมเมอร์จะเข้าใจว่าการทดสอบหน่วยที่มีค่าคืออะไรและสิ่งเหล่านี้ทำให้ผู้เขียนโปรแกรมยอมรับการใส่รหัสเพื่อตรวจสอบข้อโต้แย้งและเห็นประโยชน์ แต่ทศวรรษที่ผ่านมาอาจเป็นโปรแกรมเมอร์ส่วนใหญ่จะพูดว่า "นั่นเป็นเพียงงานพิเศษสำหรับสิ่งที่คุณรู้ว่าจะเป็นไปได้เสมอ"

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

ดังนั้นฉันคิดว่ายังมีอีกหลายทางที่จะต้องไปก่อนที่ DbC จะได้รับการยอมรับอย่างกว้างขวาง

สัญชาตญาณของฉันบอกฉันว่าการขาดการสนับสนุนต้องเป็นผลมาจากการปฏิเสธการฝึกฝน ...

เท็จ

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

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

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

หรือเป็นเพียงล้าสมัยเนื่องจาก Extreme Programming และวิธีการอื่น ๆ ?

เลขที่

เราส่วนใหญ่ใช้การทดสอบหน่วยเพื่อแสดงให้เห็นว่า DbC เป็นจริง

สำหรับ Python ดังที่คุณบันทึกไว้ DbC จะไปในหลายที่

1. ผลการทดสอบ docstring และ docstring

2. การยืนยันเพื่อตรวจสอบอินพุตและเอาต์พุต

3. การทดสอบหน่วย

ต่อไป

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

เพียงแค่คาดเดา อาจเป็นส่วนหนึ่งของเหตุผลที่ไม่เป็นที่นิยมเช่นนี้เพราะ "Design by Contract" เป็นเครื่องหมายการค้าของไอเฟล

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

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

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

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

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

ฉันยังทราบด้วยว่าแนวคิดที่เป็นสัญญาสำหรับเทมเพลตค่อนข้างมากและค่อนข้างเกี่ยวข้องกับ DbC ซึ่งถูกทิ้งไว้จากมาตรฐาน C ++ ล่าสุดแม้กระทั่งหลังจากหลายปีของการทำงานกับพวกมัน การเปลี่ยนแปลงที่กว้างขวางกว้างใหญ่และกว้างขวางเกี่ยวกับภาษาเหล่านี้ยากเกินไปที่จะนำไปใช้

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

หากไม่มีการสนับสนุนคอมไพเลอร์ "DbC" เป็นเพียงชื่ออับเรนสำหรับ "ตรวจสอบค่าคงที่ / สมมติฐานและส่งข้อยกเว้นหากละเมิด"

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

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

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

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

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

แก้ไข: ฉันค้นหาและต่อไปนี้เป็นการสนทนาที่เกี่ยวข้องซึ่งอาจมีประโยชน์: https://stackoverflow.com/questions/4065001/are-there-any-provable-real-world-languages-scala

เหตุผลส่วนใหญ่มีดังนี้

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