2008-10-09 12 views
11

जहां तक ​​मुझे पता है (ज्यादा मैं स्वीकार नहीं करूंगा), वर्तमान में लोकप्रिय प्रोग्रामिंग प्रतिमान ऑब्जेक्ट ओरिएंटेड (जावा, सी #, रूबी) बनाम कार्यात्मक (एफ #) हैं। किसी ऐसे व्यक्ति के रूप में जो पहले प्रतिमान से परिचित है, मेरे पास कई प्रश्न हैं:कौन सी प्रोग्रामिंग भाषा प्रतिमान फिट बैठता है?

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

जाहिर है, कोई "सर्वश्रेष्ठ" भाषाएं नहीं हैं, लेकिन मैं सोच रहा हूं कि यह एक नया प्रतिमान सीखने के लिए समय और ऊर्जा के निवेश के लायक है या नहीं। अग्रिम में धन्यवाद!

+0

रूबी (और पायथन) दोनों ऑब्जेक्ट उन्मुख और गतिशील हैं। ऑब्जेक्ट उन्मुख बनाम प्रक्रियात्मक बनाम कार्यात्मक एक आयाम है (और यह बहस योग्य है)। गतिशील बनाम स्टेटिक एक और आयाम है। वेब बनाम डेस्कटॉप - उल्लेख नहीं किया गया। यह सवाल उलझन में है। –

+0

प्रतिमानों पर गड़बड़ी के बारे में खेद है, मैं अभी भी उनके बारे में सवाल पूछ रहा हूं। इसके अलावा, मेरे प्रश्न का कौन सा हिस्सा उलझन में था? – echoblaze

+0

@echoblaze: चूंकि प्रतिमानों को कोई समझ नहीं आया, इसलिए किसी और चीज को पार्स करने का प्रयास करने में कोई बात नहीं थी। यही कारण है कि मैंने विशेष रूप से प्रतिमान समस्या सूचीबद्ध की है। यह एक शो-स्टॉपर था। शायद आप शुरुआती अनुच्छेद को सरल बना सकते हैं। –

उत्तर

12

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

"क्या लोगों को कभी भी एक नया प्रतिमान जानने के लिए जरूरी है?" हमेशा।

वास्तव में "प्रतिमान बदलाव" के ऊपर और नीचे का पालन करने के लिए एक चाल है। मेरे करियर के पिछले 30 वर्षों में, मैंने देखा है कि प्रोग्रामिंग अपेक्षाकृत सरल अनिवार्य/प्रक्रियात्मक मॉडल से कई समृद्ध मॉडल तक बढ़ी है जिसमें प्रक्रिया और डेटा के बीच बेहतर संतुलन शामिल है।

मैं निम्नलिखित ध्यान दिया है ... प्रेरणा शक्ति के

भाग कृत्रिम बुद्धि समुदाय है। इनमें से कई "नए मॉडल" एआई ज्ञान प्रतिनिधित्व योजनाओं के रूप में शुरू हुए। उन्हें वहां कर्षण मिला, फिर वे अधिक मुख्यधारा के अनुप्रयोगों में उलझ गए।

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

मेरा निष्कर्ष यहां है।

सॉफ्टवेयर ज्ञान का प्रतिनिधित्व है।

प्रतिमान या मॉडल या दृष्टिकोण या शैली आपके मनपसंद निम्नलिखित सवाल का जवाब पर आधारित है: "मैं सबसे अच्छा कैसे प्रतिनिधित्व कर सकते हैं इस समस्या"

यदि समस्या में वस्तुओं और रिश्ते हैं, ओओ। यदि समस्या में एल्गोरिदम और परिवर्तन हैं, मानचित्र, फ़िल्टर और कम हो जाते हैं, कार्यात्मक। यदि समस्या गतिशील, बदलती और लचीला, गतिशील है। यदि समस्या स्थैतिक है और तेजी से बढ़ जाएगी, स्टेटिक।

+0

कुल अनुबंध, अच्छा सारांश। प्रोग्रामिंग भाषाओं के विकास का इतिहास भाषा में एम्बेडेड ज्ञान में वृद्धि से विशेषता है। –

2

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

9

वैकल्पिक प्रतिमान (ओओ, कार्यात्मक, प्रक्रियात्मक, गतिशील, आदि) सीखना उचित है क्योंकि यह आपको विभिन्न तरीकों से समस्याओं के बारे में सोचने में मदद करेगा।

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

पुरानी समस्याओं पर लागू होने के बारे में सोचने के नए तरीके कुछ कठिन मुद्दों को तोड़ने में मदद कर सकते हैं।

0

ओओपी के साथ डिजाइन और आर्किटेक्चरिंग कौशल का विकास करना एक महान भाषा अज्ञेय कैरियर के लिए सबसे वांछनीय कौशल है।

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

7

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

जितना संभव हो उतना प्रतिमान जानने के लायक है। कुछ समस्याएं एक प्रतिमान में हल करने के लिए तुच्छ होती हैं, और किसी अन्य में नाज़ुक क्राफ्टिंग की आवश्यकता होती है।

एक (तुच्छ) उदाहरण के रूप में, जावा और OCaml, या बेहतर अभी भी, हास्केल में quicksort कार्यान्वयन की तुलना इस पृष्ठ पर: http://www.rosettacode.org/rosettacode/w/index.php?title=Quicksort

(मतलब यह नहीं है कि कार्यात्मक बेहतर है बेहतर के साथ हल समस्या है। OO)।

+0

धन्यवाद, जो चीजों को थोड़ा स्पष्ट बनाता है! ओओ के साथ किस तरह की समस्या हल हो जाएगी? – echoblaze

5

क्या सभी समस्याओं को एक हथौड़ा के लिए नाखूनों में कम किया जा सकता है?

एर हाँ। आप केवल एक हथौड़ा के साथ समस्याओं को हल कर सकते हैं।यह सिर्फ यह देख रहा है कि आधा दरवाजा इसके साथ बहुत अधिक समय लेता है।

क्या लोगों को कभी भी एक नया प्रतिमान सीखने की आवश्यकता है? मेरी पिछली दो नौकरियों के लिए, मेरे कार्यस्थलों को जावा और सी # की आवश्यकता थी। क्या ऐसे कार्यस्थल हैं जो विशेष रूप से गैर-ओओ भाषाओं का उपयोग करते हैं?

डेवलपर्स को हर 15-20 साल या उससे भी ऐसा करना है।

निश्चित रूप से प्रक्रियात्मक वीबीए के साथ लिखित एक्सेस आधारित सिस्टम वाली छोटी कंपनियों का एक पूरा उद्योग है। (और मुझे लगता है कि मैंने उनमें से ज्यादातर के लिए काम किया है)। क्लासिक एएसपी डेवलपर्स को एएसपी.नेट सीखना है। पर्ल डेवलपर्स पायथन सीख रहे हैं। बैच संचालित विकास ने घटना संचालित विकास के लिए रास्ता दिया।

+1

एक हथौड़ा के साथ आधा दरवाजा यह न केवल लंबे समय तक ले जाएगा, बल्कि यह वास्तव में गंदे लग रहा है। :) –

