किसी भी प्रोग्रामिंग भाषा में आपके द्वारा सामना की गई सबसे बड़ी डिज़ाइन दोष क्या है? [बन्द है]

29

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

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

programming-languages  language-design  mistakes 
— Anto
स्रोत
6
ध्यान दें कि यह भाषा डिजाइनरों (गलतियों से बचने के लिए) के लिए रचनात्मक है, अगर कोई यह सवाल करना चाहता है कि यह प्रश्न कितना रचनात्मक है।
— एंटो
— com
1
@ ग्रेफेड: वास्तव में, यह वास्तविक भाषा की खामियों के बारे में है, यह उन चीजों के बारे में लगता है जो किसी भाषा को कम करती हैं, जिसमें खराब मानक पुस्तकालय या भाषा के लिए सिर्फ एक खराब वेबसाइट शामिल हो सकती है। कुछ उत्तर सूची जैसे कि खराब वाक्य रचना, लेकिन यह एक विशिष्ट डिज़ाइन दोष नहीं है
— Anto
8
किसी भी प्रोग्रामिंग भाषा में सबसे बड़ा दोष? मनुष्य।
— जोएल एथर्टन
अगर ये जवाब सबसे बड़ी खामियां हैं, तो मैं वास्तव में प्रोग्रामिंग भाषाओं से प्रभावित हूं।
— टॉम हॉल्टिन -

जवाबों:

42

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

मुझे याद है कि 1995 में जब मैं पहली बार जावा के विवरणों के बारे में पढ़ रहा था, जब मुझे इस switchकथन के बारे में भाग मिला तो मुझे बहुत निराशा हुई कि उन्होंने डिफ़ॉल्ट फॉल-थ्रू व्यवहार को बरकरार रखा था। यह सिर्फ switchएक gotoऔर नाम के साथ एक गौरवशाली बनाता है ।

— ग्रेग हेविल
स्रोत
3
@ श्रीकृष्ण महान: switchइस तरह से काम नहीं करना है। उदाहरण के लिए, Ada का मामला / जब स्टेटमेंट (स्विच / केस के बराबर) में फॉल-थ्रू व्यवहार नहीं होता है।
— ग्रेग हेवगिल
2
@Greg: switchC से असंबंधित भाषाओं में दिए गए कथनों को उस तरह से काम नहीं करना है। लेकिन अगर आप सी-शैली नियंत्रण प्रवाह (का उपयोग {... }, for (i = 0; i < N; ++i), return, आदि), भाषा अनुमान लोग उम्मीद कर देगा switchसी की तरह काम करने के लिए, और यह दे रही है ऐडा / पास्कल / बुनियादी की तरह अर्थ विज्ञान उलझन में है | लोग। सी # के लिए एक ही कारण से बयानों की आवश्यकता होती breakहै switch, हालांकि यह साइलेंट फ़्रीथ्रू को मना करके कम त्रुटि वाला बनाता है। (लेकिन मेरी इच्छा है कि आप fall;बदसूरत के बजाय लिख सकते हैं goto case।)
— dan04
4
फिर स्विच न लिखें, लिखें ()। आप जिस कारण के बारे में शिकायत कर रहे हैं वह स्विच को बेहतर बनाता है: यह एक सही / गलत स्थिति नहीं है, यह एक संख्यात्मक स्थिति है, और यह आपको अलग बनाता है। आप अपने स्वयं के स्विच फंक्शन को भी लिख सकते हैं।
— जोक
9
-1 मैं इसके माध्यम से गिरने की अनुमति देने के लिए एक लाभ मानता हूं, मूर्खता के अलावा इससे कोई खतरा नहीं है, फिर भी यह अतिरिक्त कार्य करता है।
— परिक्रमा
11
समस्या यह नहीं है कि गिरावट की switch अनुमति देता है । यह है कि गिरावट के अधिकांश उपयोग जानबूझकर नहीं हैं।
— dan04
41

मुझे =असाइनमेंट के लिए और ==सी-व्युत्पन्न भाषाओं में समानता परीक्षण के लिए वास्तव में पसंद नहीं आया है । भ्रम और त्रुटियों की संभावना बहुत अधिक है। और मुझे ===जावास्क्रिप्ट में शुरू भी नहीं किया ।

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

— ग्रेग हेविगेल को दर्शाता है
स्रोत
3
@ नेमंजा ट्रिफ़ुनोविक: मैंने मूल रूप से उस सुझाव के बारे में सोचा था, लेकिन सी में एक नकारात्मक संख्या (यानी x<-5) के मुकाबले तुलनात्मक रूप से इसकी तुलना में दुर्भाग्यपूर्ण अस्पष्टता है । C प्रोग्रामर उस तरह के आवश्यक व्हाट्सएप को बर्दाश्त नहीं करेंगे :)
— ग्रेग हेविगिल
7
@Greg: मैं पसंद करूंगा :=और ==क्योंकि इसे भूलना बहुत आसान होगा :और इसे अधिसूचित नहीं किया जाना चाहिए क्योंकि यह पहले से ही मामला है (हालांकि उलटा) जब आप =आज भूल जाते हैं। मैं इस पर संकलक चेतावनी के लिए आभारी हूं ...
— मैथ्यू एम।
13
मेरे द्वारा उपयोग किए गए लगभग सभी कीबोर्ड पर, ": =" को टाइप करते समय शिफ्ट कुंजी को बदलने की आवश्यकता होती है। अब मैं जो प्रयोग कर रहा हूं, उस पर ':' अपरकेस है और '=' लोअरकेस है, और मैंने इसे उलट दिया है। मैं बहुत सारे असाइनमेंट टाइप करता हूं, और उस तरह की परेशानी की जरूरत नहीं है।
— डेविड थोरले
14
@ डेविड थॉर्नले: कोड को लिखे जाने की तुलना में कई बार पढ़ा जाता है। मैं "टाइपिंग परेशानी" के बारे में कोई तर्क नहीं खरीदता।
— ग्रेग हेविगिल
8
@Greg Hewgill: यकीन है कि यह लिखित की तुलना में अधिक बार पढ़ा जाता है। हालाँकि, समस्या के बीच =और ==पढ़ने में नहीं है, क्योंकि वे अलग प्रतीक हैं। यह लेखन में है और सुनिश्चित करें कि आपको सही मिला है।
— डेविड थॉर्नले
29

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

शुरुआत में यह आसान होगा कि एक नए ऑपरेटर को शुरू किया जा सके जैसे कि $स्ट्रिंग कॉन्फैटिनेशन।

— ग्रेग हेविगेल को दर्शाता है
स्रोत
13
@ बैरी: वास्तव में नहीं। +एक जोरदार टाइप की गई भाषा में एक स्ट्रिंग कॉन्टेनेशन ऑपरेटर के रूप में बहुत कुछ समझ में आता है। समस्या यह है कि जावास्क्रिप्ट इसका उपयोग करता है लेकिन दृढ़ता से टाइप नहीं किया जाता है।
— मेसन व्हीलर
13
@ मेसन: कॉन्टैकटेशन के लिए +कोई मतलब नहीं है, क्योंकि कॉन्टेक्टेशन निश्चित रूप से कम्यूटेटिव नहीं है। जहां तक ​​मेरा संबंध है, यह एक दुरुपयोग है।
— मथिउ एम।
12
@ मैथ्यू: उम्म ... वह बात क्यों करता है? कॉनटेनटेशन कम्यूटेटिव नहीं है (जैसे जोड़ है), लेकिन दो स्ट्रिंग्स का जोड़ बकवास है, इसलिए कोई भी इस तरह से नहीं सोचता है। आप एक ऐसी समस्या का आविष्कार कर रहे हैं जहाँ कोई भी मौजूद नहीं है।
— मेसन व्हीलर
4
बस C ++ पर स्विच करें और अपनी पसंद के ऑपरेटर के लिए किसी भी प्रकार के गूढ़ अतिभार को जोड़ दें
— Newtopian
8
@ मैथ्यू: कम्यूटिटी यहां मुद्दा नहीं है। यदि JS के पास एक मैट्रिक्स क्लास है, तो क्या आप इसे *ऑपरेटर के लिए दुरुपयोग मानेंगे?
— dan04
24

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

