एक साक्षात्कार के दौरान उत्तर देने के लिए प्रश्न "C # के बारे में पांच चीजें जो आप से नफरत करते हैं" क्यों इतना मुश्किल है? [बन्द है]


32

में पॉडकास्ट 73 , योएल Spolsky और जेफ Atwood पर चर्चा, अन्य विषयों के बीच, "पाँच बातें हर कोई अपने पसंदीदा प्रोग्रामिंग भाषा के बारे में नफरत चाहिए":

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

जिज्ञासु होने के नाते, मैंने किसी भी उम्मीदवार से यह सवाल पूछा जिसका मैंने साक्षात्कार किया था। उनमें से कोई भी सी # # के बारे में कम से कम एक चीज का उद्धरण देने में सक्षम नहीं था।

क्यूं कर? इस सवाल में इतना मुश्किल क्या है? यह साक्षात्कार के तनावपूर्ण संदर्भ के कारण है कि यह प्रश्न साक्षात्कारकर्ताओं द्वारा उत्तर देना असंभव है?

क्या इस सवाल के बारे में कुछ है जो एक साक्षात्कार के लिए बुरा बनाता है?


जाहिर है, इसका मतलब यह नहीं है कि C # सही है। मेरे पास सी # से नफरत करने वाली पांच चीजों की एक सूची है:

  • जेनरिक में प्रकारों की चर संख्या का अभाव ( paramsतर्कों के समान )।
    Action<T>,
    Action<T1, T2>,
    Action<T1, T2, T3>,
          ⁞ गंभीरता से ?!
    Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>

  • एफ # की तरह, माप की इकाइयों के लिए समर्थन की कमी।

  • केवल पढ़ने की कमी गुण। private readonlyहर बार एक बैकिंग फ़ील्ड लिखना, मैं चाहता हूं कि केवल पढ़ने के लिए संपत्ति उबाऊ हो।

  • डिफ़ॉल्ट मान वाले गुणों की कमी। और हां, मुझे पता है कि मैं उन्हें पैरामीटर रहित कंस्ट्रक्टर में इनिशियलाइज़ कर सकता हूं और अन्य सभी कंस्ट्रक्टर्स से कॉल कर सकता हूं। लेकिन मैं नहीं करना चाहता।

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

मुझे पूरा यकीन है कि यह सूची पूरी होने से बहुत दूर है, और हाइलाइट करने के लिए बहुत अधिक बिंदु हैं, और विशेष रूप से मेरे मुकाबले बहुत बेहतर हैं।


Framework कुछ लोगों ने .NET असेंबली में कुछ असेंबली की आलोचना की या फ्रेमवर्क में कुछ लाइब्रेरी की कमी या CLR की आलोचना की। यह मायने नहीं रखता है, क्योंकि सवाल भाषा के बारे में ही था, और जबकि मैं संभावित रूप से .NET फ्रेमवर्क के मूल में कुछ नकारात्मक के बारे में एक उत्तर को स्वीकार कर सकता था (उदाहरण के लिए कुछ इस तथ्य की तरह कि कोई सामान्य इंटरफ़ेस नहीं है TryParse, इसलिए यदि आप कई प्रकारों के लिए एक स्ट्रिंग पार्स करना चाहते हैं, आपको हर प्रकार के लिए खुद को दोहराना होगा), JSON या WCF के बारे में एक उत्तर पूरी तरह से विषय से दूर है।


52
Why the question “give five things you hate about C#” is so difficult to answerक्योंकि यह एक सूची का सवाल है, और एक दुष्ट मॉड इसे "
जवाबदेह

6
@ यानिस रिज़ोस: अच्छी बात है। BTW, जब एक शीर्षक में इस प्रश्न को टाइप करते हुए, स्टैक ओवरफ्लो चेतावनी देता है कि "आप जो प्रश्न पूछ रहे हैं वह व्यक्तिपरक प्रतीत होता है और बंद होने की संभावना है।"
बजे आर्सेनी मौरज़ेंको

