กฎข้อที่สิบของ Greenspun ทุกโครงการขนาดใหญ่มีล่ามเสียงกระเพื่อมหรือไม่? [ปิด]

กฎที่สิบของ Greenspun (จริงๆแล้วเป็นเพียงกฎเดียว) ระบุว่า:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

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

คำสั่งคืออติพจน์ แต่มีสัญญาณชัดเจนว่า Lisp อิจฉาในภาษาอื่น ๆ ดู C # และวิธีการใช้งานให้เป็นธรรมชาติมากขึ้น ดูที่ Business Process Management, เวิร์กโฟลว์และเฟรมเวิร์ก EAI ที่พยายามหลีกเลี่ยงการเขียนโปรแกรมระบบโดยไม่ต้องเปลี่ยนโปรแกรม

มีหนังสือเกี่ยวกับ Domain Specific Languages ​​โดย Martin Fowler ที่พูดถึงวิธีการเขียนโปรแกรมเมตาในภาษาเชิงวัตถุ ดังนั้นจึงมีความจริงบางอย่างเพื่ออติพจน์

Paul Graham เรียกว่า Lisp ภาษาที่ทรงพลังที่สุดเมื่อดูรายการแรกที่มาพร้อมกับ Lispมันง่ายที่จะดูว่าทำไมหลาย ๆ ภาษาจึงดูซีดเซียว

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

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

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

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

อยากรู้อยากเห็นหนึ่งคำตอบสำหรับคำถามนี้แล้วในโปรแกรมเมอร์ SE

อ้างส่วนที่เกี่ยวข้อง:

ประเด็นของ Greenspun คือ (บางส่วน) ที่โปรแกรมที่ซับซ้อนจำนวนมากมีล่ามในตัว แทนที่จะสร้างล่ามให้เป็นภาษาเขาแนะนำว่ามันอาจเหมาะสมกว่าที่จะใช้ภาษาอย่าง Lisp ที่มีตัวแปล (หรือคอมไพเลอร์) อยู่แล้ว

ตอนนั้นฉันทำงานกับแอพที่ค่อนข้างใหญ่ซึ่งทำการคำนวณที่ผู้ใช้กำหนดโดยใช้ล่ามที่กำหนดเองสำหรับภาษาที่กำหนดเอง ฉันตัดสินใจลองเขียน core ใน Lisp ใหม่อีกครั้งเพื่อทดลองขนาดใหญ่

ใช้เวลาประมาณหกสัปดาห์ รหัสเดิมคือ ~ 100,000 บรรทัดของ Delphi (ตัวแปร Pascal) ใน Lisp ที่ลดลงเหลือ 10,000 บรรทัด ที่น่าแปลกใจมากขึ้นคือความจริงที่ว่า Lisp engine เร็วกว่า 3-6 เท่า และจำไว้ว่านี่เป็นผลงานของ Neophyte Lisp! ประสบการณ์ทั้งหมดนั้นค่อนข้างเปิดตาสำหรับฉัน เป็นครั้งแรกที่ฉันเห็นความเป็นไปได้ของการรวมการแสดงและการแสดงออกในภาษาเดียว
- Michael Lenaghan

เพื่อชี้แจงเพิ่มเติมในส่วนนั้น Michael ตอบกลับความคิดเห็นด้วย:

ว้าวนั่นน่าจะเป็นโค้ด Delphi ที่น่ากลัวจริงๆถ้ามันจัดการได้ช้ากว่าการใช้ Lisp ถึง 3-6 เท่า! "ใช่ฉันจะนับว่าเป็นความล้มเหลวของฉันที่ไม่อธิบายได้ดีกว่าการใช้ Lisp นั้นสามารถเปลี่ยนได้ การแสดงออกของผู้ใช้เป็นนิพจน์ Lisp - เป็นกระบวนการที่ง่ายเล็กน้อย - แล้วรวบรวมนิพจน์ Lisp ให้เป็นรหัสเนทีฟ (ด้วยการปรับให้เหมาะสมที่สุด) นั่นคือความหมายของกฎข้อที่สิบของ Greenspun
- - Michael Lenaghan

ให้คำตอบนี้ประกอบด้วยคำตอบของคนอื่นที่อื่นมันเป็น wiki ชุมชน

กฎเป็นเรื่องตลก แต่มีความจริงอยู่เล็กน้อย ระบบที่ซับซ้อนใด ๆ จะมีชิ้นส่วนที่ถูกตีความจำนวนมาก (ดูว่า "รูปแบบการตีความ" เป็นที่นิยมในหมู่ผู้ที่เชื่อในทุกรูปแบบที่ mumbo-jumbo) ระบบที่ซับซ้อนใด ๆ จะต้องจัดให้มีวิธีการกำหนดค่าบางอย่างมักจะมีโครงสร้างมักจะตีความ

