29वें IOCCC 2025 विजेताओं की घोषणा

• International Obfuscated C Code Contest (अंतरराष्ट्रीय Obfuscated C Code Contest) एक कंप्यूटर प्रोग्रामिंग प्रतियोगिता है, जिसमें सबसे रचनात्मक, कलात्मक और पढ़ने में सबसे कठिन 'obfuscated' C code का मुकाबला होता है
• 2020~2024 के अंतराल के बाद लगातार दूसरी बार आयोजित इस प्रतियोगिता में प्रविष्टियों की संख्या पिछले वर्ष जैसी ही रही, लेकिन प्रविष्टियों का पैमाना और गुणवत्ता ऐतिहासिक स्तर पर बनी रही
• Yusuke Endoh, Nick Craig-Wood, और Don Yang ने तीन-तीन विजेता प्रविष्टियाँ देकर hat-trick हासिल की, और Taiwan से एक नए विजेता का भी आगमन हुआ
• Subleq कंप्यूटर, GameBoy emulator, patch/diff quine जैसी विविध विजेता प्रविष्टियाँ चुनी गईं, और हर विजेता प्रविष्टि में Fun challenge भी जोड़ा गया
• विजेताओं की घोषणा Our Favorite Universe YouTube चैनल के लाइव शो में की गई, और अगला IOCCC30 2026 के अंत में आयोजित होने वाला है

---

शुरुआत

• 2025 के विजेता IOCCC entries के लिंक पेज के नीचे दी गई विजेता सूची में देखे जा सकते हैं
• हर विजेता entry की index.html फ़ाइल में उस विजेता प्रोग्राम को compile और run करने के लिए ज़रूरी अधिकांश जानकारी दी गई है
• विजेता source code को पढ़कर उसके काम करने का तरीका समझा जा सकता है, और अधिक विवरण लेखक की व्याख्या में मिल सकता है
• इस वर्ष की प्रतियोगिता की सभी विजेता प्रविष्टियाँ compressed tarball के रूप में डाउनलोड की जा सकती हैं

इस प्रतियोगिता पर सामान्य टिप्पणियाँ

• IOCCC29 में submission की मात्रा और गुणवत्ता इतिहास के सर्वोच्च स्तरों के क़रीब थी
• IOCCC28 4 साल के अंतराल के बाद हुआ था, इसलिए अनुमान लगाया गया कि प्रतिभागियों को अपनी submissions निखारने का समय मिला, और इसी कारण रिकॉर्ड स्तर की submission संख्या और सामान्य से बेहतर गुणवत्ता देखने को मिली
• IOCCC29 2020~2024 के अंतराल के बाद लगातार दूसरी प्रतियोगिता थी, लेकिन submissions की संख्या पिछले वर्ष जैसी ही रही और कुल गुणवत्ता भी ऊँचे स्तर पर बनी रही
• IOCCC28 के समाप्त होने के समय से नई submissions की deadline, judging प्रक्रिया, विजेताओं के चयन, वेबसाइट अपडेट, और Our Favorite Universe लाइव शो बनाने की प्रक्रिया को सावधानी से document किया गया
• इस documentation में अतिरिक्त समय और मेहनत लगी, लेकिन इसके परिणामस्वरूप IOCCC के संचालन के कई पहलुओं में सुधार हुआ
• IOCCC29 के विजेताओं की घोषणा Our Favorite Universe YouTube चैनल पर होने के कुछ दिनों बाद, मुख्य शो की रिकॉर्डिंग को अलग-अलग segments में बाँटा जाएगा
• हर विजेता entry की index.html के ऊपरी हिस्से में एक नया Award presentation section और संबंधित YouTube segment लिंक जोड़े जाने वाले हैं

