Python is going to be hard

[Chris Angelico]

On Thu, Sep 4, 2014 at 4:23 PM, Rustom Mody <rustompmody at 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