KISS सिद्धांत भाषा डिजाइन प्रोग्रामिंग के लिए आवेदन किया?

Question

KISS ( "इसे सरल रखें, बेवकूफ" या "यह सरल रखने बेवकूफ", जैसे देखने के लिए यहाँ ) भले ही यह जाहिरा तौर पर इंजीनियरिंग में जन्म लिया है सॉफ्टवेयर के विकास में एक महत्वपूर्ण सिद्धांत है,। विकिपीडिया लेख से उद्धृत:

जॉनसन की कहानी को डिजाइन इंजीनियरों की एक मुट्ठी भर उपकरण सौंपने की कहानी को सबसे अच्छी तरह से समझा जाता है, इस चुनौती के साथ कि जो जेट विमान वे डिजाइन कर रहे थे, केवल इन उपकरणों के साथ युद्ध की परिस्थितियों में एक औसत मैकेनिक द्वारा मरम्मत योग्य होना चाहिए। इसलिए, 'बेवकूफ' उन चीजों के बीच संबंध को संदर्भित करता है जिस तरह से चीजें टूट जाती हैं और उन्हें ठीक करने के लिए उपलब्ध परिष्कार होता है।

अगर मैं इसे सॉफ्टवेयर विकास के क्षेत्र में लागू करना चाहता था, तो मैं "सॉफ्टवेयर डेवलपर के टुकड़े" के साथ "जेट विमान", "औसत डेवलपर" के साथ "औसत डेवलपर" और "लड़ाकू परिस्थितियों में" के साथ "अपेक्षित सॉफ़्टवेयर विकास / रखरखाव" के तहत प्रतिस्थापित करूंगा। स्थितियाँ "(समय सीमा, समय की कमी, बैठकें / व्यवधान, उपलब्ध उपकरण, और इसी तरह)।

इसलिए यह आमतौर पर स्वीकार किया जाने वाला विचार है कि व्यक्ति को अल्पविराम के मामले में सॉफ़्टवेयर के एक टुकड़े को सरल (या सरल बेवकूफ ) रखने की कोशिश करनी चाहिए ताकि बाद में उस पर काम करना आसान हो सके।

लेकिन KISS सिद्धांत भाषा डिजाइन प्रोग्रामिंग करने के लिए भी लागू किया जा सकता? क्या आप ऐसी किसी भी प्रोग्रामिंग भाषा के बारे में जानते हैं जो विशेष रूप से इस सिद्धांत को ध्यान में रखकर तैयार की गई है, अर्थात "कम से कम संज्ञानात्मक प्रयास के साथ यथासंभव अधिक कोड लिखने और बनाए रखने के लिए औसत कामकाजी परिस्थितियों में एक औसत प्रोग्रामर की अनुमति दें"?

यदि आप किसी विशिष्ट भाषा का हवाला देते हैं तो यह बहुत अच्छा होगा यदि आप कुछ दस्तावेज़ों के लिए एक लिंक जोड़ सकते हैं जिसमें यह आशय भाषा डिजाइनरों द्वारा स्पष्ट रूप से व्यक्त किया गया है। किसी भी मामले में, मैं एक विशेष प्रोग्रामिंग भाषा के बारे में आपकी व्यक्तिगत राय के बजाय डिजाइनरों के (प्रलेखित) इरादों के बारे में जानना चाहूंगा।

Comments

क्या आपने भाषाओं के मूल परिवार (या कम से कम, उनके पीछे मूल इरादे) का पता लगाया है?

बुनियादी और पास्कल ... दोनों को निर्देशात्मक भाषाओं के रूप में डिज़ाइन किया गया है।

— माइकल ब्राउन

आप सरल से क्या मतलब है? अधिकांश भाषाएं बहुत सरल हैं, इसमें उनके लिए बहुत कुछ नहीं है। असेंबलर की तुलना में कुछ भी कम जटिल नहीं था। फ्रेमवर्क अक्सर जटिल होते हैं, लेकिन उन्हें "कम से कम संज्ञानात्मक प्रयास के साथ जितना संभव हो उतना कोड लिखना और बनाए रखना संभव होता है"।

— 22

स्कीम (आर) का इस्तेमाल वर्षों (दशकों तक?) के लिए एक शिक्षण भाषा के रूप में किया गया था और इसे एलआईएसपी और अल्गोल (और अधिक हो सकता है) को सरल करके विकसित किया गया था। भाषा को सिखाने के लिए SICP पुस्तक को बहुत कम समय लगता है। इसके अलावा, DSL दिमाग में आते हैं।

— vpit3833

@ जियोर्जियो का हास्केल पर एक नजर है। यह बहुत है और मेरा मतलब बहुत कम इन-बिल्ट बिट्स है। अधिकांश ऑपरेटर ऐसे कार्य हैं जो मुख्य पुस्तकालय में हैं, लेकिन भाषा के लिए आवश्यक नहीं है, यह सभी अनावश्यक टुकड़ों को हटाने के लिए बहुत बड़ी लंबाई में चला गया है

— जिम्मी हॉफ

Answer 1

जब मैं न्यूनतावाद के बारे में सोचता हूं, तो मैं लिस्प और गो के बारे में सोचता हूं । लिस्प के साथ, आपके पास सभी फ़ंक्शन और सूचियां हैं, जो लगभग सरल है जितना आप प्राप्त कर सकते हैं (ठीक है, थोड़ा और अधिक है, लेकिन जो भी है)। हालांकि, मुझे लगता है कि गो मामला अधिक दिलचस्प है।

गो को सरल होने के लिए डिज़ाइन किया गया था (यह एक सभ्य पढ़ा जाता है)। उनके द्वारा उपयोग किया जाने वाला शब्द "फीचर ऑर्थोगोनलिटी" है, जिसका अर्थ है कि किसी भी सुविधा को केवल तभी जोड़ा जाना चाहिए जब यह वास्तव में कुछ अनूठा प्रदान करता है। यह लेखकों के साथ स्टेम करने के लिए लगता है '( रस कॉक्स और रॉब पाइक को ध्यान में आता है) प्लान 9 के साथ भागीदारी , जो कि यूनिक्स की सादगी को ध्यान में रखते हुए एक पुनर्मिलन था। (यदि आप न्यूनतम डिजाइन में रुचि रखते हैं, तो एक साधारण विंडोिंग सिस्टम पर रोब पाइक का पेपर एक अच्छा पढ़ा गया है।)

यहाँ सिंटैक्स के कुछ सरल उदाहरण दिए गए हैं:

केवल एक लूपिंग निर्माण

एक लूप निम्न में से एक की तरह लग सकता है:

अनंत लूप

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
}

