Although, everyone is +1ing here I agree ledow here. The only way to work on code on an embedded board is using a cross compiler and an ethernet connection to work across.
Since when? The embedded systems I work on use rs232 and usb... And who says the R-Pi is an embedded system? It's not. It's a full blown Linux computer running a multi-user, multi-tasking operating system with local storage and a built-in TCP/IP stack and 1000's (nearly 30,000 in Debian) of software packages already avalable.
For example does the keyboard slow down when you're typing on the rasp pi?
Obviously I don't know as I don't have one, but why should it? It's Linux, running on a 700MHz 32-bit processor. Did the keyboard slow down when I was using a 4MHz 16-bit processor? Not unless I really thrashed it. There is very occasionally a bit of keyboard lag when I work on my own workstation, but hey.. if I type make -j2 in the Linux kernel tree on my weedy 1.7GHz AMD processor, then maybe I get what I deserve...
How long does it take to compile code that doesn't say "hello world"
It's not going to be fast, but is it important? for a start, I don't think people will be actively devleloping BIG programs for the R-Pi. It's fairly self-limiting in that respect, but as it's just another Linux box, then cross compiling is pretty easy. I develop Linux kernels for my smaller devices (routers & PBXs) on faster boxes when I can, but they'll still do the compile if I give them enough resources.
I also think it would be good to show people how most professional programmers work*. Setting up the correct environment can be as much a learning exercise as getting hello world on screen.
I'm a professional programmer. I use text windows (xterm), VI (vim) and Makefiles. I use gdb and valgrind on occasion. When developing code for embeded systems (AVR and PIC), I do cross compile on my Linux system and use a (usb) serial line for downloading, testing and debugging, but the environment is the same - vim and makefiles. A personal project I did recently was a dive computer running on a PIC processor. That was about 12K lines of .c and .h files and compiles into about 90KB of object code, all done with vim and makefiles (and gimp which I used for some graphics and the bit-mapped font) but all the paid embedded stuff I do is still text editor, makefiles (cross) compilers and serial downloads.
It's no good comparing an old system, their OS is built around thier specs, so when I learnt on the BBC I had no problems with keyboard slowdown. When I programme Linux on a Samsung ARM I had loads of problems with key press slow down.
* I realize a million of you are now going to say I don't, but everyone I know uses a cross compiler and a Ethernet TFTP /BOOTP/DHCP, with ddd/eclipse set to debug over IP
Well now you know (of) someone who doesn't
But I also wonder if you/others are missing the real point: The Raspberry Pi is just another Linux box - We've had Linux software development for many many years now - so develop and test your software on any other Linux box, then simply copy it over and type 'make'. Once. The exception is going to be code poking the GPIO, but I suspect that's not going to be many programs once some initial libraries are written, and it's easy to simulate.
You will not be TFTP booting the R-Pi! (Well, you might, but you'll need to write the bootloader first, put it on the SD card and off you go - and if you really need to to that, then you're writing a new operating system for it and I do wish you the best of luck!
I mean; what are you going to write on the R-Pi running Linux that will not run on any other Linux box, with any other processor that you can compile it to? (other than low-level hardware drivers). There is nothing special about the R-Pi. It's just another Linux box!