क्या सॉफ्टवेयर इंजीनियरों को अब निम्न स्तर के सामान को जानने की आवश्यकता है? [बन्द है]


23

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

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


कितना सीखना पर्याप्त है? यदि हम बहुत कम स्तर के सामान सीखते हैं, तो हम अंततः इलेक्ट्रिकल इंजीनियरिंग में अधिक उन्मुख हो जाएंगे या यदि हम बहुत अधिक गणित सीखते हैं, तो हम गणितज्ञ बनना सीख सकते हैं, न कि प्रोग्रामर। मैं सिर्फ यह जानना चाहता हूं कि क्या मैथ स्टफ मैंने सीखा है (मैंने एक मैथ कोर्स लिया है जो इस पुस्तक के समान सामग्री को कवर करता है (उन्होंने अलग-अलग टेक्स्ट बुक का उपयोग किया है): डिसक्रीट मैथमेटिक्स और इसके एप्लिकेशन) वास्तव में हमारे प्रोग्रामिंग कौशल सेट के रूप में उपयोगी हैं। कई गणित अभ्यासों को करने में हमें अधिकांश घंटों का समय लग सकता है, और यदि आप इसके साथ गंभीर हैं, तो आपके पास प्रोग्रामिंग का अध्ययन करने के लिए कम समय होगा। हमारे gamedev फोरम में, यहां तक ​​कि Math और Physics के पास प्रोग्रामिंग से तुलना करने के लिए केवल एक ही खंड है।

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


1
"C / C ++ और Java के बीच प्रदर्शन महत्वपूर्ण नहीं होगा"। अगर ऐसा होता है तो कृपया मुझे अपने जावा कौशल को संशोधित करने के लिए एक पीएम भेजें। मैंने उन कारणों से कुछ साल पहले जावा का उपयोग करना बंद कर दिया है।
साकिस

3
अधिकांश C / C ++ कोड हार्डवेयर का उपयोग नहीं करता है। यह आसान बनाता है, लेकिन यह आमतौर पर डिवाइस ड्राइवरों द्वारा छिपाया जाता है। मैं यहां तक ​​कहना चाहूंगा कि 95% + C या C ++ कोड कभी भी हार्डवेयर के साथ सीधे इंटरैक्ट नहीं करता है।
पेमदास

1
मैं शीर्षक को निम्न स्तर की भाषाओं में बदलने का सुझाव दूंगा। निम्न स्तर की बहुत सी चीजें हैं (थ्रेड कैसे काम करते हैं .. आपका ओएस कैसे काम करता है .. इत्यादि) और आगे भी) जिसका अभी भी मूल्य है, भले ही C ++ या असेंबली का पता न हो।
शेन

2
@ अल्फा, लंबे समय तक चलने वाले अनुप्रयोगों के लिए, एक जावा ऐप सी / सी ++ ऐप के साथ तालमेल रख सकता है। जावा के बाद गर्म हो गया है। यह समय के साथ-साथ जावा कोड को देशी कोड में पुनः स्थापित करने वाली हॉट-स्पॉट तकनीक के कारण है। हालाँकि, कम चलने वाले अनुप्रयोगों के लिए, जावा का स्टार्ट-अप समय अभी भी भयावह है। कुछ बिंदुओं पर, विशेष रूप से सर्वर ऐप्स के लिए, वास्तविक प्रसंस्करण की तुलना में संचार आपकी अड़चन अधिक है।
बेरिन लोरिट्श

1
@BerinLoritsch जावा अपेक्षाकृत तेज़ है, हाँ, लेकिन मेमोरी ओवरहेड, रनटाइम लाइब्रेरी ओवरहेड, निम्न-स्तरीय हार्डवेयर तक पहुँच, और दौड़ने से पहले VM प्री-कॉन्फ़िगरेशन (उदाहरण के लिए, अलग-अलग हीप सीमाएँ प्राप्त करने के लिए) सभी भयानक हैं, तुलना में बस एक निम्न-स्तरीय कार्यक्रम, OS पर चल रहा है। यह सभी परिमाण के एक ही क्रम में निर्देशों को निष्पादित करने के बारे में नहीं है।