• विरासत के रूप में एक ही समस्या हल करती है
• कक्षाओं के लिए आवश्यक है

चैनल

सेमाफोर को लागू करने के लिए इस्तेमाल किया जा सकता है

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 भाषाओं के लाभ, यह मुहावरेदार कोड लिखने के लिए संभव है। उदाहरण के लिए, गो में, आप ऐसा कुछ नहीं लिख सकते हैं:

if <condition>
    statement;

आपको घुंघराले ब्रेसिज़ का उपयोग करना होगा:

if <condition> {
    statement;
}

वाक्य रचना में इसके कई अन्य उदाहरण हैं, जो अन्य लोगों के कोड को पढ़ना आसान बनाता है।

featureful से अधिक भाषाओं KISS भाषा के लाभ:

• दूसरों के कोड को समझना आसान है
• संपूर्ण भाषा को आसान बनाना (C ++ समझने में कठिन होने के लिए कुख्यात है)
• एल्गोरिथ्म पर ध्यान केंद्रित करें, वाक्यविन्यास पर नहीं

Comments

मेरी विनम्र राय में, की वाक्य रचना पाश के लिए पारंपरिक कि KISS नहीं है। बेशक यह हर सी-लाइक प्रोग्रामर से परिचित है, लेकिन मुझे याद है पहली बार जब मैंने यह सीखा: मैं बहुत उलझन में था। : बेसिक अधिक KISS है for i=1 to 10, या अजगर:for item in group

— mouviciel

@ माउवीसील - मैं शायद ही कभी लूप के लिए पारंपरिक का उपयोग करता हूं। के साथ समस्या for i = 1 to 10यह है कि क्या iकभी 10 होगा। यह भाषा पर निर्भर हो सकता है (बैश में 10, अजगर शामिल नहीं है)। पाश के लिए पारंपरिक सार्वभौमिक है।

— बीटगैमिट

+1, विशेष रूप से अतिसूक्ष्मवाद के लाभों के बारे में सारांश के लिए।

— जियोर्जियो

जाओ एक मामले का अध्ययन दिलचस्प है क्योंकि यह अपने विरोधियों द्वारा एक KISS भाषा नहीं माना जाता है। वास्तव में, तर्क इस तरह से चलता है: एक "सरल" भाषा "सरल" कोड या आसान समझ के लिए नेतृत्व नहीं करती है। कोड को समझने में आसान होने के लिए कभी-कभी अधिक जटिलता (कहना, अच्छा जेनरिक समर्थन) होना चाहिए।

— एंड्रेस एफ।

Answer 2

मुझे लगता है कि पायथन का ज़ेन बताता है कि क्यों पायथन एक सरल भाषा है जो मैं कर सकता हूं:

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 के जवाब में संपादित करें

जैसा कि आपके प्रश्न में कहा गया है,

"क्या आप ऐसी किसी भी प्रोग्रामिंग भाषा के बारे में जानते हैं जो विशेष रूप से इस सिद्धांत को ध्यान में रखकर तैयार की गई है, अर्थात 'कम से कम संज्ञानात्मक प्रयास के साथ यथासंभव अधिक कोड लिखने और बनाए रखने के लिए औसत कार्यशील परिस्थितियों में एक औसत प्रोग्रामर की अनुमति दें"

अजगर, मेरे लिए है, जो तुरंत मन में आता है। पायल की कार्यप्रणाली, पायल की कार्यप्रणाली के सीधे जवाब में है, प्रसिद्ध "इसमें एक से बढ़कर एक तरीके हैं"। जबकि यह बहुत अच्छा है, प्रोग्रामर को बहुत आसानी से कोड लिखने की अनुमति देता है, यह रखरखाव में मदद नहीं करता है। पर्ल में लिखे गए एक (बहुत खराब लिखा, मैं मानता हूँ) कार्यक्रम को प्रबंधित करने से पहले, मैं पायथन की सराहना करता हूं कि दोनों अच्छी कोडिंग प्रथाओं और अपने गले के नीचे की भाषा को मजबूर करने के लिए मजबूर करते हैं।

पायथन भी आपको प्रोग्राम लिखते समय एक विशेष पद्धति का पालन करने के लिए मजबूर नहीं करता है। मैं सख्त ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग शैली का पालन करना चुन सकता हूं, या मैं क्रमिक रूप से निष्पादित करने के लिए एक सरल स्क्रिप्ट लिख सकता हूं। क्लास को इनिशियलाइज़ करने के लिए नहीं है, तो main()आप जावा में ऐसा करने के लिए मजबूर हैं जैसे कि कॉल करना बहुत अच्छा है। (इसके अलावा, पायथन में स्टडआउट के लिए मुद्रण अद्भुत है, लेकिन यह एक बहुत ही अशक्त बिंदु है)।

अंत में, भाषा के साथ एक विस्तारक मानक पुस्तकालय सहित "बैटरियों शामिल" की पद्धति अद्भुत है। पैकेजों के लिए कुछ बाहरी भंडार के माध्यम से शिकार करने के बजाय, मुझे जो सबसे ज्यादा जरूरत है, वह पहले से ही भाषा में शामिल है। यह भी अच्छा है कि बाहरी रेपो, लेकिन एक बुनियादी ऑपरेशन करने के लिए इसके माध्यम से खुदाई नहीं करना वास्तव में आसान है।

Comments

उपयोगी उद्धरण के लिए धन्यवाद। क्या यह पायथन के डिजाइनर (ओं) का आधिकारिक इरादा है? इसके अलावा, ध्यान दें कि सभी पाठक पाइथन के बारे में आपकी राय से सहमत नहीं हो सकते हैं, इसलिए यह बताना शायद थोड़ा मजबूत होगा कि "पायथन एक सरल भाषा है" एक प्रसिद्ध और स्वीकृत तथ्य के रूप में है। क्या इसे तैयार करना संभव होगा क्योंकि "पायथन को सरलता के साथ दिमाग में बनाया गया था"?

— जियोर्जियो

@ जियोर्जियो - यह यहाँ के आसपास कई डेवलपर्स का अनुभव है कि अजगर वास्तव में एक सरल भाषा है। सीखने के लिए सरल, लिखने में सरल और पढ़ने में सरल। उद्धरण के बारे में, जैसा कि अजगर "बैटरी शामिल" है, आप इसे सीधे भाषा से import thisकमांड के साथ प्राप्त कर सकते हैं ।

— मौविसील

टीसीएल भी इसके लिए एक अच्छा जवाब है और आईआईआरसी भी पेरेल की जटिलता का जवाब था।

— जे.के.

