क्या आप आलसी हैं उपकरणों पर अत्यधिक निर्भरता? [बन्द है]

Question

मैंने uni में C ++ में प्रोग्रामिंग शुरू की और उसे पसंद किया। अगले कार्यकाल में हम VB6 में बदल गए और मुझे इससे नफरत थी।

मैं यह नहीं बता सकता था कि क्या चल रहा है, आप एक बटन को एक फॉर्म में खींचें और विचारक आपके लिए कोड लिखता है।

जब मुझे VB के कार्य करने के तरीके से नफरत थी, तो मैं यह तर्क नहीं दे सकता कि यह C ++ में एक ही काम करने की तुलना में तेज़ और आसान था, इसलिए मैं देख सकता हूं कि यह एक लोकप्रिय भाषा क्यों है।

अब मैं VB डेवलपर्स को केवल C ++ की तुलना में आसान कहने में आलसी नहीं कह रहा हूं और मैंने देखा है कि बहुत सी नई भाषाएं इस तरह के C # का अनुसरण कर रही हैं।

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

क्या यह सिर्फ एक जूनियर प्रोग्रामर की सूचना के अधीन है या प्रोग्रामर सामान्य रूप से आलसी और कम सक्षम हैं?

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

यही कारण है कि मैं इस सिद्धांत के साथ काम करता हूं कि प्रोग्रामर आलसी और कम सक्षम हो रहे हैं क्योंकि कोई भी परवाह नहीं करता है कि सामान कैसे काम करता है जब तक कि यह नहीं करता है।

Comments

"क्या यह सिर्फ एक जूनियर प्रोग्रामर की सूचना के अधीन है या प्रोग्रामर सामान्य रूप से आलसी और कम सक्षम हैं?" - यह या तो नहीं है या दोनों सच हैं (सिर्फ उन कारणों के लिए नहीं जो आप कहते हैं)।

— जॉन हॉपकिंस

शीर्षक को नापसंद किए बिना कोई भी इसका जवाब कैसे दे सकता है ?

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

इसे "व्यक्तिपरक और तर्कपूर्ण" के रूप में बंद क्यों नहीं किया गया है ...?

— ब्लूराजा - डैनी पफ्लुघोटे

यह सवाल अब हमारी मेटा-चर्चा साइट पर चर्चा कर रहा है ।

Answer 1

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

हालाँकि, एक अंतिम बिंदु है। हमेशा कुछ डेवलपर्स की आवश्यकता होगी।

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

इसी तरह डेटा लेयर, जो आम तौर पर कुछ भी नहीं है, लेकिन यह डालें, इसे हटाएं, इसे बदलें और एक ही डेटा के विभिन्न विचारों की एक बड़ी संख्या। क्यों बार-बार लिखते रहे? चलो ORM का आविष्कार करते हैं।

केवल एक चीज जिसे आपको विकसित करना चाहिए, वह कोड है जो आपके द्वारा विकसित किए जा रहे व्यवसाय के लिए अद्वितीय है।

लेकिन वहाँ हमेशा वह विशिष्टता होगी - जहाँ नहीं है, वहाँ एक व्यापार का अवसर है - और हमेशा लोगों को कोड लिखने की आवश्यकता होगी।

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

एक सॉफ्टवेयर डेवलपर होने का सबसे महत्वपूर्ण हिस्सा कंप्यूटर को समझाने के लिए व्यवसाय की आवश्यकता को अच्छी तरह से समझने में सक्षम है।

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

Comments

एक डेवलपर और एक प्रोग्रामर होने के बीच एक अंतर है।

— रायनोस

+1। ठीक ठीक। कार्यशील सॉफ़्टवेयर वह है जिसके लिए आपको भुगतान किया जाता है। कोड एक सॉफ्टवेयर, एक कलाकृति बनाने का एक साधन है। शुद्ध "प्रोग्रामिंग" सॉफ्टवेयर बनाने का आसान और मजेदार हिस्सा है।

— जूनस पुलकका

पूरे के लिए +1। मुझे यकीन नहीं है कि मैं "आपके द्वारा विकसित की जा रही एकमात्र चीज कोड है जो आपके द्वारा विकसित किए जा रहे व्यवसाय के लिए अद्वितीय है।" लेकिन मैं स्वीकार करूंगा कि यह एक वैध व्यवसाय रणनीति है।

— सोयलेन्टग्रे जूल

@Chad - अपनी बात कहो। मैं कभी-कभी हाइपरबोले में बात करता हूं। कॉमन सेंस हमेशा दर्शन पर हावी हो जाता है, जब यह क्रंच की बात आती है, लेकिन मुझे लगता है कि यह केस-बाय-केस से नीचे बात करने के लिए एक अच्छी स्थिति है, बजाय "हाँ, चलो इसे खुद लिखें।" :)

— पीडीआर

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

— डैन विलियम्स

Answer 2

क्या एक मैकेनिक आलसी और कम सक्षम है क्योंकि वह हाइड्रोलिक रिंच का उपयोग कर रहा है ?

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

दूसरी ओर, पीट का कहना है कि हाइड्रोलिक रिंच निन्दा है और ब्रैड "वास्तविक मैकेनिक" नहीं है। निश्चित पीट केवल वही कर सकता है जो ब्रैड करता है, लेकिन वह इसे "सही तरीके" से करता है।

अब आपको क्या लगता है, कौन सा गैराज ग्राहक चुनेंगे? एक जो 40 मिनट के इंतजार के साथ 20 मिनट या एक लेता है।

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