• मज़ेदार चुनौती की जानकारी

  • इस वर्ष की विजेता प्रविष्टियों में “Judges’ remarks” section के नीचे मज़ेदार चुनौतियाँ जोड़ी गई हैं
  • किसी खास विजेता प्रविष्टि की कार्यप्रणाली समझने के बाद उस चुनौती को आज़माने की सलाह दी जाती है
  • कुछ चुनौतियाँ अन्य चुनौतियों की तुलना में आसान हैं, और कुछ मामलों में prog.c या संबंधित फ़ाइलों का वैकल्पिक संस्करण बनाना पड़ सकता है
  • कुछ चुनौतियों में किसी विशेष बिंदु का विवरण लिखना होता है
  • यदि किसी विजेता प्रविष्टि के “A fun challenge” section में चुनौती still open है, तो GitHub pull request भेजकर योगदान दिया जा सकता है
  • चुनौती बंद हो जाने पर भी, यदि आपको लगता है कि आपके पास बेहतर समाधान है, तो GitHub pull request भेजा जा सकता है
  • यदि IOCCC Judges इस बात से सहमत हों कि वह बेहतर समाधान है, तो उसे समीक्षा के लिए लिया जाएगा
  • यदि किसी विजेता प्रविष्टि की मज़ेदार चुनौती के लिए आपके पास बेहतर सुधार प्रस्ताव है, तो IOCCC Judges की समीक्षा के लिए GitHub pull request भेजा जा सकता है

• इस प्रतियोगिता के नियम और दिशानिर्देश

  • इस प्रतियोगिता पर लागू अंतिम नियम 2025 rules version 29.15 2025-12-02 थे
  • इस प्रतियोगिता पर लागू अंतिम guidelines 2025 guidelines version 29.08 2025-12-02 थीं
  • IOCCC29 के नियम और guidelines पिछली प्रतियोगिता की तुलना में काफ़ी बड़े बदलावों के साथ आए
  • कई volunteers ने IOCCC Judges को उपयोगी edits, वाक्य संशोधन, एकीकरण, और समग्र संरचना में सुधार प्रदान किया

• अगली प्रतियोगिता की ओर

  • IOCCC30 को 2026 के अंत के आसपास शुरू करने की योजना है
  • IOCCC30 लगभग समान अवधि तक चलेगा और 2027 की पहली तिमाही के अंत के आसपास समाप्त होने की योजना है
  • IOCCC30 की शुरुआत के लिए आवश्यक काम करते समय, IOCCC29 की deadline के समय की तरह आंतरिक प्रक्रियाओं को document करने की भी योजना है
  • IOCCC29 विजेताओं के प्रकाशित होने के लगभग 2~3 सप्ताह बाद, और 2025 directory tree पर शुरुआती कुछ pull requests संभालने के बाद, IOCCC Judges IOCCC vacation पर जाने की योजना बना रहे हैं
  • IOCCC28 विजेताओं के प्रकाशित होने के बाद भी IOCCC vacation की योजना थी, लेकिन mkiocccentry repo में bug fixes और improvements पर इतना समय लगा कि repository स्थिर होने तक IOCCC29 शुरू होने का समय आ गया
  • इस बार post-IOCCC29 IOCCC vacation के समाप्त होने के बाद mkiocccentry repo PRs पर काम करने की योजना है

कुछ विजेता प्रविष्टियों पर टिप्पणियाँ

• judging rounds के अंतिम सेट के अंतिम round तक पहुँची submissions पर संभावित लेखन तैयार करते समय, कुछ submissions को अंतिम round के आख़िरी चरण में बाहर कर दिया गया
• बाकी कई entries के लिए अतिरिक्त प्रशंसा और मूल्यांकन में वृद्धि हुई
• विजेता लेखकों में पहले से विजेता रहे क्षेत्रों के लोग भी शामिल थे, और IOCCC29 में नए क्षेत्र Taiwan से jingp49 भी शामिल हुए
• तीन लेखकों ने तीन-तीन entries के साथ जीत हासिल कर Hat trick) के Hat-tricks पूरे किए
  • Yusuke Endoh: 2025/endoh1, 2025/endoh2, 2025/endoh3
  • Nick Craig-Wood: 2025/ncw1, 2025/ncw2, 2025/ncw3
  • Don Yang: 2025/yang1, 2025/yang2, 2025/yang3