@mouviciel कई स्थानों पर कुछ आश्चर्यजनक रूप से सजाए गए पायथन स्पेगेटी कोड के पार आने के बाद, मुझे नहीं लगता कि पायथन यहां अपने लक्ष्यों में सफल होता है। जब यह सरलता की बात आती है तो पायथन अधिकांश भाषाओं से बेहतर नहीं है - यह आकस्मिक रूप से बहुत अच्छा हो सकता है।

— इज़काता

अजगर तब तक सरल है जब तक लोग ज्यादातर __magic_functions __ () और @decorators से दूर रहते हैं।

— weberc2

Answer 3

"सादगी" बनाए रखने के लिए एक प्रमुख कुंजी यह पहचानना है कि जटिलता कब आवश्यक होगी, और सिस्टम के कुछ हिस्से हैं जो इसके साथ सबसे अच्छा सौदा कर सकते हैं, ऐसा करें। एक ही प्रकार का वस्तु संदर्भ होने से जो अपरिवर्तनीय मूल्यों, परस्पर मूल्यों और संस्थाओं के बीच कोई अंतर नहीं करता है, जावा को "सरल" बनाता है, मूल्यों और संस्थाओं के बीच अंतर करने की आवश्यकता को समाप्त नहीं करता है; यह केवल उपकरणों के प्रोग्रामर को उन्हें ऐसा करने में मदद करने से वंचित करता है।

आम तौर पर, यदि कोई प्रोग्रामिंग भाषा या फ्रेमवर्क सुविधा का उपयोग करने के लिए कई उपयोग के मामलों की कोशिश कर रहा है, तो एक को यह सुनिश्चित करना चाहिए कि ऐसी कोई भी स्थिति नहीं होगी जहां अलग-अलग उपयोग मामलों में अलग-अलग व्यवहार उचित होंगे, लेकिन संकलक यह बताने में असमर्थ होगा उनके अलावा। किसी भाषा या ढांचे में अधिक प्रकार जोड़ना एक जटिलता की तरह लग सकता है, लेकिन कई मामलों में यह वास्तव में चीजों को आसान बना सकता है।

उदाहरण के लिए, सी में हस्ताक्षरित और अहस्ताक्षरित प्रकारों के आसपास के नियमों की गड़बड़ी। इन नियमों की जटिलता इस तथ्य से उपजी है कि कुछ कोड संख्याओं का प्रतिनिधित्व करने के लिए अहस्ताक्षरित पूर्णांक प्रकारों का उपयोग करते हैं, जबकि अन्य कोड एक रैपिंग बीजगणितीय रिंग के सदस्यों का प्रतिनिधित्व करने के लिए उनका उपयोग करता है। (विशेष रूप से, पूर्णांक के समुच्चय समुच्चय मॉड 2।)। प्रकार रूपांतरण नियम उन तरीकों से व्यवहार करते हैं जो कभी-कभी एक उपयोग के लिए उपयुक्त होते हैं, और कभी-कभी दूसरे के लिए उपयुक्त तरीके से। अलग-अलग रैपिंग और नॉन-रैपिंग प्रकार पूर्णांक प्रकारों की संख्या को दोगुना कर देंगे, लेकिन उनके साथ जुड़े नियमों को सरल बना सकते हैं:

• किसी भी आकार के किसी भी गैर-रिंग पूर्णांक प्रकार को किसी भी आकार की अंगूठी को सौंपा जा सकता है; एक अंगूठी को केवल समान या छोटे आकार की अंगूठी को सौंपा जा सकता है ।

• गैर-रिंग पूर्णांक और एक रिंग से जुड़े रिलेशनल ऑपरेटर्स के अलावा अन्य ऑपरेशन, पूर्णांक को रिंग प्रकार में बदल देंगे।

• अंगूठियां स्पष्ट रूप से संख्या या बड़े छल्ले के लिए डाली जा सकती हैं; एक अहस्ताक्षरित रिंग का मान सबसे छोटा गैर-ऋणात्मक पूर्णांक है, जो जब रिंग के शून्य में जोड़ा जाता है, तो रिंग मूल्य प्राप्त होगा। एक हस्ताक्षरित अंगूठी का मूल्य सबसे छोटा-परिमाण पूर्णांक है, जो जब रिंग के शून्य में जोड़ा जाता है, तो रिंग मूल्य प्राप्त होगा, जिसमें एक टाई के मामले में नकारात्मक मूल्य को प्राथमिकता दी जाएगी।

• जैसा कि ऊपर उल्लेख किया गया है, को छोड़कर, छल्ले एक ही आकार के छल्ले या छोटे के साथ संचालन तक सीमित हैं।

• विभिन्न प्रकारों के गैर-रिंग पूर्णांक पर संचालन को संख्याओं को एक प्रकार तक सीमित करना चाहिए जो किसी भी ऑपरेंड के सभी मूल्यों को समायोजित कर सकते हैं, या संकलक द्वारा अस्वीकार कर दिया जाना चाहिए यदि कोई उपयुक्त प्रकार मौजूद नहीं है

रिंग प्रकार को परिभाषित करना पूर्णांक प्रकारों की संख्या को दोगुना करने के लिए प्रतीत होता है, लेकिन पोर्टेबल कोड के लेखन को बहुत सरल करेगा। संख्याओं और छल्लों के लिए समान अहस्ताक्षरित प्रकारों का उपयोग करने से प्रकारों की संख्या कम हो जाती है, लेकिन जटिल नियम बन जाते हैं जिससे कुशल पोर्टेबल कोड लिखना लगभग असंभव हो जाता है।

Comments

+1 पूरी तरह से सहमत है। एक "सरल" भाषा (एक छोटी कल्पना होने के अर्थ में सरल) जरूरी नहीं कि सरल कोड हो, या प्रोग्रामर के लिए तर्क में आसानी हो।

— एंड्रेस एफ

शानदार टिप्पणी। जटिलता को जोड़ना लागतों और लाभों के संदर्भ में देखा जाना चाहिए।

— user1071847

Answer 4

संभवतः, इन लाइनों के साथ Tcl विकसित किया गया था। संपूर्ण भाषा को एक ही आदमी पृष्ठ पर केवल 12 नियमों में वर्णित किया जा सकता है । यह उल्लेखनीय रूप से सरल और सुसंगत है।

Tcl के निर्माता ने मूल लक्ष्यों के रूप में निम्नलिखित का दावा किया:

