Pengumuman Pemenang IOCCC 2025 ke-29

 (ioccc.org)
3 poin oleh GN⁺ 8 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • International Obfuscated C Code Contest (kompetisi kode C obfuscated internasional) adalah kompetisi pemrograman komputer yang mempertandingkan kode C 'obfuscated' yang paling kreatif, artistik, dan sulit dibaca
  • Ini adalah kompetisi yang digelar dua kali berturut-turut untuk kedua kalinya setelah jeda 2020–2024, dan meski jumlah kiriman mirip dengan tahun sebelumnya, skala dan kualitas karya yang masuk tetap berada di level terbaik sepanjang sejarah
  • Yusuke Endoh, Nick Craig-Wood, dan Don Yang masing-masing meraih 3 karya pemenang, mencetak hat-trick, dan juga muncul pemenang baru dari Taiwan
  • Beragam karya pemenang terpilih, termasuk komputer Subleq, emulator GameBoy, dan patch/diff quine, serta diperkenalkan Fun challenge untuk tiap karya pemenang
  • Pengumuman pemenang dilakukan melalui siaran langsung di kanal YouTube Our Favorite Universe, dan IOCCC30 berikutnya dijadwalkan digelar pada akhir 2026

Titik awal

  • Tautan ke entri pemenang IOCCC 2025 dapat dilihat di daftar pemenang di bagian bawah halaman
  • index.html untuk setiap entri pemenang menyediakan sebagian besar informasi yang diperlukan untuk mengompilasi dan menjalankan program pemenang
  • Anda bisa membaca kode sumber pemenang sambil memahami cara kerjanya, dan melihat penjelasan penulis untuk rincian lebih lanjut
  • Semua karya pemenang tahun ini dapat diunduh dalam bentuk compressed tarball

Catatan umum tentang kontes kali ini

  • Jumlah dan kualitas kiriman untuk IOCCC29 berada di level yang mendekati rekor tertinggi sepanjang sejarah
  • IOCCC28 sempat menjadi bahan dugaan bahwa jeda 4 tahun memberi peserta waktu untuk memoles karya mereka, yang pada akhirnya menghasilkan jumlah kiriman rekor serta kualitas kiriman yang lebih tinggi dari biasanya
  • IOCCC29 adalah kontes kedua yang digelar berturut-turut setelah jeda 2020–2024, tetapi jumlah kiriman mirip dengan kontes tahun sebelumnya dan kualitas keseluruhan kiriman tetap tinggi
  • Sejak berakhirnya IOCCC28, proses penutupan kiriman baru, prosedur penjurian, pemilihan karya pemenang, pembaruan situs web, dan produksi siaran langsung Our Favorite Universe telah didokumentasikan secara cermat
  • Dokumentasi ini memerlukan waktu dan upaya tambahan, tetapi hasilnya adalah perbaikan menyeluruh pada cara penyelenggaraan IOCCC
  • Beberapa hari setelah pengumuman pemenang IOCCC29 disiarkan di kanal YouTube Our Favorite Universe, rekaman acara utama akan dibagi menjadi segmen-segmen terpisah
  • Di dekat bagian atas index.html tiap entri pemenang akan ditambahkan bagian baru Award presentation beserta tautan ke segmen YouTube

  • Informasi Fun challenge

    • Pada karya pemenang tahun ini, tantangan seru ditambahkan di bawah bagian “Judges’ remarks”
    • Setelah memahami fungsi karya pemenang tertentu, Anda dianjurkan mencoba tantangan tersebut
    • Beberapa tantangan lebih mudah daripada yang lain, dan dalam beberapa kasus memerlukan pembuatan versi alternatif dari prog.c atau file terkait
    • Ada juga tantangan yang meminta penulisan penjelasan untuk item tertentu
    • Jika bagian “A fun challenge” pada karya pemenang tertentu masih berstatus still open, Anda dapat berkontribusi dengan mengirim GitHub pull request
    • Meski tantangannya sudah ditutup, jika Anda merasa punya solusi yang lebih baik, Anda tetap bisa mengirim GitHub pull request
    • Jika para juri IOCCC setuju bahwa itu solusi yang lebih baik, maka akan dipertimbangkan
    • Jika ada usulan perbaikan yang lebih baik untuk fun challenge pada karya pemenang, Anda dapat mengirim GitHub pull request untuk ditinjau para juri IOCCC

  • Aturan dan panduan untuk kontes ini

    • Aturan final yang berlaku untuk kontes ini adalah 2025 rules versi 29.15 2025-12-02
    • Panduan final yang berlaku untuk kontes ini adalah 2025 guidelines versi 29.08 2025-12-02
    • Aturan dan panduan IOCCC29 mengalami perombakan besar dibanding kontes sebelumnya
    • Sejumlah sukarelawan memberikan suntingan bermanfaat, revisi kalimat, konsolidasi, dan perbaikan struktur umum untuk para juri IOCCC

  • Menuju kontes berikutnya

    • IOCCC30 direncanakan dibuka sekitar akhir 2026
    • IOCCC30 akan berlangsung dalam jangka waktu serupa dan direncanakan berakhir sekitar akhir kuartal pertama 2027
    • Sambil mengerjakan persiapan yang diperlukan untuk pembukaan IOCCC30, dokumentasi prosedur internal juga direncanakan seperti saat penutupan IOCCC29
    • Sekitar 2–3 minggu setelah publikasi karya pemenang IOCCC29 dan setelah menangani sebagian pull requests awal untuk 2025 directory tree, IOCCC Judges berencana mengambil IOCCC vacation
    • Setelah publikasi pemenang IOCCC28, sebenarnya juga ada rencana IOCCC vacation, tetapi banyak waktu tersita untuk memperbaiki bug dan meningkatkan mkiocccentry repo, sehingga saat repositori mulai stabil justru sudah tiba masa pembukaan IOCCC29
    • Kali ini, setelah post-IOCCC29 IOCCC vacation berakhir, pekerjaan pada mkiocccentry repo PRs akan dilanjutkan
    Iklan