— ज़चारी का
स्रोत
2
वैश्विक के लिए डिफ़ॉल्ट? मुझे खुशी है कि मैं तब JS का उपयोग नहीं करता ...
— Anto
5
वास्तव में यह बहुत अच्छी भाषा है, इसमें कुछ खराब डिजाइन विकल्प हैं। यह एक प्रमुख है, यदि आप एक चर को गुंजाइश नहीं देते हैं तो यह एक वैश्विक के रूप में इसे गुंजाइश देगा। अच्छी बात यह है कि डग क्रॉकफोर्ड के जेस्लिन प्रोग्राम का उपयोग करके आप इस त्रुटि और एक गुच्छा को अधिक पकड़ सकते हैं।
— Zachary K
1
varजब भी आप एक चर घोषित करते हैं और आप जाने के लिए अच्छे हैं, तो बस उपयोग करें । और मुझे यह मत कहना कि यह बहुत अधिक टाइपिंग है क्योंकि जावा आपको सभी प्रकार के दो बार घोषित करने के लिए मजबूर करता है और कोई भी इसके बारे में शिकायत नहीं करता है कि यह एक चमकदार डिजाइन विकल्प है।
— davidk01
3
@ davidk01: लोग इस बारे में शिकायत करते हैं। इसी तरह, लोगों ने std::map<KEY, VALUE>::const_iteratorC ++ में वैरिएबल घोषित करने के बारे में शिकायत की, autoजो उस भाषा में जोड़ा जा रहा है।
— dan04
1
"use strict"निर्देश, es5 में कहा, एक त्रुटि में अघोषित संदर्भ बदल जाता है।
— शॉन मैकमिलन
22

C और C ++ में प्रीप्रोसेसर एक बड़े पैमाने पर कीचड़ है, जो अमूर्त बनाता है, जो रिसाव की तरह बहता है, चूहे के #ifdefबयानों के माध्यम से स्पेगेटी कोड को प्रोत्साहित करता है , और ALL_CAPSइसकी सीमाओं के आसपास काम करने के लिए बुरी तरह से अपठनीय नामों की आवश्यकता होती है। इन समस्याओं की जड़ यह है कि यह वाक्यात्मक या अर्थ स्तर के बजाय पाठ स्तर पर संचालित होती है। इसके विभिन्न उपयोग मामलों के लिए इसे वास्तविक भाषा सुविधाओं से प्रतिस्थापित किया जाना चाहिए। यहाँ कुछ उदाहरण दिए गए हैं, हालाँकि इनमें से कुछ को C ++, C99 या अनौपचारिक लेकिन वास्तविक तथ्यों के विस्तार में हल किया गया है :

  • #include एक वास्तविक मॉड्यूल प्रणाली के साथ प्रतिस्थापित किया जाना चाहिए था।

  • इनलाइन फ़ंक्शन और टेम्प्लेट / जेनेरिक अधिकांश फ़ंक्शन कॉल उपयोग मामलों को बदल सकते हैं।

  • ऐसे स्थिरांक घोषित करने के लिए किसी प्रकार की अभिव्यक्ति / संकलन समय निरंतर सुविधा का उपयोग किया जा सकता है। डीम के विस्तार का काम यहां बहुत अच्छा है।

  • वास्तविक सिंटैक्स ट्री स्तर मैक्रोज़ विविध उपयोग के मामलों को हल कर सकता है।

  • स्ट्रिंग मिश्रण का उपयोग कोड इंजेक्शन उपयोग के मामले के लिए किया जा सकता है।

  • static ifया versionबयानों का उपयोग सशर्त संकलन के लिए किया जा सकता है।

— dsimcha
स्रोत
2
@dsimcha: मैं इस #includeमुद्दे से सहमत हूं , लेकिन मॉड्यूल प्रणाली का आविष्कार किया गया ... बाद में! और C और C ++ का अधिकतम पिछड़ी संगतता के लिए लक्ष्य: /
— Matthieu M.
@ मैथ्यू: हां, मॉड्यूल सिस्टम का आविष्कार बाद में किया गया था, लेकिन हम यहां किसी भी तरह से हंडाइट के बारे में बात कर रहे हैं।
— dsimcha
3
मैं मानता हूं कि यह शरीर के विभिन्न हिस्सों में भारी दर्द है, लेकिन मल्टी-पास डिज़ाइन में सादगी का लाभ है: एक सी कंपाइलर को ऑपरेशन के संदर्भ के बारे में अधिक जानने की जरूरत नहीं है, इससे पहले कि वह सफलतापूर्वक सी कोड का एक हिस्सा संकलित कर सके । यह केवल एक डिज़ाइन त्रुटि के रूप में योग्य हो सकता है यदि आप दिखा सकते हैं कि सी भाषा के भीतर एक काल्पनिक मॉड्यूल प्रणाली (जैसे सी ++ - जैसे कक्षाएं) का उपयोग करने की लागत हमेशा मौजूद सीपीपी-आधारित #includeहैकिंग की तुलना में कम या तुलनीय है ।
— रीयरियरपोस्ट
मैं सहमत हूँ। हालांकि, लेकिन कुछ लोग सोचते हैं कि प्रीप्रोसेसिंग एक अच्छी बात है, और शिकायत करते हैं कि यह (उदाहरण के लिए) जावा में समर्थित नहीं है।
— स्टीफन सी
5
@ स्टीफन: मैं मानता हूं कि प्रीप्रोसेसर के साथ जावा बिना जावा से बेहतर हो सकता है, लेकिन केवल इसलिए कि प्रीप्रोसेसर को बदलने के लिए जावा में "वास्तविक" सुविधाओं में से कई नहीं हैं। डी जैसी भाषाओं में, जिसमें ऐसी विशेषताएं और पायथन शामिल हैं, जो गतिशील होने से अन्य तरीकों से लचीलापन प्राप्त करता है, मैं इसे एक सा याद नहीं करता।
— dsimcha
21

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

क्यूं कर?

क्योंकि एक भाषा में गलती करने वाली चीज दूसरी भाषा की गलती नहीं होगी। उदाहरण के लिए:

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

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

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

यदि सामान्य सबक सीखे जाएं तो वे "मेटा" स्तर पर हैं:

  • आप एक प्रोग्रामिंग भाषा डिज़ाइन नहीं कर सकते जो सभी उद्देश्यों के लिए आदर्श हो।
  • आप गलतियाँ करने से बच नहीं सकते ... खासकर जब हिंद-दृष्टि से देखा जाए।
  • आपकी भाषा के उपयोगकर्ताओं के लिए कई गलतियाँ सही हैं ...
  • आपको अपने लक्षित दर्शकों की पृष्ठभूमि और कौशल का ध्यान रखना होगा; यानी मौजूदा प्रोग्रामर।
  • आप हर किसी को खुश नहीं कर सकते।
— है
स्रोत
9
-1 - प्रोग्रामिंग भाषाएँ डिज़ाइन लक्ष्यों का पालन करती हैं। एक भाषा की एक विशेषता जो इन लक्ष्यों के खिलाफ काम करती है, एक डिजाइन दोष है, जब तक कि यह उसके अन्य लक्ष्यों में से एक के लिए आवश्यक समझौता नहीं है। सभी को संतुष्ट करने के इरादे से बहुत सी भाषाएं नहीं बनाई जाती हैं, लेकिन सभी भाषाओं को उन लोगों को संतुष्ट करने का प्रयास करना चाहिए जो पहली बार में संतुष्ट करने के लिए तैयार हैं। इस तरह की उत्तर-आधुनिकतावादी राजनीतिक शुद्धता प्रोग्रामिंग भाषा अनुसंधान और विकास के लिए काफी महत्वपूर्ण है।
— री मियासका
मेरा कहना है कि डिजाइन लक्ष्यों को ध्यान में रखे बिना सबक सीखना मुश्किल है।
— स्टीफन सी
1
मुझे लगता है कि ओपी पहले ही सवाल के दूसरे पैराग्राफ में आपके जवाब के लिए जिम्मेदार है।
— ऐदन कल्ली
20

