सही कहा। कमेंट्स में भी काफ़ी बकवास है। हद से ज़्यादा डूब जाना भी ठीक नहीं, लेकिन अगर आपको लगता है कि software engineering कोई ख़ास बात नहीं है, तो वह काम छोड़ दीजिए। ईमानदारी से कहें तो मानक नीचे कर दें तो यह आसान काम है, लेकिन अगर ऐसा नहीं है तो यह मुश्किल काम है—क्या यह सच नहीं है? दुनिया के ज़्यादातर पेशों की तरह।

यह कोई ऐसा लेख भी नहीं है जो खास तौर पर दूसरे पेशों को नीचा दिखाता हो, इसलिए ऐसा लेख और भी ज़्यादा हास्यास्पद लगता है।

इस बार o3 में hallucination बहुत ज़्यादा गंभीर होने की समस्या थी
मुझे लगा यह शायद उनमें से एक होगा, लेकिन उन्होंने सीधे संपर्क किया, यह दिलचस्प है

[अपडेट] OpenAI ने Lumi को आधिकारिक रूप से जवाब दिया
OpenAI ने इस पोस्ट के बारे में हमसे संपर्क किया और बताया कि विशेष कैरेक्टर वॉटरमार्क नहीं हैं। OpenAI के अनुसार, यह सिर्फ़ “बड़े पैमाने के reinforcement learning की एक विचित्रता” है। लेकिन हम इस पोस्ट को यथावत छोड़ रहे हैं, ताकि भविष्य के पाठक अब भी ChatGPT o3/o4 के जवाबों में इन विशेष (और संभावित रूप से अवांछित) कैरेक्टर्स की समस्या देख सकें।

हाहाहाहा

ऐसा लगता है कि literal parse करने पर variables भी string के रूप में आने वाली समस्या हल हो गई है। साझा करने के लिए धन्यवाद।

सोचता हूँ तो elm में भी यह होता है।

Gleam भी इसे support करता है, इसलिए काफ़ी साफ़-सुथरे तरीके से code लिखा जा सकता है.

वैसे, शायद main text में code block होने की वजह से, mobile पर भी यह desktop layout में दिख रहा है.

ऐसा लगता है कि इसमें इस बात को नज़रअंदाज़ किया गया है कि जैसे-जैसे service बढ़ती है, जटिलता भी बढ़ती है, और ऐसे में शुरुआती तरीकों को उसी तरह लागू करते रहना अब प्रभावी नहीं रह सकता।
शुरुआत में तेज़ approach आसान और असरदार रही होगी, लेकिन अगर यह स्वीकार नहीं किया गया कि अब वह तरीका काम नहीं कर सकता, तो ऐसा महसूस हो सकता है मानो अतिरिक्त लोग अक्षम हैं या समर्पित नहीं हैं।
हालाँकि देर-सबेर यह समझ में आ ही जाएगा कि वह strategy अब और नहीं चलती।

और किसी कंपनी में सिस्टम न होने को "तेज़ execution" कहना भी मुझे शेखी बघारने वाली बात नहीं लगता।

इतने पैसे भी नहीं देने हैं, फिर भी अगर आप यह कहकर दबाव डालते हैं कि उनकी productivity नहीं निकल रही, तो जो लोग सच में अच्छा काम करते हैं वे भाग जाएंगे...

मैं Google की recommendations में संयोग से यह देखकर अंदर आया, लेकिन यह लेख बहुत ज़्यादा Geek नज़रिए से लिखा गया है। व्यावसायिक नज़रिए से यह बिल्कुल सही बात नहीं है। ऐसा क्यों है?

1. Big Tech जिन बड़े tools का इस्तेमाल करती है, उनके experts ढूँढना आसान होता है।
   Big Tech में नौकरी पाने के लिए इन्हें सीखने वाले लोग भी बहुत होते हैं, और बहुत से लोग सिर्फ इसलिए भी इन्हें पढ़ते हैं क्योंकि Big Tech ने इन्हें चुना है। इसलिए स्वाभाविक रूप से इस बारे में जानने वाले लोगों को ढूँढना आसान होता है, और experienced लोगों या experts को ढूँढना भी अपेक्षाकृत सरल होता है। लेकिन अगर tool बिल्कुल नया हो, जिसे पहली बार देखा जा रहा हो, तो क्या होगा? ऐसा नहीं है कि किसी ने इसे गहराई से नहीं खंगाला होगा, लेकिन ऐसे लोगों को ढूँढना Big Tech के tools के experts की तुलना में कहीं अधिक कठिन होगा।

