I haven't tried it, but a game of this complexity looks like it could be implemented in roughly the same number of bytes of binary, meaning it fits in a bootsector...
Coincidentally, a sector on optical media is typically 2048 bytes.
2048 implemented in 487 bytes of C
31–40 of 47 posts
Re: 2048 implemented in 487 bytes of C
#32I never understood why this sort of thing is interesting. Let's say you can program 2048 in 487 bytes of C ... and then someone else comes along and they can program it in 387 bytes of C. So what? Is there a use case in the year 2014 where 100 bytes matter?
How many bytes would it take to code it in C in a human readable fashion? Such that some other programmer could look at it, understand it, modify it, fix bugs, etc?
Is the savings in bytes going from the latter case to the former case really an issue in 2014, and does it outweigh the downside (which I think is enormous) of generating obfuscated code?
Having said all that, as an exercise purely in "how small can by code be, regardless of how obfuscated I make it", I suppose it is ... interesting?
but even still I have to admit I don't get the appeal
Re: 2048 implemented in 487 bytes of C
#33I never understood why this sort of thing is interesting. Let's say you can program 2048 in 487 bytes of C ... and then someone else comes along and they can program it in 387 bytes of C. So what? Is there a use case in the year 2014 where 100 bytes matter? How many bytes would it take to code it in C in a human readable fashion? Such that some other programmer could look at it, understand it, modify it, fix bugs, et…
Dude, it's just for fun. It's done in the same spirit as making speed runs for video games. Does everything have to be completely utilitarian?
Re: 2048 implemented in 487 bytes of C
#34I never understood why this sort of thing is interesting. Let's say you can program 2048 in 487 bytes of C ... and then someone else comes along and they can program it in 387 bytes of C. So what? Is there a use case in the year 2014 where 100 bytes matter? How many bytes would it take to code it in C in a human readable fashion? Such that some other programmer could look at it, understand it, modify it, fix bugs, et…
Although the obfuscated case is really pushing it in terms of code usability and readability, being able to write miniaturized code is really important in some industries (ie defense projects).
Take for example the Kinetis KL02 ( http://www.engadget.com/2014/02/25/freescale-kinetis-kl03/ ). With only 32KB of storage and 4KB of RAM, writing efficient code with a small footprint is important. These microprocessors can be used to make swarms of autonomous fly sized drones, and programmers that can cram more procedures into those 32KB are extremely rare and useful.
Re: 2048 implemented in 487 bytes of C
#35Earlier quoted context omitted.
Sure: gcc -o 2048 2048.c Ignore all the warnings.
That was the first command I have tried, but I get many of those: error: use of undeclared identifier 'X'. I am running OSX.
If you haven't installed gcc on your OSX, the command gcc actually calls clang.
http://stackoverflow.com/questions/19535422/os-x-10-9-gcc-li...
Re: 2048 implemented in 487 bytes of C
#36I never understood why this sort of thing is interesting. Let's say you can program 2048 in 487 bytes of C ... and then someone else comes along and they can program it in 387 bytes of C. So what? Is there a use case in the year 2014 where 100 bytes matter? How many bytes would it take to code it in C in a human readable fashion? Such that some other programmer could look at it, understand it, modify it, fix bugs, et…
Dude, it's just for fun. It's done in the same spirit as making speed runs for video games. Does everything have to be completely utilitarian?
Point taken. I think I need to take a vacation
Re: 2048 implemented in 487 bytes of C
#37I never understood why this sort of thing is interesting. Let's say you can program 2048 in 487 bytes of C ... and then someone else comes along and they can program it in 387 bytes of C. So what? Is there a use case in the year 2014 where 100 bytes matter? How many bytes would it take to code it in C in a human readable fashion? Such that some other programmer could look at it, understand it, modify it, fix bugs, et…
Although the obfuscated case is really pushing it in terms of code usability and readability, being able to write miniaturized code is really important in some industries (ie defense projects). Take for example the Kinetis KL02 ( http://www.engadget.com/2014/02/25/freescale-kinetis-kl03/ ). With only 32KB of storage and 4KB of RAM, writing efficient code with a small footprint is important. These microprocessors can…
That could be true for other embedded projects as well, but then it's the size of the executable binary that is of concern, not necessarily the size of the source code on your development box.
Re: 2048 implemented in 487 bytes of C
#38I never understood why this sort of thing is interesting. Let's say you can program 2048 in 487 bytes of C ... and then someone else comes along and they can program it in 387 bytes of C. So what? Is there a use case in the year 2014 where 100 bytes matter? How many bytes would it take to code it in C in a human readable fashion? Such that some other programmer could look at it, understand it, modify it, fix bugs, et…
Dude, it's just for fun. It's done in the same spirit as making speed runs for video games. Does everything have to be completely utilitarian?
It's also very good mental exercise, since it forces you to think even more about the corner cases of the language and its syntax. Even if you won't be using all these corner cases in production code (hopefully), it will make you a better programmer.
I find that reading minified/obfuscated code really helps with spotting syntax errors and related subtle bugs in regularly formatted code. Instead of relying on cues like indentation, you begin to parse more like a compiler, and things like missing semicolons stand out.
Re: 2048 implemented in 487 bytes of C
#39Earlier quoted context omitted.
Although the obfuscated case is really pushing it in terms of code usability and readability, being able to write miniaturized code is really important in some industries (ie defense projects). Take for example the Kinetis KL02 ( http://www.engadget.com/2014/02/25/freescale-kinetis-kl03/ ). With only 32KB of storage and 4KB of RAM, writing efficient code with a small footprint is important. These microprocessors can…
That could be true for other embedded projects as well, but then it's the size of the executable binary that is of concern, not necessarily the size of the source code on your development box.
Exceptions like C++ templates exist (in which a small amount of source can expand to a huge binary), but usually there tends to be a general correlation between the size of the source and the binary.
Trying to write as little source code as possible also leads to trying to find the simplest, most concise algorithm to do a particular task, and that also has effects on the binary size.
Re: 2048 implemented in 487 bytes of C
#40This is called sheer brilliance!