ประกาศผลงานชนะเลิศครั้งที่ 29 ของ IOCCC 2025
(ioccc.org)- International Obfuscated C Code Contest (การแข่งขันโค้ด C แบบทำให้อ่านยากระดับนานาชาติ) เป็นการแข่งขันเขียนโปรแกรมคอมพิวเตอร์ที่ประชัน โค้ด C แบบ 'Obfuscated' ที่สร้างสรรค์ มีศิลปะ และอ่านยากที่สุด
- หลังเว้นช่วงในปี 2020~2024 นี่เป็นการแข่งขันที่จัดต่อเนื่องเป็นปีที่สอง โดยจำนวนผลงานส่งเข้าประกวดใกล้เคียงกับปีก่อน แต่ ขนาดและคุณภาพของผลงาน ยังอยู่ในระดับสูงเป็นประวัติการณ์
- Yusuke Endoh, Nick Craig-Wood, และ Don Yang ต่างคว้ารางวัลคนละ 3 ผลงาน ทำ แฮตทริก ได้สำเร็จ และมีผู้ชนะหน้าใหม่จาก Taiwan ปรากฏตัว
- มีผลงานชนะเลิศหลากหลายประเภท ทั้งคอมพิวเตอร์ Subleq, GameBoy emulator, patch/diff quine และมีการเพิ่ม Fun challenge ให้แต่ละผลงานด้วย
- การประกาศรางวัลจัดขึ้นผ่านไลฟ์โชว์บนช่อง YouTube Our Favorite Universe และ IOCCC30 ครั้งถัดไปมีกำหนดจัดช่วงปลายปี 2026
จุดเริ่มต้น
- ลิงก์ไปยังผลงานชนะเลิศ IOCCC ประจำปี 2025 ดูได้จากรายชื่อผู้ชนะที่อยู่ด้านล่างของหน้า
index.htmlของผลงานที่ชนะรางวัลแต่ละชิ้นมีข้อมูลส่วนใหญ่ที่จำเป็นต่อการคอมไพล์และรันโปรแกรมที่ชนะ- สามารถอ่านซอร์สโค้ดของผลงานที่ชนะเพื่อทำความเข้าใจวิธีการทำงาน และดูรายละเอียดเพิ่มเติมได้จากคำอธิบายของผู้เขียน
- ผลงานชนะเลิศทั้งหมดของปีนี้ดาวน์โหลดได้ในรูปแบบ compressed tarball
หมายเหตุทั่วไปเกี่ยวกับการแข่งขันครั้งนี้
- ปริมาณการส่งผลงานและคุณภาพของผลงานใน IOCCC29 อยู่ใกล้ระดับสูงสุดในประวัติศาสตร์
- มีการคาดกันว่า IOCCC28 ซึ่งกลับมาจัดอีกครั้งหลังเว้นไป 4 ปี ทำให้ผู้เข้าร่วมมีเวลาขัดเกลาผลงานมากขึ้น ส่งผลให้จำนวนผลงานส่งเข้าประกวดทำสถิติสูง และคุณภาพโดยรวมสูงกว่าปกติ
- แม้ IOCCC29 จะเป็นปีที่สองติดต่อกันหลังช่วงว่างในปี 2020~2024 แต่จำนวนผลงานส่งเข้าประกวดก็ใกล้เคียงกับปีก่อน และคุณภาพโดยรวมยังคงสูง
- ตั้งแต่สิ้นสุด IOCCC28 ได้มีการจัดทำเอกสารอย่างละเอียดเกี่ยวกับขั้นตอนการปิดรับผลงานใหม่ กระบวนการตัดสิน การคัดเลือกผู้ชนะ การอัปเดตเว็บไซต์ และขั้นตอนการผลิตไลฟ์โชว์ของ Our Favorite Universe
- แม้งานเอกสารนี้ต้องใช้เวลาและความพยายามเพิ่มเติม แต่ผลที่ได้คือการปรับปรุงภาพรวมวิธีดำเนินงานของ IOCCC
- ไม่กี่วันหลังการประกาศผลงานชนะเลิศของ IOCCC29 บนช่อง YouTube Our Favorite Universe จะมีการแยกวิดีโอบันทึกรายการหลักออกเป็นแต่ละช่วงย่อย
- บริเวณด้านบนของ
index.htmlสำหรับผลงานชนะรางวัลแต่ละชิ้น จะมีการเพิ่มส่วน Award presentation ใหม่พร้อมลิงก์ไปยังช่วงวิดีโอใน YouTube -
ข้อมูลเกี่ยวกับโจทย์ท้าทายสนุก ๆ
- ปีนี้มีการเพิ่มโจทย์ท้าทายสนุก ๆ ไว้ใต้ส่วน “Judges’ remarks” ของผลงานที่ชนะ
- ขอแนะนำให้ลองทำโจทย์เหล่านั้นหลังจากทำความเข้าใจว่าผลงานชิ้นนั้นทำอะไรได้บ้าง
- บางโจทย์ง่ายกว่าโจทย์อื่น และในบางกรณีอาจต้องสร้างเวอร์ชันทดแทนของ
prog.cหรือไฟล์ที่เกี่ยวข้อง - บางโจทย์กำหนดให้เขียนคำอธิบายเกี่ยวกับประเด็นเฉพาะบางอย่าง
- หากส่วน “A fun challenge” ของผลงานชิ้นใดยังมีสถานะ still open ก็สามารถมีส่วนร่วมได้ด้วยการส่ง GitHub pull request
- แม้โจทย์จะปิดไปแล้ว หากคุณเห็นว่ามีวิธีแก้ที่ดีกว่า ก็ยังสามารถส่ง GitHub pull request ได้
- หากคณะกรรมการ IOCCC เห็นด้วยว่านั่นเป็นวิธีแก้ที่ดีกว่า ก็จะนำไปพิจารณา
- หากมีข้อเสนอปรับปรุงที่ดีกว่าสำหรับโจทย์ท้าทายสนุก ๆ ของผลงานที่ชนะ ก็สามารถส่ง GitHub pull request ให้คณะกรรมการ IOCCC ตรวจพิจารณาได้
-
กฎและแนวทางของการแข่งขันครั้งนี้
- กฎฉบับสุดท้ายที่ใช้กับการแข่งขันครั้งนี้คือ 2025 rules เวอร์ชัน 29.15 2025-12-02
- แนวทางฉบับสุดท้ายที่ใช้กับการแข่งขันครั้งนี้คือ 2025 guidelines เวอร์ชัน 29.08 2025-12-02
- กฎและแนวทางของ IOCCC29 ได้รับการปรับปรุงครั้งใหญ่เมื่อเทียบกับการแข่งขันก่อนหน้า
- อาสาสมัครหลายคนได้ช่วยแก้ไข ปรับถ้อยคำ รวมเนื้อหา และปรับโครงสร้างโดยรวมให้เป็นประโยชน์ต่อคณะกรรมการ IOCCC
-
มุ่งสู่การแข่งขันครั้งถัดไป
- มีแผนจะเปิด IOCCC30 ราวช่วงปลายปี 2026
- IOCCC30 จะดำเนินการในช่วงเวลาคล้ายกัน และมีแผนจะสิ้นสุดราวปลายไตรมาส 1 ของปี 2027
- ระหว่างดำเนินงานที่จำเป็นต่อการเปิด IOCCC30 ก็มีแผนจะจัดทำเอกสารขั้นตอนภายในเช่นเดียวกับตอนปิดงาน IOCCC29
- หลังเผยแพร่ผลงานชนะเลิศของ IOCCC29 ไปแล้วราว 2~3 สัปดาห์ และจัดการ pull requests ชุดแรกบางส่วนสำหรับ 2025 directory tree แล้ว IOCCC Judges มีแผนจะเข้าสู่ IOCCC vacation
- หลังเปิดเผยผลงานชนะเลิศของ IOCCC28 ก็เคยมีแผน IOCCC vacation เช่นกัน แต่ต้องใช้เวลามากไปกับการแก้บั๊กและปรับปรุง mkiocccentry repo จนเมื่อรีโปมีเสถียรภาพก็ถึงช่วงเปิด IOCCC29 พอดี
- ครั้งนี้มีแผนจะไปทำงานต่อกับ mkiocccentry repo PRs หลังสิ้นสุดช่วง post-IOCCC29 IOCCC vacation
หมายเหตุเกี่ยวกับผลงานชนะเลิศบางส่วน
- ระหว่างการเขียนบทความที่เป็นไปได้เกี่ยวกับผลงานซึ่งเข้ารอบสุดท้ายของชุดรอบตัดสินสุดท้าย มีบางผลงานถูกคัดออกในขั้นตอนสุดท้ายของรอบสุดท้าย
- ขณะเดียวกันก็มีความชื่นชมและการประเมินที่สูงขึ้นเพิ่มเติมต่อหลายผลงานที่เหลืออยู่
- ผู้เขียนผลงานที่ชนะมาจากภูมิภาคที่เคยมีผู้ชนะอยู่แล้ว และใน IOCCC29 ยังมี jingp49 จากภูมิภาคใหม่คือ Taiwan เข้าร่วมด้วย
- มีผู้เขียนสามคนที่ต่างชนะจากผลงานคนละสามชิ้น กลายเป็น Hat trick) แบบ Hat-tricks
- ผลงานชนะเลิศ IOCCC29 ที่น่าสนใจบางส่วนมีดังนี้
- 2025/cable: คอมพิวเตอร์ Subleq
- 2025/cesmoak: Fortran แบบ punch card หลุมดำ
- 2025/endoh3: patch/diff quine
- 2025/jhshrvdp: เกมกึ่ง rogue-like
- 2025/jingp49: ลำดับ Dr. WHO
- 2025/ncw1: GameBoy emulator
- 2025/tompng: เครื่องสร้างเสียงทะเล
- 2025/uellenberg: quine pong
- 2025/yang2: การเข้ารหัส Zoltraak
- รายการข้างต้นเป็นเพียงบางส่วนจากผลงานชนะเลิศยอดเยี่ยมจำนวนมากของ IOCCC29
-
หมายเหตุเกี่ยวกับผลงานส่งเข้าประกวดบางส่วนที่ไม่ได้รางวัล
- มีผลงานยอดเยี่ยมจำนวนมากที่เกือบผ่านการคัดเลือกขั้นสุดท้ายแต่ไม่ได้รับรางวัล
- แม้จะชื่นชมความพยายามที่ผู้เขียนแต่ละคนทุ่มให้กับผลงานของตนอย่างมาก แต่ก็ไม่อาจตัดสินให้รางวัลจากความพยายามเพียงอย่างเดียวได้
- โค้ดที่ส่งเข้า IOCCC29 แต่ไม่ได้รางวัล สามารถนำไปขัดเกลาแล้วส่งใหม่ใน IOCCC30 ได้
- อย่างน้อยหนึ่งผลงานที่ชนะใน IOCCC29 เป็นเวอร์ชันปรับปรุงของโค้ดที่เคยไม่ได้รางวัลในการแข่งขันก่อนหน้า
-
กำลังใจสำหรับผู้เข้าร่วมที่ไม่ได้รางวัลในปีนี้
- แม้ผลงานที่ส่งเข้า IOCCC ปีนี้จะผ่านความพยายามมาอย่างมาก แต่ก็ไม่สามารถมอบรางวัลให้ทุกชิ้นได้
- หากมอบรางวัลให้ทุกชิ้น ก็จะลดทอนความหมายของผลงานที่ถูกตัดสินว่ายอดเยี่ยมที่สุดและคู่ควรกับรางวัล
- แม้ผลงานที่เข้ารอบสุดท้ายจะดีพอจะเป็นผู้ชนะ แต่ก็อาจพ่ายให้กับผลงานที่คล้ายกันแต่ดีกว่าเพียงเล็กน้อย
- หากมองว่าสถานการณ์ของผลงานใดเป็นเช่นนั้น ก็ขอแนะนำให้ส่งเวอร์ชันปรับปรุงเข้า IOCCC ครั้งถัดไป
- มีผลงานที่กว่าจะไปถึงระดับชนะรางวัลได้ ก็ผ่านการส่งแบบปรับแก้หลายครั้ง
- ใน IOCCC ครั้งถัดไปก็อาจลองส่งผลงานคนละแนวไปเลยก็ได้
- หากไม่มีแผนจะปรับปรุงและส่งผลงานที่ไม่ได้รางวัลใหม่ใน IOCCC ครั้งถัดไป ก็สามารถเปิดเผยผลงานนั้นได้
การคอมไพล์และรันผลงานที่ชนะ
- C compiler บางตัวอาจให้ผลลัพธ์ได้ไม่ดีพอ
- หาก compiler ที่ใช้อยู่ทำงานได้ไม่ดี สามารถลองคอมไพล์ด้วย
clangหรือgccเวอร์ชันใหม่ล่าสุดได้ - หากพบปัญหาระหว่างคอมไพล์หรือรันผลงานที่ชนะ สามารถดู FAQ ต่อไปนี้ได้
- ข้อมูลเพิ่มเติมเกี่ยวกับการส่งแก้ไข สามารถดู FAQ ต่อไปนี้ได้
- How to submit a fix: วิธีส่งการแก้ไขผลงาน
- Update author information: วิธีแก้ไขหรืออัปเดตข้อมูลผู้เขียน IOCCC
ผลงานชนะเลิศครั้งที่ 29 ของ IOCCC ประจำปี 2025
- ผลงานชนะเลิศทั้งหมดมีให้ดาวน์โหลดที่ ดาวน์โหลดผลงานชนะเลิศปี 2025
- 2025/ayu: รางวัล IMO
- 2025/cable: รางวัลโปรแกรมจำลองในจินตนาการยอดเยี่ยม
- 2025/cesmoak: รางวัลเรโทรอวกาศ
- 2025/diels-grabsch: รางวัล one-liner ยอดเยี่ยม
- 2025/dogon: รางวัลค่าคงที่อย่างสม่ำเสมอ
- 2025/endoh1: รางวัลที่น่าจะส่องแสงเจิดจ้าที่สุด
- 2025/endoh2: รางวัลที่น่าจะทำให้ช็อกมากที่สุด
- 2025/endoh3: รางวัลความยืดหยุ่นยอดเยี่ยม
- 2025/ferguson: รางวัลตรงกันข้าม
- 2025/howe: รางวัลที่น่าจะบุกยึดมากที่สุด
- 2025/jhshrvdp: รางวัลที่น่าจะเทเลพอร์ตมากที่สุด
- 2025/jingp49: รางวัล Who won
- 2025/kurdyukov: รางวัลที่น่าจะนับได้มากที่สุด
- 2025/mattpep: รางวัลออปชันที่ทำให้อ่านยากที่สุด
- 2025/ncw1: รางวัล emulator ใช้งานจริงยอดเยี่ยม
- 2025/ncw2: รางวัล emulator แบบเศษส่วนยอดเยี่ยม
- 2025/ncw3: รางวัลการใช้ Unicode ยอดเยี่ยม
- 2025/tompng: รางวัลที่ผ่อนคลายที่สุด
- 2025/uellenberg: รางวัลปิงปอง
- 2025/yang1: รางวัลคอมโพสิต
- 2025/yang2: รางวัลคำที่มีมนตร์ขลังที่สุด
- 2025/yang3: รางวัล INABIAF
1 ความคิดเห็น
ความคิดเห็นจาก 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
ที่นั่นยังมีเวอร์ชันที่ไม่ obfuscate อยู่คร่าว ๆ ด้วย จริง ๆ แล้วผมทำงานอยู่ฝั่งนั้น แล้วค่อยใช้โปรแกรมบี้ชื่อตัวแปรทั้งหมดและอัดให้เข้ารูปทรง GameBoy ในภายหลัง
สิ่งที่ยากที่สุดคือ ข้อจำกัดด้านขนาด ผลงานที่ส่งเข้า IOCCC อนุญาตได้ถึง 2503 ตัวอักษรเมื่อไม่นับช่องว่าง และขนาดโค้ดรวมต้องอยู่ใน 4KB ซึ่งเล็กมากสำหรับการยัดทั้งตัวจำลองโปรเซสเซอร์ Z80 และฮาร์ดแวร์ของ GameBoy ลงไป
ตอนแรกผมเขียน GameBoy emulator ที่สมบูรณ์ด้วย C และเริ่มต้นที่ราว 6000 ตัวอักษรเมื่อไม่นับช่องว่าง จากนั้นใช้เวลาไปราว 100 ชั่วโมงเพื่อลดให้เข้ากับข้อจำกัด 2503 ตัวอักษร และช่วงหนึ่งก็ไม่แน่ใจเลยว่าจะยัดลงไปได้จริงไหม
ผมตั้งเป้าให้มันรัน Tetris เพราะ Tetris เป็นเกมที่ค่อนข้างเรียบง่าย จึงตัดฟีเจอร์ที่ไม่จำเป็นออกไป เช่น half carry flag ของ Z80 emulator และระบบ windowing ของการจำลอง GameBoy นอกจากนี้ยังบีบเค้นโค้ด C อย่างโหดร้าย และถึงกับทำเรื่องที่คงไม่มีวันลืมอย่างใช้ implicit int อีกด้วย กฎตรวจสอบของ IOCCC ถูกเขียนเป็นโปรแกรม C ผมเลยใช้เวลา reverse engineer มันเพื่อหาช่องโหว่ด้วย การค้นพบว่า operator บางตัวถูกนับเป็นเพียงหนึ่ง token นั้นมีประโยชน์มากเป็นพิเศษ
พอทำให้เล็กพอแล้ว ก็ยังต้องใส่เกมที่จะรันลงไปด้วย ผมทำไว้ 4 อย่าง: โปรแกรมทดสอบที่เขียนด้วย Z80 assembly, เครื่องคำนวณค่า pi ที่เขียนด้วย assembly, เกม 3D tic-tac-toe ที่เขียนด้วย C โดยใช้ gbdk-2020 และโปรแกรมหมากรุกที่เขียนด้วย C อีกตัว ผมยังพบว่าเกมโอเพนซอร์สจำนวนไม่น้อยรันบน emulator นี้ได้ด้วย จึงเพิ่มตัวดาวน์โหลดเข้าไปเมื่อทำได้ น่าแปลกที่เกมที่ใช้ BCD arithmetic มีไม่มากนัก
เป็นโปรเจ็กต์ที่สนุกมาก
https://github.com/ncw/ccforth/tree/master/examples/gameboy
สิ่งที่ฉันชอบที่สุดคือ โปรแกรมอีมูเลเตอร์ภาษา C ขนาด 366 ไบต์ ที่สามารถรัน Linux และ Doom ได้ [0]
เครื่องเสมือนนี้ทำการอิมพลีเมนต์ OISC หรือ คอมพิวเตอร์ที่มีคำสั่งเดียว [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...
ฉันสามารถเขียนรูทีนไลบรารีมาตรฐานได้มากมาย เช่น การเปิดไฟล์ การรันคำสั่งเชลล์
strstr,strcpyและพูดตามตรงก็มีบางอย่างที่ไม่จำเป็นต่อการเรียนรู้แต่ก็ทำไว้ด้วย เช่นprint(getenv("HOME"))ใช้งานได้ แต่ไม่นานก็รู้ว่าฉันต้องมี โปรแกรมตัวอย่าง สำหรับทดสอบและเอาไว้อวดเพราะงั้นโปรแกรมจริงตัวแรกที่ฉันทำจึงเป็นอินเทอร์พรีเตอร์ brainfuck แบบหลีกเลี่ยงไม่ได้ ผลก็คือภาษาของฉันตอนนี้มีความเป็น Turing-complete ทางอ้อมแล้ว
เวอร์ชันแรกใช้เวลา 9 นาทีในการสร้างเอาต์พุตของโปรแกรม mandelbrot ชื่อดัง ฉันเลยทำการปรับแต่งหลายอย่าง แล้วก็เพิ่มการรองรับคำสั่ง
switch/caseเพื่อให้เร็วขึ้น ตอนนี้สร้างเอาต์พุตเดียวกันได้ใน 2 นาที ดังนั้นยังมีพื้นที่ให้ปรับปรุงอีก แต่ก็ถือว่าก้าวหน้าไปมากวิธีแบบ โกงนิด ๆ ที่เอาภาษาอีกภาษาหนึ่งมาอิมพลีเมนต์อยู่ในภาษาของฉันเองนั้นน่าพอใจมาก แน่นอนว่าทั้งหมดนี้ทำเพื่อความสนุกและการเรียนรู้ และไม่ได้สร้างมาให้ใครรวมถึงตัวฉันเองใช้งานแบบจริงจัง
https://github.com/skx/s-lang
ตรงนี้บอกว่า Set
m[b] = m[b] - m[a]จากนั้นก็ลิงก์ไปยังการอิมพลีเมนต์อ้างอิงบน GitHub [2] ซึ่งบอกว่าแค่มีโน้ตบนกระดาษ [3] ก็พอ โดยใช้วิธีหารค่าที่อ่านได้ทั้งหมดด้วย 4 และการอิมพลีเมนต์อ้างอิง [4] ก็สนับสนุนแบบนั้น แต่ไม่ชัดเจนว่าทำไมถึงเลือก 4 แทนที่จะเป็น 2 มันดูเหมือนเสียบิตทิ้งไปหนึ่งบิต เลยสงสัยว่าบิตนี้จำเป็นจริงไหม หรือถูกจองไว้เพื่อการขยายในอนาคต
ดูเหมือนว่าการอิมพลีเมนต์ดั้งเดิมจะไม่ได้หารด้วย 4 และถูกเพิ่มเข้ามาภายหลัง แต่ฉันก็ยังไม่รู้ว่าจำเป็นไปเพื่ออะไร นอกจากช่วยให้การสร้างโค้ด LLVM ง่ายขึ้นนิดหน่อย ถ้าไม่หารด้วย 4 แล้วระบบที่อธิบายไว้จะเป็นไปไม่ได้หรือไม่ คงต้องไล่ตามตัวอย่างหลาย ๆ อันเพื่อดูให้แน่ชัด อย่างน้อยก็ดูเหมือนว่าจะเข้าถึงได้เฉพาะแอดเดรสคู่ และ PC ก็เพิ่มทีละ 3 ทุกครั้ง ดังนั้นการอ้างถึงตำแหน่งโค้ดคงยุ่งยากแน่
การอิมพลีเมนต์อ้างอิงยังมีพฤติกรรมพิเศษแบบเหมือนเวทมนตร์เมื่อเข้าถึงตำแหน่ง 64 โดยมันจะเขียนทับตำแหน่ง 64~67 ด้วยเวลาปัจจุบัน เรื่องนี้มีในคำอธิบายแบบโน้ตกระดาษ แต่ไม่มีในคำอธิบายหน้าหลัก
คำอธิบายทั้งสองแบบต่างก็พูดถึงแอดเดรส -1 แบบพิเศษ ดังนั้นจึงแปลกที่นาฬิกา UTC ซึ่งขึ้นกับการอิมพลีเมนต์นี้ไม่ได้ถูกทำเป็นแอดเดรสลบ แต่กลับไปทำให้หน่วยความจำที่ควรใช้ได้อย่างอิสระเสียไปแทน
คำอธิบายทั้งสองแบบยังพูดถึงกระบวนการ interrupt จากตัวจับเวลาแบบเป็นระยะ ซึ่งก็น่าเสียดายเช่นกัน เพราะมันนำแอดเดรส 0 มาใช้เป็นตำแหน่ง interrupt handler และ 1 เป็น PC ที่บันทึกไว้ ทำให้ต้องเขียนทับตำแหน่ง 0 ซึ่งเป็นจุดเข้าเริ่มต้นแรกสุดของโปรแกรมทันทีหลังเริ่มรัน
[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
https://www.youtube.com/live/MoWCwZx1Swc?si=eIOlRsKWNKRVRZeB...
เผื่อจะมีคนสงสัย: IOCCC ระบุไว้ในแนวทางอย่างชัดเจนว่าอนุญาตให้ใช้ LLM
"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."
อีกมุมก็น่าสนใจเหมือนกัน LLM จะเดาฟังก์ชันของโค้ดที่ obfuscated ได้ดีแค่ไหน?
ฉันมองว่าเป็นเรื่องดีที่ IOCCC ยอมรับโค้ดที่อาจถูกสร้างด้วยความช่วยเหลือจากเครื่องจักร แบบนี้ยิ่งทำให้คุณค่าของผลงานชนะเลิศที่ทำด้วยมือล้วนดูสูงขึ้น
https://www.ioccc.org/2025/rules.html
สิ่งที่พูดถึงตรงนี้น่าจะหมายถึงตัวสร้างโค้ดแบบทำขึ้นเฉพาะทาง คำว่า "ประวัติศาสตร์อันยาวนาน" ถูกกล่าวไว้อย่างชัดเจน ซึ่งถ้อยคำนี้ครอบคลุมถึงยุคก่อนมี AI ด้วย จึงไม่เข้าใจว่าทำไมต้องตีความว่าเป็น AI
ตัวเว็บไซต์เองก็ obfuscated เหมือนกัน เลยหา C source ไม่ง่ายเลย
อยากให้ Underhanded C Contest กลับมาอีกครั้ง ไม่ได้จะดูแคลนผู้เข้าแข่งขัน Obfuscated C นะ แต่สำหรับฉัน อันนั้นน่าสนใจกว่ามาก
มีการอ้างอิงถึง Frieren [1] อยู่ตรงนี้!
https://www.ioccc.org/2025/yang2/index.html
หนึ่งในตัวละครหลักคือ Fern และแทบจะใช้เวทโจมตีพื้นฐานอย่าง Zoltraak อยู่ตลอด
[1] https://en.wikipedia.org/wiki/Frieren
โอ้โห ผลงาน Game Boy Game of Life ที่ฉันทำ ดันไปอยู่ในหนึ่งในผลงานชนะด้วย!
ตอนปี 2000 ฉันไปสัมภาษณ์ฝึกงานครั้งแรก เป็นตำแหน่งที่จะเข้าทีมโปรแกรมเมอร์ C ผู้สัมภาษณ์เอาหนึ่งในผลงานชนะเก่า ๆ มาให้ดู แล้วบอกให้ลองรีวิวโค้ดก่อนที่พวกเขาจะออกจากห้องไป ประมาณ 5 นาทีต่อมาก็กลับมาแล้วถามว่า
– แล้วเป็นยังไงบ้าง?
– ขอโทษครับ เสียเวลาเปล่าเลย ผมดูไม่ออกจริง ๆ ว่ามันทำอะไร
แล้วทุกคนก็หัวเราะลั่น ก่อนจะบอกว่าเริ่ม ขั้นตอนรับเข้าทำงาน กันเถอะ
สงสัยว่าทุกวันนี้ยังแกล้งเด็กฝึกงานกันแบบนี้อยู่ไหม พอนึกถึงตอนนั้นที่ตัวเองทำอะไรไม่ถูกก็ยังขำอยู่เลย
โอ้โห! IOCCC กลับมาแล้วสินะ!
ขอส่งความรักให้ผู้จัด <3 <3 <3 ขอบคุณที่ทำให้ IOCCC เดินหน้าต่อไป และหวังว่าจะไม่หายไปอีกแล้ว
เดี๋ยวก่อน ฉันยังงง ๆ อยู่
แปลว่า Obfuscated C Code Contest ยังจัดได้ แต่ Capture the Flag จัดไม่ได้งั้นเหรอ? เพราะ AI?
https://twit.tv/posts/tech/ai-disrupts-capture-flag-what-mea...
ถ้าคำถามคือ "คิดไอเดียฉลาด ๆ แล้วให้ AI ช่วยทำออกมาให้ตรงกับข้อจำกัดของ IOCCC ไม่ได้เหรอ?" ฉันคิดว่าเครื่องมือ AI ปัจจุบันยังทำแบบนั้นได้ไม่ดีพอในระดับที่กรรมการมนุษย์จะมองว่ามีคุณค่า