• भाषा को एक्स्टेंसिबल होना चाहिए: प्रत्येक एप्लिकेशन के लिए भाषा की बुनियादी विशेषताओं में अपनी विशेषताओं को जोड़ना बहुत आसान होना चाहिए, और एप्लिकेशन-विशिष्ट विशेषताएं प्राकृतिक दिखनी चाहिए, जैसे कि उन्हें शुरू से ही भाषा में डिज़ाइन किया गया था।
• भाषा बहुत सरल और सामान्य होनी चाहिए, ताकि यह कई अलग-अलग अनुप्रयोगों के साथ आसानी से काम कर सके और ताकि यह उन विशेषताओं को प्रतिबंधित न कर सके जो अनुप्रयोग प्रदान कर सकते हैं।
• चूंकि अधिकांश दिलचस्प कार्यक्षमता एप्लिकेशन से आएगी, इसलिए भाषा का प्राथमिक उद्देश्य एक्सटेंशन को एकीकृत या "एक साथ गोंद" करना है। इस प्रकार भाषा में एकीकरण के लिए अच्छी सुविधाएं होनी चाहिए।

" Tcl का इतिहास " से - http://www.tcl.tk/about/history.html

Answer 5

एक भाषा KISS की वजह से इसकी डिजाइन में तय हो गई है, तो यह हो जाना नहीं कर सकते। एक भाषा जो विकसित नहीं हो सकती है वह मर जाएगी।

निम्नलिखित वीडियो में गाइ स्टील ने चतुराई से बताया कि एक प्रोग्रामिंग भाषा को बढ़ने की अनुमति दी जानी चाहिए और क्यों। आप KISS लागू होते हैं, तो कैसे एक भाषा के बढ़ सकता है क्योंकि एक बार जारी की है, यह टूल का सेट तय हो गई है और परिवर्तन करने की अनुमति दी कभी नहीं।

1998 में ACM OOPSLA सम्मेलन में "ग्रोइंग ए लैंग्वेज" पर गाइ स्टील के मुख्य वक्ता ने एक प्रोग्रामिंग भाषा को डिजाइन करने से जुड़े मुद्दों और उनके महत्व पर चर्चा की, जो इसके उपयोगकर्ताओं द्वारा उगाए जा सकते हैं।

यह एक घंटे लंबा वीडियो है, लेकिन देखने लायक है। अगर आपको नहीं पता कि गाइ स्टील कौन है, तो आपको वास्तव में भाषा डिजाइन के बारे में बात करनी चाहिए।

मैं क्योंकि मुझे विश्वास है कि सामान्य रूप में भाषा डिजाइन करने के लिए KISS लागू करने के गलत है, और उम्मीद है कि भाषा डिजाइन के एक प्रख्यात व्यक्ति से एक भाषण देखकर भाषा डिजाइन के भविष्य के बारे में अपनी समझ का विस्तार करने में मदद मिलेगी जवाब के रूप में इस वीडियो को चुनें।

आप यहाँ भाषा डिजाइन के बारे में जानने के लिए आया था और मैं तुम्हें उपयोग को चूमने के लिए नहीं एक कारण नहीं बताया है कि यह केवल उचित है कि मैं कुछ है कि मैं भाषा डिजाइन में मदद की लगता है का कहना है के बाद से। संकेतन के संज्ञानात्मक आयाम

संपादित करें

जब मैंने उपर्युक्त उत्तर लिखा तो यह तर्क पर आधारित था: यदि किसी इंजन को केवल उपकरणों के एक निश्चित समूह के साथ बनाए रखा जा सकता है, तो भाषा डिजाइन के संबंध में उस अर्थ का मेरा सुधार यह है कि एक बार रिलीज़ होने पर कोई भाषा नहीं बदल सकती है। टिप्पणियाँ इंगित कर रही हैं कि वह नहीं था जो कि था। तो मुझे इस संशोधित उत्तर को सामने रखना चाहिए जो संशोधित समझ के साथ अधिक इन-लाइन होगा।

यदि कोई संकेतन के संज्ञानात्मक आयामों पर एक नज़र डालता है, तो एक सीखता है कि भाषा की डिजाइन से जुड़े कई प्रतिस्पर्धी आयाम हैं, जो केवल सादगी से अधिक है और यदि आप एक पर बहुत अधिक ध्यान केंद्रित करते हैं, तो आप दूसरों में पीड़ित होंगे। की पर सादगी (चुंबन) अच्छा भारी ध्यान दे रहा है, और भाषा डिजाइन के विख्यात लोगों द्वारा समर्थित प्रश्न के साथ, मैं प्रस्तुत भाषण से लड़का स्टील पता चलता है कि एक डिजाइन पूरी तरह से सरल रखने की कोशिश कर अन्य आयामों को प्रभावित करेगा। इससे भी महत्वपूर्ण बात यह है कि मैं यह बताने की कोशिश कर रहा हूं कि आपको कई आयामों को देखना होगा और केवल सादगी ही नहीं बल्कि उनके पक्ष और विपक्ष को भी तराशना होगा।

Comments

तो, अगर वीडियो अनुपलब्ध हो जाए तो क्या होगा? या अगर यह कुछ देशों में सुलभ नहीं है? आपका उत्तर पूर्ण और स्व समाहित होना चाहिए, कृपया इसे अपडेट करें कम से कम हमें वीडियो का एक संक्षिप्त सारांश दें, लिंक केवल उत्तर वास्तव में सहायक नहीं हैं और किसी भी समय हटाया जा सकता है।

— यानिस डे

@AndreasScheinert गाइड का जवाब देने का तरीका यह स्पष्ट करता है कि लिंक हमेशा सारांश और / या प्रासंगिक कोटेशन के साथ होना चाहिए।

— थॉमस ओवेन्स

मुझे यकीन नहीं है कि मैं आपके आकलन से सहमत हो सकता हूं। उदाहरण के लिए, Tcl उल्लेखनीय रूप से सरल है। इसके उपयोग को नियंत्रित करने वाले केवल 11 नियमों के साथ यह वर्षों तक चला। फिर भी, यह जितना सरल है, यह अपने अस्तित्व के 20+ वर्षों में काफी बढ़ गया है। अब इसके 12 नियम हैं, जो यह साबित करते हैं कि न केवल इसकी लाइब्रेरी बढ़ी है, बल्कि इसकी मौलिक प्रकृति को भी इसकी सादगी को बरकरार रखते हुए बढ़ने की अनुमति दी गई है।

— ब्रायन ओकले

"आप KISS लागू होते हैं, तो कैसे एक भाषा बढ़ सकता है क्योंकि एक बार जारी की है, यह टूल का सेट तय हो गई है और परिवर्तन करने की अनुमति दी कभी नहीं।": यह निर्भर करता है कि आप साधारण से और बढ़ रही द्वारा क्या मतलब है। क्या आपका मतलब है नई लाइब्रेरी (अंग्रेजी में, शब्दावली में नए शब्द जोड़ना) या नए भाषा निर्माण को जोड़ना (अंग्रेजी में इसका मतलब होगा जोड़ना, जैसे नए क्रिया काल, नए प्रस्ताव, और इसी तरह)। प्राकृतिक भाषाएं अंततः नए व्याकरण के नियमों को जोड़ना बंद कर देती हैं जबकि वे नए शब्द जोड़ते रहते हैं। इसलिए मेरे अंतर्ज्ञान में, सरल व्याकरण के नियमों की संख्या को संदर्भित करता है, पुस्तकालयों / शब्दों की संख्या के बजाय।