• IOCCC29 की कुछ उल्लेखनीय विजेता प्रविष्टियाँ इस प्रकार हैं
  • 2025/cable: Subleq कंप्यूटर
  • 2025/cesmoak: black hole punchcard Fortran
  • 2025/endoh3: patch/diff quine
  • 2025/jhshrvdp: अर्ध rogue-like game
  • 2025/jingp49: Dr. WHO sequence
  • 2025/ncw1: GameBoy emulator
  • 2025/tompng: समुद्री ध्वनि जनरेटर
  • 2025/uellenberg: quine pong
  • 2025/yang2: Zoltraak encoding
• ऊपर दी गई सूची IOCCC29 की कई उत्कृष्ट विजेता प्रविष्टियों में से सिर्फ़ कुछ को दिखाती है

• कुछ गैर-विजेता submissions पर टिप्पणियाँ

  • कई उत्कृष्ट submissions अंतिम चयन के बहुत क़रीब पहुँचीं, लेकिन विजेता नहीं बन सकीं
  • हर लेखक ने अपनी entry में जो मेहनत लगाई, उसकी सराहना की जाती है, लेकिन केवल मेहनत के आधार पर पुरस्कार नहीं दिए जा सकते
  • जो code IOCCC29 में submitted था लेकिन विजेता नहीं बना, उसे और निखारकर IOCCC30 में फिर से submit किया जा सकता है
  • IOCCC29 की एक या अधिक विजेता प्रविष्टियाँ पहले की प्रतियोगिताओं में न जीत पाने वाले code के सुधरे हुए संस्करण थे

• इस वर्ष नहीं जीतने वाले प्रतिभागियों के लिए प्रोत्साहन

  • इस वर्ष की IOCCC submissions में बहुत मेहनत लगी, लेकिन हर submission को पुरस्कार नहीं दिया जा सकता
  • यदि हर submission को पुरस्कार दे दिया जाए, तो इससे उन submissions का महत्व कम हो जाएगा जिन्हें वास्तव में सर्वश्रेष्ठ और पुरस्कार योग्य माना गया है
  • अंतिम round की submission विजेता बनने लायक पर्याप्त अच्छी हो सकती है, फिर भी वैसी ही लेकिन थोड़ी बेहतर submission से पीछे रह सकती है
  • जिन submissions पर यह बात लागू होती हो, उन्हें अगले IOCCC के लिए बेहतर संस्करण submit करने के लिए प्रोत्साहित किया जाता है
  • कुछ submissions कई बार संशोधित कर दोबारा भेजे जाने के बाद विजेता स्तर तक पहुँचीं
  • अगले IOCCC में आप पूरी तरह अलग तरह की submission भी आज़मा सकते हैं
  • यदि आप अगले IOCCC में गैर-विजेता entry को सुधारकर फिर से submit करने की योजना नहीं रखते, तो उसे सार्वजनिक कर सकते हैं

विजेता प्रविष्टियों को compile और run करना

• कुछ C compilers पर्याप्त अच्छे परिणाम नहीं दे सकते
• यदि आपका compiler ठीक से काम नहीं कर रहा है, तो आप नवीनतम clang या gcc version से compile करने की कोशिश कर सकते हैं
• विजेता प्रविष्टियों को compile या run करते समय समस्या आने पर निम्न FAQ देखे जा सकते हैं
  • Compiling IOCCC entries
  • IOCCC entry dependencies
  • Problems compiling entries
  • Running IOCCC entries
• submissions में fixes भेजने की अतिरिक्त जानकारी के लिए निम्न FAQ देखे जा सकते हैं
  • How to submit a fix: entry में fix submit करने का तरीका
  • Update author information: IOCCC author information को ठीक या update करने का तरीका

2025 के 29वें IOCCC विजेता

