5
$\begingroup$

I teach an intro programming course in a social science department. My field is geographic information systems. The goal for the course is for the students to understand scripting in an interpreted language so that they can automate analytical workflows or add custom functionality to off-the-shelf software. The language we use is Python, but the question is more general than that.

Programming languages have some way of obtaining input and displaying output. There is a long tradition in computer science of starting with "Hello, World!" as a basic program that produces output. Additionally, output statements can be used to display the state of variables for debugging purposes. Introducing input and output is common in computer science textbooks (Think Python 1.3 The first program) as well as domain specific texts such as the one that I use for this course.

The problem I am running into is that beginning students can't seem to unlearn this after we move on to new material. Throughout the semester they turn in assignments that are littered with unnecessary print statements. These are "harmless" in the sense that they don't alter program logic, but make for sloppy code, and are perhaps not harmless if the students think that they need to do this and don't transition to, for example, using the IDE for variable inspection as they code.

Q. Is it necessary or advisable to teach text-based input and output (e.g. Python's input and print functions) in a non-CS intro programming course?

Is there pedagogical value? Does it teach something necessary? If so, can it be delayed? What are the alternatives, or is there no alternative?

Improve this question
$\endgroup$
3
  • 5
    $\begingroup$ Re, "Hello world," The purpose of Hello World is not to teach the students anything about the language. The purpose is to ensure that everybody knows how to use the tools. After everybody in the class has successfully created, built (if necessary), and run a Hello World project; then they are ready to write their first program. $\endgroup$
    – Solomon Slow
    Commented May 14, 2020 at 1:42
  • $\begingroup$ In a simple program, the printfs are the result. Students need to realize that they are not magic wands, any more than writing, "I have $1,000,000" on a piece of paper makes it the case. In the beginning, they have trouble separating the things that do stuff from the scaffolding. printf changes roles from the doing part at the beginning to the throw-away part later on. The students have to realize this. Writing a check is at first mysterious, but later you must realize that you can't write it for more money than you actually have in the bank. $\endgroup$
    – Scott Rowe
    Commented May 27, 2020 at 21:53
  • 1
    $\begingroup$ Actually I think the purpose of a "Hello, world" program is to make the programming task at hand a little less intimidating and to give the student a quick success to build upon. "Debugging a blank sheet of paper" can be very intimidating and just seeing a working example can break the ice. $\endgroup$
    – Uncle Long Hair
    Commented Jun 18, 2020 at 16:10

6 Answers 6

Reset to default
5
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • 2
    $\begingroup$ If students are leaving debug prints in the code, then teach them about logging (that can be turned off). $\endgroup$
    – ctrl-alt-delor
    Commented May 14, 2020 at 12:20
  • $\begingroup$ Just to provide a counter-argument, I too have been coding for 20 years (actually closer to 30). I was reluctant to start using graphical development environments and IDE's but finally did so some years back and am amazed that it took me so long. Today's tools go far beyond just providing a debug environment but also check and correct syntax, provide alternative API calls, etc. Also there are some situations where you can't debug with print statements because you can't modify and redeploy the code, you have to connect to a running process and need an IDE to do that. $\endgroup$
    – Uncle Long Hair
    Commented Jun 18, 2020 at 16:09
  • $\begingroup$ I guess this is specific to "non-cs" fields: Most people would have no idea what "deploying code" or "attaching to a running process" would mean. Not because they are not sufficiently skilled/experienced, but because they are not concepts that are useful in those fields. There is no such thing as "production", nor any long running processes in many places where non-cs academics use code. Code is something you write to analyse the data you've just collected. I'm guessing this applies in the OPs case. $\endgroup$
    – Ian Sudbery
    Commented Jun 23, 2020 at 13:06
4
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I was going to write your first sentence, but more generally. It is true of everything people learn. The main differentiator of students as best I can see is how hard they cling to those first few examples and concepts. Learning several extremely different languages and environments early on helps them learn what they all actually have in common. $\endgroup$
    – Scott Rowe
    Commented May 27, 2020 at 21:45
  • $\begingroup$ @ScottRowe "The enemy gate is down". :) $\endgroup$
    – Ben I. ♦
    Commented May 28, 2020 at 0:50
  • $\begingroup$ Right, we must have definitions in order to function, but we have to be able to redefine them to solve new problems. This is why Lisp makes me uncomfortable: it seems to consist of nothing but the ability to make your own magic wands. Most people need a bit more structure than that. $\endgroup$
    – Scott Rowe
    Commented May 28, 2020 at 10:45
2
$\begingroup$

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...

Improve this answer
$\endgroup$
2
$\begingroup$

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.

Improve this answer
$\endgroup$
1
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ What do you mean by "concept of standard-in and standard-out no-longer applies"? Also, what do you mean by _"win forms"? I use Windows Forms for almost everything, but I'm sure you don't mean that, because it's such a specific technology. $\endgroup$
    – VisualMelon
    Commented May 25, 2020 at 10:23
  • $\begingroup$ Win forms = Mircosoft's Windows forms. But you are correct. It is not the only system that is too hard. And made some changes to answer to make it clearer. $\endgroup$
    – ctrl-alt-delor
    Commented May 25, 2020 at 10:36
1
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.