ग्रीनस्पून के दसवें नियम, क्या हर बड़ी परियोजना में एक लिस्प दुभाषिया शामिल होता है? [बन्द है]


12

ग्रीनस्पून के दसवें नियम (वास्तव में एकमात्र नियम) में कहा गया है कि:

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

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


8
क्या आपने विकिपीडिया लेख पर शासन के अर्थ की व्याख्या पढ़ी है ? मुझे लगता है कि इस दावे की पुष्टि या अवहेलना करने के लिए गंभीर प्रयास होगा, यह वास्तव में गंभीरता से लेने के लिए नहीं था
यानिस

3
मजेदार बात यह है कि जब ग्रीनस्पून का नियम सिर्फ एक मजाक था, मैंने वास्तव में सिमुलेशन सॉफ्टवेयर पर काम किया था जिसमें एक अंतर्निहित LISP दुभाषिया था। सॉफ्टवेयर का विन्यास सभी एस-एक्सप्रेशंस के माध्यम से किया गया था और कोई भी विन्यास में विभिन्न चीजों को करने के लिए संकल्पित रूप से LISP कोड लिख सकता था।
wkl

@YannisRizos - वास्तव में, आपके किसी भी लिंक का दावा नहीं है कि नियम एक मजाक है। मॉरिस के कानून को इस तरह तैयार किया गया है, हालांकि। अब, आलंकारिक रूप से ....
आकस्मिक कैद

2
@casualcoder "यह विडंबना है कि मेरी मृत्यु के बाद यह इच्छाशक्ति, शायद एक ऐसी चीज होगी जिसे कोई भी अपने लेखन से याद करता है।" और नियम का नामकरण यह संकेत देता है कि इसे हल्के-फुल्के अंदाज में लिखा गया था ...
यानिस

क्या एरलांग और समवर्ती कार्यक्रमों के संबंध में एक समान उद्धरण नहीं था?
जियोर्जियो

जवाबों:


15

कथन अतिशयोक्तिपूर्ण है। लेकिन अन्य भाषाओं में लिस्प ईर्ष्या के स्पष्ट संकेत हैं। C # देखें और यह कैसे प्रकृति में अधिक कार्यात्मक हो रहा है। विभिन्न व्यावसायिक प्रक्रिया प्रबंधन, वर्कफ़्लो और ईएआई फ्रेमवर्क को देखें जो प्रोग्राम को बदले बिना सिस्टम को प्रोग्राम करना संभव बनाने के लिए अपने रास्ते से बाहर जाते हैं।

मार्टिन फॉवलर द्वारा डोमेन स्पेसिफिक लैंग्वेजेस पर एक किताब है जो ऑब्जेक्ट-ओरिएंटेड भाषाओं में मेटा-प्रोग्रामिंग करने के बारे में बात करती है। तो हाइपरबोले के लिए कुछ सच्चाई है।

पॉल ग्राहम ने लिस्प को सबसे शक्तिशाली भाषा कहा जो कि लिस्प के साथ आए फर्स्ट की सूची को देखते हुए, यह देखना आसान है कि तुलना में कई भाषाएं क्यों पीला पड़ती हैं।

दसवें नियम के आसपास का तरीका पॉलीग्लॉट प्रोग्रामिंग है। यह महसूस करते हुए कि एक भाषा / रूपरेखा स्वर्ण हथौड़ा नहीं है। फिर लिस्प का एक गरीब, तदर्थ कार्यान्वयन बनाने के बजाय, आप बस लिस्प का उपयोग कर सकते हैं।


4
शक्ति और आयु स्वतंत्र है। यह वास्तव में काफी अप्रासंगिक है कि सृजन के समय LISP कितना अच्छा या बुरा था, यह मायने रखता है कि यह आज भाषाओं की तुलना कैसे करता है। पहले बिलकुल महत्वहीन हैं।
डेडएमजी

2
@DeadMG, ये "फ़र्स्ट" उन चीज़ों की तुलना में कुछ भी नहीं हैं जिन्हें लिस्प से दूसरी भाषाओं में अभी तक पोर्ट नहीं किया गया है।
एसके-तर्क

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

2
"लिस्प का एक गरीब, तदर्थ कार्यान्वयन बनाने के बजाय, आप बस लिस्प का उपयोग कर सकते हैं" लेकिन मॉरिस के कोरोलरी का मतलब है कि आप अभी भी एक गरीब, तदर्थ कार्यान्वयन का उपयोग कर रहे हैं;)
जेके।