Catatan tentang beberapa karya pemenang

  • Dalam proses menulis potensi ulasan untuk kiriman yang masuk ke putaran terakhir dari set penjurian final, beberapa kiriman tersisih pada tahap terakhir putaran final
  • Untuk sejumlah entri yang tersisa, kekaguman dan penilaian positif terus bertambah
  • Para penulis karya pemenang datang dari wilayah yang sudah pernah menghasilkan pemenang sebelumnya, dan di IOCCC29 juga hadir jingp49 dari wilayah baru, Taiwan
  • Tiga penulis masing-masing menang dengan tiga entri, membentuk Hat-tricks dari Hat trick)
  • Beberapa karya pemenang IOCCC29 yang patut diperhatikan meliputi:
  • Daftar di atas hanyalah sebagian dari banyak karya pemenang IOCCC29 yang luar biasa

  • Catatan tentang beberapa kiriman yang tidak menang

    • Ada banyak kiriman hebat yang sangat dekat dengan seleksi final tetapi tidak berhasil menang
    • Upaya yang dicurahkan tiap penulis ke dalam entri mereka sangat dihargai, tetapi penghargaan tidak bisa diberikan hanya berdasarkan usaha
    • Kode yang dikirim ke IOCCC29 tetapi tidak menang dapat dipoles lalu dikirim ulang ke IOCCC30
    • Satu atau lebih karya pemenang di IOCCC29 merupakan versi perbaikan dari kode yang tidak menang di kontes sebelumnya

  • Penyemangat bagi peserta yang belum menang tahun ini

    • Banyak usaha telah dicurahkan ke kiriman IOCCC tahun ini, tetapi tidak semua kiriman bisa diberi penghargaan
    • Jika semua kiriman diberi penghargaan, itu justru akan menghilangkan makna dari kiriman yang dinilai terbaik dan layak menang
    • Bahkan jika kiriman putaran final cukup bagus untuk menjadi pemenang, bisa saja kalah oleh kiriman serupa yang sedikit lebih baik
    • Jika sebuah kiriman dirasa berada dalam situasi seperti itu, disarankan mengirim versi yang ditingkatkan ke IOCCC berikutnya
    • Ada juga kiriman yang mencapai level karya pemenang setelah melalui beberapa kali revisi dan pengiriman ulang
    • Pada IOCCC berikutnya, Anda juga bisa mencoba jenis kiriman yang sepenuhnya berbeda
    • Jika Anda tidak berencana memperbaiki dan mengirim ulang entri yang tidak menang ke IOCCC berikutnya, Anda dapat memublikasikannya
    Iklan

Mengompilasi dan menjalankan karya pemenang

