साक्षर प्रोग्रामिंग मुख्यधारा क्यों नहीं है? [बन्द है]

32

साक्षर प्रोग्रामिंग में अच्छे आदर्श हैं। आपको क्यों लगता है कि यह मुख्यधारा नहीं है? यह है क्योंकि यह देने में विफल रहा है?

programming-practices literate-programming

— Casebash
स्रोत

2

क्योंकि इसके लिए विकसित किए गए उपकरण अभी भी बहुत कमजोर हैं। Microsoft के पास संभवतः इस संबंध में अग्रणी होने का एक मौका है।

— जॉब

3

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

— oosterwal

1

यहां तक कि नुथ को अब इस अवधारणा के लिए दोषी नहीं ठहराया गया है: "और हम" साक्षर प्रोग्रामिंग "की पुरानी धारणा को छोड़ रहे हैं, जिसका उपयोग मैंने टीईएक्स 82 को विकसित करते समय किया था, क्योंकि प्रलेखन बहुत अधिक दर्द साबित हुआ है।" tug.org/TUGboat/tb31-2/tb98knut.pdf ।

— hbb0

6

TeX और इसके दर्शन से अपरिचित लोगों के लिए यह उल्लेख किया जाना चाहिए कि नुथ बोली का अर्थ विडंबना है।

3

@ h0b0 & user1249: नूथ द्वारा किया गया संपूर्ण लेख विडंबनापूर्ण है, क्योंकि आप इसे केवल स्किम-रीडिंग द्वारा पता लगा सकते हैं। वह स्टीव जॉब्स, वेब, एजाइल, रीफैक्टरिंग, ओओपी, एओपी और कई अन्य चीजों का भी मखौल उड़ाता है। यह एक मज़ाक है!

— एंड्रेस एफ।

35

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

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

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

— डेविड थॉर्नले
स्रोत

4

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

— एसके-तर्क

1

@ एसके-लॉजिक फेयर, लेकिन डेविड थोर्नली जो बिंदु बना रहा है, वह यह भी है कि WHY एक भ्रामक झूठ क्यों हो सकता है (एक जो वास्तव में समझने के लिए और भी कठिन है)।

— MrFox

1

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

— टेकजेन

1

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

— टेकजेन

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

— टेकजेन

13

मैं नेटवर्क प्रभाव को दोष दूंगा । अन्य लोगों के लिए आपके कोड और प्रलेखन को संपादित करने के लिए, उन्हें इसे समझने में सक्षम होना चाहिए।

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

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

— लैरी वांग
स्रोत

2

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

— एशेल्ली

@AShelly: यह आवश्यक नहीं है - मुझे पता है कि Noweb, कम से कम, आपको HTML का उपयोग करने देता है। लेकिन व्यवहार में, जो लोग HTML प्रलेखन लिखते हैं, वे साहित्यिक प्रोग्रामिंग टूल के बजाय javadoc और जैसे का उपयोग करेंगे।

— लैरी वांग

1

@ पूरी तरह से, काम करने के लिए साक्षर प्रोग्रामिंग के लिए, आपको मुद्रित होने के लिए दस्तावेज़ उत्पन्न करने में सक्षम होना चाहिए। यह बहुत, बहुत आसान है जब प्रारूप पाठ आधारित है, और मेरी जानकारी के लिए सबसे शक्तिशाली पाठ आधारित दस्तावेज़ फ़ॉर्मेटर है टेक्स, और टेक्स LaTeX उपयोग कर रहा है के साथ काम करने के लिए सबसे आसान तरीका है।

@ आप org-modeसाक्षर प्रोग्रामिंग के लिए समर्थन पर एक नज़र रखना चाहते हो सकता है । यह काफी आसान है, और मुझे इसे WEB या NowEB की तुलना में समझने ( प्रबंधन का उल्लेख नहीं करने ) के लिए बहुत आसान लगता है । कोड का एक महत्वपूर्ण पहलू पठनीयता है, और यह पठनीय है। (cf github.com/vermiculus/stack-mode )

— सीन एलेड

12

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

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

उन भाग्यशाली लोगों के लिए जिन्होंने मानक पास्कल की कोशिश नहीं की है, यहां कुछ हाइलाइट्स हैं।

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

मूल रूप से इन सभी चीजों का मतलब था कि नूथ को एक बेहतर प्रोग्रामिंग भाषा की आवश्यकता थी (इसलिए उन्होंने एक का आविष्कार किया) और इसने पास्कल को अपनी विधानसभा भाषा के रूप में इस्तेमाल किया।

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