5
शायद प्रोग्रामिंग भाषाओं से नफरत करने वाली चीजों के लिए आपके मस्तिष्क का भंडारण स्थान ज्यादातर उन अन्य भाषाओं के पहलुओं से भरा होता है जिनसे आपको निपटना पड़ता है।
whatsisname

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

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

जवाबों:


42

अगर मुझे अनुमान लगाना होता:

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

  2. कुछ प्रोग्रामर केवल कोड बंदर हैं। वे मुश्किल से अपने सामने की समस्याओं का विश्लेषण करते हैं, अकेले कुछ ऐसा करते हैं कि कैसे उनकी प्रोग्रामिंग भाषा बेहतर हो सकती है।

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

  4. कम से कम इधर-उधर, अत्यधिक आलोचनात्मक होना एक घातक व्यक्तित्व दोष के रूप में देखा जाता है। इसके बजाय 'वह आनंदमय डेवलपर जो हमेशा चीजों को करने के बेहतर तरीकों की तलाश में रहता है' (जैसे कुछ क्षेत्रों में मैं रहता हूं), वे 'वह गधे हैं जो हर चीज से नफरत करते हैं'। यहां तक ​​कि वे लोग जो भाषा में घृणा करते हैं, वे कम तीखा लगने के लिए एक साक्षात्कार सेटिंग में स्थगित कर सकते हैं।


22
नहीं 2 के लिए, हम सॉफ्टवेयर सिमीयन , सर पसंद करते हैं ।
toniedzwiedz

@ मुझे लगता है कि यह पैन प्रोग्राममेरीबस था ।
स्टेफानो बोरीनी

9
@Telastyn आपके उत्तर में पाँच बुलेट पॉइंट नहीं होने चाहिए ?
बेन जैक्सन

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

35

मैं कल्पना करूँगा कि साक्षात्कार के दौरान प्रश्न का उत्तर देना बहुत कठिन है क्योंकि यह है:

  1. वास्तव में अप्रत्याशित,

  2. एक साक्षात्कार के दौरान उपयोग की जाने वाली सोच से बहुत अलग सोच की आवश्यकता होती है,

  3. सामान्य रूप से कम समय में जवाब देना मुश्किल है (जब तक कि साक्षात्कार से पहले तैयार न हो)।

1. यह अप्रत्याशित है

अप्रत्याशित प्रश्न वास्तव में कठिन हैं, विशेष रूप से एक तनावपूर्ण संदर्भ में। एक साक्षात्कार के दौरान निम्नलिखित संवाद की कल्पना करें:

- बीच क्या अंतर है HashSet<T>और List<T>?
- हैशसेट को इस तरह से अनुकूलित किया जाता है कि किसी तत्व की खोज बहुत तेज हो। उदाहरण के लिए यदि आप set.Contains()बहुत बार लूप के भीतर उपयोग कर रहे हैं , तो setसूची से हैशसेट में जाने से चीजें तेज हो सकती हैं।
- आप केवल पढ़ने के लिए संपत्ति कैसे बनाते हैं?
- मैं readonlyएक संपत्ति के लिए एक बैकिंग फ़ील्ड के रूप में चिह्नित फ़ील्ड का उपयोग करता हूं, जिसमें केवल एक गेटर है।
- का उपयोग क्या है sealed?
- आप इसे उन वर्गों के लिए उपयोग करते हैं जिन्हें विरासत में नहीं मिलना चाहिए।
- आखिरी बार आपने डेंटिस्ट को क्या देखा है?
- क्या?!

2. इसके लिए काफी अलग सोच की जरूरत होती है

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

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

3. इसके लिए समय चाहिए