Karya pemenang IOCCC ke-29 tahun 2025

Bacaan terkait

1 komentar

 
GN⁺ 8 jam lalu
Komentar Hacker News

  • Kode emulator GameBoy ini sampai terlihat seperti bentuk GameBoy. Gila sampai bikin tepuk tangan lambat, dan secara pribadi ini yang paling saya suka dari kiriman tahun ini
    https://github.com/ioccc-src/winner/blob/master/2025/ncw1/pr...
    Penulisnya, Nick Craig-Wood, adalah pembuat rclone

    • Senang kalau kalian menikmatinya :-) Kalau ingin melihat bagaimana ini dibuat, sumber aslinya ada di sini
      https://github.com/ncw/ioccc-gameboy
      Di sana juga ada kira-kira versi yang tidak diobfuskasi. Sebenarnya saya bekerja di versi itu, lalu setelahnya saya memakai program untuk menindih semua nama variabel dan memadatkannya agar sesuai dengan bentuk GameBoy
      Batas ukuran kiriman adalah bagian yang paling sulit. Kiriman IOCCC mengizinkan hingga 2503 karakter tanpa spasi, dan ukuran total kodenya 4KB, yang benar-benar kecil untuk memasukkan prosesor Z80 dan emulator perangkat keras GameBoy
      Awalnya saya menulis emulator GameBoy yang lengkap dalam C dan mulai dari sekitar 6000 karakter tanpa spasi. Setelah itu saya menghabiskan sekitar 100 jam untuk menyesuaikannya ke batas 2503 karakter, dan untuk beberapa waktu saya tidak yakin ini akan muat
      Saya menetapkan target untuk menjalankan Tetris. Tetris adalah game yang relatif sederhana, jadi saya menghapus fitur yang tidak dibutuhkan seperti flag half carry pada emulator Z80 atau sistem windowing pada emulasi GameBoy. Saya juga menyiksa kode C dengan sangat parah, dan bahkan melakukan hal-hal dengan implicit int yang tak akan pernah saya lupakan lagi. Karena pemeriksa aturan IOCCC diimplementasikan sebagai program C, saya juga menghabiskan waktu untuk merekayasa baliknya demi mencari celah. Menemukan bahwa operator tertentu dihitung hanya sebagai satu token ternyata sangat berguna
      Setelah cukup kecil, saya juga harus memasukkan game yang akan dijalankan. Saya membuat empat hal: program uji yang ditulis dalam assembly Z80, kalkulator pi yang dibuat dalam assembly, 3D tic-tac-toe yang dibuat dalam C dengan gbdk-2020, dan program catur yang dibuat dalam C. Saya juga menemukan bahwa cukup banyak game open source bisa berjalan di emulator ini, jadi saya menambahkan downloader bila memungkinkan. Ternyata tidak banyak game yang memakai aritmetika BCD
      Ini proyek yang menyenangkan
    • https://github.com/ncw/ccforth
      https://github.com/ncw/ccforth/tree/master/examples/gameboy
    • Keren sekali! Sementara melihat ini, saya malah cuma ngoprek CSS dan PHP
    • Membuat kode terlihat seperti gambar adalah klise yang cukup sering dipakai dalam kontes pemrograman obfuskasi

  • Yang paling saya suka adalah emulator program C 366-byte yang bisa menjalankan Linux dan Doom [0]
    Mesin virtual ini mengimplementasikan OISC, yaitu komputer dengan satu instruksi [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...

    • Selama beberapa minggu terakhir aku membuat bahasa pemrograman sederhana milikku sendiri yang dikompilasi ke assembly Linux/amd64
      Aku bahkan sempat menulis banyak rutin pustaka standar seperti membuka file, menjalankan perintah shell, strstr, strcpy, dan sejenisnya, dan sejujurnya ada juga hal-hal yang sebenarnya tidak perlu untuk proses belajar ini. Misalnya, print(getenv("HOME")) berfungsi. Tapi kemudian aku sadar bahwa aku butuh program contoh untuk pengujian sekaligus pamer
      Jadi tentu saja program nyata pertama yang kuimplementasikan adalah interpreter brainfuck. Berkat itu, bahasaku sekarang secara tidak langsung sudah Turing-complete
      Versi awalnya butuh 9 menit untuk menghasilkan output program mandelbrot yang terkenal itu, jadi aku melakukan berbagai optimasi, lalu menambahkan dukungan untuk pernyataan switch/case agar lebih cepat lagi. Sekarang output yang sama bisa dihasilkan dalam 2 menit, jadi memang masih ada ruang perbaikan, tapi ini juga sudah kemajuan yang lumayan
      Cara agak curang dengan mengimplementasikan bahasa lain di dalam bahasaku sendiri terasa sangat memuaskan. Tentu saja ini semua hanya untuk bersenang-senang dan belajar, dan tidak dibuat agar siapa pun—termasuk diriku sendiri—memakainya secara serius
      https://github.com/skx/s-lang
    • Wah! Mereka juga mengimplementasikan varian SUBLEQ yang Turing-complete dengan cara yang sangat menarik

      VM ini mengimplementasikan OISC, yaitu One Instruction Set Computer. Instruksi ini menerima tiga operan 32-bit bertanda a, b, c, lalu menjalankan program dalam memori m[] sebagai berikut:
      1 PC (program counter) dimulai dari 0
      2 Ambil instruksi berikutnya, yaitu operan 32-bit bertanda a, b, c
      3 Jika bit rendah dari salah satu operan disetel, hapus bit itu lalu ganti operan tersebut dengan m[operand], yaitu nilai hasil dereferensi pada alamat itu
      4 Set m[b] = m[b] - m[a]
      5 Jika m[b] kurang dari atau sama dengan 0, set PC ke c; jika tidak, naikkan PC sebesar 3 word
      6 Kembali ke langkah 2

    • Aku suka idenya, tapi Eternal Software Initiative yang ditautkan [1] agak membingungkan. Penjelasan instruksi untuk mendekodenya ada dalam beberapa versi dan saling bertentangan
      Di sini tertulis Set m[b] = m[b] - m[a]
      Lalu ditautkan ke implementasi referensi GitHub [2], yang di sana mengatakan bahwa memo serbet [3] saja sudah cukup. Pendekatannya adalah membagi semua nilai yang dibaca dengan 4, dan implementasi referensi [4] juga mendukung ini. Tapi tidak jelas kenapa memilih 4, bukan 2. Terlihat seperti membuang satu bit. Aku penasaran apakah bit ini memang diperlukan, atau hanya dicadangkan untuk perluasan di masa depan
      Implementasi aslinya tampaknya tidak membagi dengan 4 dan ini ditambahkan belakangan, tetapi selain sedikit mempermudah pembangkitan kode LLVM, aku tidak tahu kenapa ini diperlukan. Untuk memastikan apakah sistem yang dijelaskan memang tidak mungkin tanpa pembagian 4, sepertinya perlu menelusuri banyak contoh. Mungkin karena hanya alamat genap yang bisa diakses dan PC selalu bertambah 3 setiap kali, jadi merujuk ke lokasi kode memang pasti merepotkan
      Implementasi referensi juga bekerja secara ajaib saat mengakses lokasi 64 dengan menimpa lokasi 64~67 dengan waktu saat ini. Ini ada di penjelasan serbet, tetapi tidak ada di penjelasan halaman utama
      Kedua penjelasan sama-sama menyebut alamat ajaib -1, jadi aneh rasanya jam UTC yang bergantung pada implementasi tidak dibuat memakai alamat negatif alih-alih merusak memori yang sebenarnya bebas dipakai
      Keduanya juga menyebut proses interupsi timer berkala, dan ini juga agak disayangkan. Karena alamat 0 dipakai ulang sebagai lokasi interrupt handler dan 1 sebagai PC yang disimpan, program harus menimpa lokasi 0—yang merupakan entry point awal—segera setelah dimulai
      [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
    • Aku sudah mengunduh dan membangunnya, dan dengan yakin bisa bilang ini adalah hal paling mengesankan yang pernah kulihat sejauh ini
    • Videonya ada di sini
      https://www.youtube.com/live/MoWCwZx1Swc?si=eIOlRsKWNKRVRZeB...

  • Kalau ada yang penasaran: IOCCC secara eksplisit mengizinkan penggunaan LLM dalam pedomannya
    "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."

    • Saya sendiri cenderung non-AI, tapi dalam kasus ini menarik. Terutama karena tidak banyak kode C yang diobfuskasi tersedia online, dan LLM juga sulit menyimpulkan maksud dari kode nyata. Jadi saya penasaran apakah sudah ada yang pernah melihat karya peserta yang dibantu LLM
      Kebalikannya juga menarik. Seberapa akurat LLM bisa menebak fungsi dari kode yang diobfuskasi?
    • Ini terutama berdampak pada juri. Mereka pada dasarnya membuka kemungkinan banjir kode murahan, tetapi mengingat sifat kompetisinya, rasanya para juri sangat mampu membedakan kode yang menarik dari kode berkualitas rendah
      Menurut saya bagus juga jika IOCCC menerima kode yang mungkin dibuat dengan bantuan mesin. Itu justru membuat nilai karya pemenang yang murni dibuat manual terlihat lebih tinggi
    • Jadi sekarang ini sudah jadi kompetisi senam LLM?
    • Kalau AI termasuk dalam kategori "alat", maka aturan 7 jadi kontradiktif
      https://www.ioccc.org/2025/rules.html
      Sepertinya yang dimaksud di sini adalah generator kode kustom. Karena mereka secara eksplisit menyebut "sejarah yang kaya", yang jelas mencakup masa sebelum ada AI, saya tidak paham kenapa itu harus ditafsirkan sebagai merujuk pada AI

  • Situs webnya sendiri juga diobfuskasi, jadi sama sekali tidak mudah menemukan source C-nya

    • Langsung saja ke https://www.ioccc.org/2025/#inventory
    • Benar-benar sulit dinavigasi. Sulit memahami ini kompetisi tentang apa, seolah-olah situsnya dibuat dengan asumsi pengunjung sudah tahu sebelumnya
    • Kalimat pertama menaut ke bagian daftar pemenang, dan di kanan atas setiap pemenang ada tautan C code

  • Saya berharap Underhanded C Contest kembali lagi. Bukan mau meremehkan peserta Obfuscated C, tapi yang itu jauh lebih menarik buat saya

  • Ada referensi Frieren di sini! [1]
    https://www.ioccc.org/2025/yang2/index.html
    Salah satu protagonisnya adalah Fern, dan ia hampir sepenuhnya memakai sihir serangan umum Zoltraak
    [1] https://en.wikipedia.org/wiki/Frieren

  • Ya ampun, implementasi Game of Life untuk Game Boy yang saya buat masuk ke salah satu karya pemenang!

    • Setelah membuat emulator, saya mencari-cari di GitHub game yang bisa dijalankan dalam batas 32KB. Saya menemukan milik Anda, jadi terima kasih :-) Saya menambahkan opsi di skrip ./try.sh agar pengguna bisa mengunduhnya dari GitHub dan mengujinya

  • Pada tahun 2000 saya menjalani wawancara magang pertama saya, untuk bergabung dengan tim programmer C. Para pewawancara menunjukkan salah satu karya pemenang lama dan keluar ruangan, meminta saya me-review kodenya. Sekitar 5 menit kemudian mereka kembali dan bertanya
    – Jadi bagaimana?
    – Maaf, saya sudah membuang waktu kalian. Saya benar-benar tidak mengerti apa pun
    Lalu mereka semua tertawa dan berkata mari mulai proses perekrutan
    Saya penasaran apakah intern masih dikerjai seperti ini sampai sekarang. Kalau mengingat betapa malunya saya waktu itu, saya masih tertawa

  • Ooooh! IOCCC sudah kembali!
    Banyak cinta untuk para penyelenggara <3 <3 <3 terima kasih sudah menjaga IOCCC tetap hidup, semoga tidak pernah menghilang lagi

  • Tunggu, saya agak tidak paham
    Jadi Obfuscated C Code Contest boleh, tapi Capture the Flag tidak? Gara-gara AI?
    https://twit.tv/posts/tech/ai-disrupts-capture-flag-what-mea...

    • Capture the Flag punya tujuan yang jelas, sedangkan Obfuscated C Contest tidak. Saya bisa memahami AI berkembang dalam kompetisi yang berorientasi tujuan, tetapi dalam kompetisi terbuka yang melibatkan rasa artistik, saya tidak yakin apa yang harus dianggap sebagai kemajuan
      Kalau yang ditanyakan adalah, "bukankah orang bisa menemukan ide cerdas lalu meminta AI mengimplementasikannya sesuai batasan IOCCC?", menurut saya alat AI saat ini masih belum mampu melakukannya pada tingkat yang akan dianggap bernilai oleh juri manusia