1
उस प्रविष्टि के लिए बिल्कुल सही है "हैकर संस्कृति की संपूर्णता को अक्सर हैकर्स द्वारा खुद को हा-हा-केवल-गंभीर माना जाता है; इसे या तो बहुत हल्के में लेना या बहुत गंभीरता से एक बाहरी व्यक्ति, एक वानाबी , या लार्वा चरण के रूप में एक व्यक्ति को चिह्नित करता है । "
माइकल ब्राउन

10

ग्रीनस्पून का "दसवां नियम" एक ऑफ-द-कफ बिट ऑफ स्नार्क था। बहुत दूर तक फैला होने पर, यदि आप इसे "किसी भी स्क्रिप्टिंग या कॉन्फ़िगरेशन सिस्टम" को कवर करते हैं, तो जाहिर है कि इस प्रश्न का उत्तर "हाँ" होगा, क्योंकि कॉन्फ़िगरेशन कुछ ऐसा है जिसे किसी भी गैर-तुच्छ कार्यक्रम के लिए कुछ डिग्री और स्क्रिप्टिंग की आवश्यकता होती है जैसे ही आप जटिलता के स्तर को बढ़ाते हैं, यह थोड़ा कम सामान्य है।

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

दूसरे शब्दों में, जब उन्होंने पर्याप्त रूप से जटिल परियोजना के लिए लिस्प का उपयोग करने की कोशिश की, तो उन्होंने पाया कि कुछ भी उपयोगी करने के लिए उन्हें भाषा को तदर्थ में बदल दिया गया था, अनौपचारिक रूप से C ++ के आधे के कार्यान्वयन को निर्दिष्ट किया गया था! ;) (और उन्हें अंततः उस व्यक्ति का उपयोग करना बंद करना पड़ा, जिसने GOAL को छोड़ दिया था, क्योंकि कोई भी उसके कोड को नहीं समझ सकता था)।


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

दरअसल, उन्होंने GOAL का उपयोग करना बंद कर दिया क्योंकि उन्हें कंपनी द्वारा खरीदा गया था जिसका कोडबेस C ++ में था। इसके अलावा, GOAL काफी लिस्प था। न्यूनतम-भाजक ऑनलाइन ट्यूटोरियल न
मानें

9

उत्सुकता से, इस सवाल का एक जवाब पहले से ही प्रोग्रामर एसई में है

संबंधित भाग को उद्धृत करने के लिए:

ग्रीनस्पून का बिंदु (भाग में) था कि कई जटिल कार्यक्रमों में अंतर्निहित दुभाषियों हैं। भाषा में एक दुभाषिया बनाने के बजाय उन्होंने सुझाव दिया कि यह लिस्प जैसी भाषा का उपयोग करने के लिए और अधिक समझदार हो सकता है जिसमें पहले से ही एक दुभाषिया (या संकलक) अंतर्निहित हो।

उस समय मैं एक बड़े ऐप पर काम कर रहा था, जो एक कस्टम भाषा के लिए कस्टम दुभाषिया का उपयोग करके उपयोगकर्ता-परिभाषित गणना करता था। मैंने एक बड़े पैमाने पर प्रयोग के रूप में लिस्प में इसके मूल को फिर से लिखने की कोशिश करने का फैसला किया।

इसमें लगभग छह सप्ताह का समय लगा। मूल कोड डेल्फी (एक पास्कल संस्करण) की ~ 100,000 लाइनें थी। लिस्प में जो ~ 10,000 लाइनों तक कम हो गया था। हालांकि इससे भी अधिक आश्चर्य की बात यह है कि लिस्प इंजन 3-6 गुना तेज था। और ध्यान रखें कि यह एक लिस्प निओफाइट का काम था! वह पूरा अनुभव मेरे लिए काफी आंखें खोलने वाला था; पहली बार मैंने एक ही भाषा में प्रदर्शन और अभिव्यक्ति के संयोजन की संभावना देखी।
- माइकल लेनघन

उस हिस्से को और स्पष्ट करने के लिए, माइकल ने एक टिप्पणी के साथ जवाब दिया:

