หลักการ KISS นำไปใช้กับการออกแบบภาษาการเขียนโปรแกรม?

KISS ("ทำให้มันง่ายโง่" หรือ "ทำให้มันง่าย ๆ โง่ ๆ ", ดูตัวอย่างที่นี่ ) เป็นหลักการสำคัญในการพัฒนาซอฟต์แวร์แม้ว่ามันจะมีต้นกำเนิดมาจากวิศวกรรม อ้างถึงจากบทความวิกิพีเดีย:

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

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

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

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

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

เมื่อฉันคิดว่า minimialism ผมคิดว่าเสียงกระเพื่อมและไป ด้วย Lisp สิ่งที่คุณมีคือฟังก์ชั่นและรายการต่าง ๆ ซึ่งเป็นเรื่องง่ายที่สุดเท่าที่จะทำได้ (ดีมีอีกเล็กน้อย อย่างไรก็ตามฉันคิดว่าคดี Go น่าสนใจกว่า

Go ออกแบบมาให้เรียบง่าย (เป็นการอ่านที่ดี) คำที่พวกเขาใช้คือ "ฟีเจอร์ orthogonality" ซึ่งหมายความว่าควรเพิ่มฟีเจอร์ใด ๆ หากมันมีสิ่งที่ไม่ซ้ำกันอย่างแท้จริง นี้ดูเหมือนว่าจะก้านมีผู้เขียน ( รัสค็อกซ์และร็อบหอกมาใจ) การมีส่วนร่วมกับแผน 9ซึ่งเป็น reimagination ของ UNIX ที่มีความเรียบง่ายในใจ (หากคุณสนใจในการออกแบบที่เรียบง่ายกระดาษของ Rob Pike บนระบบหน้าต่างที่เรียบง่ายเป็นการอ่านที่ดี)

นี่คือตัวอย่างง่ายๆของไวยากรณ์:

โครงสร้างลูปเดียวเท่านั้น

การวนซ้ำสามารถมีลักษณะอย่างใดอย่างหนึ่งต่อไปนี้:

วนไม่มีสิ้นสุด

for {
}

ในขณะที่วนรอบ

for <conditional> {
}

แบบดั้งเดิมสำหรับวง

for i := 0; i < 10; i++ {
}

วงหน้า

// works for maps or arrays
for k, v := range arr {
}

สวิตช์เอนกประสงค์

switch {
    // cases must be evaluate to a boolean
}

switch <value> {
}

switch t := <value>; t {
    // can use t inside
}

ผลตอบแทนหลายรายการ

return val1, val2, ...

• กำจัดความจำเป็นในการโยน (ส่งผ่านข้อผิดพลาดเป็นค่าส่งคืนล่าสุด)
• กำจัดความต้องการพารามิเตอร์ออก
• ขจัดความต้องการสิ่งอันดับ

อินเตอร์เฟซ

type X interface {
    DoSomething()
    String() string
}

• แก้ปัญหาที่คล้ายกันเป็นยาชื่อสามัญ
• อนุญาตให้ใช้นามธรรม

ฝัง

type A struct {
    Thing string
}

type B struct {
    A // embeds A in B, so B.Thing refers to A.Thing
}

• แก้ปัญหาเดียวกับการสืบทอด
• Obviates ต้องการคลาส

ช่อง

สามารถใช้ในการใช้เซมาฟอร์

var c = make(chan bool, 1)
c<-true // semaphore lock
<-c // semaphore free

ใช้สำหรับการส่งข้อความระหว่างเธรด

func produce(c chan<- bool) {
    for {
        c <- true
    }
}
func consume(c <-chan bool) {
    for {
        <-c
    }
}

var c = make(chan bool)
go produce(c)
go consume(c)

สามารถใช้เพื่อจัดการเหตุการณ์ไม่ตรงกัน

func async() chan bool {
    var c = make(chan bool)
    go doSomethingAsync(c)
    return c
}

// wait for long async process to finish
c := async()
select {
    case _ = <-c:
}

ข้อสรุป

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

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

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

if <condition>
    statement;

คุณต้องใช้เครื่องมือจัดฟันแบบหยิก:

if <condition> {
    statement;
}

มีตัวอย่างอื่น ๆ อีกมากมายในไวยากรณ์ซึ่งทำให้การอ่านโค้ดของคนอื่นง่ายขึ้น

ประโยชน์ของภาษา KISS ผ่านภาษาที่มีคุณสมบัติ:

• ง่ายต่อการเข้าใจรหัสของผู้อื่น
• เข้าใจภาษาได้ง่ายกว่า (C ++ มีชื่อเสียงในการเข้าใจยาก)
• มุ่งเน้นไปที่อัลกอริทึมไม่ใช่ไวยากรณ์

ฉันคิดว่าZen of Pythonจะระบุว่าทำไม Python เป็นภาษาแบบง่าย ๆ มากกว่าที่ฉันสามารถทำได้:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

แก้ไขเพื่อตอบสนองต่อ @Giorgio

ตามคำถามของคุณ

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

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

Python ไม่ได้บังคับให้คุณทำตามวิธีการเฉพาะเมื่อเขียนโปรแกรม ฉันสามารถเลือกที่จะปฏิบัติตามสไตล์การเขียนโปรแกรม Object-Oriented ที่เข้มงวดหรือฉันสามารถเขียนสคริปต์ง่าย ๆ เพื่อดำเนินการตามลำดับ ไม่ต้องเริ่มต้นคลาสจากนั้นเรียกmain()วิธีที่คุณถูกบังคับให้ทำใน Java เป็นสิ่งที่ดีมาก (นอกจากนี้การพิมพ์ไปยัง stdout ใน Python นั้นยอดเยี่ยม แต่นั่นก็เป็นจุดที่ค่อนข้างว่างเปล่า)

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

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

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

พิจารณาตัวอย่างเช่นระเบียบของกฎที่ล้อมรอบประเภทที่ลงนามและไม่ได้ลงนามใน C. ความซับซ้อนของกฎเหล่านี้เกิดจากความจริงที่ว่าบางรหัสใช้ประเภทจำนวนเต็มไม่ได้ลงนามเพื่อแสดงตัวเลขในขณะที่รหัสอื่น ๆ ใช้เพื่อเป็นตัวแทนสมาชิกของวงพีชคณิต (โดยเฉพาะชุดของจำนวนเต็ม mod สอดคล้องกัน2ⁿ) กฎการแปลงประเภทจะทำงานในลักษณะที่บางครั้งเหมาะสมต่อการใช้งานหนึ่งครั้งและบางครั้งก็เหมาะสมกับการใช้งานอื่น การมีการตัดคำแบบแยกและไม่ใช่แบบการแยกจะเพิ่มจำนวนของประเภทจำนวนเต็มเป็นสองเท่า แต่สามารถทำให้กฎที่เกี่ยวข้องนั้นง่ายขึ้น:

• ประเภทจำนวนเต็มใด ๆ ที่ไม่ใช่แหวนขนาดใด ๆ อาจได้รับมอบหมายให้แหวนขนาดใด ๆ แหวนอาจถูกกำหนดให้กับแหวนที่มีขนาดเท่ากันหรือเล็กกว่าเท่านั้น

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

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

• ยกเว้นดังกล่าวข้างต้นแหวนถูก จำกัด การดำเนินการกับแหวนที่มีขนาดเดียวกันหรือเล็กกว่า

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

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

เนื้อหา Tcl ได้รับการพัฒนาตามสายเหล่านี้ ภาษาทั้งหมดสามารถอธิบายได้ใน12 กฎเท่านั้นในหน้าเดียว มันเป็นเรื่องง่ายและสอดคล้องอย่างน่าทึ่ง

ผู้สร้าง Tcl อ้างว่าเป้าหมายดังต่อไปนี้:

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

จาก " History of Tcl " - http://www.tcl.tk/about/history.html

หากภาษาได้รับการแก้ไขในการออกแบบเนื่องจาก KISS มันไม่สามารถเติบโตได้ ภาษาที่ไม่สามารถเติบโตได้จะตาย

ในวิดีโอ ต่อไปนี้Guy Steeleอธิบายอย่างชาญฉลาดว่าภาษาโปรแกรมจะต้องได้รับอนุญาตให้เติบโตและทำไม หากคุณใช้ KISS แล้วจะมีวิธีการเติบโตอย่างไรกับ RFID เมื่อปล่อยออกมาแล้วมันเป็นชุดเครื่องมือที่ได้รับการแก้ไขและไม่เคยได้รับอนุญาตให้เปลี่ยน

คำปราศรัยของ Guy Steele ในการประชุม ACM OOPSLA ปี 1998 เรื่อง"Growing a Language"กล่าวถึงความสำคัญและประเด็นที่เกี่ยวข้องกับการออกแบบภาษาการเขียนโปรแกรมที่ผู้ใช้สามารถเติบโตได้

วิดีโอยาวหนึ่งชั่วโมง แต่ควรรับชม หากคุณไม่รู้ว่าใครคือ Guy Steele คุณควรพูดถึงการออกแบบภาษา

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

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

แก้ไข

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

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

นี่พูดใหญ่จากบรูซ McKinney ของไม่ยอมใครง่ายๆ Visual Basicซึ่งจะทำให้คำพูดเข้าไปในปากของนักออกแบบของพื้นฐานที่KemenyและKurtz เน้นการขุด

ภาษาคอมพิวเตอร์ทุกภาษามีความรู้สึกของตัวเองบรรยากาศของตัวเองวิญญาณของตัวเอง คุณไม่สามารถกำหนดจิตวิญญาณนี้ได้จริงๆ แต่คุณรู้ว่ามันคืออะไรเมื่อคุณเห็นมัน ฉันคิดว่าพื้นฐานเป็นสิ่งที่ตรงกันข้ามของคำสั่งประกอบกับ Albert Einstein:

ทำสิ่งต่าง ๆ ให้ง่ายที่สุดเท่าที่จะทำได้ แต่ไม่ง่ายกว่านี้

หากว่าข้อความนั้นถูกเขียนขึ้นโดยนักออกแบบดั้งเดิมของ Basic, John Kemeny และ Thomas Kurtz มันจะง่ายขึ้นอีก:

ทำสิ่งที่ง่ายกว่าที่เป็นไปได้

นั่นคือความขัดแย้งที่ไม่ยอมใครง่ายๆโปรแกรมเมอร์ Visual Basic อยู่กับ เราต้องการให้สิ่งต่าง ๆ เรียบง่ายหรูหราและใช้งานง่าย - แต่ไม่ใช่ เราต้องการให้โปรแกรมของเราสร้างแบบจำลองความเป็นจริง - แต่พวกเขาไม่ทำ เราต้องการให้ภาษาของเราที่จะทำงานในแบบที่เราคิดว่าไม่ใช่ทางคอมพิวเตอร์หรือระบบปฏิบัติการที่ต้องการให้เราคิดว่า แต่เราไม่เต็มใจที่จะจ่ายในราคา

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

มันเป็นสิ่งที่ดีที่คุณอธิบายสิ่งที่คุณหมายถึงโดย "ง่าย" เพราะในใจของฉันภาษาการเขียนโปรแกรมที่เรียบง่ายเป็นหนึ่งที่มีไวยากรณ์น้อยที่สุดและคุณสมบัติน้อย (Scheme, Forth, ML) ซึ่งไม่ได้แปลความหมายของคุณโดยตรง ฉันคิดว่าคุณกำลังมองหาการออกแบบภาษาโดยคำนึงถึง RAD (การพัฒนาแอปพลิเคชันอย่างรวดเร็ว) และมีอยู่ไม่กี่คน ดูเธรด StackOverflow นี้ตัวอย่างเช่น: /programming/66227/what-is-the-the-best-multi-platform-rad-language

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

• ไม่มีเวทย์มนตร์ที่ซ่อนอยู่ ถ้าคุณเขียนเป็นa + bC คุณจะรับประกันได้ว่ามันจะรวบรวมคำสั่งของแอสเซมเบลอร์เดียวมากที่สุด

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

• ชนิดข้อมูลนั้นง่ายอย่างที่อธิบายได้ในขณะที่ยังคงอธิบายโครงสร้างข้อมูลที่น่าสนใจทั้งหมดที่คุณอาจต้องการสร้างในหน่วยความจำ: มีเพียงประเภทพื้นฐานที่ CPU สามารถจัดการ + aggregation ( struct) + การทำซ้ำ (อาร์เรย์) + การอ้างอิง (พอยน์เตอร์) )

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

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

  ยกตัวอย่างอาร์เรย์ที่มีความยาวผันแปรใน C และ C ++: C ช่วยให้มีความยาวรันไทม์ได้ทุกที่ในขณะที่การร้องขอแบบเสรีที่สุดในการขยายมาตรฐาน C ++ จะอนุญาตเฉพาะในบริบทบางอย่างเช่นอาร์เรย์อัตโนมัติและแม้แต่ในมิติแรกเท่านั้น สิ่งนี้ทำให้ C สามารถจัดการกับอาร์เรย์หลายมิติที่แท้จริงด้วยขนาดที่รู้จักกันในรันไทม์เท่านั้นในขณะที่โปรแกรมเมอร์ C ++ จะถูกลดการเขียนdata[k + (j + i*lineLength)*lineCount]ซ้ำแล้วซ้ำอีก

  อีกตัวอย่างหนึ่งคือตัวชี้: ตัวชี้ข้อมูลใน C นี่ไม่มีอะไรมากไปกว่าตัวแปรที่เก็บที่อยู่หน่วยความจำของตัวแปรอื่น ๆ เนื่องจากตัวชี้เป็นตัวแปรตัวชี้คู่จึงเป็นสิ่งที่กำหนดไว้อย่างดี คือให้อะไรintและint*ชัดเจนว่าint**ต้องเป็นอะไร เปรียบเทียบสิ่งนี้กับการอ้างอิง C ++ ที่คุณไม่มีเงื่อนงำอะไรที่int&&ให้ความหมายของintและint&!)