+0

वीबीए डेवलपर्स को टाइपस्क्रिप्ट सीखना है ... –

1

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

डायनामिक/स्क्रिप्टिंग सिस्टम प्रशासकों और लिनक्स सिस्टम चलाने वाले किसी भी व्यक्ति के लिए जानना भी अच्छा है। बीएएसएच या रूबी में एक त्वरित स्क्रिप्ट लिखना जावा, या सी ++ में समान कार्यक्षमता को लागू करने की कोशिश करने से बाहर हो जाता है।

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

मुझे लगता है कि कार्यात्मक बहु-थ्रेडेड प्रोग्रामिंग के लिए अच्छा है क्योंकि सब कुछ अपरिवर्तनीय होता है।

0

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

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

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

  • यह कई डेस्कटॉप प्लेटफार्मों पर चलाने के लिए की आवश्यकता है ?
  • यदि यह डेस्कटॉप एप्लिकेशन है तो क्या इसे मूल रूप से देखने और महसूस करने की आवश्यकता है?
  • डिजाइन की तेज़ी से पुनरावृत्ति महत्वपूर्ण
  • इसे कैसे बनाए रखा जाए?
  • किस तीसरे पक्ष के सिस्टम के साथ काम करने की आवश्यकता है?
  • मौजूदा प्रोग्रामर ज्ञान/कौशल/प्राथमिकताएं।
संबंधित मुद्दे

 संबंधित मुद्दे