जावा की तुलना में C # में अधिक विशेषताएं क्यों हैं? [बन्द है]

Question

_{कृपया ध्यान दें कि इसका मतलब जावा बनाम C # तर्क नहीं है। मैं एक जावा प्रोग्रामर हूं जिसमें कोई C # अनुभव नहीं है, सिर्फ जिज्ञासा से बाहर निकलकर।}

मैंने C # पर कुछ रीडिंग की, और ऐसा लगता है कि इसमें जावा की तुलना में बहुत अधिक विशेषताएं हैं। कई उदाहरण:

• प्रकार का अनुमान।
• dynamic कीवर्ड।
• प्रतिनिधि।
• वैकल्पिक पैरामीटर।
• लैम्ब्डा और LINQ (मुझे वास्तव में पता नहीं है कि ये क्या हैं)।
• गुण।

हालाँकि Java में वास्तव में ऐसी कोई भी सुविधा नहीं है जो C # के पास नहीं है।

मेरा सवाल है: जावा की तुलना में C # में बहुत अधिक देशी विशेषताएं क्यों हैं? और जावा ने इन वर्षों में इनमें से कुछ को क्यों नहीं जोड़ा, उदाहरण के लिए गुण या प्रकार का अनुमान? क्या जावा भाषा के डिजाइनर अधिक सरल दृष्टिकोण अपनाते हैं? इसका क्या कारण है?

Comments

@ पैट्रिक - क्या यह एक विशेषता है - या कार्यान्वयन विस्तार?

— पीट

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

— फुस्स

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

— किलन फ़ॉथ

@ क्लॉकवर्क-म्यूजियम लेकिन सी # में दो रनटाइम कार्यान्वयन हैं - सीएलआर और मोनो। इसके अलावा Xamarin है। मैंने जावा का उपयोग करके क्रॉस आईओएस / एंड्रॉइड / विनफोन परियोजनाओं के निर्माण के लिए एक भी समाधान नहीं सुना है।

— Den

@KilianFoth: वास्तव में, C # शुरू में डेल्फी का एक बैट-रिप-ऑफ था, जिसे जावा की तरह देखा गया था। Microsoft ने इसे बनाने के लिए Borland से डेल्फी प्रोजेक्ट आर्किटेक्ट को भी हटा दिया।

— मेसन व्हीलर

Answer 1

कई कारण:

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

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

Comments

मुझे यकीन नहीं है कि मैं इससे सहमत हूं। मेरा मतलब है कि यह सब सच है, लेकिन मुझे संदेह है कि इसका कारण सूर्य के ढहने के आसपास की राजनीति से अधिक है। जावा के मूल रूप से 5+ वर्ष थे या इसलिए जहां कोई संगठन / नेतृत्व नहीं था - इसलिए कोई नई सुविधाएँ नहीं थीं।

— तेलस्तीन

C # 1 का मूल्य प्रकार था। कुछ ऐसा जो जावा के पास कभी नहीं होगा। तो सिर्फ एक "कठोर चीर-फाड़" नहीं।

— डेन

@Telastyn - मुझे लगता है कि यहाँ एक सबसे महत्वपूर्ण कारण है। विशेष रूप से जब आप जोड़ते हैं "और फिर आप ओर्ल द्वारा प्राप्त होते हैं" सूर्य पतन के अंत तक।

— व्याट बार्नेट

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

— डेविड किर्कलैंड

@WesleyWiser - "भविष्य में हो सकता है" में अपग्रेड किया गया।

— डेन

Answer 2

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

विस्तार विधियों और आंशिक वर्गों की तरह कुछ जोड़ने से विकास / नियंत्रण संस्करण में एक बुरा सपना हो सकता है अगर आईडीई इसे ठीक से समर्थन नहीं करेगा।

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

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

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

Comments

एक साधारण संपत्ति परिभाषा (घोषणा + प्राप्त / सेट + श्वेत स्थान) के लिए आवश्यक नौ लाइनें "कुछ" से अधिक तेजी से जुड़ती हैं।

— केविन क्लाइन

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

— SJuan76

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

— केविन क्लाइन

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

— Aviv Cohn

@AvivCohn बात यह है, "अंतर्निहित" प्रमुख भाग है। आप विधानसभा में गतिशील प्रेषण हो सकता है, आप सी में उच्च आदेश कार्यों हो सकता है, आप कर सकते हैं हर एक भाषा की सुविधा है , के बाद से कुछ बिंदु पर, यह अभी भी अपने x86 CPU पर चलता है जाहिर है - संभव विधानसभा में। आपको शायद ही कभी C # में कमांड पैटर्न को लागू करने की आवश्यकता है, क्योंकि आपके पास प्रतिनिधि हैं। ऑब्जर्वर और घटनाओं, और कई अन्य लोगों के साथ भी ऐसा ही है। जावा में कुछ समय के लिए अनाम विधियाँ थीं, लेकिन आपको एक पूर्ण अनाम प्रकार बनाना था । वे सभी चीजें छोटी हैं, लेकिन वे जोड़ते हैं।

— लुआँ