वाह, यह वास्तव में भयानक डेल्फी कोड रहा होगा अगर यह किसी तरह एक लिस्प कार्यान्वयन की तुलना में 3-6x धीमी गति से प्रदर्शन करने में कामयाब रहा! "ठीक है, मैं गिनूंगा कि इसे बेहतर तरीके से समझाने के लिए मेरी असफलता के रूप में। लिस्प कार्यान्वयन को बदलने में सक्षम था। लिस्प्र भाव में यूजर एक्सप्रेशन - एक तुच्छ आसान प्रक्रिया - और फिर लिस्प एक्सप्रेशंस को देशी कोड (पूर्ण अनुकूलन के साथ) के लिए संकलित करें। यही ग्रीन्सपुन के दसवें नियम का अर्थ है।
-माइकल लेनघन

यह देखते हुए कि यह उत्तर किसी और के उत्तर से बना है, यह सामुदायिक विकि है।


2

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

किसी भी जटिल प्रणाली में कई कोड जनरेशन पास और विभिन्न अनुकूलित प्रीप्रोसेसर होने की संभावना है, इसकी निर्माण प्रक्रिया में ( mocक्यूटी या tablegenएलएलवीएम जैसी चीजों के बारे में सोचें )।

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

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


2

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


1

नियम शायद अधिक सटीक (और कम मनोरंजक) हो सकता है क्योंकि "गतिशील व्यवहार को लागू करने के लिए हर बड़े सॉफ़्टवेयर आधारित सिस्टम की आवश्यकता होगी"।

इसे दो तरीकों से किया जा सकता है-

  1. दर्जनों मापदंडों और सैकड़ों परिभाषाओं के साथ एक बड़ी जटिल कॉन्फ़िगरेशन फ़ाइल।

  2. एक AD-HOC लिपि भाषा।

"sendmail" शायद "1" प्रकार का विहित उदाहरण है। मैं "2" प्रकार के किसी भी अच्छे उदाहरण के बारे में नहीं सोच सकता हूं जिसमें "वास्तविक" स्क्रिप्टिंग भाषा को एक ला Warcraft / LUA या यहां तक ​​कि नेटस्केप / जावास्क्रिप्ट को एम्बेड करना शामिल नहीं है।

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


0

यह सच हो सकता है, जैसा कि दूसरों ने कहा है, कई कार्यक्रमों को विन्यास की आवश्यकता होती है और इसलिए विभिन्न लिस्प-जैसे दुभाषिया होते हैं।

हालाँकि कथन का तात्पर्य यह भी है कि एक प्रोग्राम बनाने के लिए आपको एक लिस्प की आवश्यकता होती है, और यह कि अन्य सभी भाषाएं इससे हीन हैं।

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

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

यह बल्कि आसपास का दूसरा तरीका है, चाहे आप कितनी भी जटिल, होशियार या परिष्कृत भाषा का आविष्कार कर लें, यह सब समाप्त हो जाना विधानसभा लिखने का एक और तरीका है।


केवल 50 के दशक के उत्तरार्द्ध के सबसे प्राचीन लिस्प वातावरण के लिए प्रासंगिक लगता है। निजी तौर पर, मैंने बिट्स से निपटने के लिए कॉमन लिस्प के कार्यों को संभवतः सबसे अच्छे में से एक पाया (मुख्य प्रतियोगिता एर्लांग के साथ)। ऐरे, हैशटैब, स्ट्रक्चर्स सभी आम हैं।
p_l

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

0

इसे गंभीरता से लिया जाना था या नहीं, यह मेरे द्वारा काम की गई सबसे बड़ी C और C ++ परियोजनाओं के बारे में सच है।

यह सच नहीं है कि कस्टम स्क्रिप्टिंग भाषाएँ कॉमन लिस्प से मिलती जुलती हैं। सकारात्मक उदाहरण योजना से मिलते जुलते हैं (क्योंकि होशियार डिजाइनरों ने अपनी भाषा का आविष्कार करने के बजाय Guile, SpiderMonkey और Lua को एकीकृत किया।) सबसे DailyWTF- योग्य उदाहरण एक फोर्थ जैसी भाषा और एक MUMPS जैसी भाषा थी।

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


-1

दुर्भाग्य से नहीं!

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

जिन परियोजनाओं में "कोड सबकुछ" में बड़े पैमाने पर बड़े मॉड्यूल होते हैं, वे अस्पष्ट और अनम्य हो जाते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.