Hacker News की राय में Tesla की जानकारी शायद Mark Rober के प्रयोग वाले वीडियो की वजह से लग रही है,

और वह robotaxi में इस्तेमाल होने वाला FSD भी नहीं था, बल्कि पुराने Auto Pilot से प्रयोग किया गया था, इसलिए लगता है कि वे वही राय लेकर आए हैं जो विवाद का विषय बनी हुई है.

अगर मेमोरी allocation और deallocation का समय compile time पर निकाला जा सकता है, तो क्या reference counting हटाया नहीं जा सकता? ऐसा लगता है कि मूल Hacker News टिप्पणी के लेखक मेमोरी reuse की समस्या को समझ नहीं रहे हैं।

अब जबकि जनरेटिव AI कोड लिख सकता है, यह सोचने वाली बात है कि क्या garbage collector अभी भी ज़रूरी है।
> काफ़ी मायने रखता है...

अरे, इसे मैं बाद में ठीक कर दूँगा।

तो क्या अब <selectlist> की ज़रूरत नहीं रहेगी?

Show GN: कैरेक्टर सेटिंग बैटल/रैंकिंग वेबगेम

अलग बात है, लेकिन Slackbot में शीर्षक का <select> दिख नहीं रहा है, haha

कल देखा था तो पता नहीं चला, लेकिन ये Microsoft का है, हाहा, इसे आज़माना पड़ेगा

लगता है अब नए commits पर नज़र रखकर नए features का अंदाज़ा लगाने वाले bloggers को थोड़ा अफ़सोस होगा।

सहमत..!

जैसा कि इस लेख में कहा गया है, "documentation" करने की क्षमता वास्तव में बहुत महत्वपूर्ण है.
यह सिर्फ अपनी ताकतों को प्रभावी ढंग से पेश करने और उपलब्धियों को सामने रखने के लिए ही नहीं, बल्कि काम को आसान बनाने और दूसरों को निर्देश देने में भी मदद करती है.

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

मुझे नहीं पता कि यह कितनी गहरी बुनियाद तक जाता है, लेकिन मैंने देखा है कि अगर बुनियाद नहीं पता हो, तो लोग सचमुच हैरान कर देने वाले और कल्पना से परे नतीजे बना देते हैं.
उदाहरण के लिए, DB के सभी records को memory में लोड करके फिर memory में search करने के लिए implement करना.
records कम हों तो यह ठीक चलता है, लेकिन records बढ़ जाएँ तो memory फट जाती है.
क्योंकि उन्हें memory और DB में क्या फर्क है, यह बिल्कुल पता नहीं होता, इसलिए वे ऐसा लिखते हैं.
यह तो बस एक उदाहरण है, और वे हर बार सचमुच ऐसी दिशा में implement करते हैं जिसकी कल्पना भी नहीं की जा सकती.
सामान्य(?) programmer तो सचमुच इसकी कल्पना नहीं कर सकता.

https://hi.news.hada.io/topic?id=4138

Coolify नाम का एक विकल्प भी है।

मैं भी इस लेख से सहमत हूँ
मेरा भी मानना है कि अमूर्त किए गए state values के आधार पर समस्या को परिभाषित करना, समस्या खोजने में उपयोगी है, और मैं diagram आदि के जरिए state visualization या Unreal Blueprint या workflow की तरह visual और explicit state management tools बनाने की कोशिश कर रहा हूँ

लगता है पहले language को देखना होगा

यह लेख मुझे computation theory की मेजर क्लास की याद दिलाता है! जो लोग programming करते हैं, उन्हें इसे पढ़ने/समझने की सलाह दूंगा।

बहुत बढ़िया है, है ना? ऐसी चीज़ भी open source में मिलती है, यह तो कमाल है, हाहा

Worse is better!

वैसे भी, software engineering का व्यावहारिक कामकाज काफी बदलने वाला है। code machines की प्रतिस्पर्धात्मकता कम हो जाएगी, लेकिन मैं इस बात पर दांव लगा रहा हूँ कि जो engineers वास्तव में किसी product को end-to-end बना सकते हैं, वे टिके रहेंगे।

मुझे भी लगता है कि OpenAPI function calling बेहतर नहीं है क्या। इसे MCP protocol के साथ फिर से बनाना भी अपने आप में एक काम है।

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

अगर आपके पास कोई सोचा हुआ आइडिया है, तो उसे आसपास के लोगों तक प्रभावी ढंग से पहुँचाकर समर्थन हासिल करने जैसी गतिविधियाँ भी अनिवार्य हैं — यही सीख मुझे मिली।