— जियोर्जियो

@Guy कोडर: दूसरी ओर, वीडियो जिसे आपने एक लिंक पोस्ट किया है, जो आपके उत्तर की शुरुआत में कुछ अलग कहने पर लगता है कि आप क्या कहते हैं, अर्थात् यह कि भाषा को कुछ मुख्य विशेषताएं प्रदान करनी चाहिए जो इसके उपयोगकर्ताओं (प्रोग्रामर) को अनुमति दें भाषा का विस्तार करें (नए पुस्तकालय जोड़ें)। यह नहीं कहता है कि मूल भाषा को अनिश्चित काल तक बढ़ना चाहिए।

— जियोर्जियो

Answer 6

यहाँ ब्रूस मैकिन्नी के हार्डकोर विज़ुअल बेसिक का एक बड़ा उद्धरण है , जो बदले में BASIC, Kemeny और Kurtz के डिजाइनरों के मुंह में शब्द डालता है । मेरा जोर देता है।

हर कंप्यूटर की भाषा की अपनी अनुभूति, अपना माहौल, अपनी भावना होती है। आप वास्तव में इस भावना को परिभाषित नहीं कर सकते हैं, लेकिन आप जानते हैं कि यह क्या है जब आप इसे देखते हैं। मैं बेसिक के बारे में अल्बर्ट आइंस्टीन को जिम्मेदार ठहराते हुए एक बयान के विरोधी के रूप में सोचता हूं:

जितना हो सके चीजों को सरल बनाएं - लेकिन कोई सरल नहीं।

उस उद्धरण को बेसिक, जॉन कोमेनी और थॉमस कुर्तज़ के मूल डिजाइनरों द्वारा लिखा गया था, इसे और सरल बनाया गया होगा:

चीजों को संभव से ज्यादा सरल बनाएं।

यही विरोधाभास हार्डकोर विजुअल बेसिक प्रोग्रामर के साथ रहता है। हम चाहते हैं कि चीजें सरल, सुरुचिपूर्ण और सहज हों- लेकिन वे नहीं हैं। हम अपने कार्यक्रमों को वास्तविकता से जोड़ना चाहते हैं - लेकिन वे नहीं करते। हम चाहते हैं कि हमारी भाषा हमारे सोचने के तरीके पर काम करे, न कि जिस तरह से कंप्यूटर या ऑपरेटिंग सिस्टम हमें सोचना चाहते हैं - लेकिन हम कीमत चुकाने को तैयार नहीं हैं ।

Comments

संबंधित नोट पर, यह तथ्य कि कई उद्देश्यों की पूर्ति के लिए एक भाषा का निर्माण "किया जा सकता है" का मतलब यह नहीं है कि इस तरह के डिजाइन उन विभिन्न उद्देश्यों के लिए अलग-अलग निर्माण करने के लिए बेहतर है। उदाहरण के लिए, सी संख्यात्मक मात्रा का प्रतिनिधित्व करने के लिए और एक रैपिंग बीजीय अंगूठी के सदस्यों का प्रतिनिधित्व करने के लिए अहस्ताक्षरित प्रकारों का उपयोग करता है। की संख्या को जोड़ते किसी भी एक अंगूठी के आकार या signedness के एक सदस्य उपज चाहिए एक ही अंगूठी है, जबकि किसी भी आकार और signedness के दो नंबर शामिल करने के परिणामस्वरूप बड़ा पर्याप्त या तो संकार्य के किसी भी मूल्य को संभालने के लिए उपज चाहिए। दोनों उद्देश्यों के लिए अहस्ताक्षरित प्रकारों का उपयोग ...

— सुपरकैट

... इसका मतलब है कि सी के नियमों को कभी-कभी उन्हें संख्या के रूप में और कभी-कभी रिंग सदस्यों के रूप में माना जाता है, ऐसे तरीकों से जो साफ, पोर्टेबल कोड लिखना लगभग असंभव बना देते हैं।

— सुपरकैट

Answer 7

लेकिन KISS सिद्धांत भाषा डिजाइन प्रोग्रामिंग करने के लिए भी लागू किया जा सकता? क्या आप ऐसी किसी भी प्रोग्रामिंग भाषा के बारे में जानते हैं जो विशेष रूप से इस सिद्धांत को ध्यान में रखकर तैयार की गई है, अर्थात "कम से कम संज्ञानात्मक प्रयास के साथ यथासंभव अधिक कोड लिखने और बनाए रखने के लिए औसत कामकाजी परिस्थितियों में एक औसत प्रोग्रामर की अनुमति दें"?

यह एक अच्छी बात है कि आपने स्पष्ट किया कि आप "सरल" से क्या मतलब है, क्योंकि मेरे दिमाग में एक सरल प्रोग्रामिंग भाषा न्यूनतम वाक्यविन्यास और कुछ विशेषताओं (स्कीम, फोर्थ, एमएल) के साथ एक है, जो सीधे आपकी परिभाषा में अनुवाद नहीं करती है। मुझे लगता है कि आप वास्तव में RAD (तेजी से अनुप्रयोग विकास) के साथ भाषाओं के डिजाइन की तलाश कर रहे हैं, और उनमें से काफी कुछ हैं। इस StackOverflow धागे को देखें, उदाहरण के लिए: /programming/66227/what-is-the-best-multi-platform-rad-language

Comments

"क्योंकि मेरे दिमाग में एक साधारण प्रोग्रामिंग भाषा न्यूनतम वाक्यविन्यास और कुछ विशेषताओं (स्कीम, फोर्थ, एमएल) के साथ एक है": ठीक है, वास्तव में मैंने विकिपीडिया से परिभाषा की नकल की है लेकिन मैं दो चीजों की पहचान करता हूं। जैसे, स्कीम को बहुत जल्दी सीखा जा सकता है और उसके बाद मैं समस्या को हल करने पर ध्यान केंद्रित कर सकता हूं। अन्य भाषाएं (जैसे सी ++, जो मैं काम में उपयोग करता हूं) बढ़ती रहती हैं और आपको हर समय नया सामान सीखना होता है। इसके अलावा, कोड कम बनाए रखने योग्य हो जाता है क्योंकि विभिन्न प्रोग्रामर भाषा के विभिन्न सबसेट का उपयोग करते हैं। तो, मैं एसएमएल और योजना "सरल" पर विचार करेंगे।