काम पूरा करने के लिए बेहतर उपकरणों का उपयोग करें - यह कुछ भी गलत नहीं है।

Comments

मुझे नहीं लगता कि सादृश्य काम करता है क्योंकि ब्रैड और पीट दोनों को अभी भी पता चलेगा कि टायर को कैसे निकालना है, और इसमें सब कुछ शामिल है (वेनचेज़, रिंच और बीयर)।

— क्रिस्टोफर होच

+1 महान जवाब। मुझे लगता है कि कोई फर्क नहीं पड़ता कि आप किस उपकरण का उपयोग करते हैं, यदि आप समझते हैं कि यह क्या करता है, तो आप अपना काम सही करेंगे। दूसरी ओर, यदि आप नहीं करते हैं, तो कोई मैटर नहीं करता है कि उपकरण द्वारा कितना काम किया जा रहा है, कुछ बिंदु पर आप कुछ पेंच करने जा रहे हैं।

— जसक प्रूशिया

@ क्रिस्टोफर: शायद यह बेहतर होगा अगर पीट कुछ इलेक्ट्रॉनिक्स को जानता है। जबकि ब्रैड केवल निदान कंप्यूटर का उपयोग करना जानता है और पढ़ता है कि ओ 2 सेंसर खराब हो गया है, पीट देखता है कि सेंसर तार थोड़ा जला हुआ है, इसे मापने के लिए मीटर निकलता है और पता चलता है कि वोल्टेज नियामक जीत गया है और है बाहर जल O2 सेंसर।

— ज़ैन लिंक्स

@Zan वही बात नहीं है। @Kristofer सिर्फ इसलिए कि मैं एक फार्म तत्व पर नियंत्रणों को जल्दी से खींचने के लिए डिजाइनर का उपयोग करता हूं और बॉयलरप्लेट कोड प्राप्त करता हूं इसका मतलब यह नहीं है कि मुझे पता नहीं है कि फिर उस कोड को कैसे बदलना है जो मुझे बाद में चाहिए।

— jcolebrand

इसे लगाने का सही तरीका।

— रिवलक

Answer 3

तो, अब हम प्रोग्रामिंग को क्या कह रहे हैं

तुम कहो:

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

बस एक प्रयोग करें: स्टार ट्रेक देखें, और उन चीज़ों की व्याख्या करने की कोशिश करें जिन्हें कंप्यूटर को थोड़ा 'ग्रेसलेस' करने का आदेश दिया गया है।

• चाय, ईयर ग्रे, गर्म -> बहुत सी भाप।
• चाय, ईयर ग्रे, 60 डिग्री सेल्सियस -> एक पोखर और भाप का एक बादल
• कान ग्रे, 60 डिग्री सेल्सियस -> एक पोखर
• इयर ग्रे, 60 डिग्री सेल्सियस, एक कप में -> इसमें एक बूंद के साथ एक कप
• एक कप में इयर ग्रे, 60 डिग्री सेल्सियस, 0.2 लीटर। -> अंत में (ठीक है, आप अधिक नाइटपिक कर सकते हैं)

जब आप प्रोग्रामिंग कहते हैं: 'मेमोरी उपयोग, पॉइंटर्स आदि के बारे में जानना', हां, मुझे लगता है कि यह कम महत्वपूर्ण हो जाएगा (जैसा कि 'http, ओपनिड, यूनिकोड के बारे में जानना' अधिक महत्वपूर्ण हो जाएगा)।

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

Comments

@ रयोनोस: सू सच्चा। विशेष रूप से निराशाजनक जब ये लोग टीम के साथी होते हैं, और 'जब डेटा भेजने के लिए एक्स बाइट्स से कम हो, तो दिशा-निर्देश बनाते हैं, GET का उपयोग करें, जब अधिक हो, POST का उपयोग करें'

— कीपला

@keppla - आपका मुद्दा यह नहीं है कि आपकी टीम के नेता ने HTTP को नहीं समझा, यह है कि वह सबूतों के प्रकाश में अपनी राय बदलने को तैयार नहीं था कि वह गलत था (यह मानते हुए कि आपने उसे चीजों को समझाने की कोशिश की थी)। आप उन सभी से अधिक नहीं जान सकते जो आपके लिए हर चीज के बारे में काम करते हैं - वास्तविक अपराध यह स्वीकार नहीं कर रहा है कि कोई व्यक्ति आपके बारे में कुछ के बारे में अधिक जानता है।

— जॉन हॉपकिंस

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

— १६:३१ को

@Diadem: यहां तक ​​कि जब यह घोषणात्मक है, तो आपको यह जानना होगा कि क्या घोषित करना है, और एक प्रोग्रामर के रूप में, imho, आपको उम्मीद नहीं होगी कि कंप्यूटर अतीत से अनुमान लगा सकता है कि आप आगे क्या करेंगे, क्योंकि आप sth नया करेंगे। आपकी इच्छाओं की व्याख्या करने वाला इंटरफ़ेस अंतिम उपयोगकर्ताओं के लिए है।

— कीपला

@Zan Lynx: हो सकता है कि एक बेहतर उदाहरण: कंप्यूटर को आपको आगाह कर दें, हर बार किसी का अपहरण कर लिया जाता है (कंप्यूटर को टीएनजी में इसकी कोई परवाह नहीं लगती)। 'कंप्यूटर: मुझे सूचित करें, जब किसी का अपहरण कर लिया जाता है' 'कृपया उसे अपहरण कर लें।' ज्ञात से अज्ञात तक, और कोई लॉग नहीं है कि एक परिवहन अधिकारी ने उसे दूर फेंक दिया या उसने एक शटल में प्रवेश किया, और जहाज गोदी में नहीं है। ' आपको अभी भी एक प्रोग्रामर माइंडसेट की आवश्यकता है।