มันเป็นความจริงที่ว่าความเรียบง่ายนี้ได้รับความเกลียดชัง C มาก: ความเรียบง่ายของภาษาช่วยให้โปรแกรมเมอร์มีอิสระมากกว่าที่เป็นสิ่งที่ดีสำหรับพวกเขานำไปสู่ปัญหามากมายกับพฤติกรรมที่ไม่ได้กำหนดและตัวชี้ที่ผิดพลาด โดยเฉพาะอย่างยิ่งความเรียบง่ายของฉากที่ช่วยให้โปรแกรมเมอร์เพื่อกำหนดตัวแปรเป็นint (*array[m])(struct foo* (*arg)[n])เป็นประเภทที่มีแนวโน้มที่จะให้ผู้อ่านปวดหัวเพราะสิ่งที่ซับซ้อนจริงๆสามารถแสดงในรูปแบบรัดกุมมากจากการรวมกันของเสรีนิยมคุณสมบัติง่ายๆ นี่คือประเภทของความเรียบง่ายที่ C เป็นเลิศและทำให้ชื่อเสียงของมันเป็นภาษาที่ใช้ยาก

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

Java Wikipedia - แม้ว่าจะไม่ได้ระบุไว้อย่างชัดเจนใน Wikipedia แต่ Simplifaction นั้นถูกกล่าวถึงหลายครั้งและเป็นเป้าหมายการออกแบบดั้งเดิมเนื่องจากภาษา OO ที่มีความสามารถ (คำศัพท์ที่ใช้อย่างหลวม ๆ ) ในสมัยนั้นคือ C ++ ซึ่งอย่างที่เราทุกคนรู้ แต่มีกับดักมากกว่าสองสามอย่างสำหรับคนไม่ระวัง