— जियोर्जियो

Answer 8

मुझे आश्चर्य है कि किसी ने अभी तक सी का उल्लेख नहीं किया है, भले ही यह सादगी को कई महत्वपूर्ण तरीकों से पहले रखता है, अक्सर ऐसे कट्टरपंथी तरीके से, जो प्रोग्रामर सादगी की सराहना करने में विफल होते हैं:

• कोई छिपा हुआ जादू नहीं है। यदि आप a + bC में लिखते हैं , तो आपके पास गारंटी है कि यह एक ही कोडांतरक अनुदेश को संकलित करेगा।

  जावा जैसी अपेक्षाकृत सरल भाषाओं में भी, एक सरल कथन जैसे a + bकई माइक्रोसेकंड (यदि चर तार हैं) हो सकते हैं। अन्य भाषाओं में बहुत कुछ जोड़ा जाता है, C ++ के चरम उदाहरण के साथ जहां a + bगुलाबी हाथियों को दिखाई देने के लिए अतिभारित किया जा सकता है। C में ऐसा नहीं है: यदि यह एक फ़ंक्शन कॉल नहीं है, तो यह कुछ नैनोसेकंड से अधिक नहीं लेगा। प्रदर्शन की यह भविष्यवाणी सी की प्रमुख विशेषताओं में से एक है, और यह निश्चित रूप से सादगी का एक रूप है।

• डेटा प्रकार उतने ही सरल होते हैं, जितने दिलचस्प डेटा संरचनाओं का वर्णन करते समय आप कर सकते हैं, जिन्हें आप मेमोरी में बनाना चाहते हैं: केवल मौलिक प्रकार हैं जो सीपीयू + एकत्रीकरण ( struct) + पुनरावृत्ति (सरणियाँ) + संदर्भ (पॉइंटर्स) को संभाल सकता है )।

  यह सच है कि विभिन्न लिस्प-आधारित भाषाएँ इस संबंध में C से बहुत सरल हैं। हालांकि, वे प्रोग्रामर को स्वतंत्र रूप से मेमोरी में हेरफेर करने की अनुमति देने की कोशिश नहीं करते हैं जैसा कि सी करता है।

• सुविधाओं की रूढ़िवादिता: आप स्वतंत्र रूप से सुविधाओं को जोड़ सकते हैं और वे अपेक्षित रूप से एक साथ काम करेंगे। कई भाषाएं कुछ निश्चित निर्माणों को केवल परिभाषित संदर्भों में प्रकट होने की अनुमति देकर इसे विफल करती हैं।

  उदाहरण के लिए C और C ++ में वैरिएबल लेंथ सरणियों को लें: C हर जगह रनटाइम लंबाई की अनुमति देता है, जबकि C ++ मानक का विस्तार करने के लिए सबसे उदार अनुरोध स्वत: सरणियों जैसे कुछ संदर्भों में और यहां तक ​​कि केवल पहले आयाम में ही उन्हें अनुमति देता है। यह C को केवल रनटाइम पर ज्ञात आकारों के साथ सच्चे बहुआयामी सरणियों को संभालने की अनुमति देता है, जबकि C ++ प्रोग्रामर को data[k + (j + i*lineLength)*lineCount]बार-बार लिखने के लिए कम किया जाता है ।

  इसका एक और उदाहरण सूचक है: C में एक डेटा सूचक वास्तव में कुछ अन्य चर की स्मृति पता रखने वाले चर से कम या ज्यादा नहीं है। चूंकि पॉइंटर अपने आप में एक चर है, इसलिए डबल पॉइंटर एक अच्छी तरह से परिभाषित चीज है। Ie ने क्या दिया intऔर क्या है int*, यह स्पष्ट है कि क्या int**होना चाहिए। इसकी तुलना C ++ सन्दर्भों से करें जहाँ आपके पास कोई सुराग नहीं है कि int&&इसका अर्थ क्या है intऔर int&!)

यह सच है कि यह वास्तव में यह सरलता है जिसने सी को इतनी घृणा अर्जित की है: भाषा की सरलता प्रोग्रामर्स को उनके लिए और अधिक स्वतंत्रता की अनुमति देती है, जिसके कारण अपरिभाषित व्यवहार और गलत संकेत के साथ बहुत सारी समस्याएं होती हैं। विशेष रूप से ऑर्थोगोनलिटी की सादगी जो एक प्रोग्रामर को एक वैरिएबल को परिभाषित करने की अनुमति देती int (*array[m])(struct foo* (*arg)[n])है, जो उस प्रकार का है जो पाठकों को सिरदर्द देता है क्योंकि वास्तव में कुछ साधारण सुविधाओं के उदार संयोजन से जटिल सामग्री को बहुत संक्षिप्त रूप में व्यक्त किया जा सकता है । यह सरलता का प्रकार है, जिस पर C उत्कृष्टता प्राप्त करता है, और जो इसे उपयोग करने के लिए एक कठिन भाषा होने की प्रतिष्ठा देता है।

इसके अलावा, भाषा की सादगी प्रोग्रामर को अधिक फीचर-समृद्ध भाषाओं की तुलना में बहुत अधिक कोड लिखने के लिए मजबूर करती है, जो बग के पनपने के लिए अधिक उपजाऊ जमीन प्रदान करती है। फिर भी, यह सबसे सरल संभव उच्च-स्तरीय भाषा बनी हुई है यदि आपका प्राथमिक उद्देश्य एक वास्तविक कंप्यूटर को प्रोग्राम करना है और कुछ वर्चुअल मशीन नहीं है।

Comments

क्या डाउनवॉटर उनके वोट का कारण बताते हुए एक संदेश छोड़ सकता है?

— जियोर्जियो

सी एक गड़बड़ है। यदि आप एक हस्ताक्षर किए गए शॉर्ट को एक अहस्ताक्षरित लंबे समय तक जोड़ते हैं, तो परिणाम प्राप्त करने का प्रयास करें और परिणाम को एक इंट में संग्रहीत करें। यहां तक ​​कि "लंबे समय तक" के बिना, इसके आठ अलग-अलग पूर्णांक प्रकार हैं। यह आसान नहीं है।

— साइमन बी