• सभी विजेता प्रविष्टियाँ 2025 winners download के रूप में उपलब्ध हैं
• 2025/ayu: IMO पुरस्कार
• 2025/cable: सर्वश्रेष्ठ imagined emulator पुरस्कार
• 2025/cesmoak: retro cosmos पुरस्कार
• 2025/diels-grabsch: सर्वश्रेष्ठ one-liner पुरस्कार
• 2025/dogon: लगातार constant रहने वाला पुरस्कार
• 2025/endoh1: सबसे चकाचौंध पैदा करने की संभावना वाला पुरस्कार
• 2025/endoh2: सबसे बड़ा shock देने की संभावना वाला पुरस्कार
• 2025/endoh3: सर्वश्रेष्ठ resilience पुरस्कार
• 2025/ferguson: विपरीत पुरस्कार
• 2025/howe: आक्रमण करने की सबसे अधिक संभावना वाला पुरस्कार
• 2025/jhshrvdp: teleport होने की सबसे अधिक संभावना वाला पुरस्कार
• 2025/jingp49: Who won पुरस्कार
• 2025/kurdyukov: गिन सकने की सबसे अधिक संभावना वाला पुरस्कार
• 2025/mattpep: सबसे अधिक obfuscated options पुरस्कार
• 2025/ncw1: सर्वश्रेष्ठ वास्तविक emulator पुरस्कार
• 2025/ncw2: सर्वश्रेष्ठ fractional emulator पुरस्कार
• 2025/ncw3: Unicode के सर्वश्रेष्ठ उपयोग का पुरस्कार
• 2025/tompng: सबसे सुकून देने वाला पुरस्कार
• 2025/uellenberg: पिंग-पोंग पुरस्कार
• 2025/yang1: compound पुरस्कार
• 2025/yang2: सबसे जादुई शब्द पुरस्कार
• 2025/yang3: INABIAF पुरस्कार

[GN⁺]

Hacker News टिप्पणियाँ

• GameBoy emulator का कोड GameBoy के आकार जैसा भी दिखता है। इतना पागलपन है कि बस धीमी ताली बजाने का मन करे, और व्यक्तिगत रूप से यह इस बार की प्रविष्टियों में मुझे सबसे ज़्यादा पसंद आया
  https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
  लेखक Nick Craig-Wood वही हैं जिन्होंने rclone बनाया है

  • यह सुनकर खुशी हुई कि आपको यह मज़ेदार लगा :-) अगर आप देखना चाहते हैं कि यह कैसे बनाया गया, तो मूल यहाँ है
    https://github.com/ncw/ioccc-gameboy
    वहाँ लगभग एक unobfuscated version भी है। असल में काम मैंने उसी पर किया था, और बाद में एक प्रोग्राम से सभी variable names को कुचलकर GameBoy के आकार में फिट होने लायक compress किया
    प्रविष्टि की size limit सबसे कठिन थी। IOCCC प्रविष्टियों में spaces को छोड़कर 2503 characters तक की अनुमति है, और कुल code size 4KB है, लेकिन उसमें Z80 processor और GameBoy hardware emulator डालना सच में बहुत छोटा है
    शुरुआत में मैंने C में एक पूरा GameBoy emulator लिखा था और वह spaces हटाने पर लगभग 6000 characters से शुरू हुआ। उसके बाद 2503-character limit में फिट करने के लिए मैंने लगभग 100 घंटे लगाए, और कुछ समय तक मुझे यकीन नहीं था कि यह समा भी पाएगा या नहीं
    मैंने लक्ष्य Tetris चलाने का रखा। Tetris अपेक्षाकृत सरल गेम है, इसलिए Z80 emulator के half carry flag या GameBoy emulation के windowing system जैसी गैर-ज़रूरी सुविधाएँ हटा दीं। साथ ही C code को बुरी तरह निचोड़ा, और implicit int के साथ ऐसे काम किए जिन्हें मैं शायद कभी नहीं भूलूँगा। IOCCC rule checker C program में implement किया गया है, इसलिए उसे reverse engineer करके loopholes खोजने में भी समय लगाया। खासकर यह पता चलना बहुत उपयोगी था कि कुछ operators को सिर्फ एक token के रूप में गिना जाता है
    जब यह पर्याप्त छोटा हो गया, तब इसमें चलाने के लिए games भी डालने थे। मैंने Z80 assembly में लिखा हुआ एक test program, assembly में बना pi calculator, gbdk-2020 के साथ C में बना 3D tic-tac-toe, और C में लिखा chess program मिलाकर कुल 4 बनाए। यह भी पता चला कि काफ़ी सारे open source games इस emulator पर चलते हैं, इसलिए जहाँ संभव था वहाँ downloader भी जोड़ दिया। हैरानी की बात यह थी कि BCD arithmetic इस्तेमाल करने वाले games बहुत ज़्यादा नहीं थे
    यह एक मज़ेदार प्रोजेक्ट था
  • https://github.com/ncw/ccforth
    https://github.com/ncw/ccforth/tree/master/examples/gameboy
  • कमाल है! और मैं यह देखकर यहाँ CSS aur PHP ही चला रहा हूँ
  • कोड को चित्र जैसा दिखाना obfuscated programming contest में काफ़ी इस्तेमाल होने वाला एक cliché है

