On Thu, Sep 4, 2014 at 4:23 PM, Rustom Mody <rustompm...@gmail.com> wrote: > A patient goes to hospital. The first thing the nurses do (even before the > doctor arrives) is to stick all kinds of tubes into... eyes, nose, ears and > other unmentionable places. The doctor arrives and orders a few more > invasions. > Some of these are for helping eg a saline drip to a dehydrated patient, mostly > they are for 'debugging' the patient -- what things are there in the blood > (etc) > that should not be or what is defcient that should be etc etc > > Would you consider it acceptable that when the patient is declared cured, > he/she is sent home with these tubes hanging out? > > Sure there are exceptions -- eg a patient needs a plaster/pacemaker etc. > As a rule he/she should be freed from all this. > > You seem to think a print hanging out of a program to be ok, normal. > I consider it exceptional.
You keep saying that it's exceptional. You haven't really said why. It's the simplest form of "program produces output for the human to see", which all of your subsequent examples are more complicated versions of: > 1. Program is a gui -- There can be no meaningful prints, only > GUI-toolkit dialogs. (I actually disagree - several of my GUI programs have consoles for debug output - but that's a separate point.) GUI toolkit dialogs are inherently more complicated than simple print() calls, so they can be learned later. "See, this is how you print to a console. Now, if you do this, this, and this, you instead get a dialog." > 2. Program is a web-app -- It is painful and inefficient to generate > the html with prints. The correct approach is to use a templating engine The templating engine is just another more complicated form of output. Once again, learn the simple and fundamental first, and then add complexity - starting with small levels of complexity like "You are user %d of %d."%(user_num, concurrent_limit) and going up from there. > 3. Program is a classic unix filter. If it is doing something entirely trivial > -- eg cat -- it matters little how its written. If it is doing something > significant > it is best structured into IO and computation separated And how is the first of those going to be done? Somewhere, you need to do I/O, and that's going to involve something very like print. > 4. Programmer is a noob. You would start him on scripts. > I would start him in the REPL I would actually start on both. But if you're going to copy and paste a bunch of stuff to python-list and say "here's what's going wrong, can you help", it is MUCH easier if that's a script than an interactive session that might have had almost anything preceding it. > There is such a thing as law of primacy -- what is learnt first is remembered > most. And there are many important things when learning programming/python. > One of them is debugging. print is excellent for that. > > But there are more important things than that -- like structuring code and > using appropriate data structures. Putting print in the place of primacy > screws up that learning curve Okay. Here's the thing I most want people to remember: Make the program tell you stuff. Because that's more important as a debugging help than *anything* in the world. No matter how beautiful your data structure is, it's useless if you don't know how to get the program to tell you about it. You might like the idea of pure mathematical thinking, and that's fine as a theory. If you want to teach programming on a blackboard, go ahead, and use extremely functional style. Me, I've been tutoring several Python students over the past few weeks, and I want to see them get info back from the program. Using print() is perfect for them, and it won't be a bad thing in the future. Maybe it's ugly and messy and offends your theory-clean sensibilities, but it solves real-world problems. Practicality beats purity. Especially when it actually solves real problems that people pay money to get solved. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
