tough-to-explain Python

[Hendrik van Rooyen]

"D'Arcy J.M. Cain" <d.. at druid.net>

> One might also argue that divorcing the design from the code is the
> problem in a lot of legacy code.  See Agile Programming methods.  Now
> you could say that there is a design step still in talking to the
> client and making a plan in your head or in some notes but that's like
> saying that Michelangelo was done creating after discussing the Sistine
> Chapel with Pope Sixtus and that the rest was just a house painting job.

How do you know that it was not exactly like that - he did, after all, take
a much longer time than expected to complete the job - just like a house
painter that gets paid by the hour. :-)

It is also unreasonable to assume the opposite fallacy - that he was in
a creative frenzy from the start to the time at the end when he was
cleaning his brush after applying the last spot of paint.

But it is a valid point - it is often difficult to draw the line between the
design and the implementation - and one of the reasons that we all
like to program in python, is that it is almost a language that is a
design language that can also be run directly.  - I have lately been doing
stuff like writing rough prototypes using python syntax to serve as
designs for some of the assembler thingies I do. If you muck around
a bit at the lower level, you will also be more aware of the dichotomy
between the design and the implementation - in python, it is not obvious
at all.  In assembler, it is glaring.  But in either place, if you get it wrong,
you suffer. -  your programs cripple along, or they hardly do what
you thought they would, and they bear no relationship with what the
customer wanted.

- Hendrik