• मुझे सबसे ज़्यादा पसंद 366-byte C program emulator आया, जो Linux और Doom चला सकता है [0]
  यह virtual machine एक OISC, यानी single instruction computer को implement करती है [1]
  [0] https://github.com/ioccc-src/winner/blob/master/2025/cable/p...
  [1] https://github.com/ioccc-src/winner/blob/master/2025/cable/R...

  • पिछले कुछ हफ़्तों से मैं अपनी एक सरल programming language बना रहा था, जो Linux/amd64 assembly में compile होती है
    मैं file खोलने, shell command चलाने, strstr, strcpy जैसी standard library routines लिखने में काफ़ी समय लगा सकता था, और सच कहूँ तो सीखने की प्रक्रिया में कुछ ऐसी चीज़ें भी implement कर दीं जिनकी ज़रूरत नहीं थी। उदाहरण के लिए print(getenv("HOME")) काम करता है। लेकिन जल्दी ही समझ आया कि testing और दिखावे के लिए example programs भी चाहिए
    इसलिए स्वाभाविक रूप से मैंने जो पहला असली program implement किया, वह brainfuck interpreter था। इसकी वजह से मेरी language अब अप्रत्यक्ष रूप से Turing-complete है
    शुरुआती version को मशहूर mandelbrot program का output निकालने में 9 मिनट लगते थे, इसलिए मैंने कई optimizations किए, और बाद में switch/case statements का support भी जोड़ा ताकि speed बढ़े। अब वही output 2 मिनट में बन जाता है, इसलिए सुधार की गुंजाइश अभी भी है, लेकिन प्रगति भी काफ़ी हुई है
    अपनी ही language के अंदर दूसरी language implement करने का यह थोड़ा cheating जैसा तरीका मुझे बहुत संतोषजनक लगा। बेशक, यह सब सिर्फ़ मज़े और सीखने के लिए है, और इसे मेरे सहित किसी के भी गंभीर उपयोग के लिए नहीं बनाया गया
    https://github.com/skx/s-lang
  • वाह! और इसने Turing-complete SUBLEQ variant को भी बेहद दिलचस्प तरीके से implement किया है

    यह VM एक OISC, यानी One Instruction Set Computer implement करता है। यह instruction तीन signed 32-bit operands a, b, c लेती है, और memory m[] में program को इस तरह चलाती है:
    1 PC(program counter) 0 से शुरू होता है
    2 अगली instruction fetch की जाती है, यानी signed 32-bit operands a, b, c
    3 अगर किसी operand में low bit set हो, तो उस bit को हटाया जाता है, और उस operand को m[operand], यानी उस address के dereferenced value से बदल दिया जाता है
    4 m[b] = m[b] - m[a] पर set किया जाता है
    5 अगर m[b] 0 या उससे कम हो, तो PC को c पर set किया जाता है, नहीं तो PC को 3 words आगे बढ़ाया जाता है
    6 step 2 पर लौटते हैं

  • यह idea मुझे पसंद आता है, लेकिन linked Eternal Software Initiative [1] थोड़ा उलझाऊ है। इसे decode करने वाली instruction की कई versions हैं और वे एक-दूसरे से टकराती हैं
    यहाँ लिखा है Set m[b] = m[b] - m[a]
    फिर यह GitHub की reference implementation [2] पर ले जाता है, जहाँ कहा गया है कि सिर्फ़ napkin memo [3] ही काफ़ी है। वहाँ पढ़े गए सभी values को 4 से divide किया जाता है, और reference implementation [4] भी इसका समर्थन करती है। लेकिन 2 की जगह 4 क्यों चुना गया, यह साफ़ नहीं है। ऐसा लगता है जैसे एक bit बेकार जा रहा है। जिज्ञासा है कि क्या यह bit ज़रूरी था, या future expansion के लिए reserve किया गया था
    लगता है original implementation में 4 से divide नहीं किया जाता था और यह बाद में जोड़ा गया, लेकिन LLVM code generation को थोड़ा आसान बनाने के अलावा यह क्यों ज़रूरी था, समझ नहीं आता। अगर 4 से divide न किया जाए, तो क्या बताई गई system असंभव हो जाती है, यह जाँचने के लिए शायद कई examples को step-by-step देखना पड़ेगा। शायद सिर्फ़ even addresses तक ही पहुँचा जा सकता था, और PC हर बार 3 से बढ़ता है, इसलिए code locations को refer करना निश्चित रूप से झंझटभरा रहा होगा
    reference implementation location 64 को access करने पर जादुई तरीके से काम करती है और locations 64~67 को current time से overwrite कर देती है। napkin explanation में इसका ज़िक्र है, लेकिन main page explanation में नहीं
    दोनों explanations जादुई -1 address का ज़िक्र करती हैं, इसलिए यह अजीब है कि implementation-dependent UTC clock को negative address के रूप में implement करने के बजाय freely usable memory को खराब करने वाला तरीका चुना गया
    दोनों explanations periodic timer interrupt process का भी ज़िक्र करती हैं, और यह भी थोड़ा अफ़सोसजनक है। यह address 0 को interrupt handler location के रूप में, और 1 को saved PC के रूप में reuse करती है, इसलिए program शुरू होते ही शुरुआती entry point location 0 को overwrite करना पड़ता है
    [1] https://eternal-software.org/
    [2] https://github.com/adriancable/eternal
    [3] https://github.com/adriancable/eternal/blob/main/docs/napkin...
    [4] https://github.com/adriancable/eternal/blob/main/vm/vm.c
  • मैंने इसे डाउनलोड करके build किया, और पूरे भरोसे से कह सकता हूँ कि यह अब तक देखी गई सबसे प्रभावशाली चीज़ है
  • वीडियो यहाँ है
    https://www.youtube.com/live/MoWCwZx1Swc?si=eIOlRsKWNKRVRZeB...

