Don't you just love writing this sort of thing :)
castironpi at gmail.com
Sat Dec 6 12:48:55 CET 2008
On Dec 5, 7:20 pm, Lawrence D'Oliveiro <l... at geek-
> In message <32cf4a79-a6e3-4250-9b5a-1ec80c748... at j32g2000yqn.googlegroups.com>, Aaron Brady wrote:
> > On Dec 5, 4:32 am, Lawrence D'Oliveiro <l... at geek-
> > central.gen.new_zealand> wrote:
> >> The code people write is probably a direct reflection of their thinking
> >> processes: For example, slow, plodding, one step at a time, incapable of
> >> imaginative leaps, versus those who operate directly on larger patterns
> >> at once...
> > That distinction operates indirectly on smaller patterns.
Well, I was trying to be funny. But sarcasm is defined as something
said in jest that someone else would say seriously; so perhaps it's
not the most reliable tone for text. Chalk it up to a failed
communication, even though a successful expression.
I agree that programming takes imaginative leaps and operates on large
patterns. You implied that people's thinking processes vary by
"pattern size", which I thought was interesting. But 'leaps' implies
carelessness (wrong word, possibly). Is it possible to tackle a large
pattern one step at a time? Say, writing a quick sort in assembly?
> Do you find this
> (open, gzip.GzipFile)[Entry.endswith(".gz")](os.path.join(PatchesDir, Entry), "r")
> complicated or hard to understand?
It's not easy. I can't understand it at a glance, if that is your
question. But it's not obfuscated, that is true.
If I can compare programming to chess: I look at a board and you tell
me, 'white to play, mate in 5 moves.' If the board is busy (not just
Rook and King), it could take a long time to find the mate. It's
complicated, but not hard to understand. It requires
"holding" (introducing a term) several things in mind at once: first
expose the Bishop, then capture the Pawn, etc. But it is not easy in
the same way that a 'mate in one' board is, even though the pieces are
> It's made up of very simple pieces,
> combined according to very simple rules, viz:-
> A tuple of candidate functions:
> (open, gzip.GzipFile)
> A choice from that tuple according to a condition:
> And finally, arguments to pass to the chosen function:
> (os.path.join(PatchesDir, Entry), "r")
As you explain, your program (taking the fragment to be an entire
program) is composed of three "very simple pieces". I would say,
write them as three very simple pieces.
Here's a possible compromise between yours and Arnaud's:
opener( os.path.join(PatchesDir, Entry), "r" )
It's kind of swampy, I concede. About the same number of characters,
5x the lines.
Maybe something in between:
opener= (open, gzip.GzipFile)[Entry.endswith(".gz")]
path= os.path.join(PatchesDir, Entry)
opener( path, "r" )
> See, it's so simple, a child could understand it. A child who isn't burdened
> with the preconceptions that seem to afflict some participants in this
'No preconceptions' is a pretty tall order. The most basic facts
about the natural numbers weren't formalized until the 1880s, but
people used them successfully for thousands of years before, evidently
on preconception alone.
To be plodding and slow (as well as meticulous and deliberate, by the
way), the child would need 'preconceptions' about tuples, functions,
Boolean variables, etc. You might call those plain 'conceptions', and
use the other definition, 'bias' for noisegroup participants.
Emotions are biased, as are small sample sizes (small-sized samples).
I think it's also a tall order to ask a group of people to keep
objective for any length of time. Thus, since we're people, and we're
interacting, and we can't keep objective forever, we'll be non-
objective sometimes, and therefore won't all understand your program.
Perhaps you are wanting to write a 'preconception-tolerant' program: a
program that is tolerant of (can be read by) readers with
But I'll bite: what preconceptions? Favoritism?
More information about the Python-list