जवाबों:


18

दिलचस्प सवाल। मैं लंबे समय से C ++ प्रोग्रामर हूं, जो अब C # में काम कर रहा है (प्रदर्शन महत्वपूर्ण काम के लिए अप्रबंधित C ++ के साथ), और ऐतिहासिक रूप से प्रदर्शन के कारणों के लिए आमतौर पर असेंबली कोड को जोड़ना पड़ता है।

प्रश्न की प्रतिक्रिया तैयार करने में कुछ बिंदु:

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

  • असेंबली, C, और C ++ समान रूप से "निम्न-स्तर" से दूर हैं। मुझे लगता है कि आप असेंबली और सी भाषाओं को हार्डवेयर / फर्मवेयर / ड्राइवर डेवलपर्स के साथ जोड़ने में सही हैं, लेकिन C ++ आमतौर पर एक उच्च स्तर पर उपयोग किया जाता है, और अभी भी भारी उपयोग में है - हालांकि स्पष्ट रूप से C # / Java इसे TIOBE के अनुसार बाहर निकाल रहे हैं सूचकांक।

  • C ++ tier में, मैं Objective-C जोड़ूंगा, क्योंकि यह C # / Java की तुलना में C ++ से अधिक है। अंत में, मैं ध्यान दूंगा कि share_ptr <> और अन्य स्वचालित संसाधन प्रबंधन सुविधाओं के अलावा, इन भाषाओं में कचरा संग्रहण के करीब कुछ के लिए समर्थन है।

ठीक है - आपके मुख्य प्रश्न पर: क्या सॉफ्टवेयर इंजीनियरों को अब निम्न स्तर के सामान को जानने की आवश्यकता है?

मेरा जवाब: हाँ

कारण:

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

अच्छा सवाल है - लेकिन मैं असंबद्ध भाषाओं को निकट अवधि में दूर नहीं जाता।


प्रतिक्रिया के लिए धन्यवाद। मैं कंप्यूटर फाउंडेशन (जैसे ओएस, नेटवर्क, अधिक मैथ ... पर भी अधिक अध्ययन करता रहूंगा ... बस मूल सिद्धांत को समझने के लिए पर्याप्त होगा और सिर्फ प्रोग्रामिंग में सुधार पर बहुत अधिक ध्यान केंद्रित नहीं करेगा। उम्मीद है कि यह एक दिन काम आएगा।
अमुमु

1
साथ ही निचले स्तर पर क्या हो रहा है, इसकी गहरी समझ रखने से आपको अपने निर्णयों को सूचित करने में मदद मिलेगी।
आहारबुद्ध

1
मेरे 0.02 को जोड़ने के लिए, जब आप मांग करते हैं कि यह कैसे होता है, यह जानना आमतौर पर एक अच्छी बात है। आपकी मांगों को अधिक उचित और कुशल बनाने में मदद कर सकता है (उच्च-स्तरीय प्रोग्रामिंग और शायद मालिकों पर लागू होता है;))।
ssube

43
  • कोई व्यक्ति वैध रूप से निम्न स्तर की कार्यक्षमता के बारे में नहीं सीखेगा और नहीं समझेगा, और फिर भी एक बहुत ही उत्पादक और मूल्यवान डेवलपर हो सकता है, यह पहले से ही मामला है।
  • किसी को भी निचले स्तर की कार्यक्षमता को सीखने या समझने की आवश्यकता नहीं होगी, कि यह हमेशा समय की बर्बादी होगी, कभी भी ऐसा नहीं होगा।

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

कहा जा रहा है, हमें Assemby / C डेवलपर्स की तुलना में अधिक C # / Java / रूबी डेवलपर्स की आवश्यकता है। हमारे लिए "उच्च स्तर" डेवलपर्स, "हुड के तहत" क्या होता है के बारे में अधिक समझ मददगार है, और हमें बेहतर डेवलपर्स बनाएगा। लेकिन इतना अन्य सामान करता है । .NET डेवलपर के रूप में, निर्वासन के लिए, इतना है कि मैं सीख सकता हूं कि मुझे अधिक उत्पादक बना देगा, हमारी इंटरमीडिएट भाषा (बहुत कम C ++ / C / Assmebly) का अध्ययन करना, हालांकि बहुत उपयोगी है, अक्सर एक पीछे की सीट लेनी होती है।