सच कहूं, तो मेरे पास सी (# वास्तव में अधिक) चीजों की मेरी सूची है जो मुझे सी # के बारे में नफरत है, लेकिन मैंने इसके बारे में लंबे समय से सोचा था। कुछ चीजें .NET फ्रेमवर्क 2 युग से हैं; .NET फ्रेमवर्क 2 के लिए मैंने जिन अधिकांश मुद्दों को सूचीबद्ध किया है, वे अब मान्य नहीं हैं क्योंकि उन्हें हटा दिया गया था, कुछ LINQ और इस सभी कार्यात्मक प्रोग्रामिंग सामान, गतिशील प्रोग्रामिंग के साथ अन्य। मुझे यकीन नहीं है कि, इस सवाल को तैयार किए बिना, मैं एक साक्षात्कार के दौरान सभी पांच तत्वों को ढूंढने में सक्षम हूं।


3
मुझे लगता है कि आप आम तौर पर सही हो, लेकिन पर्याप्त समय के लिए एक निश्चित भाषा में प्रोग्रामिंग बस जाएगा बनाने के आप इसके बारे में कुछ 'विशेषताओं' से नफरत है। जैसे किसी तरह की हिट लिस्ट। या कम से कम मेरे पास मेरे द्वारा उपयोग की जाने वाली प्रत्येक भाषा / मंच के लिए एक है। या हो सकता है कि मैं सिर्फ खराब और अशिष्ट हूं।
K.Steff

2
@ K.Steff: "हिट-लिस्ट" इसका एक सही नाम है :)। मैं निश्चित रूप से अपने पसंदीदा मंच के साथ पांच से अधिक समस्याओं के बारे में सोच सकता हूं; यदि आप मुझसे ऐसी भाषा के बारे में पूछते हैं जो मुझे पसंद नहीं है , लेकिन उपयोग करने के लिए मजबूर किया गया है (उदाहरण के लिए जावा या पायथन) तो मैं शायद घंटों तक चला जा सकता हूं: पी।
तिखन जेल्विस

1
क्या आप उन चीजों को आसानी से याद रख सकते हैं जिनसे आप किसी भाषा में घृणा करते हैं, यह इस बात पर निर्भर करेगा कि those अजीबोगरीब ’अन्य चीजों से कितनी परेशान हैं, जिनसे आपको निपटना है। उदाहरण के लिए, मेरे अधिकांश कार्यों में एक निश्चित (और विशेष रूप से भयानक) विदेशी प्रणाली और उसके एपीआई के साथ बातचीत करना शामिल है। तुलना में C # /। NET के बारे में सबसे अधिक पकड़ है और मेरे दिमाग के पीछे धकेल दिया जाता है।
डैन लियोन

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

21

मुझे लगता है कि पांच शब्द के कारण यह मुश्किल है । और कुछ हद तक, नफरत शब्द के कारण ।

पाँच ? क्या होगा यदि आप केवल चार के साथ आते हैं? क्या आप प्रश्न का उत्तर देने में विफल रहे हैं? यदि आपके पास पाँच से अधिक है तो क्या होगा ? अब, मौके पर, आपको यह पता लगाना है कि उनमें से कौन सा उपयोग करने के लिए सबसे अच्छा पांच हैं।

नफरत एक बहुत ही नकारात्मक शब्द है। यह इस तरह की नकारात्मकता है कि लोगों को साक्षात्कारों में बचने के लिए कहा जाता है। इसके अलावा, मुझे लगता है कि यह है कि बहुत सी बातें वे "नफरत" एक भाषा वे में पूरे दिन प्रोग्रामिंग खर्च हो जाएगा के बारे में है करने के लिए बहुत से लोगों को करने के लिए अजीब लगेगा कुछ लोगों को भी यह एक चाल सवाल है सोच सकते हैं:। यदि वे वास्तव में करते आ पांच चीजों के साथ, वे C # से घृणा करने के लिए अयोग्य घोषित कर दिए जाएंगे। बहुत अच्छी तरह से प्रोग्राम करने के लिए। दुर्भाग्य से, इस तरह के विकृत चाल सवाल साक्षात्कार में अनसुना नहीं है।

इसके बजाय, आप पूछ सकते हैं कि आप C # के बारे में क्या सुधार करेंगे अगर यह आपके ऊपर था? यह साक्षात्कारकर्ता को किसी भी संख्या में चीजों के साथ जवाब देने की अनुमति देता है। यह वाक्यांशिंग अपेक्षाकृत सकारात्मक "सुधार" के लिए "घृणा" शब्द की नकारात्मकता को भी दर्शाता है।


