मैं डगलस मैक्लेरो पर विकिपीडिया लेख पढ़ रहा था और एक उद्धरण पाया जिसमें उल्लेख है
"प्रोग्रामिंग का वास्तविक नायक वह है जो नकारात्मक कोड लिखता है।"
इसका क्या मतलब है?
जवाबों:
इसका मतलब है कि अतिरेक को दूर करके या अधिक संक्षिप्त निर्माण का उपयोग करके, कोड की लाइनों को कम करना।
उदाहरण के लिए मूल Apple लिसा डेवलपर टीम के इस प्रसिद्ध उपाख्यान को देखें :
जब लिसा टीम 1982 में अपने सॉफ़्टवेयर को अंतिम रूप देने के लिए जोर दे रही थी, तो परियोजना प्रबंधकों ने प्रोग्रामर को कोड के लाइनों की संख्या पर साप्ताहिक रूप रिपोर्टिंग प्रस्तुत करने की आवश्यकता शुरू कर दी। बिल एटकिंसन ने सोचा कि मूर्खतापूर्ण था। उस सप्ताह के लिए जिसमें उसने क्विकड्रॉ के क्षेत्र गणना रूटीन को छह गुना तेज और 2000 लाइनों को छोटा करने के लिए फिर से लिखा था, उसने फॉर्म पर "-2000" डाला। कुछ और हफ्तों के बाद प्रबंधकों ने उन्हें फॉर्म भरने के लिए कहना बंद कर दिया, और उन्होंने ख़ुशी से अनुपालन किया।
कोड की लाइनों द्वारा प्रोग्रामर उत्पादकता को मापने की तर्ज पर बिल गेट्स का उद्धरण है, जैसे वजन द्वारा विमान निर्माण की प्रगति को मापना।
मैं जोड़ना चाहूंगा कि LOC मीट्रिक ने अत्यधिक लंबी-घुमावदार भाषाओं के उपयोग को प्रोत्साहित किया है और कोटा को पूरा करने के लिए जानबूझकर पहिया को फिर से मजबूत किया है।
जब मैं हाई स्कूल में था - और हां, हमारे पास 70 के दशक में कंप्यूटर थे, हालांकि हमें पत्थर के चाकू का उपयोग करके उन्हें जानवरों की खाल से बाहर करना पड़ा - गणित के शिक्षकों में से एक ने एक प्रोग्रामिंग प्रतियोगिता चलाई। नियम यह थे कि जीतने वाला कार्यक्रम वही होगा जो सही आउटपुट का उत्पादन करता है, और जिसमें कोड टाइम रन टाइम का सबसे छोटा उत्पाद था। यानी, यदि आपका प्रोग्राम लिया गया है, तो कोड की 100 पंक्तियां कहें और 5 सेकंड के लिए दौड़े, आपका स्कोर 500 था। यदि किसी और ने कोड की 90 पंक्तियां लिखीं और 6 सेकंड के लिए भागा, तो उसका स्कोर 540 था। गोल्फ की तरह कम स्कोर की जीत।
इसने मुझे एक शानदार स्कोरिंग प्रणाली के रूप में मारा, जो निर्णायक और प्रदर्शन दोनों को पुरस्कृत करता है।
लेकिन तकनीकी रूप से जीतने के मानदंडों को पूरा करने वाली प्रविष्टि को अयोग्य घोषित कर दिया गया था। यह समस्या 100 से कम की सभी अभाज्य संख्याओं की सूची को प्रिंट करने की थी। अयोग्य प्रविष्टि कुछ इस तरह से हुई (अधिकांश छात्र तब बैकसीक का उपयोग कर रहे थे):
100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"
उस प्रविष्टि को लिखने वाले छात्र ने बताया कि न केवल यह छोटा और बहुत कुशल था, बल्कि एल्गोरिथ्म प्रोग्रामिंग के न्यूनतम ज्ञान के साथ किसी के लिए भी स्पष्ट होना चाहिए, जिससे कार्यक्रम अत्यधिक बनाए रखा जा सके।
यह जीभ में गाल है। यदि यह आपकी औसत लागत वाली लाइन के अनुसार $ N खर्च करता है, तो निश्चित रूप से "नकारात्मक रेखाएं" कोडित करना एक विजेता है।
इसका मतलब है, व्यावहारिक सलाह के रूप में, वह छोटा कोड जो काम को पूरा करता है, बड़े कोड की तुलना में बहुत बेहतर है जो समान कार्य करता है, अन्य सभी चीजें समान हैं।
कम कोड में समान कार्यक्रम लिखना हर किसी के लिए एक लक्ष्य है।
यदि किसी प्रोग्राम को कोड करने के लिए 200 LOC लिया जाता है, और मैं इसे 150 में लिखता हूं, तो मैंने -50 LOC लिखा। इसलिए मैंने नकारात्मक कोड लिखा।
थिलो का उत्तर संभवतः ऐतिहासिक रूप से सबसे सटीक है, लेकिन "नकारात्मक कोड" रूपक में प्रदर्शन और मेमोरी का उपयोग भी शामिल हो सकता है - किसी चीज के निष्पादन या आवंटन को पुरस्कृत करने के लिए पुरस्कृत प्रयास जब तक कि वास्तव में इसकी आवश्यकता न हो।
यह "शिथिलता का भुगतान करता है" मानसिकता ऐसी जीभ-इन-गाल स्वयंसिद्धता उत्पन्न करती है जैसे कि "कुछ भी करने से हमेशा कुछ नहीं होता है", "सबसे तेज़ कोड वह कोड है जो कभी निष्पादित नहीं होता है", और "यदि आप इसे लंबे समय तक रख सकते हैं," आपको कभी भी ऐसा नहीं करना होगा "(वास्तव में आवश्यक होने तक महंगे ऑपरेशनों को स्थगित करने का उल्लेख करते हुए)
नकारात्मक कोड को साकार करने की एक तकनीक समस्या की प्रारंभिक मान्यताओं और परिभाषाओं को चुनौती देना है। यदि आप समस्या / इनपुट डोमेन को फिर से परिभाषित कर सकते हैं जैसे कि "चिपचिपा मुद्दा # 3" स्पष्ट रूप से असंभव है, तो आपको चिपचिपा मुद्दे # 3 से निपटने के लिए समय या कोड खर्च करने की आवश्यकता नहीं है। आपने डिज़ाइन को अनुकूलित करके कोड को समाप्त कर दिया है।