7

आप निम्न स्तर के सामान को जाने बिना एक प्रोग्रामर के रूप में आज एक जीवित बना सकते हैं। मुझे लगता है कि यह सिर्फ आपको इसे जानने के लिए एक बेहतर प्रोग्रामर बनाता है।

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


3

मुझे नहीं लगता कि, कर्नेल डेवलपर्स को हमेशा निम्न स्तर के सामान की आवश्यकता होगी। यह समझने में भी दुख नहीं है कि सब कुछ कैसे काम करता है, यदि आप मौलिक रूप से समझते हैं कि आप जो कोड लिख रहे हैं वह वास्तव में आप कर रहे हैं तो आप बेहतर कोड लिखना सीखेंगे। मुझे लगता है कि निम्न स्तर के सामान को हटाना एक भयानक विचार है क्योंकि यह अमूर्त सोच कई बार उपयोगी होती है, लेकिन वास्तव में एक बाधा हो सकती है यदि आप समस्या को सबसे अच्छे तरीके से हल करना चाहते हैं। उदाहरण के लिए यह समझना कि जब आप तार को वास्तव में नया तार पैदा कर रहे हैं तो यह महत्वपूर्ण है लेकिन अगर आपको समझ नहीं आया कि तार को कैसे लागू किया गया है तो आप बस दूर भाग सकते हैं और 5 मिनट तक प्रतीक्षा करें कि यह आपके प्रोग्राम को चलाने के लिए लेता है। यह इस तरह की चीजों पर एक उत्कृष्ट लेख है: http://www.joelonsoftware.com/articles/fog0000000319.html


3

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

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

जबकि व्यापार सॉफ्टवेयर के थोक में लिखा जाना जारी रहेगा कि किस चीज का उत्पादन सबसे तेजी से हो रहा है और दरवाजे के बाहर, जो आमतौर पर सी नहीं है, सी और सी ++ विशेषज्ञों के लिए बहुत जगह बनी रहेगी।


2

"हार्डवेयर में सुधार होता रहता है, C / C ++ और Java के बीच प्रदर्शन महत्वपूर्ण नहीं होगा, और बड़ा गेम भाषा में ऐसे जावा में प्रोग्राम किया जा सकता है।"

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

हालांकि केवल आम तौर पर अनुप्रयोगों के छोटे प्रतिशत को वास्तव में इस अनुकूलित कोड की आवश्यकता होती है। व्यावसायिक अनुप्रयोगों की अधिकांश पंक्ति किसी भी प्रबंधित कोड, .net, जावा, आदि के साथ ठीक है। इसका मतलब यह नहीं है कि जिन अनुप्रयोगों की आवश्यकता है, वे किसी भी समय जल्द ही स्विच कर देंगे। हालाँकि हाथ से लिखी विधानसभा का उपयोग अब बहुत कम हो रहा है, क्योंकि अनुकूलन C / C ++ कंपाइलर इतने अच्छे हैं। हाल ही में पूरी तरह से असेंबली में एक OS लिखा गया था, लेकिन फिर भी कुछ इस पर चल रहा है। यह सुरक्षा के क्षेत्र में भी काफी महत्वपूर्ण है।

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


@ अदम तुलिपर "एक ओएस पूरी तरह से विधानसभा में लिखा गया" दिलचस्प। क्या आप मुझे OS का नाम दे सकते हैं? आपने समस्या निवारण के बारे में एक अच्छी बात कही।
अमुमु

@ एडम: केवल एक असेंबली "OS" में कई घंटियाँ और सीटी नहीं होती (जैसे कि फैंसी एनिमेटेड GUI और एक पेंट प्रोग्राम), बल्कि यह केवल एक या दो उपयोगकर्ता-मोड प्रक्रियाओं को चलाने में सक्षम हो सकती है ...
मैके 12

