I took part in ICFPC 2018 this year to continue what has now become a tradition for me, though one that is not observed as regularly as I would like to. The task this year was similar to 3D Printing a set of objects based on models representing the respective objects, while minimizing the overall cost. A solution for the problem of printing such an object would emit instructions for one or more “nanobots” to create the object by creating matter in a three-dimensional matrix of voxels. It was fun to watch these nanobots assemble such objects in my model-viewer, though it would definitely have been more fun to actually come up with a decent solution as well for this problem in the given time.
As in 2017, I picked a higher-level programming-language compared to C or C++ to tackle the problem this time: Go. I am quite new to this language, but it turned out to be simple enough to pick up, thanks to the Go Tour, and start building programs. I built a viewer for the models using the go-sdl2 package, which turned out to have a straightforward API.
As has been observed by many others, Go seems to be language without fancy bells and whistles, but it still makes programming fun while providing a good enough performance through its compiler and runtime. Its standard library seems to be quite compact compared to some other languages (*cough* Java *cough*) while providing a lot of useful, well-designed, and well-documented functions and data-structures. In other words, Go might turn out to be a good language for me to do casual programming. (Unlike apparently many others, the lack of generics in Go is not a deal-breaker for me — it has never been one for me in the programming-languages that I have used, though a couple of them did eventually end up supporting generics.)
What I did not like about Go (apart from its insistence on using TABs –
yuck!), was the
contortions I had to go through to satisfy its weird workspace-layout diktat. I
refused to change my preferred source-code layout, so this meant playing with
setting GOPATH again and again until it could satisfy all parties.
Thankfully it seems that with Modules in Go 1.11 this
madness might come to an end. (I also found it weird to use an upper-case first
letter to indicate an exported symbol, but I can live with that.)
As for the task itself, I did not progress beyond creating the model-viewer and an execution-tracer. As has become a depressing pattern during each such ICFPC attempt, I spend far more time creating a visualizer for the problem than creating a solution for it. I need to find a way to break out of this bad habit of active procrastination.
The source-code for my attempt this year can be found on Bitbucket, on GitHub, and on GitLab. You can find some other write-ups on /r/icfpcontest.