IMHO "code golf" would be a lot more fun and interesting (and even practical in some ways) if the goal was to produce the smallest executable and not source.

Why? That's a near useless-metric on any device with more than 32kb of ram, and highly variant on things like compiler and library minor versions.

In a time when computation is largely constrained by memory bandwidth, the size optimisation can have quite practical benefits. There will definitely be variance on different systems but this is why you standardise on the system for a competition.

Also, I think it's not quite so impressive to see a 100-byte source file turn into a few hundred KB or few MB binary as it is to see what could be done in a 64K, 4K, or even 256 bytes binary.

Modern processors commonly have 8MB of L2 and 16MB or even more of L3 cache. Shaving 10kb off a binary is meaningless.

Modern hard drives have gigabytes of storage, so shaving 100 characters of a source code is pointless. I always thought code golf was for fun more than anything.

...shared among all the processes in the system. Having 8MB of cache to yourself may seem like a lot, but share it equally with 100 others and you're left with ~80KB.

Obviously I agree (check out my page of teensy executables sometime), but it's much more complicated to compete on that metric. The size of a compiled executable can vary widely depending on details of your compiler and/or platform, making for a very unportable challenge. In a monoculture world, that would be more practical, but that's not how things are nowadays.

However, I will say that trying to minimize the size of the source involves much of the same kind of resourcefulness and lateral thinking that minimizing executable size does. So despite the drawbacks, it really is just as fun.

Wow, code golf challenges are usually easy problems and the hard part is the optimization--these problems would be hard even on their own. Good luck!

Those challenges are easier than they sound (I've already mentally prototyped all bar one of the holes).

The real challenge would be writing each hole in a different language to avoid penalties. I'm a bigger language whore than most, and I've 'only' coded in about a dozen different languages, most of which I'm probably quite rusty in now due to years of neglect (Eg Pascal). But I guess if you were stuck then you could cheat and class object revisions as a separate language (Eg C and C++; Pascal and Delphi; etc).

This does look fun though 😊

Seems quite interesting. I may give it a try