C # और Java के एक भाषा के आधे होने के बारे में इस कथन का क्या अर्थ है? [बन्द है]

Question

लेख में: POCO क्यों , यह वाक्य है:

Maciej Sobczak इसे अच्छी तरह से कहते हैं: "मुझे पसंद नहीं है जब कोई मुझे भाषा का आधा हिस्सा देता है और मुझे बताता है कि यह मेरी अपनी सुरक्षा के लिए है"।

मुझे समझ नहीं आ रहा है कि उसका क्या मतलब है, भले ही C # Microsoft के स्वामित्व में है और जावा ओरेकल के स्वामित्व में है , इसका मतलब यह नहीं है कि वे भाषा का आधा हिस्सा रखते हैं, क्या यह नहीं है? मुझे उस वाक्य को साबित करने के लिए कोई सबूत नहीं मिला, और मैं वास्तव में इस बारे में उत्सुक हूं। और 'अपनी सुरक्षा के लिए' के ​​बारे में और भी उत्सुक।

Comments

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

— 14

मुझे बिलकुल यकीन नहीं है, क्योंकि वह जिस लेख से उद्धृत कर रहा है वह मृत प्रतीत होता है, लेकिन ऐसा लगता है जैसे वह कह रहा है कि जावा और C # C ++ की अधिक 'खतरनाक' या विवादास्पद विशेषताओं को याद कर रहे हैं, जैसे एकाधिक वंशानुक्रम या टेम्पलेट मेटाप्रोजलिंग।

— GoatInTheMachine

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

— जैक्सबी

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

— मार्क रोजर्स

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

— थियोडोरोस चट्जीगनिनाकिस

Answer 1

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

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

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

Comments

यह मेरा गोटो जवाब है।

— नील

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

— नील

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

— रॉबर्ट हार्वे

@RobertHarvey I 100% सहमत हैं। C ++ प्रोग्रामर होने के नाते, मैं C # जाने पर स्वचालित मेमोरी प्रबंधन पर संदेह करता था। एक बार जब मैं उस अतीत से जुड़ गया, तो यह 99% समय के बारे में चिंता करने की ज़रूरत नहीं थी। इसने अन्य मुद्दों के बारे में सोचने के लिए मेरी दिमागी ताकत को मुक्त कर दिया।

— 17 की 26

"किसी भी प्रकार की बाधाओं के बिना किसी भी अन्य वस्तु को असाइन करें।" ... तो dynamic,?

— आर्टुरो टॉरेस

Answer 2

यह उद्धरण के मूल स्रोत में काफी बारीकी से समझाया गया है :

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

[...]

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

[...]

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

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

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

Comments

विडंबना यह है कि वह सी को ठीक उसी कारण से नापसंद करता है जिस कारण वह सी ++ पसंद करता है, यह बहुत खुला है, बहुत सारी शक्ति और बहुत सारी त्रुटियों की अनुमति देता है।

— ग्रेविसेज

वह C ++ को पाइथन की तुलना में अधिक अभिव्यंजक

— मानता है

@GreySage जिसने मेरी आंख भी पकड़ ली ... C बहुत त्रुटि प्रवण है लेकिन C # आपको पर्याप्त शक्ति नहीं देता है? C क्या वह C ++ से दूर है? C # में "असुरक्षित" कोने नहीं हैं जो आपको अधिक नियंत्रण देते हैं? दिलचस्प राय के लिए निश्चित मिश्रण ...

— WernerCD

@WernerCD वास्तव में असुरक्षित C # के बारे में नहीं बता सकती है, लेकिन C और C ++ में बहुत कुछ नहीं है, सिवाय इसके कि आप एक बुनियादी C90 स्निपेट को वैध C ++ - ish स्निपेट में हरा सकते हैं, जिस पर कंपाइलर चोक नहीं करेगा।

— क्वेंटिन

Answer 3

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

2006 में वापस, जब यह लिखा गया था, जब C # अपेक्षाकृत युवा था और जावा कई तरह से अपरिपक्व था, और जब पावर बनाम सुरक्षा एक व्यापार-बंद की तरह लग रहा था, जहां आप केवल एक ही उठा सकते थे, यह लेने के लिए पूरी तरह से अनुचित स्थिति नहीं थी ।

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

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

Comments

मैं अंतिम पैराग्राफ में आपकी स्थिति से सहमत हूं। सी ++ को "फाउंटेन ऑफ एक्सप्लॉइट्स" कहा जाना चाहिए।

— कालेब मौएर

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

— हैरिसन पाइन

Answer 4

अभिलेखागार को देखते हुए , ऐसा प्रतीत होता है कि यह उद्धरण 2003 से था (लेख का हवाला देते हुए यह 2006 से होने के बावजूद)। उस समय, C # संस्करण 1 में था। x , और इसकी आधुनिक विशेषताओं में बहुत कमी थी :

नए विशेषताएँ

सी # 2.0