@ मैके: आप मजाक कर रहे हैं? असेंबली भाषा में अधिक मल्टीटास्किंग ऑपरेटिंग सिस्टम सी में लिखे गए हैं। ऑपरेटिंग सिस्टम जिसमें से NT (विंडोज कर्नेल) क्लोन किया गया था, मुख्य रूप से मैक्रो -32 विधानसभा भाषा में लिखा गया था।
बिट-टिड्डर

1
@ बिट-ट्विडलर: क्या आपको यकीन है? मैंने देखा कि ज्यादातर स्रोत BLISS में थे ...
TMN

@TMN: BLISS का उपयोग केवल उच्च-स्तरीय OS सामग्री के लिए किया गया था। पूरे वीएमएस कर्नेल को मैक्रो -32 में लिखा गया था। मैंने सालों तक कांटा-स्तरीय प्रसंस्करण कोड की एक सूची रखी क्योंकि मुझे लगा कि यह इतना अच्छा विचार है। कांटा-स्तरीय प्रसंस्करण एक ऐसा तंत्र था जिसके द्वारा एक बाधा हैंडलर अपने कोड के गैर-समय-महत्वपूर्ण हिस्से को कम बाधित प्राथमिकता स्तर पर चलाने के लिए शेड्यूल कर सकता था। एनटी कर्नेल में फोर्क-लेवल प्रोसेसिंग का नाम बदलकर डिफर्ड प्रोसीजर कॉल कर दिया गया।
बिट-ट्विडलर

2

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


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

हेक, मैं अक्सर विंडोज पर सीपीयू मोड में सी और सी ++ कोड को डिबग करता हूं। वास्तुकला का ज्ञान और उपयोग के लिए संकलक के रन-टाइम संगठन के साथ-साथ प्रोसेसर के लिए निर्धारित निर्देश, किसी के बैग में रखने के लिए कौशल का एक शक्तिशाली सेट है। कृपया निम्नलिखित प्रोग्रामर्स देखें
।stackexchange.com

2

जब पहली बार कंप्यूटर का आविष्कार किया गया था, तो कुछ ही लोग जानते थे कि उनका उपयोग कैसे किया जाए। अब, किसी भी धनी देश के अधिकांश घरों में 1 या अधिक कंप्यूटर हैं जो औसत व्यक्ति द्वारा उपयोग करने योग्य हैं। कई आम लोगों के पास रोज़ कंप्यूटर पर काम करने की नौकरी होती है। औसत व्यक्ति के पास कंप्यूटर का उपयोग करने की क्षमता है, लेकिन हमें अभी भी प्रोग्रामर की आवश्यकता है।

इसी तरह, औसत प्रोग्रामर को असेंबली लैंग्वेज में जानने या नियमित रूप से प्रोग्राम करने की आवश्यकता नहीं होती है। यह सिर्फ विपणन योग्य कौशल की एक शर्त है क्योंकि यह एक सलाम है कि हम तकनीक की दुनिया में कितने आगे आ गए हैं। व्यवसाय को कार्यों को स्वचालित करने के लिए कंप्यूटर की आवश्यकता होती है। इसलिए, प्रोग्रामर जो .NET / Java में प्रोग्राम कर सकते हैं, उनकी बहुत मांग है।

जिन कार्यों को स्वचालित किया जा सकता है, वे स्वचालित होंगे। सभी कार्यों को स्वचालित नहीं किया जा सकता है। सभी स्वचालन सही नहीं है। तो, क्या विधानसभा महत्वपूर्ण है? बेशक। क्या "प्रोग्रामर" होना आवश्यक है। बिलकूल नही।


0

हम्म मैं वास्तव में निम्न-स्तरीय सामान सीखने का आनंद लेता हूं।

शायद यह सबसे सटीक उपमा नहीं है, लेकिन मेरे लिए यह एक कार के अंदर की मशीन सीखने जैसा है। मैं नहीं जानता कि सभी टुकड़े एक दूसरे के खिलाफ कैसे काम करते हैं, लेकिन यह जानना मजेदार है कि एक इंजन, एक क्रैंकशाफ्ट, सिलेंडर, अंतर, क्रेन, ब्रेक, तेल, दहन, प्रशीतन और फिर घर्षण, तनाव, गर्मी, बल विज्ञान- ऊष्मागतिकी, भौतिकी, द्रव यांत्रिकी ...

