Originally posted here by pwaring

What, so the programmer doesn't have to worry about handling input now either?
It's not that they don't have to worry about input but it is generally as hard as writing the initializing code for starting up a window, it is trivial. Also handling input takes no real time considerations because you are just polling the hardware every iteration.

Programmers have to be aware (although not necessarily involved in, if using an external graphics library) of ALL the steps you mention, even if they don't have to write the code for it. Furthermore, programmers definitely have to worry about input - even in the most simplest of programs user input is one of the things that can cause major problems if not handled correctly. Again, you could use a library to validate the input, but still the programmer will have to worry about it.
Let's not vear off the topic we were originally discussing. We were talking about speed considerations and how you even believed you had to choose a low language project for real-time applications. I never would disagree with you on how programmers need to have a sense for how all their external dependencies should work. Knowing basic theory on graphics rendering is essential even if you're making use of a third party library but worrying about optimizations, custimizations and inlining assembly is nothing programmers should be worrying about. A game company can make a game now a days in a high level language like ruby, python, or LISP by using 3rd party libraries. Speed isn't as important as it use to be.