JVM มีจุดประสงค์เพื่อลดความซับซ้อนของการพัฒนาข้ามแพลตฟอร์มและ "เขียนทันทีที่ทำงานได้ทุกที่" กลายเป็นมนต์ Java มาสองสามปี - อีกครั้งเจตนาคือกรอบการทำงานที่ง่ายต่อการปรับใช้

ฉันเชื่อว่าภาษา C # จัดอยู่ในประเภทของการทำให้ภาษาง่ายขึ้น

หืม ... นี่เป็นคำถามที่ยากมากที่จะตอบ 'ในเชิงบวก' เพราะเมื่อฉันนึกถึงความเรียบง่ายในการออกแบบภาษาโปรแกรม (และสิ่งที่ 'ง่ายกว่า' ในการทำงานกับ) ฉันคิดทันที:

1. "ความสามารถในการอ่าน" ของโค้ด - ภาษานั้นห่อหุ้มวัตถุวิธีและอื่น ๆ ได้ดีเพียงใด
2. ความสอดคล้องของ API ภาษาและส่วนต่อประสาน

มีหลายภาษาที่ทำสิ่งเหล่านี้ได้ดี - แต่สิ่งที่ปรากฏในหัวของฉันคือภาษาที่ไม่ได้ ทำสิ่งที่ดี 'เป็นภาษาโปรแกรม': PHP