शायद बहुत उपयोगी नहीं है (मैं यह सब जानते हुए भी कार को ठीक नहीं कर पाऊंगा), निश्चित रूप से पेशेवर रूप से व्यावहारिक नहीं, लेकिन, अच्छी तरह से, मजेदार। L'art pour l'art: la connaissance pour ला अनुरूपता।


0

मुझे लगता है कि अंगूठे का एक उपयोगी नियम है - जितना तेज़ होना चाहिए, उतना ही कम स्तर आपको प्राप्त करना होगा।

तो आपके ग्राफिक्स गहन पहले व्यक्ति शूटर, या आपके एल्गोरिदम एफएक्स व्यापार प्रणाली, वे अभी भी काफी निम्न स्तर (सी ++, आदि) हैं क्योंकि गति महत्वपूर्ण है। लेकिन वह वेब ऐप जो समय पर बिक्री की रिपोर्ट पेश करता है? नरक, आप लिख सकते हैं कि सिनक्लेयर बेसिक में, और यह अभी भी स्वीकार्य होगा।


1
-1: मुझे लगता है कि अंगूठे का एक उपयोगी नियम है - जितना तेज़ होना चाहिए उतना ही कम स्तर आपको प्राप्त करना होगा। - बस जिज्ञासु, तुम कितने साल के हो? बेहतर एल्गोरिदम, बेहतर आर्किटेक्चर, और बेहतर हार्डवेयर अधिकांश आधुनिक सॉफ्टवेयर अनुप्रयोगों को गति देंगे। कंप्यूटर गेम और एम्बेडेड सिस्टम इस नियम के अपवाद हैं।
जिम जी।

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

0

सभी सॉफ्टवेयर इंजीनियरिंग नौकरियां समान नहीं हैं । ऑपरेटिंग सिस्टम, कंपाइलर, फ्रेमवर्क, डिवाइस ड्राइवर, एम्बेडेड सिस्टम और हाई-परफॉर्मेंस साइंटिफिक कंप्यूटिंग के काम करने वाले लोगों को 'लो-लेवल स्टफ' जानना जरूरी है। एक्सेस CRUD फॉर्म लिखने वाले लोग, या मॉम और पॉप स्टोर्स के लिए PHP शॉपिंग-कार्ट, शायद इतना नहीं। आप किस तरह की सॉफ्टवेयर इंजीनियरिंग करना चाहते हैं, और क्या आप इसे अपने जीवन के बाकी हिस्सों में करना चाहते हैं?

मेरी राय है कि आपको आमतौर पर काम करने वाले के नीचे कम से कम एक स्तर की सीख लेनी चाहिए। यदि आप C / C ++ में काम करते हैं, तो आपको कुछ मशीन आर्किटेक्चर और असेंबली चुननी चाहिए। यदि आप PHP में काम करते हैं तो आपको HTTP और थोड़ा C / C ++ या पर्ल समझना चाहिए। यदि एक्सेस आपकी रोटी और मक्खन है तो आप कुछ आरडीबी सिद्धांत और शायद COM या .Net के बारे में थोड़ा बहुत जानते होंगे। अपने करियर में कभी-कभी आप अपने ट्रैक्स में एब्सट्रैक्शन के निचले स्तर पर एक समस्या से मृत हो जाते हैं, और आपको कम से कम किसी ऐसे व्यक्ति से संपर्क करने में सक्षम होना चाहिए जो उस क्षेत्र का विशेषज्ञ हो। क्या आप इस सामान के बिना 'प्राप्त' कर सकते हैं? यकीन है, लेकिन एक प्रतिस्पर्धी नौकरी बाजार में सिर्फ 'पाने' की योजना खतरनाक है।


-1