2
"पाँच" के खिलाफ आपकी बात एक अच्छी है - बहुत से लोगों को संभवतः अलग-अलग डिग्री में नापसंद चीजों का एक निरंतरता होगी, लेकिन एकमात्र तरीका वे यह तय कर सकते थे कि कौन सी चीजें शीर्ष पांच का प्रतिनिधित्व करती हैं, वह सब कुछ रैंक करने के लिए होगा जो करीब हो सकता है। अगर किसी को अभी हाल ही में किसी ऐसी चीज से परेशानी है जो आम तौर पर मामूली झुंझलाहट है, तो उन्हें यह पता लगाने के लिए थोड़ी देर सोचना पड़ सकता है कि क्या यह वास्तव में शीर्ष पांच में शामिल होना चाहिए, या अगर यह सिर्फ दिमाग में आया क्योंकि यह हाल ही में एक मुद्दा था। इसके अलावा, C # को .NET के साथ इतना इंटरवेट किया गया है कि यह कहना मुश्किल है कि किस पर क्या दोष लगाया जाए। उदाहरण के लिए ...
17

1
... मैं कहता हूं कि सभी भाषाओं को यह गारंटी देनी चाहिए कि यदि कोई कंस्ट्रक्टर फेंकता है, तो आंशिक रूप से निर्मित ऑब्जेक्ट मिलेगा Disposed, लेकिन एक आवश्यकता अनुपस्थित है कि सभी भाषाएं लागू करती हैं, एक यह तर्क दे सकता है कि जो भाषाएं ऐसा करती हैं वे झूठी उम्मीदों को आमंत्रित करेंगे। इस प्रकार यह स्पष्ट नहीं हो सकता है कि क्या सी # कंस्ट्रक्टर विफलता पर संसाधन लीक से बचने की कठिनाई को सी # या सीएलएस पर दोषी ठहराया जाना चाहिए।
सुपरकैट

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

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

दूसरे शब्दों में, देखें- Sharpers यह बहुत अच्छा है, सभी बातों पर विचार किया।

यहाँ मेरी सूची है:

  • लैम्ब्डा स्टेटमेंट्स वाट्सएप / मूल्यांकन योग्य नहीं हैं । वीएस के क्विकवॉच में नामित विधियों को कॉल किया जा सकता है। तो भाव हो सकते हैं। लेकिन लंबोदर? नहींं (कम से कम VS2010 में नहीं)। Linq श्रृंखला को एक असली नृत्य की डिबगिंग बनाता है।

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

  • सी # गंभीर विरासत कोड समस्याओं के लिए काफी पुराना हो रहा है । मूल रूप से 1.1 के लिए लिखे गए कोड से भयावहता में 4.0 करने के लिए किसी को भी इस्तेमाल किया जाएगा। यहां तक ​​कि 2.0 कोड बहुत याद आती है। उसी समय, तृतीय-पक्ष पुस्तकालय आ गए हैं, जिससे ADO.NET जैसी चीजें विकट रूप से आदिम लगती हैं (और ADO.NET के "कनेक्टेड मॉडल" का एक बहुत बड़ा प्रतिमान है)। फिर भी, पश्चगामी-अनुकूलता के लिए, इस पुराने, बुरे कोड के लिए .NET schleps के साथ, कुछ भी कहने की हिम्मत नहीं है "ArrayList यह करने के लिए एक भद्दा तरीका था, हमें खेद है कि हम इसे कभी भी डाल सकते हैं और हम ले रहे हैं इसका उपयोग करें, इसके बजाय सूची का उपयोग करें और यदि आपको बिल्कुल भिन्न प्रकार की सूची की आवश्यकता है, तो इसे घोषित करें List<Object>

  • गंभीरता से सीमित स्विच स्टेटमेंट नियम । संभवतः पावरबुलस्ट के बारे में मैं कह सकता हूं कि सबसे अच्छी चीजों में से एक यह है कि चुनिए केस स्टेटमेंट (स्विच के बराबर) ने बूलियन अभिव्यक्तियों को चर पर आधारित अनुमति दी। इसने कोड स्टेटमेंट्स को कोड के माध्यम से भी गिरने दिया। मैं उन कारणों को समझता हूं कि क्यों दूसरे को अस्वीकृत किया गया है (यह उद्देश्य पर अनजाने में किए जाने की अधिक संभावना है), लेकिन यह अभी भी समय-समय पर एक बयान लिखने के लिए अच्छा होगा:

    switch(someInt)
    {
        case < 0: //all negative values enter here
           //...
           break;
        case 0: 
           //...
           break;
        case 1:
           //...
           //no break; continue through to the code for > 1
        case > 1 // all positive values enter here (including 1)
           //...
           break;
    }
  • कोई इनुमेरिक इंटरफ़ेस नहीं । यदि यह एक संख्या है, तो आप इसके साथ गणित कर सकते हैं। कई मामलों में वास्तविक विधि की परवाह नहीं की जाती है कि किस प्रकार के प्लग इन हैं; परिशुद्धता कॉलर की जिम्मेदारी है। फिर भी एक सामान्य विधि या वर्ग बनाना संभव नहीं है जो केवल जीटीपी के रूप में संख्या प्रकार स्वीकार कर सकता है।

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