[ข้อจำกัดความรับผิดชอบ - ฉันเขียน PHP และ PHP ยังเป็น 'ไปสู่ภาษา' ของฉันสำหรับโครงการเว็บทั่วไป นี่คือคำวิจารณ์ของความรัก ... ]

อันดับแรก PHP ทำสิ่งที่ดีสำหรับสภาพแวดล้อมที่โดยปกติแล้วจะทำงานใน - เว็บเซิร์ฟเวอร์ ติดตั้งง่ายบำรุงรักษาง่าย ฯลฯ

ที่ฉันต่อสู้กับ PHP: เมื่อคุณต้องการทำบางสิ่งที่ "ผิดปกติ" - สิ่งที่คุณมักไม่ทำอยู่เป็นประจำ (ในกรณีที่ฉันคิดว่ามันใช้บริการเว็บ SOAP - ไม่ใช่สิ่งที่ฉันทำ ทำได้มากด้วย PHP) คุณต้องเผชิญกับสองตัวเลือก:

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

2) "ในตัว" ฟังก์ชั่น - ซึ่งมีอยู่เป็นจำนวนมาก ฉันได้ผ่านช่องกระต่ายไปไม่กี่ครั้งเพื่อหาห้องสมุดอื่นหรือใช้งานฟังก์ชั่นสักเล็กน้อยเพื่อที่จะสะดุดในภายหลังimpossiblyfound_basefunction()