@SimonB आप स्पष्ट रूप से समझ नहीं पाए हैं कि मेरी पोस्ट क्या है। पूर्णांक प्रकारों के बारे में सरलता यह है: एक पूर्णांक प्रकार का आकार (बाइट्स और बिट्स में) होता है, और हस्ताक्षरित या अहस्ताक्षरित हो सकता है। आप इन दो ऑर्थोगोनल विशेषताओं के किसी भी संयोजन का उपयोग कर सकते हैं। यह इस orthogonality है जिसके बारे में मैं बात कर रहा हूँ। सी में सभी विशेषताएं हैं जो वास्तविक हार्डवेयर का पूरी तरह से दोहन करने के लिए आवश्यक हैं, और यह एक निश्चित जटिलता को दर्शाता है। हालांकि, सी जिस तरह से इस जटिलता से निपटता है, वह प्रोग्रामर को जटिल चीजें करने के लिए ऑर्थोगोनल फैशन में सरल अवधारणाओं को मिलाकर है ।

— विस्फ़ोटक -

Answer 9

जावा विकिपीडिया - यद्यपि स्पष्ट रूप से विकिपीडिया में नहीं कहा गया है, सरलीकरण का कई बार उल्लेख किया गया है और यह एक मूल डिजाइन लक्ष्य था, क्योंकि उन दिनों में एकमात्र गंभीर OO सक्षम (टर्म प्रयुक्त शिथिल) भाषा C ++ थी, जिसे हम सभी जानते हैं, शक्तिशाली है लेकिन कुछ जाल के लिए अधिक से अधिक जाल है।

JVM को क्रॉस प्लेटफॉर्म डेवलपमेंट को सरल बनाने के तरीके के रूप में किया गया था, और "एक बार कहीं भी लिखें" कुछ वर्षों के लिए जावा मंत्र बन गया - फिर से, इरादा था कि फ्रेमवर्क को तैनात करना सरल था।

मेरा मानना ​​है कि C # भाषा के सरलीकरण की श्रेणी में आता है।

Comments

क्या आपका मतलब है कि C # को भी शुरू में C ++ के सरलीकरण के रूप में तैयार किया गया था?

— जियोर्जियो

C ++ और OO? एलन Kay ऐसा नहीं सोचता। सी # Sinplyfication ???? मैं नहीं जानता कि आप सरल से क्या मतलब है। मुझे लगता है कि चीजों को इस तरह से घोषित करने से पहले आपको यह बताना सबसे अच्छा होगा। LISP सरल है क्योंकि इसमें बहुत कम वाक्यविन्यास हैं। इसके विपरीत C # में वाक्य रचना और कीवर्ड के शब्द हैं।

— एंड्रियाशेचेर्ट

क्रॉस-प्लेटफॉर्म विकास को सरल बनाने की क्षमता का मतलब यह नहीं है कि भाषा सरल है। कुछ क्रॉस-प्लेटफ़ॉर्म हो सकता है फिर भी सरल और अपने आप में नहीं।

— ब्रायन ओकले

@ ब्रायन सहमत - जावा के डिजाइन ने ध्यान में रखा कि क्रॉस प्लेटफॉर्म प्रोग्राम (उस समय) सरल नहीं थे, और सरल प्रोग्राम बनाने के लिए, आपको प्रोग्राम में ही मंच विशिष्ट कोड को संभालने की जटिलता को हटाने के लिए एक सरल भाषा की आवश्यकता थी।

— मटनज

@ जियोर्जियो सी # जावा का एक पुनर्मिलन था। जावा का उद्देश्य सी ++ की तुलना में कम जटिल था (उदाहरण के लिए कोई बहु विरासत नहीं) और कुछ अधिक बड़ा (उदाहरण के लिए विशाल मानक पुस्तकालय, माला संग्रह)।

— सीन मैकोसमेलिंग

Answer 10

हम्म ... यह वास्तव में 'सकारात्मक रूप से' का जवाब देने के लिए एक कठिन सवाल है, क्योंकि जब मैं प्रोग्रामिंग भाषा डिजाइन में सादगी के बारे में सोचता हूं (और इसके साथ काम करने में क्या आसान है), मैं तुरंत सोचता हूं:

1. "पठनीयता" कोड की - कैसे अच्छी तरह से भाषा समाहित वस्तुओं, तरीकों, आदि
2. भाषा एपीआई और इंटरफेस की स्थिरता।

भाषाओं कि इन बातों को अच्छी तरह से करने की एक संख्या हैं - लेकिन क्या मेरे सिर में पॉप एक भाषा है कि नहीं करता है 'एक प्रोग्रामिंग भाषा के रूप में' अच्छी तरह से काम करते हैं: PHP।

[अस्वीकरण - मैंने लिखा है PHP और PHP अभी भी सरल वेब परियोजनाओं के लिए मेरी 'भाषा पर जाएं' है। यह प्रेम की आलोचना है ...]

सबसे पहले, PHP पर्यावरण के लिए अच्छी तरह से करता है कि यह आमतौर पर वेब सर्वर में चलता है। इसे स्थापित करना आसान है, बनाए रखना आसान है, आदि।

नहीं कुछ मैंने - जब आप कुछ 'असामान्य' क्या करना चाहते हैं - कुछ है कि आप आमतौर पर एक नियमित आधार पर ऐसा नहीं करते हैं (मामले मैं इसके बारे में सोच रहा हूँ एक सोप वेब सेवा लेने वाली किया गया था में: जहां मैं PHP के साथ संघर्ष PHP के साथ बहुत कुछ किया), आप दो विकल्पों के साथ सामना कर रहे हैं:

1) PHP के लिए विभिन्न खुले स्रोत एक्सटेंशन। PHP ऑब्जेक्ट मॉडल पर्याप्त ढीला है जहां इंटरफ़ेस डिज़ाइन भी लाइब्रेरी से लाइब्रेरी, डेवलपर से डेवलपर तक बहुत अनुकूल नहीं है। जब कोड के एक सेट के साथ सामना किया जाता है जहां किसी ने एक पुस्तकालय का उपयोग किया है जिसके बारे में आपने कभी नहीं सुना है, तो आप बहुत समय बिताते हैं जो यह बताता है कि यह क्या करता है 'क्योंकि भाषा ढीली एपीआई / पुस्तकालय निर्माण के लिए अनुमति देती है।

2) "बिल्ट-इन" फ़ंक्शन - जिनमें से बहुत सारे हैं । मैं या तो किसी अन्य पुस्तकालय को खोजने या बाद में ठोकर खाने पर किसी तरह की कार्यक्षमता को लागू करने के कुछ खरगोश छेद से गुजरा हूंimpossiblyfound_basefunction()

मेरी राय में, सादगी स्थिरता है।

Answer 11

