Amazing
Uh, about that 9-line emulator : could the guy who wrote that interest himself in an open-source version of VMware ?
He can do it in 20 lines, I'm not picky.
The Twenty-Ninth International Obfuscated C Code Contest – or IOCCC for short – is back again with the results of the 2025 competition. This year, one of the entrants has a unique new trick up their sleeve: a valid use case. When we reported on last year's event, it had just been revived from a four-year hiatus, so we're happy …
Wow! That Adrian Cable can put this 366 byte obfuscated subleq computer VM together, pipe some vmlinux.bootimage into it, and then ¡BAM! ***Doom*** -- at decent speed!!!! (around 4:23 on that 1ˢᵗ YT) ... Awe-friggin-some!
Also notable, from ref. 6 of the FPGA PDF in TFA (Mavaddat and Parhami, 1988 "URISC: The Ultimate Reduced Instruction Set Computer" -- pdf available online), it seems the subleq arch dates back to '88, from those 'same' (kindof) U. Waterloo (CAN) folks who gave us WATFOR, WATFIV (FORTRANs), and MAPLE (symbolic and numeric computing) among others ... big brains there (good company)!
And, oh my, Jonah Uellenberg's repeatedly compiled self-modifying Pong frame quine just bakes the cake! Yes, "If you squint a bit, you can see a Pong screen in the whitespace", ***BUT*** if you go to Uellenberg's github page for his quine-compiler (named: Insert), he's got a nifty animation of the code self-modifying (itself), with the ball and paddles moving about in it too ...
It's 100% crazy good stuff (too impressive!)! [ https://github.com/uellenberg/Insert ] ;) [Thx for writing about it!]
>
> Wow! That Adrian Cable can put this 366 byte obfuscated subleq computer VM together, pipe some vmlinux.bootimage into it, and then ¡BAM! ***Doom*** -- at decent speed!!!!
>
Indeed. There are so many egotistical show-offs in the world of tech, but guys like this truly humble us.
The Art of Computer Programming
"... called like that for a reason."
Indeed ...
But it looks (more and more) like it is on the road to becoming a lost art.
eg: just look at what Debian has turned into, with all the systemd crap floarting* about.
* It was actually a typo but, on reflection, decided to let it stay.
Seems to fit nicely.
.
Exactly.
For me the most frustrating thing about being a 'normal' developer (i.e. one who works in a normal company making normal business software.) is being told how to program.
I don't mean how to solve problems, I mean how to 'program', shit like 'Make sure you use spaces around ==, make sure you don't use var, make sure you do use var, make sure you put all arguments on multiple lines, make sure all arguments are on the same line, etc etc...
It feels like all codebases have the style of the person in the team who shouts loudest. Once your code base gets more than a few months old these rules can start to conflict too. I have a project I work on that's about 5 years old... It complained that I'd added extra unnecessary brackets around something the other day, so I removed them... at which point it complained that I'd not made the operational order explicit with brackets....
I'd much rather programmers be able to work with any code, and I worry about the amount of time people spend correcting fluff like this as a result of code coverage tools.
It's an art as well as a science.
(Just to be clear, there is merit in a consistent code layout, but most IDEs these days will allow you to run formatters on load and save, so you can make it a programmatic thing, rather than a pestering thing...)
I have a particular personal gripe about people (and linters! especially sodding linters) who try and make themselves arbiters of what is and is not acceptable code.
Did it compile? Then it's correct. The compiler* sets the standard for what is and is not valid in any given language. Anyone who insists that you're not allowed to
function(){ tiny one line function }
because it has to be
function(){
tiny function that's now three lines long in the diff
}
or some bullshit like that can fuck all the way off. It compiled. It was correct. Stop complaining about it!
*or interpreter, if that's the sort of language you're using.
It depends on context.
If you’re working on a codebase that’s expected to have a relatively long lifetime and to be maintained by a team, then readability is paramount.
With these kind of projects, we end up spending far more time reading code than writing it. Even your future self will thank you for making that less of a chore.
The point however is that readability has very little to do with code formatting, how many brackets you use etc. it’s much more about using the right nouns for variables / objects and verbs for functions / methods, functional decomposition, keep it simple stupid etc.
That’s as much art as science.
Tell that to the poor sap who has to:
The best code doesn't just work. It's also easy to understand and modify by other people (or yourself long after it was first written).
Almost all source code evolves over time. There's a special place in programmer's hell for those who think obfuscation or bizarre identifier names are a good idea.
And style matters. It's all about readability and a lot of that comes down to what the eye/brain is expecting. It's easy to overlook something because it's not where you were expecting it.
I think you've found the case here that I disagree with. Arguments about the One True Brace Style aside, unless you're writing it as a lambda, that should definitely go over multiple lines.
Readability to humans is arguably more important than readability to the compiler, which will waste no time in telling you if it doesn't compile, but won't find the bug that whoever comes back to your wall of code has to correct eighteen months down the line when the client is shouting about not being able to get paid because your code went wrong.
1. then somebody decided
function {
is the right way (to make things unreadable) than the readable
function
{
and now all code is this mess.
2. decades ago we were told to include comments in code to explain things. we had very little disk space.. now with petabytes of storage hardly any conmment in kernel or any application code.
Dislike these practices to show off you think you are a GOAT.
Who here doesn't love the arguments between multiple competing LINTers, that result in you having to add an additional file to your work to tell them all to shut up about whether or not you should be putting comments on all the getters and setters on generated boilerplate code. Nobody cares if the model class for your database ORM has some hinky names in it because somebody 25 years ago made a mistake following their own convention for naming database fields, and you can't change any of it now. It's all a distraction from writing the business logic in a completely different file, that's probably going to work out as ten lines of pretty obvious code anyway.
> For many of these programs, you really must see what they do to believe it
I have the same views regarding (my)code as I do with foreign languages. Specifically if it hard for me to understand them, it should be hard for them to understand me.
May C remain obfuscatable and it's obscurity celebrated.
"Unusually for the IOCCC, it has a real-life use case"
Every piece of code submitted over the years has a real-life use case ... Specifically, education.
Writing that kind of code forces the coder to learn far more about the language(s) in question than they would ever learn through normal means. This can (and does, I've seen it!) lead to interesting and useful methods in more prosaic, every-day code.
Same can be said for writing a compiler ... or even your own text editor.
...I tried compiling the Nixie tube code with both GCC 11.4, on my Linux Mint box, and - purely for shits'n'giggles - SAS-C 6.50 under my Amiga emulator. I wasn't seriously expecting the latter to compile, and it didn't, but surprisingly even modern GCC barfed at the code. Didn't seem to like the trailing //||\\ lines that represent the "pins" in the source-code. I removed those lines and the code compiled, but then it didn't do anything other than segfault.
Clearly I'm missing any or all of 1) a brain, 2) a decent C compiler, or 3) some non-default compiler options.
Applause to the IOCCC entrants, though; I am in awe of their ability to make functional code that is indistinguishable from line-noise and not do so in Perl.
I think AI must be banned from this contest at once. AI will be either Hors-Concours (because every single program is obfuscated, regardless of how hard it works towards not being it), or completely fail at doing creative stuff.
Otherwise, I had a lot of fun watching those tiny pieces of code doing interesting stuff.
It's not "only C", there was also an Obfuscated Perl contest for a few years, and a handful of slightly more obscure variations on the theme.
Why not Rust? Because most Rust programmers haven't yet learned to lighten up and not take themselves so seriously, whereas most C and perl folks are inveterate punsters, at the very least.
Oh man, obfuscated Perl...
I used to love writing Perl one liners to absolutely baffle people. My absolute classic was a one liner that would loop through text files and pull out all the email addresses.
I wrote it about 20 years ago but I lost that one liner about a decade ago...I rebuilt my machine and forgot to backup a folder...so I'll never see it again. Not sure I have the Perl skill these days to pull it off again...I've barely touched Perl in well over 15 years.
Obfuscated C looks bonkers, obfuscated Perl looks downright insane...it literally looks like someone smashed their face into the keyboard.
No doubt using a regular expression, but I'm willing to bet it didn't cater for every single valid format of an email address, because the regex for that would make your eyes fall out.
My advice is: don't:
"...this vulture was still at school and learning BASIC...
Which reminds me of Diomidis Spinellis' 1991 entry: a working BASIC interpreter, contained in a rectangle of C code that fits precisely onto a 80x20 terminal screen with some room to spare (albeing not much). It was the first entry I ever saw (I came across it on Fidonet) and I remember being mightily impressed. Grab a copy and run LANDER.BAS to play Lunar Lander!
Many years ago as a fresh faced CS student, I fancied myself to be a hotshot C programmer. I stumbled on to the IOCCC and thought that I would be able to cook up a great entry of my own. After all, I was a pretty good programmer, and had some artistic talents to boot, which surely would put me in the running.
Then I started digging in to that year's winners.
I realized that not only was I not about to create a winning entry for IOCCC, I also realized that I would not be able to feed myself using my programming abilities. Instead, I learned how to run and terminate CAT5 cable, learned how routers worked, and managed to earn my keep in that realm.
As they plaster all over the website, recommendations to use github, discord, youtube, bmac, patreon and even mastodon - when none of those things should ever be used (there is no excuse as to why the IOCCC "needs" to use github - after all, the website doesn't use anything even functionally superior site hosts and git hosts don't offer and you can already download winning entries as a tar.bz2 file just fine).
Also, while they've at least selected a free license for 2025, even though CC licenses should not be used for software (unlike previous years where a proprietary license was selected), all the submitted programs are proprietary software, as for each winning entry, the prog.orig.c doesn't include the source form (it's only good fun to go and obfuscate things, if you also provide at the same time the original non-obfuscated version - as then the reader is free to choose whether they want to work out how the program works themselves, or if they want to take less time looking at the non-obfuscated program) and none of the programs include a suitable license statement either.
Back in the early days of UNIX applications had to be compiled not just for each system type but just about each individual computer. It was normal for applications to be delivered as source so it was common to run the source through an obsurfurcation program that produced "Shrouded Source". This filter removed comments and whitespace, replaced variable names and generally tried to make the code unreadable.
I've had junior colleagues who seemed to think that making difficult to read lines of code was clever. They tended to either get reformed or find another job. Source is designed primarily to be human readable.
in the 80/90's with a few 100mb of disk space we needed to add a header comments to every function and explain what it did. now with terabytes of storage it hard to find any comments in code, even in the kernels.
and dont get me started why i should format thing like
function {
instead of
function
{
it would be nice to have a code readability contents. obfuscation code GOAT is an indication of how deep coding style and coding has sunk.