— कीपला

Answer 4

प्रोग्रामर्स को लेजियर नहीं मिल रहा है। प्रोग्रामर हमेशा आलसी रहे हैं। आलसी होना नौकरी की मौलिक प्रकृति का हिस्सा है। समस्या यह है कि लोग मानते हैं कि आलसी होना नकारात्मक है। "आलसी" प्रोग्रामर होना एक गुण है।

पुरानी कहावत को याद रखें, "होशियार काम करें, कठिन नहीं।" यह प्रोग्रामर का मूलभूत अभियान है।

लोग बनाया और प्रोग्राम पहले कंप्यूटर ऐसा नहीं किया क्योंकि वे कड़ी मेहनत कर रही पसंद है, वे करने के लिए यह किया बचें और भी कठिन काम करते हैं। (हाथ से गणना के पृष्ठ कर)

'आलसी' होना मूलभूत कारणों में से एक है कि प्रोग्रामर प्रोग्राम क्यों करते हैं। यही कारण है कि हम नई और कभी भी उच्च स्तरीय भाषाएं लिखते हैं, बेहतर और बेहतर डिबगर्स और आईडीई, शेल और स्क्रिप्ट का निर्माण करते हैं, आदि ...

एक प्रोग्रामर एक समस्या को देखता है, कुछ भी वह या वह करता है और सोचता है;

"क्या मैं इसे स्वचालित कर सकता हूं?" , "कितना समय लगेगा?" , "मुझे बचाने में कितना समय लगेगा?"

हम ऐसा इसलिए करते हैं क्योंकि हम आलसी हैं, हम एक दोहराव और उबाऊ कार्य नहीं करना चाहते हैं जब हम ऐसी चीजें कर सकते हैं जो कहीं अधिक मजेदार हैं।

यदि प्रोग्रामर आलसी नहीं थे, तो किसी भी प्रोग्रामर को कभी भी एक नई भाषा या कंपाइलर लिखने की आवश्यकता नहीं दिखती।

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

अगर कोई हार्ड प्रोग्रामिंग काम करना चाहता है, तो मैं उनसे कहूंगा कि हेक्स में कुछ कच्चे मशीन कोड हाथ से कोड करें। हो गया? कुछ कठिन चाहते हैं? अब इसे डीबग करें।

Answer 5

कचरा-कलेक्टर आलसी के साथ उदाहरण के लिए भाषाओं का उपयोग करने वाले लोगों को कॉल करने वाले लोगों में से सबसे पहले, स्वचालित ट्रांसमिशन ट्रांसमिशन वाली कारों को चलाने वाले लोगों को कॉल करने की तरह है। IMO यह थोड़ा हास्यास्पद है।

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

Comments

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

— कोडर

@ कोडर: "अतिरिक्त काम की आवश्यकता है" - राजमार्ग पर यह ट्रैफ़िक जाम में नहीं होता है, लेकिन फिर यह आपको किसी भी तरह से कोई फायदा नहीं देता है।

— vartec

मैनुअल ट्रांसमिशन भी राजमार्ग पर बेहतर ईंधन अर्थव्यवस्था प्रदान करते हैं, हालांकि लॉक-अप टॉर्क कन्वर्टर्स के साथ यह कम सच है।

— डेव मार्कले

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

— सोयालेंटग्रे जूल

@ कोडर - यदि आपको लगता है कि मैनुअल ड्राइविंग के लिए "बहुत कौशल" की आवश्यकता होती है, तो आपको मैनुअल ट्रांसमिशन के साथ सड़क पर हजारों अक्षम ड्राइवरों को देखने की आवश्यकता है। ;)

— techie007

Answer 6

मुझे यह कहते हुए ललचाया गया, "हाँ, बिन बुलाए जाने वाले कनिष्ठ प्रोग्रामर आलसी और कम सक्षम हो गए हैं", लेकिन आइए एक गंभीर उत्तर देने की कोशिश करें:

कई चीजें आसान हो गई हैं, लेकिन हमसे ज्यादा की उम्मीद की जाती है। मैं वर्तमान में एक वेब ऐप बना रहा हूं जिसमें बहुत सारे फीचर्स हैं जो आमतौर पर अच्छी तरह से बनाए गए गुई ऐप (टैब किए गए विचार, संपादन योग्य और छांटने वाले ग्रिड, एक्सेल एक्सपोर्ट आदि) में मिलते हैं। मैं जो उपकरण (एक्सटीजेएस आदि) का उपयोग कर रहा हूं, ऐसे ऐप बनाने के लिए यह काफी सस्ती है।

दस साल पहले, ऐसा ऐप बनाना लगभग असंभव था, कम से कम बहुत महंगा। लेकिन दस साल पहले, एचटीएमएल टेबल के साथ एक सरल एचटीएमएल फॉर्म ग्राहकों के लिए पर्याप्त होता। आज उसी प्रयास के साथ, बेहतर (कम से कम अधिक सुंदर) परिणाम संभव हैं, और ग्राहकों को उन्हें प्राप्त करने की उम्मीद है!

