🤚🏼 🍍 🥇 पर्ल में प्रोग्रामर के चार पेशेवर विकृति, एक जीवित उदाहरण द्वारा प्रदर्शित किए गए हैं 🌹 🐰 🐴

Edsger Wiebe Dijkstra को विशेष रूप से, कई कैपेसिटिव और अभिव्यंजक कथनों के लेखक के रूप में जाना जाता था, जो प्रोग्रामर के व्यावसायिक विकृति के रसातल को रेखांकित करते हुए, एक या किसी अन्य असुविधाजनक प्रोग्रामिंग भाषा को प्राथमिकता देते थे। विशेष रूप से दिज्क्स्ट्रा के निम्नलिखित अनुमान कुख्यात हैं, (मैं उन्हें विकीकोट से उद्धृत करूंगा):

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

6 अगस्त, 2002 को दिज्क्स्त्र का निधन हो गया। आज, उनकी मृत्यु के दस साल से अधिक समय के बाद, हमें अपने चारों ओर देखने और खुद से पूछने का अधिकार है: हालात कितने बदल गए हैं? दूसरे शब्दों में: और आजकल (आजकल) व्यापक रूप से उपयोग की जाने वाली प्रोग्रामिंग भाषाओं में से कोई भी ऐसी भाषा हैं जिनके उपयोग से प्रोग्रामर के लिए ध्यान देने योग्य पेशेवर विकृति का लगभग अपरिहार्य जोखिम हो जाता है?

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

इनमें से सबसे आम भाषा पर्ल है ।

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

यह उदाहरण फिडोस होगा।

तीन दिन पहले, पचासवीं क्षेत्र के सिसोपों के फिडोनेट गूंज सम्मेलन ने ऐसे नए फ़िडोनेट नोड सूची प्रारूप ( अंग्रेजी नोडलिस्ट ) पर स्विच करने के इरादे पर चर्चा की, जिसमें समय झंडे ( टिक्सी प्रारूप में) नोड विवरण रेखा के मुख्य (और उपयोगकर्ता में नहीं) भाग में होंगे। किसी एक सिसॉप्स ने पहले से एक नए प्रारूप में नोडेलिस्ट बनाने का सुझाव दिया ताकि कोई भी उस पर अपने सिस्टम के व्यवहार की जांच कर सके:

╔═════════════════════════════════════════════════════──────────────────────── ║   : R50.SysOp (   ) ║ URL : area://R50.SysOp?msgid=2:5000/111+503b7f4b ║   : Oleg Redut, 2:5000/111 (27 Aug 12 21:06) ║  : Vladimir Donskoy ║  :  Txy ╚════════════════════════════════════════════════════════════════════───────── @REPLY: 2:5020/5480 503a828c @MSGID: 2:5000/111 503b7f4b @CHRS: CP866 2 @TZUTC: 0700 @TID: hpt/w32-mvcdll 1.9.0-cur 12-03-11  (current)  , Vladimir! VD>>     ,     -  VD>>   . AB>  - .    . :) , . -        ,     .        . :)     ?.. Oleg ... AKA oleg(&)redut.info AKA ICQ 28852595 ■■■ GoldED+/W32-MINGW 1.1.5-b20120515 ( ) √ Origin: --- ...    ... --- (2:5000/111) @PATH: 5000/111 5020/1042 830 ────────────────────────════════╪══╬═╣()╠═╬══╪════════────────────────────────

मैंने इस पत्र को सभी तकनीकी जानकारी के साथ जानबूझकर उद्धृत किया। पत्र की शुरुआत में आप "hpt / w32" का उल्लेख देख सकते हैं , और अंत में - "GoldED + / W32" का उल्लेख कर सकते हैं : यह स्पष्ट हो जाता है कि यह fidoshnik Win32 के लिए डिज़ाइन किए गए सॉफ़्टवेयर का उपयोग करता है, अर्थात यह विंडोज के तहत काम करता है।

और इस पत्र के जवाब में पर्ल प्रोग्रामर की प्रतिक्रिया क्या है:

 ╔═════════════════════════════════════════════════════──────────────────────── ║   : R50.SysOp (   ) ║ URL : area://R50.SysOp?msgid=2:463/68+503b854d ║   : Pavel Gulchouck, 2:463/68 (27 Aug 12 17:32) ║  : Oleg Redut ║  : Re:  Txy ╚════════════════════════════════════════════════════════════════════───────── 27 Aug 12, Oleg Redut ==> Vladimir Donskoy: VD>>>     ,     -  VD>>>   . AB>>  - .    . :) OR> , . -       OR>  ,     .     OR>    . :)     U,Txy  : perl -pe 'next unless /(([^,]*,){6,})U(.*)/; ($l,$u)=($1,$3); while ($u =~ /^(.*,)?(T[A-Xa-x]{2}),?(.*)/) { $l.="$2,"; $u="$1$3" }; $_="${l}U$u\n"; s/,U?,?\s*$/\n/' ────────────────────────════════╪══╬═╣()╠═╬══╪════════────────────────────────

