[Tutor] Simple Python Program

[Steven D'Aprano]

On Sun, 1 Aug 2010 01:11:41 pm bob gailer wrote:
> On 7/31/2010 8:24 PM, Steven D'Aprano wrote:
> > On Sun, 1 Aug 2010 04:35:03 am bob gailer wrote:
> >> Continue to avoid writing functions. They are not necessary for
> >> such a simple program.
> >
> > That is *terrible* advice. Absolutely awful.
>
> Well I disagree. I was trying to steer the OP to get the simplest
> possible program running, then do incremental expansion.

In hindsight, my post was a bit harsh. I actually agreed with nearly 
everything else you said, which I should have said. So I would like to 
apologise for the way I said what I said.


> In my understanding user defined functions serve these purposes:
> 1 - modularizing large programs

Leave out the "large", and you would be right. There is no limit to how 
small a program need be before using functions becomes appropriate. A 
one line program could be better off split into functions if the line 
is complex enough.


> 2 - factoring out common code
> 3 - providing callbacks
> 4 - choosing callable objects from some collection.
> 5 - providing a main function for the if __name__ == "__main__" idiom
> 6 - what else can we think of?

Code reuse, ease of testing, simplicity of debugging, separating the 
interface from the implementation, avoiding side-effects, writing 
self-documenting code, ease of refactoring, simplifying redesign, and 
probably many others.


> None of these are needed in this simple case.

Whether needed or not, splitting the code into small, easily testable, 
self-contained pieces is never a bad thing to do. Sometimes, rarely, 
for performance reasons you might choose to give up all those positives 
in order to win a bit of extra performance in a critical section of 
code, but that's the only reason I can think of to *actively* avoid the 
use of functions. (As opposed to passively avoid them because you just 
started programming yesterday and haven't got to "Chapter 3: Functions" 
yet.)


> > Functions should not be avoided unless necessary. Functions should
> > be used unless there is a compelling reason to avoid them.
>
> Once the OP has succeeded in getting some program running he will
> experience some relief and satisfaction. Then I think it is time to
> add language features. But not just for the sake of using them.

This is an excellent point. I might take the OP many, many hours, or 
days, or weeks, of effort to get the entire program working. The 
process until that point is just frustration after frustration as 
things go wrong. Until the entire function is working, it's hard to see 
any positive progress because it's just bug after bug after bug.

Or he can write one function that does one small thing, debug that, and 
get a sense of satisfaction that this function, at least, is working as 
designed, before going on to write the next function. Functions are not 
just for the compiler, they are for the human reader and writer too. 
It's easier to wrap your brain around a small, self-contained piece of 
code that does one thing in three or five or ten lines, than a 
comparatively large piece of code that requires thirty or fifty.


> > This is not 1972 any more, and we're not teaching kids to write
> > spaghetti code with BASIC and GOTO.
>
> Functions have no relationship to avoiding spaghetti code. Python
> makes spaghetti code impossible since it lacks a goto or equivalent
> statement.

Nonsense. Procedural programming (the use of functions, procedures, or 
sub-routines) was created partly to avoid spaghetti code. The primary 
reason GOTO is to be avoided is because of the tendency to lead to 
spaghetti. (Technically a function call is a specialist kind of GOTO. 
In early BASIC, it would be like a GOSUB. But it is a structured jump, 
tamed and on a leash rather than running wild like GOTO.)

Of course, the use of functions in and of itself does not guarantee you 
won't write spaghetti code. Object oriented programming sadly lends 
itself to class-based spaghetti (fettuccine perhaps?). But that's not 
likely to be a risk here.


> > Functions, or their object-oriented
> > equivalent methods, are *the* single most important feature of
> > programming. And they're simple too
>
> Well - almost simple. Until you get into issues like global vs local
> names, positional vs keyword arguments, required vs optional
> arguments, default values (especially mutable objects), * and **,
> generator functions, magic methods, nested defs, decorators, ....

Of course. But apart from the distinction between local and global, 
everything else is optional.


> > -- they might not be the first thing you teach an absolute newbie
> > who has never programmed before
>
> That is what our OP appears to be.

He's experienced enough to be attempting to write functions. I don't 
believe you are doing him a favour by discouraging him.



-- 
Steven D'Aprano