C और C ++ : वे सभी पूर्णांक प्रकार जिनका कोई मतलब नहीं है।

खासतौर पर char। क्या यह पाठ है या यह एक छोटा पूर्णांक है? यदि यह पाठ है, तो क्या यह "ANSI" वर्ण या UTF-8 कोड इकाई है? यदि यह पूर्णांक है, तो क्या यह हस्ताक्षरित या अहस्ताक्षरित है?

int "देशी" आकार के पूर्णांक होने का इरादा था, लेकिन 64-बिट सिस्टम पर, यह नहीं है।

longसे बड़ा हो सकता है या नहीं भी हो सकता है int। यह एक पॉइंटर के आकार का हो भी सकता है और नहीं भी। कंपाइलर लेखकों की ओर से यह 32-बिट या 64-बिट की तुलना में बहुत अधिक मनमाना निर्णय है।

निश्चित रूप से 1970 के दशक की एक भाषा। यूनिकोड से पहले। 64-बिट कंप्यूटर से पहले।

— dan04
स्रोत
10
C को एक मानक फिट-ऑल लैंग्वेज के लिए डिज़ाइन नहीं किया गया था, इसलिए यह एक डिज़ाइन त्रुटि नहीं हो सकती है। यह सीपीयू-विशिष्ट कोडांतरक कोड से बचने के लिए पोर्टेबल असेंबलर के रूप में एक सीपीयू मॉडल करने के लिए डिज़ाइन किया गया था। हालांकि, यह जावा में तय किया गया था।
7
मुझे लगता है कि बड़ी समस्या नई भाषाएं हैं जो इतिहास को एक भयानक विचार के रूप में दिखाने के बावजूद उसी अर्थहीन शब्दों का उपयोग करना जारी रखती हैं। कम से कम C लोगों ने अपनी गलती को देखा और मानक int प्रकार बनाए।
— मार्क एच
5
एक char एक utf-8 यूनिट नहीं है। एक utf-8 चरित्र को स्टोर करने के लिए 8 बिट्स अधिक लग सकते हैं। सी 1970 की भाषा नहीं है, मैं इसे अभी (स्वेच्छा से) एक परियोजना के लिए उपयोग कर रहा हूं।
— dan_waterworth
4
C, PDP-11 प्रोसेसर के उच्च-स्तरीय अमूर्तता से थोड़ा अधिक है। उदाहरण के लिए, पूर्व और बाद के वेतन वृद्धि को सीधे पीडीपी -11 द्वारा समर्थित किया गया था।
— बिट-ट्विडलर
5
यह एक बहुत ही गलत जवाब है। पहले बंद, C और C ++ विनिमेय नहीं हैं। दूसरा, भाषा की कल्पना स्पष्ट रूप से परिभाषित करती है कि एक चार क्या है - एक ऑब्जेक्ट जिसे प्रकार चार के रूप में घोषित किया गया है वह मूल निष्पादन वर्ण सेट के किसी भी सदस्य को संग्रहीत करने के लिए पर्याप्त है। । तीसरा, सी "70 के दशक की भाषा" नहीं है, यह एक ऐसी भाषा है जो हार्डवेयर के करीब रहती है और शायद वह भाषा है जो अंततः आपके सभी उच्च स्तर के अमूर्त को वास्तव में सीपीयू के लिए समझ में आने देती है। आप एक ऐसे व्यक्ति के रूप में आते हैं, जो केवल उच्च स्तरीय भाषाओं को जानता है और इस बात के लिए कोई प्रशंसा नहीं है कि वास्तव में चीजें कैसे काम करती हैं। -1
— एड एस।
18

null।

इसके आविष्कारक, टोनी होरे, इसे "अरब डॉलर की गलती" कहते हैं ।

यह 60 के दशक में ALGOL में पेश किया गया था, और आज की अधिकांश प्रयुक्त प्रोग्रामिंग भाषाओं में मौजूद है।

OCaml और Haskell जैसी भाषाओं में इस्तेमाल किया जाने वाला बेहतर विकल्प, शायद है । सामान्य विचार यह है कि वस्तु संदर्भ शून्य / खाली / गैर-मौजूद नहीं हो सकते जब तक कि कोई स्पष्ट संकेत न हो कि वे ऐसा हो सकते हैं।

(हालांकि टोनी की अपनी विनम्रता में कमाल है, मुझे लगता है कि लगभग किसी ने भी वही गलती की होगी, और वह सिर्फ पहले हुआ था।)

— रेई मियासाका
स्रोत
असहमत, अपने आविष्कारक के साथ भी !!! null सूचक / संदर्भ डेटा प्रकार के लिए रिक्त मान है। स्ट्रिंग्स में रिक्त स्ट्रिंग होती है, सेट में खाली सेट होता है (पास्कल खाली सेट = []), पूर्णांक में 0. अधिकांश प्रोग्रामिंग भाषाएं होती हैं जो अशक्त / शून्य / जो भी उपयोग करती हैं, यदि एक चर को ठीक से सौंपा गया है, तो एक शून्य त्रुटि को रोका जा सकता है।
— umlcat
4
@ user14579: किसी भी प्रकार के सेट या स्ट्रिंग या सरणी का समर्थन करने वाली प्रत्येक भाषा में {} है, लेकिन यह अभी भी शब्दार्थ रूप से उपयुक्त है और दुर्घटनाग्रस्त नहीं होगी जब तक कि आपके पास पहले से ही कुछ ऐसा न हो जो संभवतः सरणी सीमा त्रुटि का कारण बन सकता है - लेकिन यह एक और मुद्दा है। आप सभी वर्णों को ऊपर ले जाने के लिए एक रिक्त स्ट्रिंग संसाधित कर सकते हैं, जिसके परिणामस्वरूप रिक्त स्ट्रिंग होगी। आप अशक्त स्ट्रिंग पर एक ही चीज़ की कोशिश करते हैं, और उचित विचार के बिना, यह दुर्घटनाग्रस्त हो जाएगा। समस्या यह है कि यह उचित विचार थकाऊ है, अक्सर भुला दिया जाता है, और एकल-अभिव्यक्ति फ़ंक्शंस (यानी लंबोदा) लिखना मुश्किल हो जाता है।
— री मियासाका
1
मैं हर बार जब मैं नल टाइप करता हूँ तो पैसे कमाता हूँ ... ओह, ठीक है, हर बार जब मैं शून्य टाइप करता हूँ तो कोई व्यक्ति पैसे खो देता है। इस समय को छोड़कर।
— केवपी
3
@umlcat - जब आपके पास Ocaml, Haskell, और F # जैसे पैटर्न मिलान वाली भाषाएँ हैं, तो शायद x का उपयोग करके | कोई भी पैटर्न आपको संकलन-समय पर अशक्त मामले को भूलने से नहीं रोकता है। संकलित समय-प्रवंचना की कोई भी राशि उन भाषाओं में त्रुटि नहीं पकड़ सकती है जहाँ अशक्त स्थापित मुहावरे हैं। चूंकि आपको स्पष्ट रूप से उन भाषाओं में शून्य मामले से निपटने के लिए नहीं चुनना है जिनमें शायद और शायद कुछ सनक है, इसलिए उन्हें "अशक्त" दृष्टिकोण पर एक गंभीर लाभ है।
— जेसनट्र्यू
1
@ जेसन - मुझे maybeएक शून्य ऑप्ट-इन के रूप में सोचना पसंद है , जबकि शून्य अपवाद एक ऑप्ट-आउट है। बेशक रनटाइम त्रुटियों और संकलन-समय त्रुटियों के बीच अंतर के बारे में भी कुछ बातें कही जानी हैं, लेकिन सिर्फ यह तथ्य कि शून्य अनिवार्य रूप से व्यवहार को इंजेक्ट कर रहा है, अपने आप में उल्लेखनीय है।
— री मियासाका १३'११
14

मुझे लग रहा है कि जिन लोगों ने PHP डिज़ाइन किया था, वे एक सामान्य कीबोर्ड का उपयोग नहीं करते थे, वे एक colemak कीबोर्ड का उपयोग भी नहीं करते हैं, क्योंकि उन्हें एहसास होना चाहिए कि वे क्या कर रहे थे।