अब, प्रोग्रामिंग भाषाओं को KISS दृष्टिकोण एक अजीब धारणा, यदि आप भाषाओं प्रोग्रामिंग एक CPU के अनुदेश सेट, आदि के लिए एक अमूर्त परत पर विचार कम से कम आपके द्वारा निर्धारित नहीं करते हैं "किस" और अधिक बारीकी से है। मैं बस यहाँ कह रहा हूँ, एक OXCART KISS अपनी पूर्णता के साथ एक कार के लिए आवेदन किया है।

अब KISS की एक और व्याख्या की तरह "चालाकी से अनावश्यक गहने के बिना किया और वह बहुत जटिल नहीं" कुछ हो सकता है। विशेष रूप से एक यह तर्क दे सकता है कि समान चीजों के लिए बहुत अधिक विशिष्ट मामले नहीं होने चाहिए, आदि आमतौर पर गणित अपने सार में सामान को उबालने में काफी अच्छा है, और - ओ आश्चर्य - गणितज्ञों ने प्रोग्रामिंग और कंप्यूटर के बारे में भी सोचने में कुछ समय बिताया है ।

प्रोग्रामिंग के लिए, 2 काफी प्रसिद्ध सार मॉडल मौजूद हैं:

• एक ट्यूरिंग मशीन है जो एक मशीन और एक सरल निर्देशात्मक मॉडल को परिभाषित करता है जो एक कंप्यूटर जो कुछ भी कर सकता है, उसे गणना करने में सक्षम है।
• चर्च एट द्वारा अन्य एक लैम्बडा-कैलकुलस है। अल। यह सत्ता में बराबर है

मज़ा बात है: एक ओर जहां ट्यूरिंग मशीन अपने लेआउट में काफी सरल है, यह एक ऐसी प्रणाली संभाल करने के लिए आसान है कि नहीं है और मैं इसे "स्मार्ट किस" के लिए उत्तीर्ण नहीं लगता। लेकिन लैम्ब्डा कैलकुलस का प्रोग्रामिंग भाषाओं के साथ अधिक है जो हम जानते हैं - और लिम्बडा कैलकुलस की लिस्प और स्कीम अग्रणी विशेषताओं के साथ इसने कई भाषाओं में अपना रास्ता बना लिया है।

लिस्प और स्कीम वास्तव में सरल हैं, कम से कम वाक्यविन्यास बुद्धिमान हैं। प्रोग्रामिंग भाषाओं के साथ सिंटैक्स एक बड़ी समस्या है (जो शायद इसीलिए उन्हें हर समय पुष्ट किया जाता है)। C ++ के मामले में मानव मस्तिष्क के लिए यह अनुमान लगाना लगभग असंभव है कि संकलक द्वारा कुछ स्रोत रेखाओं की व्याख्या कैसे की जाती है।)

लिस्प्स आज्ञाओं के लिए एक सामान्य रूप को प्रस्तुत करके वाक्य रचना की जटिलता को पूरी तरह से कम कर रहे हैं:

(command param1 param2 ...)

इस तरह के रूप में एक विधि कॉल, हो सकता है

(max 1 2 3 4)

साथ ही अगर एक शाखा, लूप आदि।

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

(यहाँ सभी कोड छद्म लिस्प / बोली अज्ञेय है)

फार्म

(command param1 param2 ...)

एक सूची के रूप में भी व्याख्या की जा सकती है

(item1 item2 item3)

और यही लिस्प्स सादगी और सुंदरता का आधार है। क्योंकि नेस्टेड सूचियों (जैसे ifकथन उदाहरण में) पेड़ों का निर्माण करती हैं और जिन्हें मशीन द्वारा और मशीन के सामने मानव द्वारा आसानी से समझा जा सकता है।

लिस्प्स की एक अन्य विशेषता मैक्रोज़ हैं जो मैं यहां गंदे विस्तार में नहीं जाऊंगा, लेकिन चूंकि सामान्य फ़ंक्शन कॉल और "सिंटैक्स (अंडाकार छोरों के लिए अंडा), चर घोषणा, आदि के बीच कोई वाक्यात्मक अंतर नहीं है, जो कुछ भी पार्सर को दूसरे में संभालना पड़ता है। प्रोग्रामिंग लैंग्वेज) आप अपना स्वयं का सिंटैक्स बना सकते हैं। मैक्रोज़ सार में हैं ट्री ऑफ मैनिपुलेशन जो आपके प्रोग्राम का गठन करता है।

मुझे लगता है कि लिस्प प्रोग्रामिंग करने के लिए एक KISS है। यह कि आप मैक्रो का उपयोग करके वाक्यविन्यास में हेरफेर कर सकते हैं, जिससे लिस्प काफी गतिशील रूप से विकसित हो गया है। आवश्यकता की तरह एक नई भाषा सुविधा - बस मैक्रो के साथ एक OOP प्रणाली बारे में - कहते हैं कि वस्तु उन्मुखीकरण देता है!

जबकि C को OOP फीचर्स (C ++, Obj। C) के साथ 2 बार राउंडअबाउट बढ़ाया गया था, लिस्प को कई बार बढ़ाया गया था, अंत में एक विजेता था।

यह लिस्प के बारे में एक और विचित्रता है, यह विकसित होता है (लिस्प के दिलचस्प नए उत्परिवर्तन के लिए क्लोजुरे और क्लोजुरस्क्रिप्ट देखें)।

इसके KISS प्रॉपर्टी के लिए Lisps कुछ लोगों द्वारा भाषाओं को पढ़ाने के रूप में इष्ट है। जैसे एक शैक्षिक भाषा के अपने खाका में फोगस की रूपरेखा ( http://blog.fogus.me/2013/01/21/enfield-a-programming-language-designed-for-pedagogy/ )

शुरू करने के लिए, मैं मजबूत विश्वास रखता हूं कि जब नया सीखते हैं, और कई बार जटिल विषयों पर यह छात्रों के लिए प्रतिकूल सिंटैक्स नियमों के साथ अधिभार के लिए हानिकारक है। इसलिए, एनफ़ील्ड को न्यूनतम सिंटैक्स नियमों के साथ डिज़ाइन किया गया है और सिंटेक्स जैसे लिस्प की तुलना में अधिक न्यूनतम क्या है।

Comments

ओपी परिभाषित करता है सुंदर स्पष्ट रूप से इस सवाल के संदर्भ के लिए चुम्बन, "लिखने के लिए औसत काम की परिस्थितियों के तहत एक औसत प्रोग्रामर की अनुमति है और कम से कम संज्ञानात्मक प्रयास के साथ संभव के रूप में ज्यादा के रूप में बनाए रखने के कोड" । ओपी में " किसी विशेष प्रोग्रामिंग भाषा के बारे में आपकी व्यक्तिगत राय के बजाय डिजाइनरों (प्रलेखित) इरादों के बारे में जानने की दिलचस्पी"

— gnat