• शायद किसी को जिज्ञासा हो: IOCCC अपने guidelines में LLM usage को स्पष्ट रूप से अनुमति देता है
  "IOCCC has a rich history of remarkable winning entries created by authors who skillfully employed various techniques (often their own tools) to develop their code."

  • मैं non-AI पक्ष का हूँ, लेकिन इस मामले में यह दिलचस्प है। खासकर क्योंकि ऑनलाइन obfuscated C code बहुत ज़्यादा नहीं है, और LLM के लिए वास्तविक code से intent infer करना भी मुश्किल होता है। यह जानना दिलचस्प होगा कि क्या किसी ने LLM की मदद से बनी entry देखी है
    उल्टा सवाल भी दिलचस्प है। LLM obfuscated code का function कितना सही पहचान सकता है?
  • इसका असर मुख्य रूप से judges पर पड़ता है। यह अपने आप ही इस संभावना को खुला छोड़ता है कि बहुत सारा घटिया code आ सकता है, लेकिन contest की प्रकृति को देखते हुए लगता है judges interesting code और low-quality code में बहुत अच्छी तरह फर्क कर पाएँगे
    मुझे लगता है IOCCC का ऐसे code को स्वीकार करना ठीक है जो शायद मशीन की मदद से बना हो। इससे पूरी तरह हाथ से बनाई गई winning entries की value और भी बढ़ी हुई लगती है
  • तो क्या यह LLM gymnastics contest बन गया है?
  • अगर "tools" में AI शामिल है, तो rule 7 self-contradictory हो जाता है
    https://www.ioccc.org/2025/rules.html
    मेरा खयाल है यहाँ बात custom code generators की हो रही है। वहाँ स्पष्ट रूप से "rich history" कहा गया है, और अगर उस अभिव्यक्ति में AI से पहले का दौर भी शामिल है, तो मुझे समझ नहीं आता कि उसे AI के अर्थ में क्यों लिया जाए