4
जेनरिक और कंटेनरों पर बिट - सुपरिक्स के साथ उपयोगी उदाहरण और जेनेरिक में फैली अस्पष्टता के साथ? इसे थोड़ा समझाता है। निरुपित करने Bag<Fruit> bag = Bag<Huckleberry>का मतलब होगा कि आप ऐसा कर सकते हैं bag.add(new Watermelon())जो इसे पकड़ नहीं सकता है।

4
No INumeric के लिए +1। दुर्लभ, लेकिन कष्टप्रद।
6

मान लीजिए Thing<out T>कि एक स्थिर क्षेत्र है जो एक इंस्टेंस विधि और एक स्टैटिक विधि द्वारा पहुँचा जाता है। यदि किसी Thing<Cat>विधि से अपेक्षा की जाती है Thing<Animal>, और वह विधि Thing<Animal>संदर्भ पर पूर्वोक्त उदाहरण और स्थिर विधियों को कहती है , तो उन विधियों का किस स्थैतिक क्षेत्र में प्रवेश करना चाहिए?
सुपरकैट

11

मेरा सुझाव है कि समस्या का हिस्सा एक बुरा जवाब देने से डरता है - आप कहते हैं कि आप एक्स से नफरत करते हैं, साक्षात्कारकर्ता एक्स से प्यार करता है या सोचता है कि एक्स से नफरत करने का आपका कारण मूर्खतापूर्ण है, यह कहना कि आपको लगता है कि यह ठीक है कम विवादास्पद विकल्प लग सकता है।

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


7

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

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


1
+1 फाइव डराने वाला है, इस कारण से 1 या 2 को शायद अधिक उत्तर मिलेंगे।
लॉरेंट कौविदो

2
नफरत एक सीमा से काफी अलग है ......
मैट्नज़

4

यह नीचे आता है जैसे आपने कहा कि C # और / या अन्य भाषाओं के संपर्क में कमी के साथ गहराई के अनुभव की कमी है। मैंने कई डेवलपर्स का साक्षात्कार लिया है जो खुद को वरिष्ठ मानते थे जो कुछ सवालों के जवाब नहीं दे सके थे कि यहां तक ​​कि सी # की सतह पर एक हल्का खरोंच भी उन्हें प्रकट करना चाहिए था।

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

  1. अपरिवर्तनीय वस्तुओं को बनाने के लिए बहुत अधिक समारोह की आवश्यकता होती है (एक कार्यात्मक भाषा के विपरीत जहां ऑब्जेक्ट डिफ़ॉल्ट रूप से अपरिवर्तनीय होते हैं)।
  2. मेटाप्रोग्रामिंग करना मुश्किल है। लिस्प मैक्रोज़ के प्रकार की तुलना करें। (कंपाइलर सर्विसेज इसके आगे बढ़ने में बहुत मदद करेगी)।
  3. विस्तार के तरीके महान हैं ... विस्तार गुण और विस्तार ऑपरेटर (विशेष रूप से निहित और स्पष्ट ऑपरेटर) बेहतर होंगे।
  4. रन-टाइम के बजाय संकलित समय पर स्पष्ट कास्ट को हल किया जाता है।
  5. फंक्शन ओवरलोडिंग की तुलना में कोई सीक्वेंस मैचिंग इतना साफ नहीं है।