सामान्य तौर पर, आज के एक सॉफ्टवेयर डेवलपर को 20 साल पहले एक सॉफ्टवेयर डेवलपर की तुलना में अधिक भाषाओं को जानने की आवश्यकता होती है। वापस तो, सी और एसक्यूएल जैसे कुछ पर्याप्त थे। आज, मैं एक ही परियोजना में जावास्क्रिप्ट, एचटीएमएल, ग्रूवी, जावा, एसक्यूएल का उपयोग कर रहा हूं।

Comments

+1 हाँ, बिना विचार के कनिष्ठ जूनियर प्रोग्रामर आलसी और कम सक्षम हो गए हैं

— सोयलेंटग्रे जूल

Answer 7

प्रोग्रामर कुछ तरीकों से कम सक्षम और आलसी होते जा रहे हैं, लेकिन दूसरों में अधिक सक्षम हैं, हालांकि सी ++ / वीबी डिवाइड मेरे दिमाग में इसका कारण या लक्षण नहीं है।

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

व्यापक बिंदु पर, आमतौर पर प्रोग्रामर की शिक्षा पहले की तुलना में अब बेहतर है। उदाहरण के लिए स्रोत नियंत्रण का उपयोग नहीं करने का विचार बहुत ज्यादा हर किसी के लिए बहुत घृणित है जहां 10 या 20 साल पहले ऐसा नहीं हुआ था। इसी तरह वे समझने की अधिक संभावना रखते हैं और स्वचालित इकाई परीक्षण, निरंतर एकीकरण और इतने पर उपयोग करना चाहते हैं, इसलिए इस मायने में वे उनके मुकाबले अधिक सक्षम हैं।

लेकिन मुझे लगता है कि यह बदल गया है कि लोगों को अब यह नहीं पता है कि समस्या को कैसे हल किया जाए जो वे करते थे और यह किसी भी मुख्यधारा की भाषा के लिए बहुत सही है। किसी भी मुद्दे पर अब तुरंत प्रतिक्रिया देना Google है और जब तक यह बहुत अच्छा है और 95% काम करता है, मुझे बहुत सारे प्रोग्रामर मिलते हैं, जिन्हें पता नहीं है कि यह क्या करना है।

ऐसा नहीं है कि वे मूल सिद्धांतों को नहीं समझते हैं (वे ऐसा नहीं करते हैं लेकिन यह वास्तव में उतना बड़ा सौदा नहीं है), यह है कि वे समस्याओं को इस तरह से नहीं तोड़ सकते हैं कि वे उन बुनियादी बातों को भी काम कर सकें जो उन्हें करने की आवश्यकता है के साथ पकड़ हो रही है।

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

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

लेकिन शायद यह इन दिनों प्रोग्रामर की एक महत्वपूर्ण आलोचना के रूप में देखने के लिए कठोर है, वे कौशल विकसित नहीं करते हैं क्योंकि उन्हें उनकी आवश्यकता नहीं है, लेकिन यह उन लोगों की तुलना में एक कमजोरी है जो कौशल से उठाते हैं जब वे आवश्यक थे।

Comments

इसलिए जब कोई नहीं जानता कि एल्गोरिथ्म क्या है या डेटा संरचना को कैसे लागू किया जाए क्योंकि वे सभी "प्रोग्राम" खींचें और ड्रॉप आईडीई के हैं तो क्या वे सिर्फ नौकरी के लिए सही उपकरण का उपयोग कर रहे हैं?

— स्केथ जूथ

@ स्किथ - डिपेंड करता है कि जॉब क्या है लेकिन अगर वह ऐसे सॉफ्टवेयर का निर्माण करता है जो समस्या को हल करता है तो हां।

— जॉन हॉपकिंस

@ जॉन-हॉपकिंस, मैं कहूंगा कि Google पर निर्भर प्रोग्रामिंग में बड़े पैमाने पर अपटेक को उन एपीआई की भारी संख्या के साथ करना पड़ता है जिनकी हमें आजकल आवश्यकता है। यह सब का ट्रैक रखने के लिए बहुत मुश्किल है। (लेकिन, अनिवार्य रूप से, आप सही हैं)

— जर्रॉड नेटल्स

@ स्किथ - एक यूआई के निर्माण में औसत एप्लिकेशन डेवलपर्स समय का लगभग 5% हिस्सा लगता है। आपको क्या लगता है कि वे अन्य 95% क्या करते हैं? डिजाइनर बैकएंड कोड के साथ ज्यादा मदद नहीं करता है। आप स्पष्ट रूप से एक पुआल आदमी पर हमला कर रहे हैं। अधिकांश लोग अपने काम के लिए आवश्यक उपकरण जानते हैं, अन्यथा वे नियोजित नहीं होंगे।

— मॉर्गन हेरलॉकर

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

— निकोल बोलस

Answer 8

मैं आपकी प्रोफ़ाइल से ध्यान देता हूं कि आप 23 वर्ष के हैं। मुझे अपने दाँत लगाने दो और अपनी उम्र के बारे में दो बार किसी से कुछ परिप्रेक्ष्य दे दो जो बहुत लंबे समय से कर रहे हैं:

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

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

... कोई परवाह नहीं करता है कि सामान कैसे काम करता है जो वह तब तक करता है जब तक वह नहीं करता।

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

अब मैं VB डेवलपर्स को केवल C ++ की तुलना में आसान कहने में आलसी नहीं कह रहा हूं और मैंने देखा है कि बहुत सी नई भाषाएं इस तरह के C # का अनुसरण कर रही हैं।

यह सब परिप्रेक्ष्य की बात है। मैं देखने के लिए C ++ अस्तित्व में आया था, और यह उस प्रवृत्ति का अनुसरण करता है। C ++ C की तुलना में चीजों को बहुत आसान बनाता है, C चीजों को असेंबली की तुलना में बहुत आसान बनाता है और असेंबली चीजों को हाथ से ऑपकोड लिखने की तुलना में बहुत आसान बनाती है। जैसा कि किसी ने बहुत सी असेंबली लिखी है और खरोंच से हाथ से कुछ चीजें इकट्ठी की हैं, जो आपको सी ++ प्रोग्रामर के रूप में, "यह आसान है" पथ से तीन कदम नीचे है।

Comments

+1 यह बताते हुए कि यह परिप्रेक्ष्य की बात है। मैं उस समय आसपास था जब UNIX पहली बार बेल लैब्स से बाहर आया था और काफी मात्रा में 'tsk tsk'ing' था कि 'C' जैसी उच्च स्तरीय भाषाएं ऑपरेटिंग सिस्टम लिखने की प्राचीन और गूढ़ कला को कम कर रही थीं, और यह निश्चित रूप से आगे ले जाएगा अच्छा नहीं। जैसे-जैसे हमारे उपकरण बेहतर होते हैं और हमारे लिए अधिक नासमझी बहीखाता पद्धति का ध्यान रखते हैं, हम कठिन और अधिक सूक्ष्म समस्याओं से निपटने के लिए बचाए गए समय का उपयोग कर सकते हैं।

— चार्ल्स ई। ग्रांट

Answer 9

कुछ समय के लिए मैंने कुछ बनाए रखा है:

विजुअल बेसिक लैंग्वेज की एक सबसे बड़ी खूबी यह है कि एक शुरुआत करने वाला कई उपयोगी चीजों को काफी जल्दी करना सीख सकता है।

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

जब मैं पहली एक्सरसाइज की प्रोग्रामिंग सिखाऊंगा, तो क्लास का पहला दिन नोटपैड में एप्लिकेशन बनाने और वीसीसी या वीबीसी का उपयोग करके इसे संकलित करने का था। हां, ये ऐसी चीजें हैं जिन्हें हम (प्रोग्रामर के रूप में) दैनिक आधार पर नहीं करते हैं, लेकिन यह समझना चाहिए कि जब हम "एफ 6" दबाते हैं तो क्या हो रहा है।

प्रोग्रामर (आम तौर पर) 'लेज़ीयर' नहीं प्राप्त कर रहे हैं जितना हम अपने टूल से बाहर निकलने की उम्मीद कर रहे हैं। मुझे दिन में 10,000 बार "गेट / सेट" टाइप करने की कोई आवश्यकता नहीं है, मैं उस विज़ुअल स्टूडियो और कोड स्मिथ और रिसर्पर जैसे अन्य टूल के लिए काम करता हूं जो मुझे पहले से ही पता है कि मुझे कैसे करना है ताकि मैं अपनी कोशिश को लागू कर सकूं "नई" चीजें कैसे करें। यह मुझे आलसी नहीं बनाता है, जो मुझे "अभिनव" बनाता है।

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

Answer 10

के लिए की जरूरत रैपिड एक्शन डेवलपमेंट (अनिवार्य विकी लिंक: http://en.wikipedia.org/wiki/Rapid_application_development ) का मतलब है डेवलपर्स लिखते हैं कि कम कोड और नए डेवलपर्स, कम समझते हैं क्योंकि वे समझते हैं कि कैसे एक को लागू करने की जरूरत नहीं है लिंक की गई सूची चूंकि उन्हें ध्यान केंद्रित करने के लिए कुछ और उच्च स्तर मिला है।

मैं मांस को नहीं पकड़ सकता, मार सकता हूं, त्वचा, कसाई और मांस को ठीक कर सकता हूं, और मुझे लगता है कि कैफे के नीचे के हिस्से में आदमी को शक हो सकता है, लेकिन मुझे अभी भी उससे मेरे बेकन सैंडविच मिलते हैं, जैसे बहुत से व्यवसायियों को डेवलपर्स से अपने ऐप मिलते हैं जिनके बारे में पता नहीं है संकेत (मेरी तरह)

Answer 11

यह कहा गया है कि महान वैज्ञानिक विषय अन्य दिग्गजों के कंधों पर खड़े दिग्गजों के उदाहरण हैं। यह भी कहा गया है कि सॉफ्टवेयर उद्योग अन्य बौनों के पंजों पर खड़े मिडजेट्स का उदाहरण है।
- एलन कूपर

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

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

Answer 12

नहीं, आप अभी बूढ़े हो रहे हैं।

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

जब तक मशीनें हम सभी को नष्ट नहीं करती हैं, तब तक यह निंदा दोहराई जाएगी: "क्या ऐसा लगता है कि प्रौद्योगिकी एक्स डेवलपर्स को लज़ीयर बना रही है और प्रौद्योगिकी जेड से भी बदतर है जो मैंने हमेशा उपयोग किया है?"

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

Comments

+1: "ये आलसी बच्चे आज अपने रथ और धनुष और तीर के साथ। जब मैं एक बालक था, तो हमने अपनी लड़ाई छोटी तलवारों से लड़ी, और युद्ध के मैदान से और दूर तक चले गए। और यह दोनों तरह से कठिन था।" - एक्सरेक्स I, फारस के सम्राट, 473 ईसा पूर्व

— बॉब मर्फी

Answer 13

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

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

एक ठोस उदाहरण के लिए: मैं व्यापार के द्वारा एक .NET डेवलपर हूं। मुझे उम्मीद है कि एक सक्षम .NET डेवलपर को LINQ, Entity Framework, WPF, MVC और जैसी चीजों के बारे में पता होना चाहिए ; उन्हें इसका उपयोग करने की आवश्यकता नहीं है, या इसे कार्यस्थल पर धकेलना है, लेकिन कम से कम "यह मौजूद है" की एक गुजर समझ पूर्ण अकड़न से बेहतर है जिसे मैं बहुत बार देखता हूं।

Answer 14

मैं अब केवल 4 साल के लिए काम कर रहा हूं और यह लगभग पूरी तरह से सी # हो गया है। मैंने C ++ तब सीखा जब मैं College और Uni में था लेकिन अब मैं इसके साथ ज्यादा कुछ नहीं कर पाऊंगा।

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

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

Answer 15

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

इसका तात्पर्य यह है कि यदि आप चौड़ाई पर विचार करते हैं तो वास्तव में क्षमता का स्तर बढ़ गया है। यह कलाकार कार्यक्रम का अर्थ यह भी कर सकते हैं कि कलात्मक कौशल के साथ अब अधिक प्रोग्रामर हैं।

Comments

क्षमता से मेरा मतलब था कि प्रोग्रामिंग, गणित को छोड़कर अन्य सभी कौशल अप्रासंगिक हैं।

— स्कीथ

@ स्किथ - "सक्षमता से मेरा मतलब था कि प्रोग्रामिंग, गणित को छोड़कर अन्य सभी कौशल अप्रासंगिक हैं" - यह बहुत गलत है। पिछले 30 वर्षों में उद्योग में सबसे बड़ा सुधार यह है कि संचार कौशल को अब पूरी तरह से महत्वपूर्ण माना जाता है। मुझे महान गणित कौशल या महान संचार कौशल के साथ एक मूल रूप से सक्षम प्रोग्रामर दें और यह हर बार संचार कौशल के साथ लड़का है।

— जॉन हॉपकिंस

+1 @Jon - पूरी तरह से सहमत हैं। प्रोग्रामर जो ग्राहकों से कुछ भी नहीं बोलते हैं, लेकिन लैम्ब्डा कैलकुलस और एलापेप्ट सूप सूप के बहुमत पर बेकार हैं।

— मॉर्गन हेरलॉकर

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

— मार्टिन विलकंस

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

— क्रिस्टोफर महान

Answer 16

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

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

आवश्यकता से अधिक व्यंग्य के लिए खेद है, लेकिन मुझे लगता है कि यह लेख I से बेहतर कहता है।

क्या मै गलत हु?

UPD: मुख्य और महत्वपूर्ण बात बुनियादी बातों का ज्ञान है, जैसे कि एल्गोरिदम, डेटा संरचनाएं आदि। यदि आप आज गलती से हटा दिए जाएंगे तो आप में से कितने पुस्तकालयों / मानक कार्यों / आदि को लागू कर सकते हैं? आईएमओ, प्रोग्रामर को विकसित / अच्छी तरह से डिबग किए गए 'एलियन' कोड (लाइब्रेरी / फ्रेमवर्क / आदि) का उपयोग करना चाहिए, लेकिन पहिया को सुदृढ़ करने में सक्षम होना चाहिए, हमेशा!

Comments

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

— जॉन हॉपकिंस

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

— पीटर टेलर

मनुष्य के पास यह सीखने की आवश्यकता नहीं है कि अब तक खोजे गए सभी पहियों को कैसे सुदृढ़ किया जाए, और न ही अभी आविष्कार किए जा रहे पहियों को सुदृढ़ करना सीखना है ।

— मैके

@Dehumanizer: मुझे उम्मीद है कि प्रशिक्षित किया जाएगा और दुनिया को बचाने के लिए मेरे हाथों में एक सी संकलक से अधिक होगा, अन्यथा मुझे किसी भी तरह से खराब कर दिया जाएगा। (BTW क्यों भी एक सी संकलक? क्यों न सिर्फ एक यूएसबी-स्टिक, एक आस्टसीलस्कप और एक 9V वोल्टेज। गंभीरता से ....)

— मैके जूल

बस अपने कंपाइलरों को बंद कर दें और आप देखेंगे कि ज्यादातर लोग बस आसपास ही बैठेंगे जबकि REAL प्रोग्रामर मशीन कोड को सीधे फाइल में टाइप करते हैं!

— फिलिप

Answer 17

वीबी का उपयोग करने में आसान होने के कारण, और आलसी प्रोग्रामर इसकी वजह से वीबी उठाते हैं:

मुझे लगता है कि VB उपयोग में आसान होने के एक बड़े मिथक से घिरा हुआ है। यह मिथक मूल रूप से कुछ हद तक सही था: 1991-1994 के आसपास के दिनों में जब डायनासोर पृथ्वी पर चले गए थे, वीबी और डेल्फी के आसपास केवल दो असली रेड उपकरण थे। वे काफी समान थे, लेकिन इस पर ध्यान दें: डेल्फी और वीबी समान रूप से उपयोग करने में आसान थे! उनके बीच एकमात्र उल्लेखनीय अंतर यह था कि वीबी पूरी तरह से अतार्किक सिंटैक्स था और अविश्वसनीय रूप से सुस्त कार्यक्रमों का उत्पादन करता था।

C / C ++ GUIs को MFC में या कच्चे विन एपीआई में लिखा गया था। इसलिए VB Microsoft विकल्प की तुलना में उपयोग करना आसान था। तब अफवाह मिल गई:

• VB Microsoft C / C ++ / Win API की तुलना में उपयोग करना आसान है। ->
• वीबी का उपयोग करना आसान है। ->
• VB का उपयोग करना आसान है। ->
• VB सबसे आसान है।

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

फिर 90 के दशक के अंत में बोरलैंड ने डेल्फी: सी ++ बिल्डर के बराबर एक सी ++ जारी किया। अब 3 समान रूप से आसान उपकरण थे। इस समय के आसपास, वीबी का उपयोग करने के लिए कुछ शेष तर्कसंगत तर्क मर गए। फिर भी मिथक अभी भी जीवित था। "वीबी सबसे आसान है"।

तब जावा साथ आया और इसके साथ ही इसके लिए कई राड टूल भी थे (और इसके माइक्रोसॉफ्ट फियास्को संस्करण के लिए जे ++)। फिर भी VB मिथक पर रहा।

तब Microsoft ने C ++ के लिए भी RAD का समर्थन किया, और C # के साथ भी आया, इसे .NET नामक एक बड़े goo में पकाना। चूंकि VB मिथक अभी भी जीवित था, वे CB या C # के बजाय VB.NET का उपयोग करने के लिए पुराने VB डेवलपर्स को धोखा देने में सक्षम थे। हालांकि VB.NET पहले VB संस्करणों के साथ काफी गैर-संगत था।

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

Comments

धन्यवाद अब मैं एक कारण जोड़कर VB की मेरी घृणा में अधिक न्यायसंगत लग सकता हूँ

— स्कीथ

Answer 18

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

Answer 19

इसका एक पक्ष यह है कि मुझे लगता है कि अन्य सभी उत्तर केवल इस बात पर गौर कर रहे हैं कि यह केवल सामान्यीकृत प्रवृत्ति है जो निम्न-स्तरीय भाषाओं से उच्च-स्तरीय भाषाओं में जा रही है।

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

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

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

इसके अलावा,

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

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

Answer 20

मुझे लगता है कि जिस तरह से आप प्रोग्रामर को भुगतान करने के लिए भुगतान करते हैं, उससे कहीं खो गए हैं।

हमारा डिलीवरेबल कोड नहीं है, यह काम करने वाला सॉफ्टवेयर है।

हम ऐसे फर्नीचर का निर्माण नहीं कर रहे हैं जहां हाथ से कटे हुए डवेट्स किसी भी तरह से अतिरिक्त मूल्य प्रदान करते हैं क्योंकि सभी मैनुअल "शिल्प कौशल" जो इसमें गए थे।

हम कंप्यूटर पर व्यावसायिक समस्याओं को हल करने के लिए भुगतान करते हैं)। यदि आप कम पैसे में कम समय में एक ही उत्पाद वितरित कर सकते हैं, तो मुझे लगता है कि यह ढोंग छोड़ना हमारा उद्देश्य है कि C ++ प्रोग्राम केवल इसलिए बेहतर हैं क्योंकि वे निर्माण के लिए अधिक जटिल हैं।