• वेबसाइट खुद भी obfuscated है, इसलिए C source ढूँढना बिल्कुल आसान नहीं है

  • सीधे https://www.ioccc.org/2025/#inventory पर जाएँ
  • navigate करना वाकई मुश्किल है। contest क्या है, यह समझ में नहीं आता, और ऐसा लगता है जैसे इसे इस मानकर बनाया गया हो कि आप पहले से जानते हैं
  • पहली line winning entries list section से link होती है, और हर winning entry के ऊपर दाईं ओर C code link है

• काश Underhanded C Contest वापस आए। Obfuscated C प्रतिभागियों को नीचा दिखाने का इरादा नहीं है, लेकिन मेरे लिए वह काफ़ी ज़्यादा दिलचस्प था

• यहाँ Frieren [1] का reference है!
  https://www.ioccc.org/2025/yang2/index.html
  मुख्य पात्रों में से एक Fern है, और वह लगभग पूरी तरह सामान्य offensive spell Zoltraak का इस्तेमाल करती है
  [1] https://en.wikipedia.org/wiki/Frieren

  • Frieren के दो references हैं। दूसरा https://www.ioccc.org/2025/yang1/index.html में है

• अरे वाह, मैंने जो Game Boy Game of Life implementation बनाया था, वह winning entries में से एक में शामिल है!

  • emulator बनाने के बाद मैं GitHub पर ऐसे games ढूँढ रहा था जो 32KB limit के भीतर चल सकें। मुझे आपका वाला मिला, और धन्यवाद :-) मैंने ./try.sh script में एक option जोड़ दिया है ताकि लोग उसे GitHub से डाउनलोड करके test कर सकें

• 2000 में मैंने अपना पहला internship interview दिया था, C programmers की team में शामिल होने के लिए। interviewers ने मुझे एक पुरानी winning entry दिखाई और कहा कि code review करके देखो, फिर वे कमरे से बाहर चले गए। करीब 5 मिनट बाद लौटकर उन्होंने पूछा
  – तो?
  – माफ़ कीजिए, मैंने आपका समय बर्बाद कर दिया। मुझे यह बिल्कुल समझ नहीं आ रहा
  फिर सब लोग हँस पड़े और बोले कि hiring process शुरू करते हैं
  सोचता हूँ क्या आज भी interns के साथ ऐसा मज़ाक किया जाता है। उस समय मैं कितना घबरा गया था, यह सोचकर अब भी हँसी आती है

• ओह्ह! IOCCC वापस आ गया!
  organizers को ढेर सारा प्यार <3 <3 <3 इसे जारी रखने के लिए धन्यवाद, और उम्मीद है यह फिर कभी गायब नहीं होगा

• रुको, यह बात मुझे कुछ समझ नहीं आ रही
  Obfuscated C Code Contest चल सकता है, लेकिन Capture the Flag नहीं? AI की वजह से?
  https://twit.tv/posts/tech/ai-disrupts-capture-flag-what-mea...

  • Capture the Flag का एक स्पष्ट goal होता है, लेकिन Obfuscated C Contest का वैसा नहीं है। goal-oriented contests में AI का आगे बढ़ना समझ आता है, लेकिन ऐसे open-ended contests में जहाँ artistic sense भी शामिल हो, उसे प्रगति किसे कहें यह स्पष्ट नहीं है
    अगर सवाल यह है कि "क्या कोई clever idea सोचकर AI से उसे IOCCC constraints के हिसाब से implement करने को नहीं कह सकता?", तो मेरा मानना है कि अभी के AI tools यह काम उस स्तर पर नहीं कर पाते जिसे human judges सचमुच मूल्यवान मानें