6 ms·

9 Hole Code Golf Challenge

42 points by codecurve 13y ago

joliv 13y ago
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!
- laumars 13y ago
  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 😊
fjcaetano 13y ago
Seems quite interesting. I may give it a try
userbinator 13y ago
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.
- TylerE 13y ago
  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.
  - userbinator 13y ago
    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.
    - TylerE 13y ago
      Modern processors commonly have 8MB of L2 and 16MB or even more of L3 cache. Shaving 10kb off a binary is meaningless.
      - aeykie 13y ago
        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.
      - userbinator 13y ago
        ...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.
- breadbox 13y ago
  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.

42 points by codecurve 13y ago

joliv 13y ago

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!

laumars 13y ago
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 😊

fjcaetano 13y ago

Seems quite interesting. I may give it a try

userbinator 13y ago

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.

TylerE 13y ago
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.
- userbinator 13y ago
  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.
  - TylerE 13y ago
    Modern processors commonly have 8MB of L2 and 16MB or even more of L3 cache. Shaving 10kb off a binary is meaningless.
    - aeykie 13y ago
      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.
    - userbinator 13y ago
      ...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.
breadbox 13y ago
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.