ระบบที่ซับซ้อนใด ๆ มีแนวโน้มที่จะมีการสร้างรหัสผ่านจำนวนมากและตัวประมวลผลล่วงหน้าที่กำหนดเองหลายอย่างในกระบวนการสร้าง (คิดจากสิ่งต่าง ๆ เช่นmocใน Qt หรือtablegenLLVM)

ระบบจำนวนมากกำลังเล่นโครงสร้างข้อมูลที่มีลักษณะเหมือนต้นไม้ที่ซับซ้อนโดยใช้ชุดการเดินของต้นไม้ที่ออกแบบมาไม่ดีและเกือบทุกครั้งที่เครื่องมือต่าง ๆ คล้ายกับการทำงานของไลบรารีจาก Common LISP

ทุกสิ่งเหล่านี้มีให้ฟรีกับ LISP และในกรณีส่วนใหญ่สิ่งที่ไม่ได้วางแผนไว้ไม่ได้คิดว่าผ่านการติดตั้งใช้งานที่ละเอียดเพียงพอจะด้อยกว่าอย่างสิ้นเชิง

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

กฎอาจจะแม่นยำมากขึ้น (และน้อยกว่าที่น่าขบขัน) เนื่องจาก "ระบบที่ใช้ซอฟต์แวร์ขนาดใหญ่ทุกตัวจะต้องใช้พฤติกรรมแบบไดนามิก"

สามารถทำได้สองวิธี -

1. ไฟล์การกำหนดค่าที่ซับซ้อนขนาดใหญ่ที่มีพารามิเตอร์หลายสิบและหลายร้อยคำจำกัดความ

2. ภาษาสคริปต์ AD-HOC

"sendmail" น่าจะเป็นตัวอย่างที่ยอมรับได้ของประเภท "1" ฉันไม่สามารถนึกถึงตัวอย่างที่ดีของประเภท "2" ที่ไม่เกี่ยวข้องกับการฝังภาษาสคริปต์ "ของจริง" a la Warcraft / LUA หรือแม้แต่ Netscape / Javascript

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

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

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

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

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

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

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

สิ่งที่ไม่เป็นความจริงก็คือภาษาสคริปต์ที่กำหนดเองมีลักษณะคล้าย Common LISP ตัวอย่างในเชิงบวกมีลักษณะคล้ายกับ Scheme (เนื่องจากนักออกแบบที่ชาญฉลาดผสาน Guile, SpiderMonkey และ Lua แทนที่จะประดิษฐ์ภาษาของตนเอง) ตัวอย่างที่มีค่ามากที่สุดของ DailyWTF คือภาษาที่เหมือนมาและภาษาที่เหมือน MUMPS

อีกตัวอย่างหนึ่ง (ไม่แน่ใจว่านับเป็น Greenspunning แต่แน่นอนว่าเป็น WTF) คือล่าม XSLT ที่ใช้สำหรับการสร้างสคริปต์ทั่วไป นี่เป็นเหมือนเสียงกระเพื่อมมากขึ้นขณะที่พวกเขาเพิ่มลูปการตอบกลับซึ่งเอาต์พุตจะถูกแปลง XSLT เป็นครั้งที่สองดังนั้นตอนนี้คุณจึงมีมาโครได้อย่างมีประสิทธิภาพ
แรงจูงใจที่นี่แม้ว่าจะไม่ได้รับการเข้าถึงคุณลักษณะ lispy แต่เพื่อเลี่ยงขั้นตอน QA ของรหัส บริษัท (ซึ่งเพิ่มเวลาแฝง 3 สัปดาห์ในการแก้ไขข้อบกพร่องทุกครั้ง XML ถูกพิจารณาว่าเป็น "ข้อมูล" และได้รับการยกเว้นจากกระบวนการ)

แต่น่าเสียดายที่ไม่ได้!

ในขณะที่มันเป็นการดีที่สุดที่จะฝังล่าม lisp (y) จริง (javascript หรือ lua alos ทำงานได้ดี) การเพิ่ม homebrew 4gl ลงในโครงการจะลดขนาดโดยรวมในขณะที่เพิ่มความยืดหยุ่น

โครงการที่ "รหัสทุกอย่าง" มีโมดูลที่ใหญ่กว่านับและกลายเป็นเทอะทะและไม่ยืดหยุ่น