In the days when the console or command line interface was the normal computer interface, beginners were plenty satisfied with learning to write programs to that interface. Now the normal user is familiar with a graphical interface, and command lines feel odd, awkward, or otherwise weird and unreal.
So, my experience is that it's better to have students create graphical applications as early as possible in an introductory programming course. In more advanced courses I'm a firm advocate of teaching the traditional way. In these courses, what is being taught is computer science. In an introductory class, however, the point is to open the doors to controlling the computer, give an entree into the world of programming. At this point the student is probably unsure of whether programming is for them, they may even feel that it's only for geeks and eggheads who are willing to live a monkish existence for the sake of computer control.
Seeing is UnderstandingWith a graphical application, the student gets a result of their work to which they can immediately relate. They can also see the results of mathematical and flow control operations, without the need to read numbers or other output and interpret the result. It also invites experimentation. They can look at what is drawn on the screen and immediately visualize other possibilities, then start asking the questions of how to achieve the desired results.
An intermediate step is to use visual examples at the command line. Make words or numbers move back and forth across the screen on successive lines, for example. Create output that is formatted like the output of an old Trek game. In other words, not just a table of data or a row of numbers, but something that is visually more stimulating.
Examples from the PastIn the days of BASIC, one of my first teaching examples in a class consisted of changing the number of spaces before a printed word to make the word move across the screen:
10 FOR I=0 to 70
20 PRINT SPC(I)+"SKI"
30 NEXT I
40 GOTO 10
This program makes the word "SKI" run from left to right across the screen, then from left to right again. After the students had had a chance to watch it run, I'd ask "How can we make the word ski back and forth across the screen instead of just going from left to right?" Immediately ideas would come forth. Once this problem was solved, the next question would be "How can we make it ski back and forth in smooth curves?" This example would be built on for at least five lessons, likewise the students would spontaneously experiment with their own ideas during this time and afterward.
The same happens today when I introduce simple graphics. Once students are taught to do some basic plotting of points, the purpose and significance of mathematical and flow control operations becomes obvious. They experiment on their own. They start asking about what else they can do. For me, this is more than worth the cost of a little black magic in the code.