Alright people who know how to tell there computer what to do and how to get there... I bring you a challenge from the interweb.

THE 4K CODE CHALLENGE

Objective: To create the most productive/useful code that as source code is no larger than 4 kilobytes (4096 bytes). There is no restrictions as to what your code does, or what language it is used in.

Rules:

• The code must be yours, and you must be willing to give your code out to the public domain.
• You must state EXACTLY what your code does. If it is malicious you must state what it does/exploit.
• There is no restriction on what language, however markup languages are not allowed. Javascript/VBScript are, and any HTML required to perform the task is not counted towards the byte tally however objects calling to Javascript/VBScript do.
• Common standard libraries (.h files, javabeans, perl modules etc) are allowed and dont count towards the byte tally.
• You can use as many seperate files in your source code as you wish.
• If you code requires to be compiled to run, it must be able to compile without a problem. For C and other languages that require a makefile, these will not go towards the byte tally.
• Any other data in the form of databases, information etc that isn't a part of the code also does not count towards the byte tally.
• If your program requires parameters to begin, you must state what they do.

Gentlemen, START YOUR TEXTEDITORS

this thread seems dead or something, so i take it that either nobody's hacking up some code or everybody's still at it.confirm/deny :O?
as for me, i'm about 3/4 done i think.. and i still have plenty of bytes to waste code and long strings/variable names on. coders using a language the kind of perl, ruby or python have a huge advantage when only filesize and productivity matter... so this challenge is somewhat unfair to, say, the c/c++/java/malbolge crowd imo.

The challenge is a great one, but I don't think people have that much time. It's also amazingly open-ended.

BTW, here's my recipe for guaranteed success:

Make a tiny makefile that takes filenames, inserts them into a file, and compiles the result. Put all the code in filenames, leave the file empty, and on some filesystems you could fit an entire kernel tree in 0 bytes.

All perfectly within the rules too! Whee! >;D

I'd do something but I'm busy with other things. We shall see.

"you must be willing to give your code out to the public domain."
what

>>5

You post anything here it becomes property of the internet... sif you have a say on the matter.

then why saying it

Is perl::sdl okay?

I was thinking of using SDL from Perl too, but it seems to kind of suck. Just the base SDL library, with nothing much in the way of graphics drawing except blitting. Boring.

well, don't you get an event loop, timers, stuff like that, and audio?

I think it'd be cool to whip up a little keyboard-based realtime synth with some sort of cheezy visual feedback.

You could always use Allegro. Oft overlooked, but both mature and stable. Perfect for 2D gaming with things like blitting, timers, audio, midi, controls, yadda, yadda. I have no idea if someone has cooked up a perl module that interfaces with it though.

Allegro is a lot older than SDL (and better maintained). Perhaps they were looking for something more lightweight, but I think Allegro should have become de facto, not SDL.

I've written several (unfinished, of course) games in Allegro, and it is a joy to work with, but it's really not very good at interfacing with the host OS. SDL wins there, but not by much. SDL is also more widely supported.

Allegro was cool back when I was playing with DJGPP and DOS extenders. Nowadays it reaches too much and carries around too much useless cruft.
SDL seems leaner and meaner, leaving other details to other libraries.

However, I absolutely despise the "leave other details to other libraries" mindset. It makes for a horrid mess of libraries to get and install to compile code, or even worse, to install just to run the software.