मैं एक PHP डेवलपर हूं। PHP टाइप करने के लिए मजेदार नहीं है।

Who::in::their::right::mind::would::do::this()? ::ऑपरेटर पकड़े पारी और उसके बाद दो कुंजी दबाव की आवश्यकता है। ऊर्जा की बर्बादी क्या।

Although-> इस-> है-> नहीं-> much-> बेहतर। यह भी दो प्रतीकों के बीच में बदलाव के साथ तीन प्रमुख प्रेस की आवश्यकता है।

$last = $we.$have.$the.$dumb.'$'.$character। डॉलर चिन्ह का उपयोग कई बार किया जाता है और इसके लिए कीबोर्ड के बहुत ऊपर और एक शिफ्ट की प्रेस के लिए पुरस्कार की आवश्यकता होती है।

वे उन कुंजियों का उपयोग करने के लिए PHP डिज़ाइन क्यों नहीं कर सकते हैं जो टाइप करने के लिए बहुत तेज़ हैं? we.do.this()वैर एक ऐसे कुंजी के साथ क्यों या शुरू नहीं हो सकता है, जिसके लिए केवल एक कीपर की आवश्यकता होती है - या नॉन (जावास्क्रिप्ट) और केवल पूर्व के सभी संस्करणों को परिभाषित करना (जैसे मुझे वैसे भी E_STRICT के लिए करना है)!

मैं कोई धीमा टाइपिस्ट नहीं हूँ - लेकिन यह सिर्फ एक लंगड़ा डिज़ाइन विकल्प है।

— Xeoncross
स्रोत
पर्ल इस दर्द को साझा करता है।
— डेन्थ
2
तो C ++ करता है, और कुछ अकथनीय विचित्र कारण के लिए, PowerShell।
— री मियाँसाका
2
अधिक शक्तिशाली संपादक का उपयोग करें, और उन ऑपरेटरों के लिए अपने स्वयं के प्रमुख दृश्यों को परिभाषित करें।
— केविन क्लाइन
1
I::have::nothing::against::this->at.all()
— मतीन उल्हाक
1
शायद वे qwerty कीबोर्ड का उपयोग नहीं करते हैं। $ और: की-बोर्ड की तरह सभी azerty पर दबाए गए शिफ्ट कुंजी की आवश्यकता नहीं है।
— अरख
13

Asp.net के भीतर डेस्कटॉप प्रेरित रूपों का उपयोग ।

यह हमेशा एक ठग महसूस करता था और रास्ते में मिला या वेब वास्तव में कैसे काम करता है। शुक्र है कि asp.net-mvc उसी तरह से पीड़ित नहीं है, हालांकि उस प्रेरणा के लिए रूबी आदि को श्रेय दिया गया है।

— कबूतर
स्रोत
18
एक पुस्तकालय बात नहीं है?
— नीकी
@ मिनी यह एक अच्छा बिंदु है;)
— dove
1
@ मिनी दरअसल, XML- आधारित ASPX कोड एक भाषा है, जिससे आप इसे काम करने के लिए मोड़ सकते हैं। : डी
— कोडेक्सआर्केनम
2
ASP.NET के साथ असली समस्या, मुझे लगता है, यह प्रोग्रामर से वेब के विवरण को छिपाने की कितनी कोशिश करता है। ASP.NET में वास्तव में कुछ साफ-सुथरा, उपयोगी सामान चल रहा है, लेकिन आपको इसे पाने के लिए इतनी मेहनत और खुदाई करनी पड़ती है।
— 21x पर कोडेक्सआर्कनम
1
दूसरी ओर हजारों और हजारों सरल और सफल डेटा संग्रह ऐप हैं जो "क्लासिक" डेस्कटॉप ऐप चीज़ का उपयोग करके एक साथ डालते हैं। केवल बुरी बात यह थी कि MVC तक केवल Microsoft विकल्प ही विंडोज़ के रूप थे।
— एलग्रिन्गोग्रैन्ड
13

मेरे लिए यह अपने मानक पुस्तकालय में नामकरण और तर्क आदेश परंपराओं के PHP की पूर्ण कमी है।

हालाँकि संदर्भित ऑब्जेक्ट के रिलीज़ / हटाए जाने के बाद JASS की ज़रूरतों को कम किया जा सकता है (या संदर्भ लीक हो जाएगा और मेमोरी के कई बाइट्स खो जाएंगे) अधिक गंभीर है, लेकिन चूंकि JASS एकल उद्देश्य भाषा है, इसलिए यह महत्वपूर्ण नहीं है।

— Matj Zábský
स्रोत
9
PHP के stdlib में सम्मेलनों की कमी एक भाषा डिजाइन दोष नहीं है।
3
@delnan: सम्मेलनों की कमी PHP को कैसे डिज़ाइन किया गया था, इसका एक परिणाम है, और इसलिए भाषा डिजाइन के साथ बहुत कुछ करना है। इसके अलावा यह मेरे लिए स्पष्ट नहीं है कि पुस्तकालयों और भाषा के बीच एक स्पष्ट अंतर है। विशेष रूप से लिस्प में एक भाषा को दूसरे के ऊपर बूटस्ट्रैप करने की एक गौरवशाली परंपरा है।
— btilly
1
जेएएसएस के बारे में वास्तव में उल्लेखनीय बात यह थी कि इसमें हैंडल पर गिनती होती थी, लेकिन जब तक वे मैन्युअल रूप से नष्ट नहीं हो जाते (और ग्राफिक इंटरफ़ेस ने हर जगह मेमोरी लीक कर दी) तब तक उन्हें साफ नहीं करेंगे!
— क्रेग गिदनी
13

सबसे बड़ी डिजाइन दोष जो मुझे लगता है कि अजगर की शुरुआत के लिए अजगर 3.x की तरह डिजाइन नहीं किया गया था।

— dan_waterworth
स्रोत
1
ठीक है, नहीं भी Guido एक बार में सब कुछ ठीक हो सकता है ...
5
@ डेलन, ओह मुझे पता है, और अजगर <3 अभी भी एक बहुत अच्छी भाषा है, लेकिन यह अजगर 3.x के रूप में बेहतर भाषा के लिए थोड़ा कष्टप्रद है जो मैं उपयोग नहीं कर सकता क्योंकि यह सभी मॉड्यूल को तोड़ता है मुझे जरूरत है।
— dan_waterworth
अपने अजगर 3.x मॉड्यूल की पैरवी करना जारी रखें! इस बीच मैं 2.5.4 में लिखता रहूंगा। एसओ के लिए धन्यवाद मुझे वास्तव में याद दिलाया गया है कि 3.x जीवित और अच्छी तरह से है।
— केवपी
@kevpie सबसे पहले, पुस्तकालय रखरखाव के लिए संक्रमण को आसान बनाने के लिए अजगर के लिए सशर्त संकलन को जोड़ने के लिए लॉबी। 2to3 लंबी अवधि में एक अनुरक्षित समाधान नहीं है।
— इवान प्लाइस
12

C में क्षय का क्षय और फलस्वरूप C ++।

— निमंजा ट्रिफ़ुनोविक
स्रोत
मैं उचित सरणी समर्थन की भी कामना करता हूं। C ++ में आप फरार सिंटैक्स और टेम्प्लेट का उपयोग करके क्षय को रोक सकते हैं ... लेकिन यह एक हैक के अधिक है: /
— Matthieu M.
1
ध्यान दें कि यही कारण है कि C ++ में अलग deleteऔर delete[]ऑपरेटर हैं।
— dan04
आप किसी सरणी को हमेशा एक संरचना में रख सकते हैं और यदि आप चाहें तो इसे मूल्य के आसपास से पास कर दिया है, लेकिन यह आमतौर पर मूल समस्या की तुलना में अधिक अजीब है। C ++ में, आप आमतौर पर सरणियों का उपयोग करने की आवश्यकता से बच सकते हैं।
— डेविड थॉर्नले
2
कम से कम सी मामले में, उचित सरणी समर्थन के खिलाफ तर्क "सरणी सीमा की जाँच महंगी है", विशेष रूप से सी पॉइंटर अंकगणितीय कार्यों को देखते हुए।
— स्टीफन सी
@ स्टीफन सी: सरणी क्षय की जाँच किस सीमा सीमा से करनी है?
— नेमेनजा ट्रिफ़ुनोविक
11