इसके अलावा आधुनिक भाषाएं अधिक अभिव्यंजक हैं जो अधिक विचार को कोड में ही डालने की अनुमति देती हैं।

तो, क्या बचा है? स्रोत कोड से दस्तावेज़ीकरण का एक टाइपसेट प्रपत्र उत्पन्न करने की क्षमता है, और है कि आज मौजूद है।

ज़रा सोचिए JavaDoc - Java रनटाइम API शायद आज उपलब्ध लिटरेट प्रोग्रामिंग का सबसे बड़ा टुकड़ा है (सिवाय इसके कि कोड वास्तव में प्रस्तुत नहीं किया गया है, लेकिन यह COULD है अगर जावा को शुरू से ही खुला रखा गया था)। उदाहरण के लिए http://download.oracle.com/javase/6/docs/api/java/util/Collection.html पर संग्रह ढांचे की प्रस्तुति देखें

मेरा मानना है कि .NET और अन्य मुख्यधारा के कार्यक्रमों के लिए समान सिस्टम मौजूद हैं।

To make it possible to have a single-pass compiler, all declarations had to come in a certain order. इस तरह की घोषणा का आदेश निश्चित रूप से संकलक डिजाइन को सरल करता है, लेकिन यह एकल-पास संकलन को सक्षम / रोक नहीं सकता है। उदाहरण के लिए, डेल्फी में वह आदेश प्रतिबंध नहीं है, लेकिन यह अभी भी एक सख्ती से एकल-पास पास्कल संकलक है।

— मेसन व्हीलर

माना। टर्बो पास्कल में यह प्रतिबंध नहीं था। हालाँकि, ध्यान दें कि यह प्रतिबंध शुरू से ही पास्कल की परिभाषा में था।

1

नहींं, नथ ने बहुत पहले CWEB में कदम रखा, यह पास्कल कमियों को ठीक करने के बारे में नहीं है। नहींं, JavaDoc को नूथ की "साक्षर प्रोग्रामिंग" से कोई लेना-देना नहीं है - वह मौलिक रूप से बदलने के बारे में बात कर रहा है कि वह कोड कैसे बनाता है, और यह दावा करने से उसे जटिलता से निपटने की अनुमति मिलती है कि वह अन्यथा उसके या किसी और के लिए संभव नहीं होगा।

— रॉन बुर्क

@ रॉनबर्क CWEB सिर्फ एक बेहतर "असेंबली भाषा" के लिए संकलित करता है। यह मूल डिज़ाइन निर्णयों को अमान्य नहीं करता है।

— Thorbjørn रेवन एंडरसन

5

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

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

— dfan
स्रोत

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

— थोरबजोरन रावन एंडरसन

3

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

— Nisanio
स्रोत

फिर लिटरेट प्रोग्रामिंग के साथ वे सोच सकते हैं कि आप अभी तक एक और सॉफ्टवेयर के बजाय विज्ञान-फाई बुक लिखने में व्यस्त हैं! : डी

— महदी

उस तरह की कंपनियां यह नहीं समझती हैं कि अच्छा सॉफ्टवेयर बहुत लंबा रहता है और बेहतर प्रलेखन स्रोत के लायक है।

— थोरबजोरन रेव एंडरसन

2

कोडर्स अंग्रेजी नहीं कोड लिखते हैं।

कोडर्स को दस्तावेज़ लिखना पसंद नहीं है क्योंकि यह कोड चलाने में मदद नहीं करता है।

कोडर प्रलेखन लिखने में अच्छे नहीं हैं क्योंकि यह उनके विचारों को व्यक्त करने का एक खराब माध्यम है।

साहित्य प्रोग्रामिंग को अगले स्तर पर प्रलेखन लेने का विचार प्रतीत होता है जहां कोड एक विचार के बाद अधिक होता है। शायद यह काम करेगा, लेकिन अधिकांश कोडर के लिए यह अप्रिय दस्तावेज की तरह दिखता है।

— विंस्टन इवर्ट
स्रोत

29

कोडर्स जो आपके द्वारा बताए गए बिंदुओं का पालन करते हैं, वे कोडर नहीं हैं जिन्हें मैं मेरे साथ काम करना चाहता हूं।

— पॉल नाथन

1

