लगता है आप founder और CEO को लेकर भ्रमित हैं। कई CEO ऐसे भी होते हैं जो सिर्फ़ अल्पकालिक नतीजों पर ध्यान देते हैं और फिर अगली कंपनी की ओर बढ़ जाते हैं।
वैचारिक अंतर्दृष्टि सिर्फ़ उन्हीं को मिलती है जो जानते हैं कि कोई concept, concept क्यों है; कोई insight, insight क्यों है; और ज्ञान, ज्ञान क्यों है। निंदकता, निंदकता क्यों है; उसका कारण क्या है; कैसे; कहाँ से शुरू होकर किन प्रक्रियाओं और संरचनाओं के जरिए बनती है; और फिर वह किस तरह के परिणामों और घटनाओं के रूप में सामने आती है—इसकी समग्र समझ ज़रूरी है। यह सिर्फ़ उसी एक चीज़ की बात नहीं करता। सभी concepts और विचारों के बारे में। युग और देशों के बारे में। दुनिया की हर चीज़ के बारे में सोच, चिंतन और समझ की कमी है।
आह... हाँ, बेशक यह भी महत्वपूर्ण है। जब मैंने इसे पहली बार पढ़ा था, तो मुझे लगा कि लेख का लेखक शायद कोड execution speed के कुछ अधिक मूलभूत पहलू पर बात करना चाहता था। जैसा आपने कहा, यह भी सच है कि Unity का editor धीमा है, import भी धीमा है, और कुल मिलाकर test loop भी धीमा है...
मुझे तो ऐसा नहीं लगता कि असफल CEO किसी दूसरी कंपनी में करियर बदलते समय वास्तव में कोई नुकसान उठाते हैं। असली जोखिम की ज़िम्मेदारी तो उन कर्मचारियों पर आती दिखती है, जिन्हें असफल बिज़नेस को दाँत भींचकर चलाना पड़ा, और फिर विभागीय पुनर्गठन में उनकी ज़िंदगी ही खतरे में पड़ गई।
सिद्धांत रूप में देखें तो .NET Standard 2.0 को target करने वाले Nuget packages को Unity environment में भी import करके इस्तेमाल किया जा सकता है.. लेकिन लगता है कि व्यावहारिक असुविधाएँ काफ़ी हैं.
बड़े प्रोजेक्ट्स में editor performance डेवलपमेंट अनुभव को काफ़ी कमज़ोर कर देती है, इसलिए editor performance भी मायने रखती है. Editor खुलने में धीमा है, asset import भी धीमा है, और debugging/testing loop भी धीमा है...
या फिर छोड़ो-टाइप बकवास से भरे बेकार लेख पता नहीं क्यों लगातार बढ़ते जा रहे हैं। लगता है यह एक वैश्विक प्रवृत्ति है, हा हा।
किसी कंपनी में सक्रिय रूप से जोखिम उठाने वाला एकमात्र व्यक्ति CEO होता है। यह इतना छोटा जोखिम नहीं है कि बस वेतन न मिलने तक की बात हो। CEO वह होता है जो अपना सब कुछ छिन जाने का जोखिम भी उठाता है। यही हिस्सा सबसे महत्वपूर्ण है। अगर AI इस जोखिम को भी अपने ऊपर ले सकता हो, तब इस विषय पर फिर से बात की जा सकती है।
यह सही है कि टेक्स्ट वाकई एक बहुत अच्छा अभिव्यक्ति का माध्यम है, और बहुत महत्वपूर्ण भी है......
लेकिन हर चीज़ को टेक्स्ट में स्टोर नहीं किया जा सकता।
आख़िरकार टेक्स्ट एक संपीड़ित अभिव्यक्ति है। हम जो पाँच इंद्रियों (दृष्टि, श्रवण, स्पर्श, स्वाद, गंध) से महसूस कर सकते हैं, उसे सामाजिक रूप से सहमत एक रूप में संपीड़ित करके व्यक्त करते हैं।
लेकिन अगर उस मूल वस्तु के बारे में जानकारी ही न हो, तो भले ही डेटा को टेक्स्ट में सहेज लिया जाए, बाद में अगर उस मूल वस्तु को ही कोई न जानता हो, तो वह टेक्स्ट अपना अर्थ खो देता है।
हम कैसेट क्या होता है यह जानते हैं, लेकिन अगर हाल ही में पैदा हुए छोटे बच्चों को सिर्फ़ कैसेट जैसा टेक्स्ट दिखाकर पूछा जाए कि यह क्या है, तो कितने बच्चे सही जवाब दे पाएँगे? चाहे हम कैसेट की बनावट, कार्य और काम करने के तरीके के बारे में कितनी भी मेहनत से लिख दें, क्या हज़ारों साल बाद सिर्फ़ उस टेक्स्ट के आधार पर उस कैसेट को पूरी तरह फिर से बनाया जा सकेगा?
ऐसे मामलों में, उसकी बजाय कैसेट की कुछ तस्वीरें, कोई आरेख, या कैसेट का इस्तेमाल करते हुए कुछ मिनट का वीडियो ज़्यादा उपयोगी हो सकता है.
और मुझे लगता है कि .NET 10 के संदर्भ में यह बात भी ध्यान में रखी जानी चाहिए कि जिन समस्याओं को वे पहले IL2CPP के ज़रिए हल करना चाहते थे, वे अब अलग दिशा में सही तरह से addressed हो रही हैं (Native AOT)।
बेशक, इसकी सीमा यह है कि बीच में edit किए जा सकने वाला C++ code तैयार नहीं होता, लेकिन नतीजे के तौर पर Just-In-Time के बिना native binary production, .NET 8 से शुरू होकर .NET 10 तक आते-आते और अधिक परिपक्व हो गया है.
इसी वजह से, CoreCLR के साथ modernization को लगातार टालते रहना Unity के लिए अच्छा विकल्प नहीं होगा, ऐसा मुझे लगता है. या फिर पूरी तरह किसी अलग भाषा या आधार पर switch करना भी शायद अधिक प्रभावी replacement हो सकता है!
साल का अंत है... लगता है GitHub Star किसी का KPI रहा होगा।
यह Goodhart's law के काम करने का एक उदाहरण है, लेकिन मैनेजर के नज़रिए से देखें तो numbers के आधार पर मैनेज करने जितनी सुविधाजनक चीज़ और क्या है...
GitHub जैसे प्लेटफ़ॉर्म में stars का काफ़ी महत्व होता है, लेकिन क्या GitHub को abusing detection में दिलचस्पी नहीं है? सिर्फ़ GeekNews में भी यह तुरंत flagged हो जाता है।
मुझे लगता है कि Mono को ज़रूर CoreCLR में आधुनिक बनाया जाना चाहिए, इसका एक और कारण यह है कि Unity के पास Mono की performance सुधारने में निवेश करने की न तो पर्याप्त स्थिति है और न ही खास इच्छा। मेरा मानना है कि .NET Framework दौर की विरासत को जितनी जल्दी हो सके समेट देना सही होगा. :-D
बात तो सही है, लेकिन खास तौर पर editor performance की तुलना करने की वजह समझ नहीं आ रही... कम से कम debug build के साथ ही तुलना करके लाते? या नहीं, फिर शायद उसकी विश्वसनीयता और गिर जाती? दूसरी तरफ देखें तो IL2CPP हो या Mono, दोनों ही किसी न किसी तरह से पुराने पड़ चुके तकनीक लगते हैं।
लगता है आप founder और CEO को लेकर भ्रमित हैं। कई CEO ऐसे भी होते हैं जो सिर्फ़ अल्पकालिक नतीजों पर ध्यान देते हैं और फिर अगली कंपनी की ओर बढ़ जाते हैं।
अगर इसे सफलतापूर्वक अपनाया गया, तो लगता है कि बहुत-से indie game optimization शायद बेहतर हो जाएंगे...
वैचारिक अंतर्दृष्टि सिर्फ़ उन्हीं को मिलती है जो जानते हैं कि कोई concept, concept क्यों है; कोई insight, insight क्यों है; और ज्ञान, ज्ञान क्यों है। निंदकता, निंदकता क्यों है; उसका कारण क्या है; कैसे; कहाँ से शुरू होकर किन प्रक्रियाओं और संरचनाओं के जरिए बनती है; और फिर वह किस तरह के परिणामों और घटनाओं के रूप में सामने आती है—इसकी समग्र समझ ज़रूरी है। यह सिर्फ़ उसी एक चीज़ की बात नहीं करता। सभी concepts और विचारों के बारे में। युग और देशों के बारे में। दुनिया की हर चीज़ के बारे में सोच, चिंतन और समझ की कमी है।
आह... हाँ, बेशक यह भी महत्वपूर्ण है। जब मैंने इसे पहली बार पढ़ा था, तो मुझे लगा कि लेख का लेखक शायद कोड execution speed के कुछ अधिक मूलभूत पहलू पर बात करना चाहता था। जैसा आपने कहा, यह भी सच है कि Unity का editor धीमा है, import भी धीमा है, और कुल मिलाकर test loop भी धीमा है...
मुझे तो ऐसा नहीं लगता कि असफल CEO किसी दूसरी कंपनी में करियर बदलते समय वास्तव में कोई नुकसान उठाते हैं। असली जोखिम की ज़िम्मेदारी तो उन कर्मचारियों पर आती दिखती है, जिन्हें असफल बिज़नेस को दाँत भींचकर चलाना पड़ा, और फिर विभागीय पुनर्गठन में उनकी ज़िंदगी ही खतरे में पड़ गई।
क्या CEO और बड़े शेयरधारक हमेशा एक ही व्यक्ति नहीं होते? वेतनभोगी प्रोफेशनल मैनेजर CEO आखिर किस चीज़ को खोने के जोखिम को उठाते हैं?
सिद्धांत रूप में देखें तो .NET Standard 2.0 को target करने वाले Nuget packages को Unity environment में भी import करके इस्तेमाल किया जा सकता है.. लेकिन लगता है कि व्यावहारिक असुविधाएँ काफ़ी हैं.
https://learn.microsoft.com/ko-kr/dotnet/…
बड़े प्रोजेक्ट्स में editor performance डेवलपमेंट अनुभव को काफ़ी कमज़ोर कर देती है, इसलिए editor performance भी मायने रखती है. Editor खुलने में धीमा है, asset import भी धीमा है, और debugging/testing loop भी धीमा है...
या फिर छोड़ो-टाइप बकवास से भरे बेकार लेख पता नहीं क्यों लगातार बढ़ते जा रहे हैं। लगता है यह एक वैश्विक प्रवृत्ति है, हा हा।
किसी कंपनी में सक्रिय रूप से जोखिम उठाने वाला एकमात्र व्यक्ति CEO होता है। यह इतना छोटा जोखिम नहीं है कि बस वेतन न मिलने तक की बात हो। CEO वह होता है जो अपना सब कुछ छिन जाने का जोखिम भी उठाता है। यही हिस्सा सबसे महत्वपूर्ण है। अगर AI इस जोखिम को भी अपने ऊपर ले सकता हो, तब इस विषय पर फिर से बात की जा सकती है।
अगर NuGet compatibility भी जोड़ दें तो अच्छा होगा (या शायद मुझे Unity की ज़्यादा समझ नहीं है?)
लगता है AI CEO के decision-making की ज़िम्मेदारी कौन लेगा, यही सवाल है।
यह सही है कि टेक्स्ट वाकई एक बहुत अच्छा अभिव्यक्ति का माध्यम है, और बहुत महत्वपूर्ण भी है......
लेकिन हर चीज़ को टेक्स्ट में स्टोर नहीं किया जा सकता।
आख़िरकार टेक्स्ट एक संपीड़ित अभिव्यक्ति है। हम जो पाँच इंद्रियों (दृष्टि, श्रवण, स्पर्श, स्वाद, गंध) से महसूस कर सकते हैं, उसे सामाजिक रूप से सहमत एक रूप में संपीड़ित करके व्यक्त करते हैं।
लेकिन अगर उस मूल वस्तु के बारे में जानकारी ही न हो, तो भले ही डेटा को टेक्स्ट में सहेज लिया जाए, बाद में अगर उस मूल वस्तु को ही कोई न जानता हो, तो वह टेक्स्ट अपना अर्थ खो देता है।
हम कैसेट क्या होता है यह जानते हैं, लेकिन अगर हाल ही में पैदा हुए छोटे बच्चों को सिर्फ़
कैसेटजैसा टेक्स्ट दिखाकर पूछा जाए कि यह क्या है, तो कितने बच्चे सही जवाब दे पाएँगे? चाहे हम कैसेट की बनावट, कार्य और काम करने के तरीके के बारे में कितनी भी मेहनत से लिख दें, क्या हज़ारों साल बाद सिर्फ़ उस टेक्स्ट के आधार पर उस कैसेट को पूरी तरह फिर से बनाया जा सकेगा?ऐसे मामलों में, उसकी बजाय कैसेट की कुछ तस्वीरें, कोई आरेख, या कैसेट का इस्तेमाल करते हुए कुछ मिनट का वीडियो ज़्यादा उपयोगी हो सकता है.
और मुझे लगता है कि .NET 10 के संदर्भ में यह बात भी ध्यान में रखी जानी चाहिए कि जिन समस्याओं को वे पहले IL2CPP के ज़रिए हल करना चाहते थे, वे अब अलग दिशा में सही तरह से addressed हो रही हैं (Native AOT)।
बेशक, इसकी सीमा यह है कि बीच में edit किए जा सकने वाला C++ code तैयार नहीं होता, लेकिन नतीजे के तौर पर Just-In-Time के बिना native binary production, .NET 8 से शुरू होकर .NET 10 तक आते-आते और अधिक परिपक्व हो गया है.
इसी वजह से, CoreCLR के साथ modernization को लगातार टालते रहना Unity के लिए अच्छा विकल्प नहीं होगा, ऐसा मुझे लगता है. या फिर पूरी तरह किसी अलग भाषा या आधार पर switch करना भी शायद अधिक प्रभावी replacement हो सकता है!
साल का अंत है... लगता है GitHub Star किसी का KPI रहा होगा।
यह Goodhart's law के काम करने का एक उदाहरण है, लेकिन मैनेजर के नज़रिए से देखें तो numbers के आधार पर मैनेज करने जितनी सुविधाजनक चीज़ और क्या है...
> Unity के पास Mono की performance सुधारने में निवेश करने की न तो पर्याप्त स्थिति है और न ही खास इच्छा।
इस बात से भी मैं पूरी तरह सहमत हूँ...
Manus - सोच और कार्रवाई को जोड़ने वाला एक सामान्य-purpose AI agent
Hacker News की टिप्पणियों में इस अधिग्रहण को लेकर प्रतिक्रिया अच्छी नहीं दिख रही है.
GitHub जैसे प्लेटफ़ॉर्म में stars का काफ़ी महत्व होता है, लेकिन क्या GitHub को abusing detection में दिलचस्पी नहीं है? सिर्फ़ GeekNews में भी यह तुरंत flagged हो जाता है।
सरकारी अवकाश API से देखकर पता चलता है कि Christmas को
기독탄신일के रूप में दिखाया गया है। लगता है इसका आधिकारिक नाम기독탄신일ही है।मुझे लगता है कि Mono को ज़रूर CoreCLR में आधुनिक बनाया जाना चाहिए, इसका एक और कारण यह है कि Unity के पास Mono की performance सुधारने में निवेश करने की न तो पर्याप्त स्थिति है और न ही खास इच्छा। मेरा मानना है कि .NET Framework दौर की विरासत को जितनी जल्दी हो सके समेट देना सही होगा. :-D
बात तो सही है, लेकिन खास तौर पर editor performance की तुलना करने की वजह समझ नहीं आ रही... कम से कम debug build के साथ ही तुलना करके लाते? या नहीं, फिर शायद उसकी विश्वसनीयता और गिर जाती? दूसरी तरफ देखें तो IL2CPP हो या Mono, दोनों ही किसी न किसी तरह से पुराने पड़ चुके तकनीक लगते हैं।