जावा में आदिम प्रकार।

वे इस सिद्धांत को तोड़ते हैं कि सब कुछ एक वंशज है java.lang.Object, जो सैद्धांतिक दृष्टिकोण से भाषा विनिर्देश की अतिरिक्त जटिलता की ओर जाता है, और एक व्यावहारिक दृष्टिकोण से वे संग्रह के उपयोग को बेहद थकाऊ बनाते हैं।

ऑटोबॉक्सिंग ने व्यावहारिक कमियों को दूर करने में मदद की, लेकिन विनिर्देश को और अधिक जटिल बनाने और एक मोटी वसा वाले केले की त्वचा को पेश करने की कीमत पर: अब आप एक साधारण अंकगणितीय ऑपरेशन की तरह दिखने वाले से एक शून्य सूचक अपवाद प्राप्त कर सकते हैं।

— biziclop
स्रोत
यदि आप आदिम प्रकारों को निकालते हैं तो यह भयानक प्रदर्शन का कारण होगा। और ऑटोबॉक्सिंग को आसानी से गड़बड़ किया जा सकता है, इसलिए यह कुछ भी नहीं सुधारता है।
— deadalnix
उस समय, यह जावा डिजाइनरों का एक समझदार निर्णय था। 90 के दशक में उपलब्ध मशीनों / VMs के प्रदर्शन लाभ ने java.lang.Object के चारों ओर सब कुछ एकजुट करने के वैचारिक लाभों को पछाड़ दिया।
— मिकेरे
10

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

पर्ल ने कई विचारों की कोशिश की। कुछ अच्छे थे। कुछ खराब थे। कुछ मूल थे और अच्छे कारण के लिए व्यापक रूप से कॉपी नहीं किए गए थे।

एक संदर्भ का विचार है - प्रत्येक फ़ंक्शन कॉल सूची या स्केलर संदर्भ में होता है, और प्रत्येक संदर्भ में पूरी तरह से अलग चीजें कर सकता है। जैसा कि मैंने http://use.perl.org/~btilly/journal/36756 पर बताया है कि यह हर एपीआई को जटिल करता है, और अक्सर पर्ल कोड में सूक्ष्म डिजाइन मुद्दों की ओर जाता है।

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

एक और आम गलती, कई भाषाओं द्वारा की गई है, लेक्सिकल के बजाय डायनेमिक स्कूपिंग की शुरुआत करना है। बाद में इस डिजाइन के फैसले को वापस लेना कठिन है, और लंबे समय तक चलने वाले मौसा की ओर जाता है। पर्ल में उन मौसाओं का क्लासिक विवरण http://perl.plover.com/FAQs/Namespaces.html है । ध्यान दें कि यह पर्ल ourऔर staticवेरिएबल्स के जोड़े जाने से पहले लिखा गया था ।

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

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

— रेवली btilly
स्रोत
5
हाँ, पर्ल में बहुत सारी गलतियाँ हैं, क्योंकि जिन लोगों ने इसे बनाया था वे नए विचारों की कोशिश कर रहे थे, और जब आप ऐसा करते हैं कि आप अक्सर उन्हें गलत करते हैं। (पर्ल के पास कुछ बहुत अच्छी चीजें हैं, और Regexps के लिए मानक है कि हर किसी की नकल करने के लिए लगता है)
— Zachary K
@ zachary-k: बिल्कुल सहमत। और मैंने मुद्दों के माध्यम से चलना शुरू करने से पहले यह स्पष्ट करने की कोशिश की।
— बीटीली
4
लिस्प्स को मूल रूप से गतिशील रूप से स्कूप किया गया था, और समय के साथ लेक्सिकली स्कॉप्ड (कम से कम स्कीम और कॉमन लिस्प) में बदल दिया गया। इसे बदलना असंभव नहीं है।
— डेविड थॉर्नले
4
@ डेविड-थॉर्नले: यह असंभव है जब तक कि आप कहीं पीछे की ओर संगतता का त्याग नहीं करते हैं। स्कीम को हमेशा लांछित किया गया था। आम लिस्प को उस समय से ही स्कोप किया गया था जब इसे मानकीकृत किया गया था, लेकिन विभिन्न लिस्प समुदायों ने अपने संघर्षों को अपनाया था। और Emacs Lisp अभी भी गतिशील स्कूपिंग का उपयोग कर रहा है, भले ही लंबे समय से इसे बदलने की इच्छा रही हो।
— btilly
1
BTW, लोगों को पर्ल के लिए नापसंद चीजों में से कई पर्ल में आविष्कार नहीं किया गया था, लेकिन अन्य भाषाओं, ज्यादातर बॉर्न शेल से लिया गया था।
— रीयरियरपोस्ट
10

जावा कोड कोड ब्लॉक और ऑब्जेक्ट शाब्दिक के लिए अस्पष्टता।

  {a:b}

एक कोड ब्लॉक हो सकता है, जहां aएक लेबल है और bएक अभिव्यक्ति है; या यह एक वस्तु को परिभाषित कर सकता है, जिसमें एक विशेषता है aजिसका मूल्य हैb

— user281377
स्रोत
मुझे वास्तव में जावास्क्रिप्ट के बारे में यह पसंद है। भाषा संरचना सरलता अच्छी है और उद्देश्य स्पष्ट होना चाहिए यदि डेवलपर को पता है कि वे क्या कर रहे हैं।
— Xeoncross
2
Xeoncross: मैं आमतौर पर अस्पष्टता को नापसंद करता हूं। इस मामले में, यह डेवलपर के लिए स्पष्ट है, लेकिन eval () को अतिरिक्त कोष्ठक की आवश्यकता है।
— user281377
2
@ स्तन: यह स्पष्ट है? तो यह क्या है? ऑब्जेक्ट या कोड ब्लॉक?
— विन्यासकर्ता
विन्यासक: स्पष्ट रूप से एक वस्तु। कोई भी समझदार व्यक्ति नामक लेबल का उपयोग नहीं करेगा a।
— user281377
10

मैं फोरट्रान और व्हाट्सएप असंवेदनशीलता पर वापस जा रहा हूं।

इसने विशिष्टता को बढ़ा दिया। ENDकार्ड, बल्कि "END" के साथ एक कार्ड की तुलना में उचित में कोई अन्य nonblanks एक 'ई' के साथ एक कार्ड, एक 'एन', और स्तंभों 7-72 में इसी क्रम में एक 'डी', और के रूप में परिभाषित किया जा सकता था कॉलम और कुछ नहीं।

इसने आसान वाक्यात्मक भ्रम पैदा किया। DO 100 I = 1, 10एक लूप कंट्रोल स्टेटमेंट DO 100 I = 1. 10था , जबकि एक स्टेटमेंट था जिसे वैल्यू 1.1 को वेरिएबल में असाइन किया गया था DO10I। (यह तथ्य कि घोषणा के बिना चरों को बनाया जा सकता है, उनके प्रकार उनके पहले अक्षर के आधार पर, इस में योगदान दिया।) अन्य भाषाओं के विपरीत, अव्यवस्था की अनुमति देने के लिए अलग-अलग टोकन का उपयोग करने के लिए रिक्त स्थान का उपयोग करने का कोई तरीका नहीं था।

इसने अन्य लोगों को भी वास्तव में भ्रमित कोड लिखने की अनुमति दी। कारण है कि FORTRAN की इस सुविधा को कभी दोबारा दोहराया नहीं गया था।