@Paul, दी गई। लेकिन वास्तव में वहाँ बाहर thats। लेकिन यह मुझे लगता है कि अधिक प्रलेखन जरूरी बेहतर नहीं है।

— विंस्टन एवर्ट

1

पर्याप्त संभवतः सबसे अच्छा है

— mlvljr

6

अनुभवी प्रोग्रामर जानते हैं कि उन्हें प्रलेखन लिखने की आवश्यकता है क्योंकि यह वह जगह है जहां "मैंने ऐसा क्यों किया था" वह जाता है।

1

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

— विंस्टन इर्वर्ट

2

मुख्य रूप से क्योंकि लोग बहुत स्थिर हैं। स्पष्ट गवाही जो इस सरल तकनीक की प्रकृति के बारे में युवा लोगों द्वारा व्यक्त अनुमानों और गलतफहमी की एक अंतहीन धारा है।

लोग एलपी होने के लिए: (ए) प्रलेखन की एक विधि (बी) कुछ पॉलिश निबंध लिखने की एक विधि जो कुछ विशेष कौशल या प्रतिभा (सी) की आवश्यकता है, बस कोई सुराग नहीं है - लियो प्रोग्रामिंग संपादक के निर्माता के रूप में, अपने स्वयं के प्रवेश द्वारा आदि आदि।

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

युवा लोग इस अत्यंत सरल विचार को कभी नहीं आजमाते हैं - और या तो नकली कारणों की कल्पना करते हैं या कल्पना करते हैं कि वे कभी ऐसा क्यों करेंगे या नहीं करेंगे।

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

3

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

— एसके-तर्क

1

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

— लैरी ओब्रायन
स्रोत

1

क्योंकि कार्यक्रमों के तर्क वैसे ही काम नहीं करते हैं जैसे हम बोलते हैं। एक कार्यक्रम में एक अच्छी तरह से निर्दिष्ट प्रवाह, और स्थितियां और लूप हैं।

बहुत से कोडिंग करने के बाद, मैं इन शब्दों में सोचता हूं। मेरा मस्तिष्क समस्याओं को निष्पादन योग्य कोड के लक्ष्य डोमेन में बदल देता है। और मेरे कार्यक्रमों को साक्षर बनाने के लिए अतिरिक्त रूपांतर करने के लिए, आमतौर पर प्रोग्रामिंग भाषा में इसे लिखना मेरे लिए बहुत अधिक कुशल है।

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

निष्कर्ष निकालने के लिए: मेरा जावा कोड अपने आप में अधिक साक्षर है क्योंकि हर "साक्षर" प्रोग्रामिंग बनना चाहता है।

— डैनियल
स्रोत

2

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

— एसके-तर्क

1

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

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

— जुराज
स्रोत

0

मैं इसे एक मूल्यवान शिक्षण उपकरण के रूप में देखता हूं, जहां कोड पर एक शोध प्रबंध लिखा जा सकता है, और फिर काम करने वाले कोड के स्निपेट को कोड के व्हाट्स, व्हाट्स और व्हाट्स पर पाठकों को निर्देश देने के लिए इसमें हस्तक्षेप किया जाता है।

विशुद्ध रूप से शैक्षिक वातावरण के बाहर, मुझे लगता है कि केवल नूथ वास्तव में समझता है कि इसका उपयोग कैसे करना सबसे अच्छा है।

— greyfade
स्रोत

-4

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

— मार्टिन बेकेट
स्रोत

3

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

— एसके-लॉजिक

यदि टिप्पणी यह नहीं कहती है कि कोड क्या कर रहा है तो यह साक्षर प्रोग्रामिंग कैसे है - यह टिप्पणियों के साथ सिर्फ नियमित प्रोग्रामिंग है। मैंने सोचा था कि साक्षर प्रोग्रामिंग का पूरा बिंदु डॉक्स में प्रोग्राम का वर्णन करना था और क्या सिस्टम प्रलेखन से कोड उत्पन्न करता है?

— मार्टिन बेकेट

3

"TeX, कार्यक्रम" पढ़ने की कोशिश करें। वहां टिप्पणियों में कोड को दोहराया नहीं जाता है। टिप्पणियाँ बताती हैं कि कोड इस तरह क्यों लिखा गया है, और वास्तुकला की व्याख्या करता है।

— एसके-तर्क 19

3

@MartinBeckett आप जो वर्णन करते हैं वह एलपी नहीं है।

— एंड्रेस एफ।