The developer of this thing has thoughtfully provided a "hello.c" file and cc. Oh, yes, and emacs. So go ahead and type:
cc -o hello hello.c
and marvel at the speed.
This environment is just like my first full-time, non-student programming job. There was no IDE, so we pretty much lived in emacs. I haven't used emacs in decades, but my fingers still remember the key bindings for the commands -- as long as I'm not trying to consciously remember them.
It was on a 68020 running at 16 MHz which delivered a grand total of 2 MIPS at 16 MHz. We shared all that computing power among four programmers, which was luxury because the system was supposed to support 16 users (32 max).
It seems almost inconceivable, but the funny thing is it was really just as fun programming back then as it is now with a supercomputer all to myself. Our office was next to a reservoir, and used to start a compile, wait five minutes for the parsing to catch any syntax error (about 75% of the time), then go for a walk on the 1.5 mile trail around the pond. Then I'd stop in at the convenience store to buy a cup of coffee, and head back to the office, and make would just be finishing up the linking. God forbid you got a link error though. That's why we had time to read the entire Unix manual (all eight sections) cover to cover. Many times.
This has fed my conviction that user perceptions of system speed are as strongly affected by consistency as it is by absolute speed. If you're used to a build taking fifteen seconds,a sudden change to 30 seconds seems unbearable.