— डेविड थॉर्नले
स्रोत
1
ऐसी भाषा में जहां आप शाब्दिक रूप से सबसे खराब उदाहरणों को फिर से परिभाषित कर सकते हैं - मेरा मतलब है कि यह केवल एक छोटे से अंतरिक्ष यान के दुर्घटनाग्रस्त होने का कारण बना
— मार्टिन बेकेट
आरंभ में, आप आयाम के स्थान पर DAMNATION लिख सकते थे, और यह काम करेगा।
— माइक डनलैवी
यह अभी भी सीएस के बाहर के लोगों द्वारा सिखाया जा रहा है। मुझे अभी भी उन लोगों से निपटना है जो क) घोषणाओं के खिलाफ लड़ते हैं, ख) "निरंतरता की रेखाओं" की तरह सी) के खिलाफ लड़ाई करते हैं, घ) 6-वर्ण नामों का उपयोग करते हैं, या 4, डी) जब वे देखते हैं तो स्टम्प्ड होते हैं (test ? a : b), ई। उपयोग करने पर **, f) केस-सेंसिटिविटी को हैंडल नहीं कर सकता है। यह 50 के दशक में कीपंच के कारण था।
— माइक डनलैवी
1
@ मर्टिन बेकेट - फोरट्रान में शाब्दिक रूप से परिभाषित करना वास्तव में एक भाषा सुविधा के बजाय एक संकलक दोष था। यह निश्चित रूप से एक जानबूझकर भाषा की विशेषता नहीं थी।
— स्टीफन सी
1
@ बूस्टरवाल: मैंने निश्चित रूप से किया। मैं गलत हो सकता हूं, लेकिन मैं पंच कार्ड के आधार पर भाषा की परिभाषा को याद करता हूं। वे फ़ॉरट्रान कार्यक्रमों को फिर से इनपुट करने का मुख्य तरीका थे, और 73-80 आरक्षित स्तंभों के साथ 80-स्तंभ वाली लाइन का विचार पंच कार्डों से है।
— डेविड थॉर्नले
9

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

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

— hotpaw2
स्रोत
2
+1: उचित मॉड्यूल और पुस्तकालयों के बिना कोई भी भाषा गलती होने की प्रतीक्षा कर रही है। COBOL को इस बात का भी सामना करना पड़ा, जो कि अजीब वेरिएंट के लिए अग्रणी है जो संगत नहीं हैं।
— एस.लॉट
8

मैं DSLs (डोमेन-विशिष्ट-भाषाएं) में विश्वास करता हूं और एक भाषा में एक चीज जो मैं महत्व देता हूं, वह है अगर यह मुझे इसके ऊपर एक डीएसएल को परिभाषित करने की अनुमति देता है।

लिस्प में मैक्रोज़ होते हैं - ज्यादातर लोग इसे एक अच्छी बात मानते हैं, जैसे कि मैं।

सी और सी ++ में मैक्रोज़ हैं - लोग उनके बारे में शिकायत करते हैं, लेकिन मैं उन्हें डीएसएल को परिभाषित करने के लिए उपयोग करने में सक्षम था।

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

— माइक डनलवे
स्रोत
4
मैं सहमत हूँ कि सभ्य मैक्रोज़ के बिना कोई भी भाषा एक बहुत बड़ा डिजाइन दोष है। लेकिन were उन्हें छोड़ दिया गया ’से आपका क्या मतलब है ? C प्रीप्रोसेसर किसी भी तरह का एक सभ्य मैक्रो सिस्टम नहीं था। जावा मैक्रोज़ के साथ किसी भी उचित भाषा से व्युत्पन्न नहीं है।
— एसके-लॉजिक
1
आप अपने DSL को बाहरी मैक्रो प्रोसेसिंग लैंग्वेज में लिख सकते हैं (जैसे कि m4, say, दूसरों के असंख्य के बीच)।
— मेरी सही ओपिनियन
4
@ एसके: मैं यह नहीं कहूंगा कि सी प्रीप्रोसेसर लिस्प की तुलना में एक सभ्य मैक्रो सिस्टम है (उदाहरण के लिए)। लेकिन, कुछ भी नहीं की तुलना में , यह बेहद उपयोगी है।
— माइक डनलैवी
4
@reinierpost: मैं उन चीजों के बारे में सोच रहा हूं जो मैं लिस्प में कर सकता हूं, जैसे कि अंतर निष्पादन और बैकट्रैक जैसी नियंत्रण संरचनाओं को पेश करना। ये लिस्प मैक्रोज़ के साथ किया जा सकता है। सी / सी ++ में मैं सी मैक्रोज़ (और थोड़ा प्रोग्रामर अनुशासन) के साथ अंतर निष्पादन कर सकता था, लेकिन पीछे नहीं। C # के साथ मैं न तो कर सकता हूं। बदले में मुझे जो मिलता है वह है इंटेलीजेंस जैसी चीजें। BFD।
— माइक डनलैवी
1
@ डेविड: जिस तरह से मैंने किया था, मैं साधारण कोड के चारों ओर लपेटने के लिए एक मैक्रो था, जैसे कि बयानों की एक सूची। यह cdrसूची में ले जाता है और इसमें से एक लंबोदर क्लोजर बनाता है (यानी एक निरंतरता) और इसे carसूची के तर्क के रूप में पास करता है । यह पुनरावर्ती, निश्चित रूप से किया गया था, और सशर्त, लूप और फ़ंक्शन कॉल के लिए "सही काम करेगा"। फिर "पसंद" फ़ंक्शन केवल एक सामान्य लूप में बदल गया। सुंदर नहीं था, लेकिन यह मजबूत था। समस्या यह है, यह अति-नेस्टेड लूप बनाने के लिए सुपर आसान बनाता है।
— बजे माइक डनलवे
7

कथन , हर भाषा में जो उनके पास है। वे कुछ भी नहीं करते हैं जो आप भावों के साथ नहीं कर सकते हैं और आपको बहुत सारी चीजें करने से रोकते हैं। एक ?:टर्नरी ऑपरेटर का अस्तित्व उनके आस-पास होने का प्रयास करने का सिर्फ एक उदाहरण है। जावास्क्रिप्ट में, वे विशेष रूप से परेशान हैं:

// With statements:
node.listen(function(arg) {
  var result;
  if (arg) {
    result = 'yes';
  } else {
    result = 'no';
  }
  return result;
})

// Without:
node.listen(function(arg) if (arg) 'yes' else 'no')
— उदार
स्रोत
मैं यहां उलझन में हूं: क्या आप चीजों को करने का एक सरल तरीका चाहते हैं?
— TheLQ
2
सही बात। हर चीज के लिए भाव।
— उदार
1
लिस्प इसके लिए अच्छा काम करता है।
— डेविड थॉर्नले
1
@ एसके-तर्क: मुझे संदेह है कि बयानों को मशीन की भाषा से, फोरट्रान, ALGOL और COBOL के माध्यम से प्राप्त किया गया था।
— डेविड थॉर्नले
1
मुझे पूरा यकीन है कि मशीन भाषा आम पूर्वज है, और यह सिर्फ इस तथ्य का प्रतिबिंब है कि वॉन न्यूमैन वास्तुकला पर आधारित आधुनिक कंप्यूटर क्रमिक रूप से निर्देशों को निष्पादित करते हैं और राज्य को संशोधित करते हैं। अंततः जब IO होता है, तो ऐसे भाव होने वाले हैं जो अर्थपूर्ण डेटा नहीं देते हैं, इसलिए कथन पूरी तरह से अर्थपूर्ण संकेत देने में बेकार नहीं हैं कि कुछ कोड के केवल दुष्प्रभाव हैं। यहां तक ​​कि जिन भाषाओं में बयानों के बजाय unitप्रकार (उर्फ ()) की धारणा है, उन्हें यह सुनिश्चित करने के लिए विशेष विचार है कि वे चेतावनी नहीं फेंकते हैं या अन्यथा अजीब व्यवहार करते हैं।
— री मियासका
6

मेरे लिए, यह डिज़ाइन की समस्या है जो C से ली गई सभी भाषाओं की दुर्दशा करती है; अर्थात्, " लटकना बाकी "। इस व्याकरण संबंधी समस्या को C ++ में हल किया जाना चाहिए था, लेकिन इसे जावा और C # में आगे बढ़ाया गया।

