I was about to argue in favor of using print as a debugging tool because it's easier for students to understand than a debugger. But I changed my mind: I think using a good debugger during lecture to show students what is happening to control flow and to variable values as some new concept executes may help students create a useful mental model. The side-effect is that students may be comfortable using the debugger, mimicking what they saw in class.

I still think (as others have noted) that console-based input/output is beneficial in its simplicity. In principle you could provide a GUI as part of the starter code for assignments until you're ready to teach students how to write their own -- but in a 1-semester intro-to-CS course I'm not sure that I'd want to take time away from other topics to teach GUI development. Tough call.

The reason that a simple text based interface is often used is that it is very simple to implement and run, and you don't have to spend time in the class teaching the student how to build a UI or GUI or other ways to interact with the program.

Littering the code with print statements is inefficient but is probably how a majority of coders learned how to debug their code. What's important is understanding what is happening as each line executes.

The question from a teaching perspective is what are the alternatives? You could take time to teach the students other ways of interacting with the code, or put them into an integrated environment of some kind. Or provide them with a pre-built UI or GUI and just tell them not to worry about how that is created.

I often wonder to what extent educators will allow students to use modern IDE's. These are very sophisticated now and either provide suggestions or outright fix your syntax, API calls, some will even offer performance optimizations. On one hand it is important that any coder really understand the details of this and should do it themselves without an IDE, on the other hand you don't want a student to use up all of their time in the class struggling with some simple syntax issue.

You've asked several questions here, so I'll attempt to address them separately. However, a big disclaimer that a lot of what you've asked for is subjective, so take my opinions here with a grain of salt.

TL;DR: In my experience, text-based output is essential for teaching debugging, however text-based input is a huge pain and generally isn't all that engaging for an introductory course. There are no concepts intrinsic to text-based input that can't be deferred until later.

Q. Is it necessary / advisable to teach text-based input and output in a non-CS intro programming course?

I would definitely advise teaching text-based output, solely because it's the easiest way to teach and use debugging.

Unless you have a good reason to teach text-based input (and here "good reason" is defined as "connects to your course outcomes in some way"), I don't think there's any reason to try to fit text-based input into your course solely for tradition. Is it useful? sure. Is it necessary for a intro course for non-cs majors? No.

Q. Is there pedagogical value?

There is some value in all knowledge, but the sheer breath and depth of topics available to be taught in an introductory programming course is such that you have to draw some lines in the sand as to what to keep and what to cut. I suggest those lines are connected to your course outcomes.

Q. Does it teach something necessary?

The main thing it's going to teach your students is that taking text-based input and doing something useful with it is a non-trivial exercise with lots of edge cases.

If that concept is central to your course outcomes, then you should include it. Otherwise...

Q. If so, can it be delayed? It can absolutely be delayed. How long it can be delayed depends on the scope and sequence of the program this course is a part of.

Q. What are the alternatives, or is there no alternative?

If you mean "what are the alternatives for allowing students to create interactive programs"? There are plenty. You could use windows with buttons, arrow keys, audio / video input devices, etc...

I have wondered the same. Since the 1980s when we down-graded to Microsoft's windows, The concept of standard-in and standard-out no-longer seems relevant, to most learners. So does it make sense to continue to write programs that write to standard-out?

What can we do?

• Use turtle graphics (I have done this).
• Create windowing programs (this it to hard for a beginner, and win forms is un-necessarily hard for an expert).
• Embrace the command line: upgrade to Gnu/Linux, teach the command line, write bash scripts.

In the Unix shell we use text in and out. The output of one program in the input to the next. A function returns data by sending it to standard out (printing). So if you print it, then it is returned or passed to the next program in a pipe-line.

When it comes to input and output, it has been my experience that students cling to whatever they are immersed in first.

print is great to make sure that your language is properly installed and hooked up with your IDE because it can typically be run in 1 line with no libraries, dependencies, linkages, etc. After that, it can be dispensed with if you wish.

As Ian pointed out, there are plenty of people who stick with printing to the console, and there is nothing wrong with this per se. But if you want your kids immersed in a different toolset with a different UI because it will be more useful in your field, that's fine, and you should pull them into that environment as soon as you conceivably can.

I've been coding for 20 years in non-cs fields. I've worked on several >100k line code bases.

Almost every program I write comunicates with the outside world via text, usually a file hand or file-handle-like connection to stdin and stdout.

In addition, I also almost exclusively do my debugging via print statements (or output to debugging logs).

IDEs and graphical debuggers can be very useful tools, but they can become a crutch that excuses the student from thinking. Print statements encorage the student to really reason about the logical and flow of their program - they must be able to hold the program in their mind and understand where it is going to be important to output a variable state, or just ping "here" to the terminal.

Now obviously I wouldn't insist that students must do this when working on large, complex code bases, but while they are making simpler things, things where holding the whole structure in your head is possible, then I think it is good for them.