2. Big Tech द्वारा इस्तेमाल किए जाने वाले बड़े tools के लिए references और materials भरपूर होते हैं
   जिन बड़े tools का बहुत से लोग इस्तेमाल करते हैं, उनके लिए समस्या हल करने की सामग्री और Google search results भरपूर मिलते हैं। ज़्यादातर समस्याएँ ऐसी होती हैं जिनका सामना पहले भी किसी और ने किया होता है, और साधारण search से ही समस्या को आसानी से समझा जा सकता है। लेकिन किसी अनजान tool में समस्या आने पर references ढूँढना मुश्किल होता है, और अगर कोई समस्या हो जाए तो उसके कारण को समझने में काफ़ी समय लगने की संभावना होती है। और यह सब आखिर पैसा ही तो है। यह समस्या क्या नए अपनाए गए छोटे tool की वजह से है? या फिर कहीं और की समस्या को गलत समझा जा रहा है?

उल्टा, Big Tech के लिए ऐसी चीज़ों को बदलना ज़्यादा आसान होता है। बहुत बड़े data processing scale की वजह से, I/O में थोड़ा-सा फ़ायदा भी उनके लिए बड़ा लाभ बन सकता है। और सिर्फ इसलिए भी बहुत से लोग इन्हें पढ़ना चाहते हैं क्योंकि Big Tech ने इन्हें अपनाया है। लेकिन छोटे और मध्यम आकार की कंपनियों में, अपेक्षाकृत छोटे data scale के कारण I/O में थोड़ा-सा लाभ इतना बड़ा लाभ नहीं बनता, जबकि ऊपर बताई गई समस्याएँ बहुत गंभीर होती हैं। और छोटे-मध्यम आकार की कंपनियों द्वारा अपनाए गए solutions को सीखना चाहने वाले लोग भी कम होते हैं। इसलिए अगर आप छोटे या मध्यम आकार के उद्यमी हैं, तो Geek की तरह इन बातों को बारीकी से तौलने के बजाय, Big Tech के tools का अनुसरण करना कई मामलों में अधिक आर्थिक निष्कर्ष साबित होता है।

कोरियन का इंतज़ार है!!

शायद यह इसलिए हो कि AI-generated data को training data के रूप में इस्तेमाल न किया जाए (model collapse)।

लगता है जैसे इसे कोरियन-स्टाइल की रटवाने वाली ट्यूशन मिली हो… बस टेस्ट ही अच्छे देता है.
लेकिन असल में बात करो तो… काफ़ी खोखला है.

"अगर आप सोचते हैं कि इसमें ज़्यादा समय लगेगा, तो ज़्यादा समय लगेगा; और अगर आप सोचते हैं कि यह जल्दी खत्म हो जाएगा, तो यह जल्दी खत्म हो जाएगा।" इसे पढ़कर मुझे Parkinson's Law याद आया।

Parkinson's Law: Parkinson's Law के अनुसार, किसी काम को पूरा करने में लगने वाला समय उसे दिए गए उपलब्ध समय के अनुसार बढ़ जाता है.

क्या बस इसे मार देना चाहते थे?

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

कम मात्रा के डेटा और ऊपर दिए गए उदाहरण जैसे सरल स्तर के कोड में, देखने में यह अच्छा लगता है और कोई खास बुराई भी नहीं लगती।

लेकिन map() के अंदर थोड़ा-थोड़ा करके कोड घुसने लगता है ... और कोड धीरे-धीरे फूला हुआ होता जाता है।
भाषा या implementation library के अनुसार असर अलग हो सकता है, लेकिन जब डेटा की मात्रा बढ़ जाती है, तो सिर्फ data structure में डेटा जमा करके या उसे manipulate करते हुए प्रोसेस करने की तुलना में यह आसानी से हज़ारों गुना धीमा भी हो सकता है।

और एक नया कारण भी जुड़ गया है जिसकी वजह से अब इसे पसंद नहीं करता हूँ। जब मैंने यह लेख फोन पर देखा, तो PC-स्तर की चौड़ाई वैसे की वैसे बनी रही, और नतीजा यह हुआ कि अक्षरों का आकार बहुत ही बारीक हो गया, इसलिए लेख पढ़ना बेहद मुश्किल था T.T

मूल रूप से मैं इसे पसंद नहीं करता, और जानबूझकर इसे इस तरह लिखने की कोशिश भी नहीं करता।

MAUI ... दुखी