— fretje
स्रोत
3
सी ++ के मुख्य लक्ष्यों में से एक सी के साथ पूरी तरह से पिछड़ा होना था। यदि उन्होंने बहुत ही शब्दार्थ व्यवहार को बदल दिया होता तो शायद वह उस तरह से पकड़ में न आता जैसा उसने किया था (या कम से कम, उस समय यही सोचा गया था)
— एड एस
2
@ ईडी एस, हालांकि, "लटकती हुई और" समस्या का उन्मूलन <कंपाउंड_स्टैटमेंट> (उर्फ <ब्लॉक>) व्याकरणिक उत्पादन को समाप्त करके और सशर्त ब्रेसिज़ को सशर्त और पुनरावृत्त नियंत्रण संरचनाओं में शामिल करके किया जा सकता है, जैसे कि उन्होंने जब किया था नियंत्रण संरचना को संभालने की कोशिश / पकड़ अपवाद को जोड़ा। जावा और C # में इस व्याकरणिक अस्पष्टता को ठीक न करने का कोई बहाना नहीं है। वर्तमान में, इस व्याकरणिक अस्पष्टता के लिए आस-पास का रक्षात्मक कार्य हर उस बयान को करना है जो एक सशर्त या पुनरावृत्त नियंत्रण कथन का एक यौगिक कथन करता है।
— बिट-टिड्डर
1
उससे तुम्हारा क्या मतलब है? यह एक "व्याकरणिक समस्या" नहीं है (यह पूरी तरह से अस्पष्ट है)। आप इसे कैसे हल करेंगे? मैं वास्तव में सी संतोषजनक में नियम पाते हैं। यकीनन, केवल पायथन जैसा सिंटैक्स (= सार्थक इंडेंटेशन) वास्तव में इस समस्या को हल कर सकता है। इसके अलावा, मैं वास्तव में बहुत खुश हूं कि आधुनिक भाषाएं ब्रेसिज़ को अनिवार्य नहीं करती हैं । मैं सहमत हूं कि सभी सी-जैसे सिंटैक्स चूसते हैं लेकिन झूलना-झेलना उनकी समस्याओं में से सबसे कम है।
— कोनराड रुडोल्फ
1
जारी रखना: मुझे लगता है कि पायथन का उपयोग एक इंडेंटेशन के रूप में किया जाता है जिसके द्वारा एक बयान सूची को विश्वास से परे अजीब माना जाता है। यह तकनीक वाक्यविन्यास विश्लेषण के साथ कसकर युग्मन स्कैनिंग द्वारा "चिंताओं के अलगाव" सिद्धांत का उल्लंघन करती है। स्रोत के लेआउट के बारे में कुछ भी जाने बिना एक संदर्भ-मुक्त व्याकरण को पार्स किया जा सकता है।
— बिट-ट्विडलर
3
@ बिट-ट्विडलर: नहीं, यह नहीं है। पायथन लेक्सर सिर्फ व्हाट्सएप को उपयुक्त इंडेंट और डेडेंट टोकन में परिवर्तित करता है। एक बार ऐसा करने के बाद, पायथन में एक बहुत ही पारंपरिक व्याकरण ( docs.python.org/reference/grammar.html ) है।
— dan04
6

मुझे लगता है कि अब तक के सभी उत्तर कई मुख्यधारा की भाषाओं की एकल असफलता की ओर इशारा करते हैं:

पिछड़ी अनुकूलता को प्रभावित किए बिना मूल भाषा को बदलने का कोई तरीका नहीं है।

यदि इसे हल किया जाता है, तो बहुत अधिक उन सभी पकड़ को हल किया जा सकता है।

संपादित करें।

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

अंततः मुझे नहीं लगता कि मुझे पता है कि इसे कैसे हल किया जाए जो पूरी तरह से संतोषजनक हो, लेकिन इसका मतलब यह नहीं है कि कोई समाधान मौजूद नहीं है, या ऐसा नहीं किया जा सकता है

— jk।
स्रोत
1
आप इसे "हल" के बारे में कैसे करेंगे?
— बज्कर फ्रायंड-हेन्सन
मुझे यकीन नहीं है कि इसे पूरी तरह से हल किया जा सकता है - जाहिर है कि चीजों को मूल भाषा से बाहर रखना और एक मानक पुस्तकालय में मदद करता है इसलिए मुझे लगता है कि मैं इसे आगे बढ़ाने की कोशिश करूंगा जहां तक ​​यह जा सकता है
— जेके।
1
संगत द्वारा, क्या आपका मतलब है कि नए संकलक पुराने कोड को संकलित करने में सक्षम होना चाहिए?
— री मियासाका
मेरा मतलब है कि नए कंपाइलरों को पुराने कोड के अर्थ को नहीं बदलना चाहिए, संकलन करने में विफल होना उस का सबसेट होगा
— jk।
अधिकांश मामलों में, जब कोई विशेष सुविधा मौजूद नहीं होती है, या बदलना चाहते हैं, तो लोग पिछले एक में आधारित एक नई भाषा बनाते हैं। C कक्षाओं के साथ => C ++
— umlcat
4

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

बाद के एक उदाहरण के रूप में, उस पर विचार करें 

सार्वजनिक स्थैतिक T Parse <T> (टाइप <T> प्रकार, स्ट्रिंग str) जहां T: Enum
साथ या बदलनेवाला 
सार्वजनिक स्थिर ऑब्जेक्ट पार्स (प्रकार प्रकार, स्ट्रिंग स्ट्र)
में Enumवर्ग की अनुमति होगी
MyEnum e = Enum.Parse (टाइपोफ़ (MyEnum), str);
बल्कि तनातनी के बजाय 
MyEnum e = (MyEnum) Enum.Parse (टाइपोफ़ (MyEnum), str);

tl; dr: पैरामीट्रिक बहुरूपता के बारे में सोचें जब आप संस्करण 1 प्रकाशित करने के बाद नहीं, अपने प्रकार की प्रणाली को डिजाइन करना शुरू करते हैं।

— पीटर टेलर
स्रोत
2
Enum में प्रकारों को प्रतिबंधित करने की अक्षमता C # में कष्टप्रद है, लेकिन आप इसके चारों ओर इस तरह का काम कर सकते हैं MyMethod<T>(T value) where T : struct, IComparable, IFormattable, IConvertible लेकिन आपको अभी भी एक enum के लिए परीक्षण करना है और यह एक हैक है। मुझे लगता है कि सी # जेनरिक में बड़ी कमी उच्च प्रकार के लिए कोई समर्थन नहीं है, जो वास्तव में कुछ शांत अवधारणाओं के लिए भाषा को खोल देगा।
— कोडेक्सअर्बनम
4

मुझे लगता है कि मैं अपने आप को आग की लपटों के लिए खोल रहा हूं, लेकिन मुझे सी ++ में संदर्भ द्वारा सादे पुराने डेटा प्रकारों को पारित करने की क्षमता से नफरत है। मुझे केवल संदर्भों द्वारा जटिल प्रकारों को पारित करने में थोड़ी नफरत है। अगर मैं एक समारोह में देख रहा हूँ:

void foo()
{
    int a = 8;
    bar(a);
}

कॉलिंग पॉइंट से, यह बताने का कोई तरीका नहीं है bar, जिसे पूरी तरह से अलग फ़ाइल में परिभाषित किया जा सकता है:

void bar(int& a)
{
    a++;
}

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

bar(&a);

बहुत अधिक पठनीय है।

— जेफ
स्रोत
+1 मैं आपसे सहमत नहीं हूं, लेकिन मैं आपके तर्क की सराहना करता हूं।
— जॉन पूर्डी
@ मैं वास्तव में आप क्या सोचते हैं पर बहुत दिलचस्पी होगी। क्या आप "भाषा को दोष नहीं देते" दृश्य रखते हैं?
— जेफ
6
@ जेफ: एक बात के लिए, शब्दार्थ को सी ++ में प्राथमिक कारण ऑपरेटर ओवरलोडिंग था, जिसके लिए समान संदर्भ व्यवहार बस समझ में आता है। अधिक महत्वपूर्ण बात, हालांकि, C ++ को बहुमुखी बनाने के लिए डिज़ाइन किया गया है और प्रोग्रामर त्रुटि के महत्वपूर्ण जोखिम को बढ़ाता है, भले ही यह बहुत ही बढ़िया सुविधाएँ प्रदान करता हो। तो हाँ, कम से कम इस विशेष मामले में, भाषा को दोष न दें। मैं इसके बजाय गलतियाँ करने में सक्षम होना चाहूंगा कि कोई भाषा मेरे रास्ते में आए।
— जॉन पूर्डी
@ जॉन ने सहमति व्यक्त की, यह POD के अलावा हर चीज पर लागू होने के संदर्भ में पास के लिए बहुत अजीब होगा। अगर यह सुविधा पूरी तरह से C ++ से एक विकल्प के रूप में गायब थी, तो हम इसे पसंद करेंगे, लेकिन हम इससे सहमत नहीं हो सकते :)। इनपुट के लिए धन्यवाद!
— जेफ
लगता है कि जावा आपको पॉइंटर्स जितना पसंद नहीं है।
— मतीन उल्हाक
4