• जेनेरिक्स
• आंशिक प्रकार
• अनाम तरीके
• iterators
• अशक्त प्रकार के
• गेटटर / सेटर की अलग पहुँच
• विधि समूह रूपांतरण (प्रतिनिधि)
• प्रतिनिधियों के लिए सह- और कंट्रा-विचरण
• स्थैतिक वर्ग
• प्रत्यायोजन करें

सी # 3.0

• अवैध रूप से टाइप किए गए स्थानीय चर
• ऑब्जेक्ट और संग्रह आरंभीकरण
• स्वतः-कार्यान्वित गुण
• अनाम प्रकार
• एक्सटेंशन के तरीके
• क्वेरी के भाव
• लैंबडा अभिव्यक्ति
• अभिव्यक्ति के पेड़
• आंशिक तरीके

C # 4.0

• गतिशील बंधन
• नामित और वैकल्पिक तर्क
• जेनेरिक सह और विरोधाभासी
• एंबेडेड इंटरोप प्रकार ("NoPIA")

सी # 5.0

• अतुल्यकालिक तरीके
• कॉलर जानकारी विशेषताएँ

सी # 6.0

• कंपाइलर-ए-ए-सर्विस (रोजलिन)
• नाम स्थान में स्थिर प्रकार के सदस्यों का आयात
• अपवाद फ़िल्टर
• पकड़ में अंत में इंतजार / अंत में ब्लॉक
• ऑटो संपत्ति इनिशियलाइज़र
• गटर-केवल गुणों के लिए डिफ़ॉल्ट मान
• अभिव्यक्ति-शारीरिक सदस्य
• अशक्त प्रचारक (शून्य-सशर्त ऑपरेटर, सक्सेस नल जाँच)
• स्ट्रिंग इंटरपोलेशन
• nameof ऑपरेटर
• शब्दकोश इनिशियलाइज़र

सी # 7.0

• बाहर चर
• पैटर्न मिलान
• tuples
• डीकंस्ट्रक्शन
• स्थानीय कार्य
• अंक विभाजक
• द्विआधारी शाब्दिक
• रेफरी और स्थानीय लोग
• सामान्य रूप से async रिटर्न प्रकार
• अभिव्यक्ति ने रचनाकारों और फाइनलर्स को उभारा
• अभिव्यक्ति ने धूम मचा दी

C # 7.1

• Async मुख्य
• डिफ़ॉल्ट शाब्दिक भाव
• टुप्ल तत्व तत्व नाम

- "सी शार्प" , विकिपीडिया (संदर्भ और लिंक हटा दिए गए)

यह शायद अधिक समझ में आता है कि सी # उस संदर्भ में आधी-अधूरी भाषा की तरह लग रहा था, क्योंकि आज सी # की बहुत कमी थी। यह सोचना अजीब है कि इसमें staticकक्षाएं भी नहीं थीं!

अधिक सामान गायब था, भी, क्योंकि C # को .NET से जोड़ा गया है। उदाहरण के लिए, WPF तब पीछे नहीं था; यह सब WinForms था।

Comments