पर्ल में कोड की दो और कुछ पंक्तियाँ; और यह कोड, जैसा कि आप आसानी से देख सकते हैं, बड़े पैमाने पर केवल लेखन की परिभाषा के भीतर आता है ।

लेकिन वास्तव में पर्ल इस कोड को क्या करता है?

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

दूसरे, शब्दार्थ (कुछ का अर्थ नहीं) का उपयोग, लेकिन संक्षिप्त (इस मामले में, एकल-वर्ण भी) चर नाम। चूंकि पर्ल द्वारा स्वयं बनाए गए चर में एकल-वर्ण नाम (जैसे $ 1 , $ 3 , $ 6 , $ _ ) हैं, उनके साथ काम करने की आदत धीरे-धीरे प्रोग्रामर में एक भावना पैदा करती है कि इसके नाम की संक्षिप्तता के पक्ष में चर के शब्दार्थ मूल्य को छोड़ना कुछ है। पूरी तरह से प्राकृतिक और न्यायसंगत - जिसका अर्थ है कि वह और उसके स्वयं के चर अंततः एक-अक्षर कहलाने लगेंगे (जैसे $ l , $ f , $ u ), क्योंकि यह कुछ फोरट्रान के अंधेरे और अमर युग में या BASIC के पहले संस्करणों में था। स्रोत कोड केवल लेखन है, क्योंकि कोड रीडर यह समझने के लिए अधिक प्रयास का क्रम लेता है कि $ u चर में उपयोगकर्ता झंडे हैं (जो तुरंत स्पष्ट होगा यदि इसका नाम $ userflags था )। $ f में अगला ध्वज ( $ ध्वज ) होता है, चर $ l में एक पंक्ति ( $ लाइन ) या सूची आइटम ( $ list_item ) की शुरुआत होती है ।

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

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

सोचें और सोचें: कमांड लाइन के लिए इरादा पर्ल में कुछ लाइनों के साथ नुस्खा केवल इन दोनों से कितना लाभ होगा?

 perl -pe 'next unless /(([^,]*,){6,})U(.*)/; ($l,$u)=($1,$3); while ($u =~ /^(.*,)?(T[A-Xa-x]{2}),?(.*)/) { $l.="$2,"; $u="$1$3" }; $_="${l}U$u\n"; s/,U?,?\s*$/\n/'

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

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

इसके अलावा, एपोस्ट्रोफ के साथ स्रोत कोड का उपरोक्त फ्रेमिंग विंडोज में काम करने में सक्षम नहीं है। दूसरे शब्दों में, भले ही नुस्खा का प्राप्तकर्ता perl.exe हो और सही ढंग से " <इनपुट " और " > आउटपुट " फ़ाइल का चयन करता है , यह अभी भी दर्दनाक रूप से निराश होगा - उसी तरह के बारे में जैसे आपने "C:" ड्राइव पर cd 'दस्तावेज़ कमांड जारी किया था। और cd के बजाय "दस्तावेज़ और सेटिंग" ।

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

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

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

केवल मामले में, इस पर जोर देना उचित है: उपरोक्त उदाहरण में, मेरे लिए यह स्पष्ट है कि यह पावेल गुल्चुक की गलती नहीं है (एक उत्कृष्ट प्रोग्रामर, प्रमुख binkd डेवलपर जो binkp.net डोमेन का समर्थन करता है, और इसी तरह आगे भी), लेकिन पर्ल भाषा की गलती है, जो धीरे-धीरे प्रोग्रामर को प्रोत्साहित करती है। लेखन और केवल लेखन स्रोत कोड का वितरण । तब भी जब प्रोग्रामर खराब न हो।

यह कुछ हद तक जॉर्ज ऑरवेल के उपन्यास "1984" से एक शानदार भाषा (मानव, कंप्यूटर नहीं) "अखबार" की याद दिलाता है - एक कृत्रिम भाषा जिसने मूल वक्ता के सोचने के तरीके को धीरे-धीरे विकृत कर दिया, जिससे वह सोच के एक पार्टी मार्ग पर चला गया।

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

(यह ध्यान रखना उचित है कि डायलन एक समलैंगिक, अधिक काला था।)

पर्ल में प्रोग्रामर के चार पेशेवर विकृति, एक जीवित उदाहरण द्वारा प्रदर्शित किए गए हैं

More articles: