क्या एल्गोरिथ्म प्रोग्रामिंग भाषा की तुलना में अधिक महत्वपूर्ण है?

Question

वर्तमान (2013) Google कोड जाम प्रतियोगिता के दौरान, पायथन लोगों की तुलना में C ++ और Java लोगों को कोड की 200+ लाइनें लेने वाली एक समस्या थी, जिसने कोड की केवल 40 लाइनों का उपयोग करके उसी समस्या को हल किया।

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

भाषा की पसंद की तुलना में सही एल्गोरिदम को जानना कितना महत्वपूर्ण है? एक उत्कृष्ट रूप से लागू किया गया पायथन प्रोग्राम C ++ या जावा में बेहतर तरीके से (समान एल्गोरिथ्म का उपयोग करके) लागू किया जा सकता है और क्या इससे कुछ प्रोग्रामिंग भाषाओं की स्वाभाविक क्रियाशीलता का कोई संबंध है?

Comments

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

— जोरिस टिम्मरमंस

यह बहुत कुछ पूरी तरह से उस पैमाने पर निर्भर करता है जो आप LOC से परे काम कर रहे हैं। कुछ भाषाएं केवल गति या संगामिति की जरूरत का समर्थन नहीं करती हैं। एल्गोरिदम महत्वपूर्ण हैं, लेकिन कभी-कभी अगर भाषा x, y की तुलना में भाषा z की तुलना में धीमी है, तो आप केवल वर्बोसिटी की परवाह किए बिना x का उपयोग नहीं कर सकते हैं।

— रिग

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

— ट्रैविस पेसेट्टो

@ ट्राविस: "प्रति SLOC दर का दोष भाषा की परवाह किए बिना स्थिर रहता है" हालांकि यह सच नहीं है। देखिये जॉन का जवाब

— बेन वोइग्ट

अब आप मुझे F # भाषा के रूप में अगली प्रतियोगिता में प्रवेश करने के बारे में सोच रहे हैं!

— कोड

Answer 1

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

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

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

एक शिल्पकार के दृष्टिकोण से, हम हमेशा नौकरी के लिए सही उपकरण के साथ संपर्क करने की कोशिश करते हैं, लेकिन सही शब्द इतना मुश्किल है कि कोई भी इसे आसानी से गलत कर सकता है।

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

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

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

Comments

+ 1 "लाख अन्य कारकों पर विचार किया जाए" के लिए

— ozz

मैं यह जोड़ूंगा कि यदि यह एक कार्यात्मक समस्या है जिसे आप हल करने की कोशिश कर रहे हैं, तो आकाश के लिए, कृपया एक कार्यात्मक भाषा का उपयोग करें! इसलिए मेरा तर्क है कि आपको वास्तव में प्रमुख प्रोग्रामिंग प्रतिमान के लिए एक भाषा छड़ी चाहिए।

— मार्टिग्न वर्बर्ग

अंतिम वाक्य के लिए +1।

— शिवन ड्रैगन

+1 कोड की लाइनें अपने आप में एक भयानक मीट्रिक है। हमें स्थिरता बनाए रखने की जरूरत है , न कि कोड की लाइनें। टाइप-सेफ कोड की 200 लाइनें संभावित रूप से पायथन की 50 लाइनों की तुलना में बहुत अधिक बनाए रखने योग्य हो सकती हैं।

— फिल

@Phil: और पायथन की 200 लाइनें संभावित रूप से टाइप-सेफ कोड की 50 लाइनों की तुलना में बहुत अधिक बनाए रखने योग्य हो सकती हैं। मैंने अच्छी तरह से लिखित कोड मानते हुए, टाइप-सेफ भाषाओं में इतना स्पष्टता लाभ नहीं देखा है।

— डेविड थॉर्नले

Answer 2

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

बेशक, आप जिस भाषा में भी काम करना चाहते हैं उसे जानना चाहते हैं, लेकिन भाषाएँ आती हैं और जाती हैं, जबकि एल्गोरिदम के संदर्भ में सोचने की क्षमता एक अत्यधिक हस्तांतरणीय कौशल है।

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

मैं मानता हूं कि उदाहरण सरल हैं, लेकिन वे बिंदु को पार लाने में मदद करते हैं।

Answer 3

भाषा मायने रखती है।

DARPA और US नेवी ने लगभग 20 साल पहले शूटआउट प्रयोग किया था। डार्क हॉर्स भगोड़ा विजेता हास्केल था। Ada और C ++ दोनों का प्रतिनिधित्व किया गया; जावा नहीं था।

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

अटारी ने वीडियोगेम्स को विकसित करने के लिए FORTH का उपयोग किया, और यह तथ्य कि वे FORTH का उपयोग कर रहे थे, अत्यंत स्वामित्व माना जाता था।

एलआईएसपी का उपयोग करने पर पॉल ग्राहम की टिप्पणियां प्रसिद्ध हैं। JPL में LISP पर Erann Gat की टिप्पणियां समान रूप से धूर्त हैं, हालांकि अच्छी तरह से ज्ञात नहीं हैं।

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

भाषा मायने रखती है।

Comments

जाहिर है, जावा को उस प्रयोग के बाद जारी किया गया था जिसे आप लिंक कर रहे हैं।

— toasted_flakes

लेख 1994 में जारी किया गया था। जावा की पहली सार्वजनिक रिलीज़ 1995 में हुई थी।

— एलेसेंड्रो टेरुज़ि

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

— जॉन आर। स्ट्रोम

Answer 4

कुछ बिंदु:

• शीर्ष स्थिति C ++ / C / Java हो सकती है, भले ही कोड की कितनी पंक्तियाँ हो और उसके बीच कोई और भाषा हो। यह इस बारे में अधिक हो सकता है कि शीर्ष कोडर इन भाषाओं को कुछ अन्य लोगों पर लेने की प्रवृत्ति रखते हैं, शायद उनकी कच्ची गति के कारण।
  दुर्भाग्य से आप आसानी से Google कोड जाम पर प्रोग्रामिंग भाषा नहीं देख सकते हैं, लेकिन मैंने कुछ शीर्ष डाउनलोड किए हैं और जहां तक ​​मुझे याद है, ये ज्यादातर C / C ++ हैं। TopCoder (एक लोकप्रिय ऑनलाइन प्रोग्रामिंग प्रतियोगिता होस्टिंग साइट) के ज्यादातर परिणाम समान हैं।

• क्योंकि वे काफी निचले स्तर के हैं, मुझे पूरा यकीन है कि आप कच्चे चलने के समय के मामले में C / C ++ को आसानी से नहीं हरा पाएंगे (और जावा बहुत पीछे नहीं है)। मेरे अनुभव से, गतिशील रूप से टाइप की जाने वाली भाषाएँ सांख्यिकीय रूप से टाइप की जाने वाली भाषाओं की तुलना में काफी धीमी होती हैं। इष्टतम समाधान कुछ भाषाओं में पर्याप्त तेज़ नहीं हो सकता है, लेकिन यह एक सामान्य नियम नहीं होना चाहिए।

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

• लाइनों की सीधी संख्या इतनी बड़ी बात नहीं है। एक बार जब आप पर्याप्त प्रोग्रामिंग अनुभव प्राप्त करते हैं, तो आपको पता चल जाएगा कि आप 10 मिनट की प्रोग्रामिंग 10 लाइनें या 200 लाइनें खर्च कर सकते हैं, यह सब निर्भर करता है कि लाइनें कितनी जटिल हैं। साथ ही, यदि आपने सैकड़ों बार इसी तरह का कोड बनाया है, तो आप बहुत जल्दी ऐसा कर पाएंगे। सभी मैक्रो का उल्लेख नहीं है जो कि शीर्ष C / C ++ कोडर्स अक्सर अपने कोडिंग समय का अनुकूलन करने के लिए उपयोग करते हैं।

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

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

Comments

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

— रेयान

@LieRyan ट्रू, लेकिन कुछ दर्जन प्रोग्रामिंग प्रतियोगिताओं (जैसा कि मेरे पास है) में भाग लेना (यकीनन) सबसे लोकप्रिय ऐसी साइट (TopCoder) है और हमेशा C / C ++ / Java के रूप में शीर्ष पदों के बहुमत को देखना महत्वपूर्ण है। इसके अलावा, मैंने कहा कि "" नहीं "करने के लिए हमेशा" कर रहे हैं।

— डुकलिंग

असहमत हैं कि "लाइनों की सीधी संख्या इतनी बड़ी बात नहीं है।" कोड दुश्मन है

— jk।

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

— डुकलिंग

Answer 5

क्या वही तर्क C ++ में बेहतर तरीके से लागू किए जा सकते हैं? बेशक, अगर आप बेहतर तरीके से तेज और अधिक मेमोरी कुशल हो सकते हैं। समस्या यह है कि ऐसा करने के लिए आवश्यक प्रयास की मात्रा काफी अधिक है। इसके अलावा, सैद्धांतिक रूप से आप अभी भी निचले स्तर पर जा सकते हैं और इसे शुद्ध सी या यहां तक ​​कि एएसएम में भी लागू कर सकते हैं, जिसमें अधिक समय लगेगा, लेकिन आपके पास और भी अधिक अनुकूलित कोड हो सकते हैं।

बेशक, कोड जाम या TopCoder जैसी प्रतियोगिताओं के मामले में यह एक बड़ी बात नहीं है, क्योंकि यह सिर्फ 40 लाइनों बनाम 200 लाइनों का है। दूसरी ओर इस प्रकार की प्रतियोगिता में एल्गोरिथ्म का समय / स्थान जटिलता सबसे अधिक मायने रखती है। वास्तविक जीवन में आवेदन करते समय, YMMV, इन प्रकार की प्रतियोगिताओं में O (n) भाषाओं में सबसे धीमी गति से लिखी गई एल्गोरिथ्म हमेशा सबसे तेज भाषाओं में लिखी O (n²) को हराएगी । विशेष रूप से कि कई परीक्षाएं होंगी जो सबसे खराब स्थिति हैं।

लेकिन प्रतियोगिताओं के अलावा, अगर हम वास्तविक जीवन की बड़ी परियोजनाओं की बात कर रहे हैं, तो यह अब 40 लाइनों बनाम 200 लाइनों की नहीं है। बड़ी परियोजनाओं में यह एक बड़ा कोड आधार एक समस्या होने लगती है। आप किस बिंदु पर आते हैं:

सी ++ बनाम पायथन?

प्योर पायथन धीमा है। यही कारण है कि मानक पायथन इंटरप्रेटर (CPython) को C. में लिखा जाता है। व्यावहारिक रूप से बिल्ट-इन फ़ंक्शन के साथ सभी को अत्यधिक अनुकूलित C. Python के रूप में लिखा जाता है। C पुस्तकालयों के साथ संयोजन के रूप में ( ctypes के रूप में या देशी फ़िफ़थॉन मॉड्यूल के साथ) और C ++ पुस्तकालयों के साथ आसानी से उपयोग किया जा सकता है। बूस्ट के माध्यम से :: पायथन । इस तरह से आप पायथन में अपने उच्च स्तरीय तर्क को लिख सकते हैं, एक ऐसी भाषा जो लचीली है, त्वरित प्रोटोटाइप और अनुकूलन की अनुमति देता है (जिसका अर्थ है कि आप अपना एल्गोरिथ्म ट्विक करने और सुधारने में अधिक समय व्यतीत कर सकते हैं)। OTOH, आप अपने निचले स्तर के पुस्तकालय कार्यों को C या C ++ मॉड्यूल में लिख सकते हैं। इस तरह के दृष्टिकोण का महान उदाहरण SciPy है, जो कि पायथन लाइब्रेरी है, फिर भी हुड के तहत यह अति अनुकूलित न्यूमेरिक लाइब्रेरी जैसे ATLAS, LAPACK, Intels MKL या AMD के ACML का उपयोग करता है।

Comments

आप जो लिख रहे हैं वह केवल सतह को खुरच रहा है। आप 'बेहतर ’की धारणा मान रहे हैं जो हर कोई साझा नहीं करता है। गुणवत्ता हमेशा किसी के लक्ष्यों के अनुकूल होने की बात है। C ++ में प्रोग्रामिंग हमेशा हर लक्ष्य के लिए एक अच्छा फिट नहीं है।

— रीइनियरियरपोस्ट

@reinierpost: इसीलिए मैंने काफी उच्च प्रयास के बारे में लिखा। जिन मामलों में आप C ++ का उल्लेख करते हैं, वे अच्छे नहीं हैं, लेकिन ऐसा नहीं है क्योंकि ऐसा नहीं किया जा सकता है। यह अच्छा नहीं है, क्योंकि यह बहुत अधिक डेवलपर संसाधन लेगा।

— vartec

क्या अधिक है, यह उस मामले में बेहतर नहीं है।

— रीइनियरियरपोस्ट

और वास्तव में यह बहुत सारे उद्योगों में होता है, उदाहरण के लिए खेल में बहुत सारे लुआ कोड होते हैं जो प्रदर्शन और उत्पादकता दोनों के लिए C ++ कोड को एक साथ जोड़ते हैं।

— gbjbaanb

Answer 6

मेरी राय में, जो लोग बोलचाल की भाषा में "प्रोग्रामिंग भाषाओं" पर विचार करते हैं, वे वास्तव में तीन अलग-अलग चीजें हैं:

1. भाषा प्रकार और वाक्य रचना
2. भाषा आईडीई
3. किसी भाषा के लिए उपलब्ध पुस्तकालय

उदाहरण के लिए जब कोई चर्चा में C # लाता है तो आप सोच सकते हैं कि वह भाषा वाक्य रचना (1) के बारे में बात कर रहा है लेकिन यह 95% निश्चित है कि चर्चा में .Net फ्रेमवर्क (3) शामिल होगा। यदि आप एक नई भाषा नहीं डिज़ाइन कर रहे हैं, तो यह कठिन है और आमतौर पर अलग करने के लिए (1) और उपेक्षा (2) और (3)। ऐसा इसलिए है क्योंकि आईडीई और मानक पुस्तकालय "आराम कारक" हैं, चीजें जो एक निश्चित उपकरण का उपयोग करने के अनुभव को सीधे प्रभावित करती हैं।

पिछले कुछ वर्षों में मैंने भी Google Code Jam में भाग लिया था। पहली बार मैंने C ++ का विकल्प चुना क्योंकि इसमें इनपुट पढ़ने के लिए अच्छा समर्थन है। उदाहरण के लिए C ++ में एक मानक इनपुट से तीन पूर्णांक पढ़ना इस तरह दिखता है:

int n, h, w;
cin >> n >> h >> w;

जबकि C # में भी ऐसा ही लगेगा:

int n, h, w;
string[] tokens = Console.ReadLine().Split(' ');
n = int.Parse(tokens[0]);
h = int.Parse(tokens[1]);
w = int.Parse(tokens[2]);

यह एक साधारण कार्यक्षमता के लिए एक बहुत अधिक मानसिक उपरि है। मल्टीलाइन इनपुट के साथ C # में चीजें और भी जटिल हो जाती हैं। शायद मैं बस फिर एक बेहतर तरीका समझ नहीं आया है। वैसे भी, मैं पहले दौर को पारित करने में विफल रहा क्योंकि मेरे पास एक बग था जिसे मैं दौर के अंत से पहले ठीक नहीं कर सकता था। विडंबना यह है कि इनपुट रीडिंग विधि ने बग को बाधित कर दिया। समस्या सरल थी, इनपुट में एक संख्या थी जो 32 बिट पूर्णांक के लिए बहुत बड़ी थी। C # में int.Parse(string)एक अपवाद होगा, लेकिन C ++ में फ़ाइल इनपुट स्ट्रीम एक निश्चित त्रुटि ध्वज को सेट करेगा और किसी समस्या से अनजान डेवलपर को चुपचाप विफल बना देगा।

दोनों उदाहरण प्रदर्शित करते हैं कि कैसे लाइब्रेरी का उपयोग किया गया था फिर भाषा सिंटैक्स का। पहला वर्बोसिटी दर्शाता है और दूसरा विश्वसनीयता प्रदर्शित करता है। कई पुस्तकालयों को कई भाषाओं में पोर्ट किया जाता है और कुछ भाषाएं उन पुस्तकालयों का उपयोग कर सकती हैं जो विशेष रूप से उनके लिए नहीं बनाए गए हैं (देखें सी लाइब्रेरी के साथ पायथन के बारे में @ vartec का उत्तर)।

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

Comments

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

— मार्क हर्ड

दूसरी बार मैंने कुछ ऐसा ही किया लेकिन प्रोजेक्ट टेम्पलेट के रूप में। यह एक इनपुट क्लास के साथ एक स्रोत फ़ाइल बनाता है Mainऔर Mainविधि के अंदर कुछ चीजें (मेरे इनपुट क्लास का उदाहरण और आउटपुट स्ट्रीम और केस लूप)।

— सम्राट ओरियोनी