स्थैतिक कक्षाएं एक अनुपस्थित सुविधा का एक खराब विकल्प हो सकती हैं, जिसे देखकर लगता है कि जावा अभी भी उनके पास नहीं है (C # तरह)। जब तक यह जावा पर एक जैब नहीं है?

— user253751

@immibis जावा पर एक जानबूझकर छुरा नहीं है, लेकिन, जीज़, वास्तव में? staticकक्षाएं इस तरह की एक आदिम सुविधा की तरह लगती हैं; मुझे लगता है कि वे पूर्व दिनांकित वर्ग कक्षाओं कल्पना की थी।

— नेट

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

— user253751

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

— जिर्का हनिका

@JirkaHanika हाँ, मैं staticवैसे भी ज्यादातर मामलों में कक्षाओं का बहुत बड़ा प्रशंसक नहीं हूँ । ईमानदारी से मैंने इसे कॉल करने के लिए एक सुविधा के रूप में चुना क्योंकि यह वास्तव में सरल था, सी # का आदिम हिस्सा; मुझे नहीं लगा कि वे जावा में नहीं थे।

— नेट

Answer 5

वह भाषा सुविधाओं की कमी की शिकायत कर रहा था, जो ठीक-ठाक नियंत्रण को सक्षम बनाता है। इनमें उपकरण शामिल हैं

• अपरिवर्तनीयता लागू करना (जैसे C ++ constकीवर्ड)
• वस्तु जीवनकाल और स्वामित्व को नियंत्रित करना
• मेमोरी उपयोग, कॉपी और आवंटन शैली को नियंत्रित करना

---

यह मुझे जावा की मेरी एक आलोचना की याद दिलाता है:

सब कुछ एक सूचक है, लेकिन संकेत मौजूद नहीं हैं।

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

एक अच्छी तरह से परिभाषित सी ++ प्रोग्राम में प्रोग्रामर संदर्भों को वैध और गैर-शून्य होने की उम्मीद कर सकता है। अपने सरलीकृत मॉडल के कारण, जावा समान गारंटी नहीं दे सकता है।

इस कम स्पष्ट मॉडल के लक्षणों में अशक्त वस्तु पैटर्न और योडा सशर्त जैसे शामिल हैं 5.equals(potentiallyNullIntegerReference)।

Comments

यह बहुत उलझा हुआ है। पॉइंटर्स (तार्किक अर्थों में जावा में मौजूद हैं) आप केवल उनके साथ पेंच नहीं कर सकते। मॉडल को सरल बनाने का पूरा बिंदु अधिक गारंटी के लिए अनुमति देना है। जिस तर्क को आप किसी भाषा में कोड के बारे में अधिक मान सकते हैं वह प्रतिबंध कम होगा। अधिक प्रतिबंध -> अधिक गारंटी।

— जिमीजम्स 18

@JimmyJames वाक्यांश का अर्थ है कि, भले ही सभी जावा वर्गों में निहितार्थ (yuck, btw) संदर्भ शब्दार्थ हो, लेकिन आपके पास वास्तविक सूचक नहीं हो सकता है। उदाहरण के लिए, एक संदर्भ के लिए "संदर्भ" प्राप्त करने का कोई तरीका नहीं है। यह कई स्थानों पर भाषा को अपंग करता है, कभी-कभी पागल वर्कअराउंड की आवश्यकता होती है (देखें कि Map.mergeजब आप बस एक नक्शे में एक मूल्य को अपडेट करना चाहते हैं)।

— क्वेंटिन

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

— सुपरकैट

@JimmyJames: दूसरी ओर, जावा और "सेफ-मोड" C # के कुछ और मौलिक प्रतिबंधों ने उन्हें एक बहुत ही उपयोगी गारंटी दी है कि C ++ नहीं कर सकता है: कोई भी संदर्भ (C ++ में क्या होगा) एक सूचक है किसी विशेष वस्तु की पहचान करने के लिए मनाया जाता है और किसी चीज की पहचान करने के लिए कभी नहीं मनाया जाएगा ।

— सुपरकैट

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

— जोर्ग डब्ल्यू मित्तग

Answer 6

मैं @Kilian के जवाब से सहमत हूं लेकिन मैं कुछ तत्वों को जोड़ूंगा।

1- वर्चुअल मशीन के खिलाफ रनिंग ओएस नहीं

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

2- आवेदन के टन आप इस तरह के सामान की जरूरत नहीं है।

ऐसे बहुत सारे एप्लिकेशन हैं जिन्हें वास्तव में आपको बहुत सारे विवरणों के माध्यम से खुदाई करने की आवश्यकता नहीं है, फिर भी अगर आप ऐसा करते हैं, तो आपको उस भाषा के साथ जो आपको करने की आवश्यकता होती है:

• उन अनावश्यक चीजों के कारण कीड़े होने का अधिक जोखिम।
• अधिक विकास लागत, स्मृति का प्रबंधन और परीक्षण में समय और इतना पैसा लगता है!

3 - भाषा कुछ पसंद / उपयोग / जोखिम, जैसे कि ... सब कुछ पर बनाई जाती है।

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

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

Comments

कई उत्तराधिकार की वास्तविक लागत इस तथ्य में निहित है कि निम्नलिखित दोनों गारंटियों को बरकरार रखना संभव नहीं है: (1) यदि बेस-क्लास के किसी सदस्य को Bमध्य वर्ग में ओवरराइड किया जाता है M, तो Bउस सदस्य का संस्करण केवल M'' के माध्यम से सुलभ होगा । ओवरराइड; (2) किसी भी प्रकार का संदर्भ दिया गया है T, इसे किसी भी सुपर-प्रकार और बैक में परिवर्तित करना Tमूल के बराबर एक संदर्भ देगा। उन दोनों की गारंटी उपयोगी है, और कई विरासत का समर्थन करने के लिए कम से कम एक को देने की आवश्यकता होगी।

— सुपरकैट

Answer 7

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

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

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

यहाँ जावा और C # जैसी भाषाएँ अत्यंत सहायक हैं; ऐसा नहीं है कि हम इस तथ्य का आनंद लेते हैं कि वे हमें उन सभी साफ-सुथरी चीजों को नहीं करने देते, जो अन्य भाषाओं में करते हैं, यह है कि हमें उन सिरदर्दों की कमी का आनंद लेना पड़ता है क्योंकि अन्य प्रोग्रामर उन साफ-सुथरी चीजों का दुरुपयोग करते हैं जो अन्य भाषाएं कर सकती हैं करना।

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

Comments

ऐसा लगता है कि बनाए गए कुछ बिंदुओं पर पर्याप्त रूप से कुछ नहीं दिया गया है और पहले 5 उत्तरों में समझाया गया है

— gnat

They exist not so much to protect the programmer from him/herself, but rather to protect the programmer from other programmers!या यह प्रोग्रामर से अन्य प्रोग्रामर की रक्षा के लिए है?

— टोबिया टेसन

@TobiaTesan वह भी :)

— Akumaburn