ในความคิดของฉันความเรียบง่ายคือความสอดคล้อง

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

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

สำหรับการเขียนโปรแกรมมีตัวแบบนามธรรมที่โด่งดัง 2 ตัวอยู่:

• หนึ่งคือเครื่องจักรทัวริงซึ่งกำหนดเครื่องและแบบจำลองการเรียนการสอนง่ายๆที่สามารถคำนวณทุกสิ่งที่คอมพิวเตอร์สามารถทำได้
• อีกอย่างคือแลมบ์ดา - แคลคูลัสโดยคริสตจักรและอื่น ๆ อัล ที่เทียบเท่ากับพลังงาน

สิ่งที่สนุกคือ: ในขณะที่เครื่องทัวริงค่อนข้างเรียบง่ายในรูปแบบของมัน แต่มันไม่ใช่ระบบที่ง่ายต่อการจัดการและฉันไม่คิดว่ามันจะมีคุณสมบัติสำหรับ "smart KISS" แต่แลมบ์ดาแคลคูลัสนั้นเกี่ยวข้องกับการเขียนโปรแกรมภาษาที่เรารู้จักมากขึ้นและด้วย Lisp และ Scheme ที่เป็นผู้บุกเบิกคุณสมบัติของแลมบ์ดาแคลคูลัสมันทำให้มันเป็นภาษาจำนวนมาก

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

Lisps กำลังลดความซับซ้อนของการสร้างประโยคทั้งหมดด้วยการแนะนำรูปแบบทั่วไปสำหรับคำสั่ง:

(command param1 param2 ...)

นี่อาจเป็นการเรียกเมธอดเช่น

(max 1 2 3 4)

เช่นเดียวกับถ้าสาขาห่วง ฯลฯ

(if (< 1 2) 
    (write 4)
    (write 5))

(รหัสทั้งหมดที่นี่คือผู้ไม่เชื่อเรื่องพระเจ้าหลอกหลอก / ภาษาถิ่น)

แบบฟอร์ม

(command param1 param2 ...)

สามารถตีความได้ว่าเป็นรายการ

(item1 item2 item3)

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

คุณสมบัติอีกประการของ Lisps คือมาโครฉันจะไม่เข้าไปดูรายละเอียดที่สกปรกที่นี่ แต่เนื่องจากไม่มีความแตกต่างทางไวยากรณ์ระหว่างการเรียกใช้ฟังก์ชันปกติและ "ไวยากรณ์ (ไข่สำหรับลูป, การประกาศตัวแปร ฯลฯ ) ทุกอย่างที่ parser ต้องจัดการ ภาษาการเขียนโปรแกรม) คุณสามารถสร้างไวยากรณ์ของคุณเองมาโครเป็นสาระสำคัญการจัดการของต้นไม้ที่ถือโปรแกรมของคุณ

ฉันคิดว่า LISP มี KISS สำหรับการเขียนโปรแกรม ที่คุณสามารถจัดการกับไวยากรณ์โดยใช้แมโครได้นำไปสู่ปรากฏการณ์ที่ Lisp มีการพัฒนาค่อนข้างแบบไดนามิก ต้องการคุณสมบัติภาษาใหม่เช่น - สมมติว่าการวางแนววัตถุ - เพียงแค่เขียนระบบ OOP ด้วยมาโคร!

ในขณะที่ C ถูกขยายวงเวียน 2 ครั้งด้วยคุณสมบัติ OOP (C ++, Obj. C) เสียงกระเพื่อมขยายออกไปหลายครั้งในท้ายที่สุดก็มีผู้ชนะ

นั่นเป็นเรื่องแปลกใหม่เกี่ยวกับเสียงกระเพื่อมมันวิวัฒนาการ (ดู Clojure และ Clojurescript สำหรับการกลายพันธุ์ใหม่ที่น่าสนใจของเสียงกระเพื่อม)

สำหรับคุณสมบัติของ KISS Lisps นั้นได้รับการสนับสนุนเป็นภาษาการสอนโดยบางคน เหมือน Fogus สรุปในพิมพ์เขียวของเขาเกี่ยวกับภาษาการศึกษา ( http://blog.fogus.me/2013/01/21/enfield-a-programming-language-designed-for-pedagogy/ )

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