मैं खुद C # .NET में बड़े पैमाने पर काम करता हूं और हमेशा C, C ++ से दूर चला गया हूं। हाल ही में नौकरी की तलाश शुरू की और यह देखने के लिए आश्चर्यचकित था कि कितने काम उपलब्ध हैं और सी, सी ++ के लिए अनुभव की आवश्यकता है। मैं शुरू में यद्यपि C, C ++ पुराना हो गया था लेकिन उपलब्ध नौकरियों को देखते हुए ऐसा नहीं लगता कि ऐसा है।


-1

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


-1

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

आमतौर पर मैं जो भी करता हूं, उसके लिए C # बहुत निम्न स्तर की भाषा है, और मैं इसे हार्डवेयर के बहुत करीब मानता हूं। लेकिन फिर भी मेरा मानना ​​है कि डिजिटल इलेक्ट्रॉनिक्स, सीपीयू डिज़ाइन इत्यादि के बारे में मेरी अल्पविकसित, कठोर जानकारी भी मेरे द्वारा किए जा रहे हर काम के लिए बहुत उपयोगी है।


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

@ एना लीयर, समस्या यह है कि कोई "व्यावहारिक" मास्टर नहीं कर सकता है, "गैर-व्यावहारिक" के बहुत व्यापक कवरेज के बिना सीधे लागू कौशल। सिर्फ इसलिए कि इस दुनिया में सभी ज्ञान कसकर जुड़े हुए हैं। कोई भी ज्ञान "समय की बर्बादी" नहीं हो सकता है, चाहे वह किसी भी संभावित अभ्यास से कितना भी दूर हो।
एसके-लॉजिक

1
-1: जो भी आप कभी भी सीखते हैं वह उतना ही व्यावहारिक होता है। - वाह। हो सकता है कि मुझे अपने सभी Pur ट्रिवियल पर्पस ’प्रश्न कार्डों के उत्तर याद करने चाहिए! ;)
जिम जी।

@ जीम जी, हाँ, जब तक आपको पर्याप्त खाली समय मिल गया है, तब तक और यह कुछ भी नहीं सीखने की कीमत पर नहीं होगा जो आपको इससे आगे बढ़ाएगा। "बेकार" चीजों को याद रखना वास्तव में आपकी याददाश्त में सुधार का एक बहुत मजबूत तरीका है।
SK-तर्क

-1

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


-1

मेरे विचार में, जब आप एक शब्द "इंजीनियर" का उपयोग करते हैं, तो आपका मतलब है कि वह आदमी / महिला वह है जो चीजों को बहुत ही खरोंच से डिजाइन और निर्माण करता है। एक सॉफ्टवेयर इंजीनियर्स की वास्तविक समस्या एक समस्या को हल करना है, लेकिन क्या समस्या है? यह एक बड़ा सवाल है।

एक डेवलपर कई मायनों में एक इंजीनियर से अलग है। "डेवलपर" एक ऐसा व्यक्ति है जो आमतौर पर पहले से मौजूद प्लेटफार्मों पर चीजों का निर्माण करता है। वह मौजूदा प्लेटफार्मों का विकास करता है या पुराने प्लेटफ़ॉर्म से विरासत में मिला नया प्लेटफ़ॉर्म बनाता है, यह निश्चित रूप से मूल प्रणाली के घटक का उपयोग करता है।

एक डेवलपर आमतौर पर व्यावसायिक दृष्टिकोण से सोचता है, वह वैज्ञानिक नहीं है। :) डेवलपर सिस्टम के उपयोगकर्ता के अधिक करीब है, वे उपयोगकर्ता के दृष्टिकोण से चीजों को सोचते हैं और इसलिए प्रौद्योगिकी का उपयोग करके उपयोगकर्ता की समस्याओं को हल करते हैं।

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

वास्तव में, एक सॉफ्टवेयर इंजीनियर को निम्न स्तर के सामान के साथ सीखने और अच्छी तरह से पारंगत होने की आवश्यकता है ... :)

जबकि एक डेवलपर, यह पूरी तरह से उसकी रुचि पर निर्भर करता है। :)


1
-1: उम्म ... नौकरी के शीर्षक व्यर्थ हैं, यार।
जिम जी।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.