प्रोग्रामर्स की क्रमिक पीढ़ियों को प्रभावित करने वाली प्रणालियों की जटिलता में वृद्धि कैसे हुई है?


127

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

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

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

मेरा सवाल यह है कि अगर पुराने प्रोग्रामर इन जैसे इनोवेशन को एक ईश्वर के रूप में देखते हैं या एक अतिरिक्त परत के माध्यम से अमूर्त होते हैं, और वे ऐसा क्यों सोच सकते हैं? और क्या युवा प्रोग्रामरों को उच्च-स्तरीय प्रोग्रामिंग सीखने में अधिक लाभ होता है, जो विस्तृत पुस्तकालयों के दायरे की खोज कर रहा है? यदि ऐसा है तो क्यों?


24
2002 से जोएल स्पोल्स्की का लेख प्रासंगिक है: joelonsoftware.com/articles/LeakyAbstractions.html वाक्यांश / रूप में, हालांकि, इस सवाल का अंत मुख्य रूप से राय-आधारित माना जा सकता है।
ब्रायन एचएच

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

1
यह प्रासंगिक है। की तरह। (मेरा मतलब है, मुझे उम्मीद है कि छवि एक मजाक है, लेकिन
स्टैकऑवरफ्लो में

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

1
40/50 yr timescale गलत है। मेमोरी कुशल प्रोग्रामिंग अभी भी 16 बिट विंडोज (20 साल से कम पहले) और आज (सबसे दुर्भाग्यपूर्ण) रोबोटिक्स में महत्वपूर्ण रूप से महत्वपूर्ण है।
david.pfx

जवाबों:


174

यह आवश्यक नहीं है क्योंकि प्रसंस्करण शक्ति और स्मृति की बढ़ी हुई मात्रा उपलब्ध है।

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

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

हालांकि मेरा सवाल यह है कि लोग निचले स्तर के तत्वों के इस "छिपने" के बारे में कैसा महसूस करते हैं। क्या आप पुराने प्रोग्रामर इसे एक गॉडसेंड या अनावश्यक परत के रूप में देखते हैं?

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

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

क्या आपको लगता है कि युवा प्रोग्रामर कम-स्तरीय प्रोग्रामिंग सीखने से अधिक लाभान्वित होंगे, जो विस्तृत पुस्तकालयों के दायरे की खोज कर रहे हैं?

आप पहले से अधिक जोर देते हैं, इसलिए मुझे आपके प्रश्न का उत्तर नकारात्मक में देना चाहिए। मैं एक 12 साल के दोस्त को अभी कार्यक्रम सीखने में मदद कर रहा हूं और आपको बेहतर विश्वास होगा कि मैं उन्हें प्रसंस्करण में शुरू कर रहा हूं । न कि x86 कोडांतरक। यदि आप किसी युवा प्रोग्रामर को कुछ इस तरह से शुरू करते हैं, जैसे Processing.jsकि वे लगभग आठ घंटे में अपने शूट-एम-अप गेम लिख रहे होंगे। यदि आप उन्हें कोडांतरक में शुरू करते हैं तो वे लगभग आठ घंटे में तीन संख्याओं को एक साथ गुणा करेंगे। जो आपको लगता है कि एक युवा प्रोग्रामर के हित में संलग्न होने की अधिक संभावना है?

अब अगर सवाल "क्या प्रोग्रामर जो केक की लेयर एन को समझते हैं, लेयर n - 1 को समझने से फायदा होता है?" उत्तर हाँ है, लेकिन यह उम्र या अनुभव से स्वतंत्र है; यह हमेशा ऐसा मामला होता है कि आप अपने अंतर्निहित स्तर को बेहतर ढंग से अंतर्निहित अमूर्तताओं को समझकर सुधार कर सकते हैं।


12
+1 मज़ेदार उद्धरण: डनबर नंबर एक अच्छा उदाहरण है (अध्ययन के लिए अन्य लोग हैं) संज्ञानात्मक क्षमता वाले उद्धरण हैं जो कि कई लोगों को दिखाते हैं कि हमारे पास एक निश्चित मानसिक स्थान है। कई चीज़ों को एकवचन सामान्यीकरण में शामिल करना एकमात्र तरीका है जिससे हम अपने मानसिक स्थान में चीजों की संख्या को बढ़ा सकते हैं, और यही उच्च स्तर की प्रोग्रामिंग का लाभ उठाना चाहते हैं।
जिमी हॉफ

18
@ उत्साही: आपका सवाल समझ में आता है लेकिन आप कहाँ रुकते हैं? मान लीजिए कि मैं कहता हूं "अच्छी तरह से, सीखने की बजाय प्रसंस्करण। जेएस सीखें कि सी ++ में वीडियो गेम कैसे लिखना है। डायरेक्टएक्स का उपयोग करके"। अच्छी बात है। अब आपको यह कहने से रोकता है कि "क्या यह समस्या पैदा करने वाला नहीं है यदि वे कुछ कम सार करना चाहते हैं?" और इसलिए शायद हम ग्राफिक्स कार्ड ड्राइवर लिखने के साथ शुरू करना चाहते हैं। लेकिन तब आप फिर से सवाल पूछते हैं, और इससे पहले कि आप इसे जानते हैं, हम टॉगल स्विच के साथ एक अल्टेयर में मशीन कोड दर्ज कर रहे हैं। आपको कहीं न कहीं अमूर्तता का स्तर चुनना होगा !
एरिक लिपर्ट

35
@ व्यंग्यात्मक: क्या आप एक ही तर्क देंगे, कहना, कहना? हमें और अधिक लोगों की आवश्यकता नहीं है जो नए छोटे व्यवसाय के लिए सरल पुस्तकें रख सकते हैं; हमें महान, विश्व स्तरीय एकाउंटेंट की आवश्यकता है। यदि परिचयात्मक लेखांकन पाठ्यक्रम इतना कठिन है कि वे उन लोगों को डराते हैं जो केवल उत्पादक, काम करने वाले लेखाकार, गुड की इच्छा रखते हैं। हम लेखा उद्योग में उन लोगों की जरूरत नहीं है! पियानोवादकों के बारे में कैसे? यदि परिचयात्मक पियानो पाठ उन लोगों को डराता है जो महान पियानोवादक नहीं हैं, तो यह अच्छा है; हम दुनिया में केवल महान पियानोवादक चाहते हैं। क्या इस तर्क में कुछ गलत लगता है?
एरिक लिपिपर्ट

25
@ उत्साही: संक्षिप्त जवाब अच्छा है हाँ हमें और अधिक सभ्य प्रोग्रामर की आवश्यकता है! हमें क्षमता और अनुभव के प्रत्येक स्तर पर अधिक प्रोग्रामर की आवश्यकता है। दुनिया सॉफ्टवेयर पर चलती है । जितने अधिक लोगों को अपनी दुनिया को बेहतर बनाने की कोई समझ होगी, उतना ही बेहतर होगा।
एरिक लिपिपर्ट

6
@ यूफोरिक (और अन्य) - हम टिप्पणियों की रचनात्मकता के बारे में सीमा को मारने की तरह हैं। कृपया हमें सॉफ़्टवेयर इंजीनियरिंग चैट में शामिल करें यदि आप इस बातचीत को जारी रखना चाहते हैं।

50

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

आपके प्रश्न का एक सरल उत्तर उतना ही पुराना है जितना कि अरस्तू: प्रकृति एक निर्वात का पालन करती है । जितना मशीनों ने तेजी से और बड़ा किया है, उतना ही सॉफ्टवेयर धीमा और बड़ा हो गया है।

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

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

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

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

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

यह सच है, हमारे पास बहुत उपयोगी पुस्तकालय हैं। हालांकि, मुझे लगता है कि हमें अमूर्तता के बारे में बहुत चौकस होना चाहिए। हमें यह नहीं मान लेना चाहिए कि यदि B A पर बनाता है और यह अच्छा है, कि यदि C, B पर बनाता है तो यह और भी अच्छा है। मैं इसे "राजकुमारी और मटर" घटना कहता हूं। कुछ परेशानी के शीर्ष पर पाइलिंग परतें जरूरी नहीं कि इसे ठीक कर दें।

एक लंबी पोस्ट को समाप्त करने के लिए, मैंने प्रोग्रामिंग की एक शैली विकसित की है (जो कभी-कभी मुझे परेशानी में डालती है) जहां

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

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

3
@PeterMortensen: सहमत। यह अकेला है। इसके लिए एक शब्द है - कैसंड्रा कॉम्प्लेक्स
माइक डनलैवी

2
कोड कलाकृतियों को "विस्तारित" करने के लिए भाषाओं को लिखना एक कठिन उपक्रम नहीं है, एक अच्छा एपीआई बना रहा है जो समस्या डोमेन को
रॉबर्ट हार्वे

3
@ मायिक डनलैवी: बीटीडब्ल्यू: आप "नो-प्रोफाइलर" आदमी भी हैं (इसका मतलब सकारात्मक तरीके से है)। कुछ महीने पहले, मैंने फिर से वास्तविक दुनिया में आपकी तकनीक का उपयोग करते हुए दस्तावेज़ फ़ाइल के लोड समय को तेजी से कम करने के लिए आमतौर पर 25 सेकंड से 1 सेकंड (उपयोगकर्ता को सीधे अनुभव का लोड समय) दिया। इसने कुछ पुनरावृत्तियों को लिया, और सभी पुनरावृत्तियों में 10-20 नमूने पर्याप्त से अधिक थे। प्रदर्शन की समस्याएं निश्चित रूप से अप्रत्याशित स्थानों में थीं।
पीटर मोर्टेंसन

2
@ इज़काटा और पीटर: हाँ, मैं वह ऑडबॉल हूं। एफडब्ल्यूआईडब्ल्यू, मैंने कुछ युगल (बेहद शौकिया) वीडियो डाले, इसे समझने में आसान बनाने की उम्मीद में। रैंडम ठहराव। विभेदक निष्पादन। चीयर्स।
माइक डनलैवी

35

कंप्यूटिंग में चल रही प्रगति को प्राप्त करने के लिए उच्च-स्तरीय अमूर्तता आवश्यक है।

क्यों? क्योंकि मनुष्य किसी भी क्षण केवल इतना ज्ञान अपने सिर में धारण कर सकता है। आधुनिक, बड़े पैमाने पर सिस्टम केवल आज ही संभव हैं क्योंकि आप इस तरह के सार का लाभ उठा सकते हैं। उन अमूर्तता के बिना, सॉफ्टवेयर सिस्टम बस अपने स्वयं के वजन के तहत ढह जाएगा।

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

कंप्यूटिंग के शुरुआती दिनों में, हमने मशीन भाषा का उपयोग किया। हमने हार्डवेयर के अंतरंग ज्ञान के साथ बहुत छोटे, नंगे धातु के प्रोग्राम लिखे, जिनके लिए हम उन्हें लिख रहे थे। यह एक श्रमसाध्य प्रक्रिया थी। कोई डिबगर नहीं थे; आपका कार्यक्रम आमतौर पर या तो काम करता है, या यह दुर्घटनाग्रस्त हो गया। कोई GUI नहीं था; सब कुछ या तो कमांड-लाइन या बैच प्रक्रिया था। आपके द्वारा लिखा गया कोड केवल उस विशेष मशीन पर काम करेगा; यह एक अलग प्रोसेसर या ऑपरेटिंग सिस्टम वाली मशीन पर काम नहीं करेगा।

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

क्या यह सब अमूर्तता आपको हार्डवेयर से प्रेरित करती है? ज़रूर करता है। क्या एक तम्बू खड़ा करने के बजाय एक घर में रहना आपको प्रकृति से प्रेरित करता है? पूर्ण रूप से। लेकिन हर कोई जानता है कि वे एक तम्बू के बजाय एक घर में क्यों रहते हैं, और एक घर का निर्माण एक तम्बू को पिच करने की तुलना में पूरी तरह से अलग गेंद का खेल है।

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


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


1
+1, हालांकि मुझे लगता है कि आपको कार्यात्मक प्रोग्रामिंग का इतिहास पीछे मिला है (लैम्ब्डा कैलकुलस इलेक्ट्रॉनिक कंप्यूटरों से पहले, और कई कार्यात्मक भाषाएं समवर्ती प्रोग्रामिंग से पहले आती हैं)।
अमन

1
मैंने एक छोटा सा स्पष्टीकरण जोड़ा।
रॉबर्ट हार्वे

2
"कंप्यूटिंग के शुरुआती दिनों में, हमने मशीन भाषा का उपयोग किया। हमने हार्डवेयर के अंतरंग ज्ञान के साथ बहुत छोटे, नंगे धातु के कार्यक्रम लिखे, जिनके लिए हम उन्हें लिख रहे थे।" एम्बेडेड प्रोग्रामिंग में हम में से कुछ कभी-कभी ऐसा कर रहे हैं, 8-लेकिन माइक्रोकंट्रोलर पर जो 1K से कम प्रोग्राम मेमोरी, 64 बाइट्स रैम, और एक चौथाई के आसपास खर्च करते हैं। वहां कोई सी कंपाइलर नहीं। (लेकिन मैं आमतौर पर 32-बिट माइक्रोकंट्रोलर के साथ आमतौर पर 1/2 एमबी प्रोग्राम स्पेस के साथ काम करता हूं।)
tcrosley

9

वास्तव में अच्छे प्रशिक्षण में दोनों चरम शामिल हैं, साथ ही साथ एक पुल भी है।

निम्न-स्तरीय पक्ष पर: कैसे एक कंप्यूटर जमीन से * कोड को निष्पादित करता है, जिसमें विधानसभा भाषा का ज्ञान और एक संकलक क्या कर रहा है।

उच्च-स्तरीय पक्ष पर: सामान्य अवधारणाएं, जैसे कि साहचर्य सरणियों, क्लोजर आदि का उपयोग करना, बिना समय बर्बाद किए चिंता करना कि यह हुड के नीचे कैसे काम करता है।

IMHO हर किसी को दोनों के साथ अनुभव होना चाहिए, जिसमें उनकी कमियां भी शामिल हैं, और निम्न-स्तर की अवधारणाओं से उच्च-स्तरीय अवधारणाओं तक कैसे पहुंचें, इसका स्वाद। प्रेम सहयोगी सरणियाँ? महान, अब 1kB रैम के साथ 50-प्रतिशत एम्बेडेड प्रोसेसर पर उनका उपयोग करने का प्रयास करें। C का उपयोग करके तेज कोड लिखना पसंद है? महान, अब आपके पास वेब ऐप लिखने के लिए तीन सप्ताह हैं; आप अपना समय सी का उपयोग करके डेटा संरचनाओं और मेमोरी मैनेजमेंट से निपटने में बिता सकते हैं, या आप अपना समय एक नया वेब फ्रेमवर्क सीखने में बिता सकते हैं और फिर कुछ दिनों में वेब ऐप को लागू कर सकते हैं।

जहां तक ​​इसकी जटिलता का पहलू है: मुझे लगता है कि ऐसा करने की लागत की स्पष्ट समझ के बिना जटिल प्रणाली बनाने के लिए इन दिनों बहुत आसान है । परिणामस्वरूप, हमारे पास, एक समाज के रूप में, तकनीकी ऋण की एक बड़ी मात्रा का निर्माण हुआ जो हमें समय-समय पर काटता है। यह भूकंप की तरह है (सिर्फ एक भूवैज्ञानिक दोष के पास रहने की लागत, सही?), केवल यह धीरे-धीरे खराब हो रहा है। और मुझे नहीं पता कि इसके बारे में क्या करना है। आदर्श रूप से हम सीखेंगे और प्रबंधन की जटिलता को बेहतर बनाएंगे, लेकिन मुझे नहीं लगता कि ऐसा होने वाला है। एक जिम्मेदार इंजीनियरिंग शिक्षा में वर्तमान में प्रदान किए जा रहे हमारे विश्वविद्यालयों की तुलना में जटिलता के परिणामों की बहुत अधिक चर्चा शामिल करने की आवश्यकता है।


* और, वैसे भी, "ग्राउंड" कैसे एक कंप्यूटर कोड निष्पादित करता है? क्या यह विधानसभा की भाषा है? या कंप्यूटर आर्किटेक्चर? या डिजिटल लॉजिक? या ट्रांजिस्टर? या उपकरण भौतिकी?


7

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

अब हम प्रोग्रामिंग लैंग्वेज यूजर्स को प्रोग्रामिंग लैंग्वेज राइटर (कंपाइलर राइटर) से अलग कर सकते हैं। हम लेखकों के लिए आशावाद छोड़ देते हैं। हम रखरखाव, पुन: उपयोग आदि पर अधिक ध्यान केंद्रित करते हैं


7

प्रणालियों की जटिलता में वृद्धि अथक, दमनकारी और अंततः अपंग है। मेरे लिए एक पुरानी पीढ़ी के प्रोग्रामर के रूप में, यह भी निराशाजनक रूप से निराशाजनक है।

मैं 40 से अधिक वर्षों से प्रोग्रामिंग कर रहा हूं, 50-100 विभिन्न भाषाओं या बोलियों में लिखित कोड है, और 5-10 में विशेषज्ञ बन गया हूं। मेरे इतने सारे होने का कारण यह हो सकता है कि ज्यादातर वे केवल एक ही भाषा हैं, ट्विक्स के साथ। जुड़वाँ जटिलता को जोड़ते हैं, जिससे हर भाषा थोड़ी अलग होती है।

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

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

मैंने चौथी पीढ़ी की भाषाओं के युग में अपना शिल्प सीखा, जहाँ हम वास्तव में यह मानते थे कि हम लेखन सॉफ्टवेयर के दोहराव वाले भागों में उत्तरोत्तर अधिक से अधिक भाषाओं को पकड़ने के लिए उच्च और उच्च स्तर की भाषाओं का उत्तराधिकार प्राप्त करेंगे। तो यह कैसे निकला, बिल्कुल?

माइक्रोसॉफ्ट और आईबीएम ने विंडोज और ओएस / 2 के लिए ऐप लिखने के लिए सी पर लौटकर उस विचार को मार दिया, जबकि डीबेस / फॉक्सप्रो और यहां तक ​​कि डेल्फी भीग गई। फिर वेब ने इसे फिर से विधानसभा भाषाओं की अपनी अंतिम तिकड़ी के साथ किया: एचटीएमएल, सीएसएस और जावास्क्रिप्ट / डोम। यह सब वहाँ से खस्ताहाल है। हमेशा अधिक भाषाओं और अधिक पुस्तकालयों और अधिक रूपरेखा और अधिक जटिलता।

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

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

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

अंतिम शब्द: जटिलता परम दुश्मन है! मारो कि और जीवन सरल हो जाए।


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

@dicsalvage: मैं सहमत हूं, और मेरी बड़ी निराशा कभी उच्च स्तर की कमी है। 1980 के दशक में 10 लाइनों में क्या awk कर सकते थे अब रूबी या पाइथन में 15 लाइनें लें, लेकिन मैं इसे करने के लिए कुछ ढूंढता हूं। 3. और फोन पर बंद वातावरण का मतलब है कि जावा या ऑब्जेक्टिव सी में 50 ही लगते हैं। शेल स्क्रिप्ट!
david.pfx

Google "एंड्रॉइड के लिए बैश" बंदरगाहों पर काम करने वाले बहुत से लोगों को दिखाता है। पाइथन के संस्करण भी हैं जैसे किवी
डॉकस्लेवगेर

@DocSalvage: जल्द या बाद में फोन का माहौल सभ्यता में शामिल हो जाएगा (जैसा कि हम जानते हैं)। मेरी शिकायत बार-बार करने में लगने वाला समय है और जो चीजें खत्म होती दिख रही हैं। जब हम गगनचुंबी इमारतों का निर्माण करना चाहते हैं, तो हम नींव और ईंट-पत्थर और ड्रेनेज और शेक को बिछाने के लिए वापस जाते रहते हैं।
david.pfx

4

हालांकि मेरा सवाल यह है कि लोग निचले स्तर के तत्वों के इस "छिपने" के बारे में कैसा महसूस करते हैं। क्या आप पुराने प्रोग्रामर इसे एक गॉडसेंड या अनावश्यक परत के रूप में देखते हैं?

न, वास्तव में।

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

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

क्या आपको लगता है कि युवा प्रोग्रामर कम-स्तरीय प्रोग्रामिंग सीखने से अधिक लाभान्वित होंगे, जो विस्तृत पुस्तकालयों के दायरे की खोज कर रहे हैं?

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

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

इस सब का कारण यह है कि यह अब केवल विकास के बारे में नहीं है। निरंतर विशेषज्ञता का मतलब है कि डेवलपर्स को अपने संचार और एकीकरण कौशल में सुधार जारी रखने की आवश्यकता होगी।


3

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

इसका सार यहाँ वर्णित है

या यहाँ - "कोड की एक एकल पंक्ति के साथ आप डोमेन में 500 उपयोगकर्ता जोड़ सकते हैं" ...

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


2

क्या युवा प्रोग्रामर को उच्च-स्तरीय प्रोग्रामिंग सीखने में अधिक लाभ होता है, जो कि विस्तृत पुस्तकालयों के दायरे की खोज कर रहा है? यदि ऐसा है तो क्यों?

मुझे ऐसा नहीं लगता। अभी भी बहुत सारी स्थितियाँ ऐसी हैं जिनमें 'परत के नीचे' के कार्यों के बारे में जानकारी होना फायदेमंद है, जैसे

  • परत पर किसी समस्या को डीबग करते समय n, अक्सर यह विचार करके समझाया जा सकता है कि परत पर क्या होता है n-1(यानी नीचे की परत)। मुझे लगता है कि परत 0 "ट्रांजिस्टर" होगा, लेकिन यदि आप ट्रांजिस्टर के साथ एक समस्या की व्याख्या करना चाहते हैं, तो आप शायद भौतिकी (उदाहरण के लिए गर्मी) के बारे में बात करेंगे, इसलिए शायद भौतिकी वास्तव में स्तर 0 है।

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

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

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

  • आपके द्वारा लिखे गए कार्यक्रमों में तार्किक त्रुटियों को खोजने में कंप्यूटर आपकी मदद करता है। स्टैटिक टाइप सिस्टम या सोर्स कोड एनालाइजर जैसी चीजें (मुझे लगता है कि एरिक लिपर्ट इन दिनों काफी लोकप्रिय हैं) उनकी मदद करते हैं।

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

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



1

"अगर पुराने प्रोग्रामर इन जैसे नवाचारों को एक देवी के रूप में देखते हैं या एक अतिरिक्त परत के माध्यम से अमूर्त करते हैं, और वे ऐसा क्यों सोच सकते हैं?"

जब से मैं हाई स्कूल में था तब से प्रोग्रामिंग कर रहा हूँ, लगभग 34 साल, बेसिक और Z80 असेंबलर से शुरू करके, C, विभिन्न 4GL भाषाओं, स्कीम, SQL और अब विभिन्न वेब भाषाओं पर जा रहा हूँ। पेशे से संबोधित समस्याओं का दायरा, पैमाना और गहराई उस समय की मुद्रास्फीति की अवधि का अनुभव करती थी, खासकर 1990 के दशक में। पुस्तकालयों, चौखटे, और ओएस सेवाओं जैसे निर्माण सभी जटिलताएं हैं जो समस्याओं के विस्तारित स्थान के साथ जाने वाली जटिलता को संबोधित करने के लिए हैं। वे एक देवता नहीं हैं और न ही अपने आप में एक बोझ हैं - एक विशाल समाधान स्थान का सिर्फ एक निरंतर अन्वेषण।

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

"और क्या छोटे प्रोग्रामर को उच्च-स्तरीय प्रोग्रामिंग सीखने में अधिक लाभ होता है, जो कि विस्तृत पुस्तकालयों के दायरे की खोज कर रहा है। यदि ऐसा है तो क्यों?"

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

OTOH, भले ही आपका लक्ष्य एक तकनीशियन / यांत्रिक स्तर के रूप में काम करना हो, लेकिन निम्न स्तर के प्रोग्रामिंग एक्सपोज़र का कुछ स्तर अभी भी आपकी समस्या को सुलझाने के कौशल को विकसित करने में सहायक होने वाला है।


1

मेरा पहला कार्यक्रम (15 साल की किशोरी के रूप में) 1974 में आईबीएम 370/168 मेनफ्रेम के लिए पंच कार्डों पर पीएल / 1 में था। मेरे पिता आईबीएम में काम कर रहे थे और मैं भाग्यशाली था कि रविवार को डेटासेंटर में जा पाया।

उस समय, कई हज़ारों बयानों का एक कार्यक्रम (iepunched कार्ड) एक बड़ा कार्यक्रम था (और एक भारी भी, क्योंकि कई हजार कार्डों में कई किलोग्राम वजन होता था)। विजुअल इंटरफेस मौजूद नहीं थे ( //GO.SYSIN DD *IIRC के साथ शुरू होने वाले एक छिद्रित कार्ड कमांड का उपयोग करके अपने "मानक इनपुट" से पढ़ा गया एक विशिष्ट कार्यक्रम , लेकिन मैंने JCL में मास्टर नहीं किया था )। एल्गोरिथम महत्वपूर्ण था, और IIRC मानक पुस्तकालय आज के मानक से काफी छोटा था।

आज, कई हजारों लाइनों के कार्यक्रमों को आम तौर पर छोटा माना जाता है। उदाहरण के लिए, जीसीसी संकलक के पास स्रोत कोड की दस लाख से अधिक लाइनें हैं, और कोई भी उन्हें पूरी तरह से नहीं समझ रहा है।

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

मुझे अभी भी लगता है कि निम्न-स्तरीय प्रोग्रामिंग को समझना आज भी महत्वपूर्ण है (भले ही अधिकांश प्रोग्रामर अपने आप को बुनियादी कंटेनर एल्गोरिदम को संतुलित पेड़ों की तरह कोडित नहीं करेंगे, द्विचमीय रूप से सॉर्ट किए गए सरणियों, आदि ...) क्योंकि पूरी तस्वीर अभी भी महत्वपूर्ण है।

1970 और आज के बीच एक बड़ा अंतर डेवलपर (मानव) के प्रयासों और कंप्यूटर शक्ति के बीच लागत का अनुपात है।

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