ALTER

जब मैंने COBOL सीखा, तो ALTER स्टेटमेंट अभी भी मानक का एक हिस्सा था। संक्षेप में, यह कथन आपको रनटाइम के दौरान प्रक्रिया कॉल को संशोधित करने की अनुमति देगा।

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

मेरे विश्वविद्यालय के प्रशिक्षक ने बहुत जोरदार ढंग से कहा कि अगर उन्होंने कभी भी हमारे किसी भी कार्यक्रम में वह बयान देखा है तो वह स्वतः ही हमें भड़का देगा।

— oosterwal
स्रोत
हालांकि इसके उपयोग के मामले अच्छे हैं - स्टबिंग या मेमोइज़ेशन। लिखने के बजाय v() { if (not alreadyCalculatedResult) { result = long(operation); alreadyCalculatedResult = true; } result; }आप कहते हैंv() { result = long(operation); v = () => result; result; }
— विन्यासकर्ता
4

एक प्रोग्रामिंग भाषा के सबसे खराब पाप को अच्छी तरह से परिभाषित नहीं किया जा रहा है। एक मामला जो मुझे याद है वह है C ++, जो अपने मूल में है:

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

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

कुछ और मैं एक पाप पर विचार करता हूं (क्या यह एक अलग जवाब में जाना चाहिए?) कुछ सामान्य कार्य करने के लिए एक से अधिक "सबसे अच्छा" तरीका है। यह (फिर से) सी ++, पर्ल, और रूबी का मामला है।

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

C ++ में कक्षाएं भाषा में कुछ प्रकार के मजबूर डिज़ाइन पैटर्न हैं।

एक संरचना और एक वर्ग के बीच रनटाइम पर व्यावहारिक रूप से कोई अंतर नहीं है, और यह समझने के लिए इतना भ्रामक है कि "सूचना छिपाने" का वास्तविक वास्तविक प्रोग्रामिंग लाभ क्या है जो मैं इसे वहां रखना चाहता हूं।

मैं उस के लिए नीचा दिखाया जा रहा हूँ, लेकिन वैसे भी, सी ++ संकलक इतना कठिन है कि इस भाषा को एक राक्षस की तरह लगता है।

— jokoon
स्रोत
2
जानकारी छिपाना महत्वपूर्ण है क्योंकि यह आपको कार्यान्वयन के विशिष्ट विवरणों को छिपाने की अनुमति देता है, जो एपीआई के सुलभ भागों (एपीआई के "यूआई") से बदलने की संभावना है, इस प्रकार कार्यक्रम में परिवर्तन करना आसान और कम दर्दनाक हो जाता है।
— Anto
1
एपीआई के यूआई ... नहीं, गंभीरता से, मैं इसे नहीं खरीदता।
— जोक
3
यह अंतर C ++ का सबसे विद्रोही हिस्सा नहीं है, करीब भी नहीं। एकमात्र अंतर एक डिफ़ॉल्ट एक्सेस संशोधक है (स्ट्रक्चर्स के लिए सार्वजनिक, कक्षाओं के लिए निजी)। C ++ एक भयानक, राक्षसी भाषा है, लेकिन निश्चित रूप से इस भाग में नहीं है।
— तर्क
sk- तर्क: ठीक है, मैं कह सकता हूँ कि भयावहता वहाँ शुरू होती है।
— जौकून
2
जानकारी छिपाना अच्छा है; आप उस पर चर्चा कर सकते हैं। एकमात्र प्रमुख सॉफ्टवेयर पुस्तक, जिसके बारे में मैं सोच सकता था कि वह ब्रूक्स की "द मैथिकल मैन-मंथ" थी, और उन्होंने बाद में इसे पुस्तक की सबसे बड़ी गलती माना। यदि आप फायदे नहीं समझते हैं, तो आप वास्तव में निर्णय लेने के लिए योग्य नहीं हैं।
— डेविड थॉर्नले
3

हालाँकि हर भाषा में इसके दोष होते हैं, लेकिन कोई भी उपद्रव नहीं करता है, क्योंकि आप उनके बारे में जानते हैं। इस जोड़ी को छोड़कर:

कॉम्प्लेक्स सिंटैक्स एक वर्डी एपीआई के साथ युग्मित होता है

यह विशेष रूप से Objective-C जैसी भाषा के लिए सही है। न केवल वाक्यविन्यास अत्यधिक जटिल है, लेकिन एपीआई फ़ंक्शन नामों का उपयोग करता है जैसे:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

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

— दिमित्रि
स्रोत
उद्देश्य-सी सिंटैक्स अत्यधिक जटिल है? क्या आपने C ++ नहीं देखी है? और वहाँ वास्तविक विधि का नाम है tableView:cellForRowAtIndexPath:, जो मेरी राय में बहुत वर्णनात्मक है।
— rightfold
टच-टाइप करना सीखें।
— फाइनेंन नोव
2
  1. सी में हस्ताक्षर किए गए चार्ट - गणितज्ञों को छोटी वस्तुओं के बड़े संग्रह को बताने के लिए आविष्कार किया गया एक घृणा
  2. शब्दार्थ सामग्री को ले जाने के लिए मामले का उपयोग करना - गणितज्ञों के लिए फिर से, जिन्हें बात करने की आवश्यकता नहीं है , और उनके सूत्रों के लिए पर्याप्त जगह नहीं है
  3. आज्ञा देना / सादा असाइनमेंट बनाम सेट असाइनमेंट बेसिक बोलियों में - यहाँ कोई गणितज्ञ शामिल नहीं है जो मुझे लगता है
— Ekkehard.Horner
स्रोत
मैं आपके हस्ताक्षरित वर्ण टिप्पणी के अनुसार खो गया हूं, क्या आप समझा सकते हैं?
— विंस्टन इर्वर्ट
1
मानव के लिए, (संयुक्त राष्ट्र) की अवधारणा पर हस्ताक्षर किए गए चरों और संकलित वर्णों को डिफ़ॉल्ट रूप में उपयोग करने के लिए बताने की आवश्यकता निश्चित रूप से सिर्फ गणितज्ञ के रूप में पागल है जैसा कि दावा है कि 2! = 2, क्योंकि दूसरा 2 अपरकेस है, बोल्ड! , या इटैलिक
— एक्केहार्ड। हॉर्नर
5
समस्या यह है कि सी "चार" (यानी, एक पाठ स्ट्रिंग का हिस्सा) और "बाइट" (यानी, (u)int_least8_t) की अवधारणा को भ्रमित करता है । सांकेतिकता छोटे पूर्णांकों के लिए सही अर्थ बनाती है, लेकिन पात्रों के लिए बिल्कुल भी समझ में नहीं आती है।
— dan04
@ dan04: मैं सहमत हूं, मेरी इच्छा है कि उनके पास छोटे पूर्णांक (हस्ताक्षरित और अहस्ताक्षरित), बाइट और चरित्र के लिए विभिन्न प्रकार हों। जब आप newbies को समझाते हैं कि कच्ची मेमोरी में हेरफेर करने के लिए उन्हें एक char*... सी-स्ट्रिंग की तरह डालने की जरूरत है , तो वे वास्तव में भ्रमित हो जाते हैं।
— Matthieu M.
सी # अलग के साथ इस अधिकार मिल गया sbyte, byteऔर charप्रकार के।
— dan04
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.