"डेटा सिर्फ गूंगा कोड है, और कोड सिर्फ स्मार्ट डेटा है" मतलब?

Question

मैं सिर्फ The Structure And Interpretation of Computer Programs में एक विचार भर में आया था:

डाटा सिर्फ गूंगा कोड है, और कोड सिर्फ स्मार्ट डेटा

मैं समझने के लिए इसका क्या मतलब असफल है। क्या कोई इसे बेहतर समझने में मेरी सहायता कर सकता है?

Answer 1

यह एसआईसीपी के मूलभूत पाठों में से एक है और कंप्यूटर विज्ञान के सबसे शक्तिशाली विचारों में से एक है। यह इस तरह काम करता है:

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

#!/usr/bin/perl 
# Note that the above line explicitly defines the interpretive context for the 
# rest of this file. Without the context of a Perl interpreter, this script 
# doesn't do anything. 
sub foo { 
    my ($expression) = @_; 
    # $expression is just a string that happens to be valid Perl 

    print "$expression = " . eval("$expression") . "\n"; 
} 

foo("1 + 1 + 2 + 3 + 5 + 8");    # sum of first six Fibonacci numbers 
foo(join(' + ', map { $_ * $_ } (1..10))); # sum of first ten squares 

कुछ भाषाएं: या यहां तक ​​कि रन टाइम पर कोड उत्पन्न -

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

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

कोड लिखने के सबसे शक्तिशाली तरीकों में से एक है जो आपको चाहिए, इसका एक सरल विवरण है: डेटा जो कोड में बदल दिया जाएगा, यह बताता है कि आपको व्याख्यात्मक संदर्भ से आपको क्या चाहिए। हम इसे "declarative programming" कहते हैं।

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

Answer 2

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

Answer 3

यह कुछ ऐसा है जो आपको एक कंपाइलर में लिखने से समझने के लिए आना चाहिए।

कंपाइलरों में एक आम कदम प्रोग्राम को एक सार वाक्यविन्यास पेड़ में बदलना है। प्रतिनिधित्व अक्सर पेड़ की तरह होगा [+, 2, 3] जहां + रूट है, और 2, 3 बच्चे हैं।

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

Answer 4

सुरक्षा के संदर्भ में: बफर ओवरफ्लो के कारण, आपने डेटा के रूप में क्या सोचा और इस प्रकार हानिरहित (जैसे छवि) को कोड के रूप में निष्पादित किया जा सकता है और आपकी मशीन को p0wn किया जा सकता है।

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

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

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

Answer 5

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

आप शायद कह सकते हैं कि कोई तकनीकी/आकस्मिक डेटा कोड है और वह कार्यात्मक/आवश्यक डेटा नहीं है।