Comments

* यह फूला हुआ सॉफ्टवेयर है, (कभी

— -

Answer 21

(मुख्य कार्यक्रम डेवलपर्स / डेवलपर गणना) का अनुपात कम हो रहा है क्योंकि:

• उपकरण आसान हो रहे हैं, इसका मतलब है कि समान समस्या के लिए छोटी प्रतिभा की आवश्यकता है

• लोग आईटी प्रौद्योगिकियों के लिए उपयोग हो रहे हैं, यह अनुकूलित उपकरणों के लिए पैसा खर्च करने के लिए अधिक इच्छुक है

• कंप्यूटर विज्ञान साहित्य तेजी से बढ़ रहा है, विशेषज्ञता और श्रम का विभाजन बढ़ रहा है, इसलिए कोई "अरस्तू" लोग नहीं हैं जो हर चीज के बारे में बात करते हैं (वास्तव में अमूर्त परतों के कारण उन्हें सब कुछ जानने की जरूरत नहीं है)

• अधिक नौकरियों की पेशकश, फिल्टर ढीला है

• जीवन के प्रत्येक चक्र में अधिक स्वचालन की आवश्यकता होती है, मांग बढ़ रही है और आपूर्ति पर्याप्त नहीं है

• जनसंख्या का डेवलपर अनुपात बढ़ रहा है।

  इसलिए लोग आलसी और कम सक्षम नहीं हो रहे हैं, औसत गिरता है क्योंकि कंप्यूटिंग अब एक अधिक खुला क्षेत्र है।

Answer 22

बहुत सारे उत्तर कहते हैं कि पहिया का आविष्कार क्यों करें और मैं इससे सहमत हूं लेकिन जब व्हील उपलब्ध हैं तो लोग यह जानने के लिए परेशान नहीं हैं कि पहिया कैसे बनाया जाए।

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

Answer 23

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

मुझे लगता है कि एंट्री लेवल डेवलपर्स के लिए एक और अच्छा व्यायाम यह है कि उन्हें विंडोज एपीआई का उपयोग करके कुछ एप्लिकेशन लिखें। फिर, जब वे इसे खत्म कर लेते हैं, तो वे इसे ऑब्जेक्ट ओरिएंटेड बनाते हैं, जहां हर फॉर्म आपके जेनेरिक विंडो क्लास से विरासत में मिलता है। क्या उन्होंने इवेंट लूप को एनकैप्सुलेट किया है और कुछ फंक्शन पॉइंटर्स को अपने फॉर्म क्लास में वापस शूट किया है। फिर अच्छी नौकरी कहो, Microsoft ने आपके लिए पहले से ही ऐसा किया है, इसका नाम System.Windows.Forms है। मज़े करो।

यदि वे वेब डेवलपर होने के लिए हैं, तो उन्हें कुछ CGI प्रोग्राम लिखें, ताकि वे POST, GET आदि को समझें ... और फिर पेज को स्क्रिप्ट करना। यह ASP.NET और PHP बहुत अधिक समझ में आता है।

यदि वे किसी नेटवर्क पर कुछ निचले स्तर पर काम कर रहे हैं, तो उन्हें उन पुस्तकालयों में पेश करने से पहले कुछ ऐप लिखें, जो उन्हें पुस्तकालयों में पेश करने से पहले कर चुके हैं।

मैंने पाया है कि यह लंबे समय में उत्पादकता में सुधार करता है क्योंकि यह उन्हें अपनी समस्याओं को हल करने के लिए उपकरण और सही अंतर्ज्ञान देता है।

विश्वविद्यालय ऐसा करने वाले हैं, लेकिन वे हमारे पास नहीं हैं।

उस ने कहा, मैं मानता हूं कि प्रोग्रामर ढूंढना कठिन और कठिन होता जा रहा है, जो कॉलेज से निकलने वाले लानत के लायक हैं, मुख्य रूप से क्योंकि वे पुनरावर्ती एल्गोरिदम और लिंक की गई सूचियों को लिखने के लिए मजबूर होने के कारण बाहर नहीं थे। इसके अलावा, उनके पास आमतौर पर केवल जावा या .NET पाठ्यक्रम होते हैं और इसलिए उनके काम करने के तरीके के बारे में बहुत ज्यादा समझ नहीं है। फिर भी, ठीक से उपयोग किए जाने पर अमूर्त काफी उपयोगी है।

Answer 24

(..) अभी या बाद में ऐसी कोई चीज नहीं होगी जिसे हम अब प्रोग्रामिंग कहते हैं

मैं इस बात से असहमत हूं।
चेतना क्या है, यह जाने बिना प्रोग्रामर की नौकरी सुरक्षित है।

इस समय "सोच मशीनें" इस तरह दिखती हैं:

-बदलता विषय बदल रहा है!
-मुझे लगा कि हमारा प्यार खास था।
-बदलता विषय बदल रहा है!
-मैं विषय नहीं बदल रहा हूं।
-तुम हो! मैं आपकी असमर्थता के बारे में बात करने की कोशिश कर रहा हूं कि हम क्या बात कर रहे हैं।
-नहीं तो पास भी नहीं। मेरा पसंदीदा हरा गीत ब्रह्मांड के पार है। आपका क्या है?

मेरा मानना ​​है कि केवल वे प्रोग्रामर जिन्हें यह बात समझ में नहीं आती है वे दयालु हैं।

उदाहरण के लिए Dehumanizer`s जवाब:

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

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

उपकरण स्वयं समस्याओं को ठीक नहीं करते हैं, वे सिर्फ (कभी-कभी) प्रोग्रामर को अधिक कुशल बनाते हैं।

यह इस तरह है: "बंदूकें नहीं मारते, इंसान करते हैं"।

Comments

अगर मैं गलत नहीं हूँ, तो क्लेवरबॉट सिर्फ वही नहीं दोहराते जो लोग पहले ही कह चुके हैं?

— एंड्रयू अर्नोल्ड

Answer 25

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

Answer 26

क्या आप आलसी हैं उपकरणों पर अत्यधिक निर्भरता?

सामान्यतया, 'नहीं'; लेकिन वहाँ एक बड़ी चेतावनी है।

मैंने uni में C ++ में प्रोग्रामिंग शुरू की और उसे पसंद किया। अगले कार्यकाल में हम VB6 में बदल गए और मुझे इससे नफरत थी।

मैं यह नहीं बता सकता था कि क्या चल रहा है, आप एक बटन को एक फॉर्म में खींचें और विचारक आपके लिए कोड लिखता है।

हाँ सचमुच। यूनी में आपका अनुभव मेरे द्वारा उल्लेखित बहुत चेतावनी के लिए बोलता है।

यदि आपको नहीं पता कि आपका उपकरण किस समस्या का समाधान कर रहा है, या जब आप अपने उपकरण की अपनी समस्याएँ हैं, तो आप समस्याओं का निवारण करने में असमर्थ हैं, तो यह एक बड़ा लाल झंडा है। यह परिस्थिति आवश्यक रूप से आलस्य का मतलब नहीं है, लेकिन यह संभवतः अनुभवहीनता का अर्थ है।

Answer 27

मुझे लगता है कि प्रोग्रामर के 2 फ्लेवर हैं। ऐसे प्रोग्रामर हैं जो सिर्फ एक समय सीमा या शायद अधिक उत्पादक होने के कारण काम पाने के लिए प्रोग्राम करते हैं। मैं कहूंगा कि वे आलसी थे। मेरा बस मानना ​​है कि उन्हें "कैसे" में कोई दिलचस्पी नहीं है कि एक कंप्यूटर वह क्या करता है या "कैसे" एक कार्यक्रम करता है जो वह करता है।

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

Comments

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

— संभावना

Answer 28

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

यह काफी संभव है कि नॉन-ड्रैग-एंड-ड्रॉप प्रोग्रामिंग की मांग कम हो जाए और हम कुछ और दिलचस्प नौकरियों को देखेंगे।