मैं आपके पहले दो बिंदुओं से सहमत हूं, लेकिन मैं एक विस्तार अंतर्निहित रूपांतरण के विचार से झकझोरता हूं।
कोडइन्चौस

3

मुझे लगता है कि वह कह रहा है के बारे में अपने दौर में; अगर आपको लगता है कि यह टूट गया है तो आप शायद यह नहीं समझ पा रहे हैं कि यह ऐसा क्यों है। आपके ज्ञान में छेद हो सकता है।

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


मेरा तर्क है कि यह हमेशा ऐसा नहीं होता है। जैसे, डगलस क्रॉकफोर्ड "जावास्क्रिप्ट: द गुड पार्ट्स" में कहते हैं कि आपको भाषा की कुछ विशेषताओं से बचना चाहिए, और मुझे नहीं लगता कि उनका मतलब है कि वे उपयोग करने के लिए 'बहुत कट्टर' हैं।
K.Steff

10
मुझे लगता है कि वह इसके विपरीत कह रहा है - अगर आपको लगता है कि एक मंच किसी भी तरह से टूटा नहीं है , तो आप इसे अच्छी तरह से नहीं जानते हैं। यही है, उसकी बात यह है कि जब तक आप इसकी कमियों के प्रति अंधे नहीं हो जाते तब तक एक ही मंच पर रहना ठीक है।
तिकोन जेल्विस

3

वे जवाब देने में अनिच्छुक हो सकते हैं क्योंकि वे इस धारणा के तहत हो सकते हैं कि यदि वे 5 चीजों को सूचीबद्ध कर सकते हैं जो वे एक भाषा के बारे में नफरत करते हैं तो साक्षात्कारकर्ता गोल हो सकता है और कह सकता है कि ओह, हम सी # 'निन्जा' की तलाश कर रहे हैं और आप नहीं लगते हैं यदि आप भाषा पसंद नहीं करते हैं, तो आपने 'या' भाषा के लिए आवेदन क्यों किया? '

साक्षात्कार के दौरान सकारात्मक रहने के लिए साक्षात्कार बहुत दबाव में हैं।


अगर मैं किसी भाषा में कुछ नफरत करता हूं, तो इसका मतलब यह नहीं है कि मैं भाषा से नफरत करता हूं। इस प्रश्न <del> कर सकते हैं </ del> एक सकारात्मक तरीके से भी जवाब दिया जाना चाहिए। अगर हमें HTML4 में कुछ भी नफरत नहीं है, तो हमें HTML5 की आवश्यकता क्यों है? :)
ई-एमईई

3

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

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

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

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

और जब आप C # पर वापस आते हैं, तो आप इस तरह होंगे, "मुझे इस सरल कार्य को करने के लिए C # की एक सौ लाइनों की आवश्यकता क्यों है? हास्केल में सिर्फ एक लाइन है?"। आपको C # के बारे में बहुत सारी चीजों से नफरत होगी।

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

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

हां, सवाल का जवाब देना मुश्किल है, खासकर एक साक्षात्कार के दौरान। लेकिन जो लोग इसका जवाब दे सकते हैं, वे साबित कर सकते हैं कि उन्होंने इसके बारे में सोचा है, कि उनके पास कुछ दृष्टिकोण है।


+1। बहुत बढ़िया बिंदु। दरअसल, C # से मुझे बहुत नफरत है, इस तथ्य से आती है कि अन्य भाषाओं में समान कमियां नहीं हैं। असली ट्यूपल्स की कमी (यानी (a, b) = this.something();पायथन की तरह करने की असंभवता ) पहली बात है जो मेरे दिमाग में आती है।
बजे आर्सेनी मूरज़ेंको
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.