मुझे पिछली बार याद नहीं आ रहा है जब मैं स्टडिन से पढ़ा था मुझे एक फ़ाइल दें जिसे मैं JSON पार्सर में चिपका सकता हूं।

— gnasher729

Answer 7

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

Integer prev = b.get(k)
if (prev == null) prev = 0
Integer v = a.get(k);
if (v == null) v = 0;
b.put(prev + v);

के बजाय

b[k] += a[k]

कई पुस्तकालयों को सीखने के बारे में चिंता न करें। वे सभी बहुत समान हैं और प्रलेखन ऑनलाइन है। अधिक अभिव्यंजक भाषाओं में धाराप्रवाह बनना आपको कम अभिव्यंजक भाषाओं में बेहतर (लेकिन संभवतः निराश) प्रोग्रामर बना देगा। विपरीत सत्य नहीं है।

एनबी

कोड की 200 लाइनों और कोड की 40 लाइनों के बीच अंतर बहुत बड़ा है, और यह 200,000 लाइन प्रोग्राम और 40,000 लाइन प्रोग्राम के बीच अंतर होने पर भी बड़ा है। फिर यह फ़ाइव प्लस मैनेजर की टीम और एक या दो की टीम के बीच का अंतर है।

Comments

(ए) मैं एक तथ्य के लिए जानता हूं कि C / C ++ / Java प्रोग्रामिंग प्रतियोगिताओं में शीर्ष स्थान पर हैं। (b) C / C ++ को कई (निश्चित रूप से पर्ल / रूबी / पायथन से ऊपर) "सबसे शक्तिशाली भाषा" माना जाता है। (c) ऑपरेटर की ओवरलोडिंग के कारण, C ++ कोड आपके दूसरे उदाहरण के समान दिखाई दे सकता है। (d) ऐसी व्यापक जाँच (जावा में, यह है?) केवल आवश्यक है अगर: (1) आपको पता नहीं है कि आप क्या कर रहे हैं। (2) डेटा की प्रकृति ऐसी है कि यह आवश्यक है (कोडिंग प्रतियोगिताओं में नहीं होता है)। (3) आप अन्य लोगों द्वारा उपयोग किए जाने वाले कोड (लागू नहीं) लिख रहे हैं।

— डुकलिंग

@ डुकलिंग: इस अध्ययन के अनुसार ( page.mi.fu-berlin.de/prechelt/Biblio/jccpprtTR.pdf ) स्क्रिप्टिंग भाषाएं तेजी से विकास और छोटे स्रोत कोड की अनुमति देती हैं। एक अन्य अध्ययन ( flownet.com/gat/papers/lisp-java.pdf ) के अनुसार , लिस्प स्क्रिप्टिंग भाषाओं की तुलना में अधिक उत्पादकता प्रदान करता है। ऊपर उल्लिखित दूसरे अध्ययन के अनुसार, लिस्प कोड सी ++ कोड के रूप में लगभग उतना ही तेज हो जाता है, जबकि इसे लिखने में कम समय लगता है।

— जियोर्जियो

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

— जियोर्जियो

@ जिओर्जियो मैं विकास के समय या स्रोत कोड के आकार के बारे में बहस नहीं कर रहा हूं, विशुद्ध रूप से प्रोग्रामिंग प्रतियोगिताओं में वास्तव में महत्वपूर्ण अनुभव के आधार पर क्या होता है।

— डुकलिंग

मैं दो वैज्ञानिक पत्रों का हवाला दे रहा था (जो IMO देखने लायक हैं), मैं इस बारे में नहीं बोल रहा था कि वेब पेजों पर लोग इसके बारे में क्या सोचते हैं। तथ्य यह है कि एक राय व्यापक प्रसार है स्वचालित रूप से इसका मतलब यह नहीं है कि यह मान्य है। :-) कम से कम, किसी को इसे कड़े तरीके से सत्यापित करना होगा।

— जियोर्जियो

Answer 8

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

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

Answer 9

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

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

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

एक बहुत ही तुलनात्मक तुलना: मेरे पास 20k के अजगर ऐप के बजाय "ओवरकिल" सामानों से भरे टेस्ट सीक्स्ड डिकॉल्ड सी # कोड की 100k एलओसी होगी, बजाय इसके कि "सामान किया हुआ"। 5 गुना अधिक कोड या नहीं, आर्किटेक्चर हर दिन जीतता है।

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