use Perl

Perhaps it isn't inactive. There were 70 messages there since Monday and it's now Sunday.

Perhaps all the popular modules have their own mailing lists or other forums.
Meaning by definition, there won't be many messages.

But even some well-known modules like ingy's don't have forums. In particular, cpanforum didn't spring to mind, when I wanted to post something about Test::Base somewhere.

Perhaps I should have sent it to perl-qa@perl.org.

Laziness, impatience and hubris, the 3 perl
programmer virtues may have their source in these
3 critical personality traits from the Psychology
of Computer Programming (1971) by Gerald
Weinberg, apparently one of the first 'people'
people in programming.

Assertiveness is the other side of the coin of
humility, and both are necessary. Without
humility, success leads to overconfidence
(hubris), which leads to blind self-destruction.
On the other hand, assertiveness is like a steam
boiler without a safety valve. And on the
gripping hand, a spirit of self-criticism is like
a safety valve without a steam boiler.

This collusion of opposites is a reason for the
humour of the 3 perl virtues.

The other necessary traits: ability to tolerate
stressful situations, adaptability to rapid
change, and neatness.

This book seems to have got under the radar here.
I wonder why I have heard more about a
contemporary at IBM, Brooks and his Mythical
Man-Month, which appears to have come out 4 years
later in 1975, when essentially the same
observation is made by Weinberg.

It appears like Brooks he escaped from IBM into
academia. It appears the suits sent him back to
do a PhD in psychology. The experience seems to
have only changed him superficially. I wouldn't
call the book scientific, despite the inclusion
of some experiments he did teaching programming.

He tells stories about life as a programmer in
relation to some ideas of academic psychology.
One funny one is about 'a military project that
involved the creating of a world-wide network.'
The government was getting completely fictional
accounts of the progress being made. He also says
that when programmers don't get feedback about
their work, 'they start to vary the input in
arbitrary ways to see the effect--to get some
feedback, even at the risk of a poor evaluation.'

Some interesting hairshirt views about learning:
'When our program does not run correctly, we have
the opportunity to learn more specific lessons.
Quite often, under the pressure of production,
the programmer is tempted to bypass a trouble
spot with a fix that he knows will work, since it
does not use some new technique which he was
trying to master. .. [But] he will have missed a
golden opportunity for learning. No time will be
more propitious for learning than that time at
which the need for learning is felt most
strongly--the very moment when we detect an
error.'

Some principles for language design: Uniformity
or 'If a programmer asks, Can I write ...? The
answer should be yes. Just like the child who is
told, No, too often, the programmer working in a
nonuniform language will tend to be discouraged
from trying new things.' This is close to DWIM. I
thought I saw something close to TIMTOWTDI too,
but perhaps what I remember was my looking for
it.

The issue of whether your personal atttitude to the language is determined or not by your attitude to Larry Wall is an interesting one, however. A lot of prominent perl people seem to have a zany sense of humor, zanier than that of other language proponents. But perhaps they acquired it as they learned the language. Perhaps proponents of other languages have a sense of humor too, but are funny in private, rather than in public.

Here's another URL I want to bookmark, David Hume's History of England, vol 6: http://oll.libertyfund.org/Home3/HTML.php?recordID=0011.06

The skeptical Scottish philosopher's account of The English Civil War of the 17th century, fought over religion, warns of the dangers of sectarianism. It's fascinating. Never again will you ridicule Third World political developments, having read this.

He blogs (in Japanese) about the difficult
situation, starting from O'Reilly's laying off of
Larry Wall and ruby's Matsumoto Yukihiro's
possibly getting hit by a bus.
http://blog.livedoor.jp/dankogai/archives/5028008
2.html

I found Design Patterns in the library while
looking for a Haskell book and had to read it,
because I had read so much about it.
It's quite a different sort of book than Damian
Conway's Object-Oriented Perl. I haven't actually
read that book, but judging from the downloadable
chapters, it's a nuts-and-bolts book. Perl
provides you some object-oriented jigsaw puzzle
pieces and Object-Oriented Perl helps you work
out which pieces fit together to get things done.

Design Patterns, on the other hand, is a top-down
kind of book. Its focus is on what sorts of
things get done in object-oriented programming,
and although there is C++ and Smalltalk code, I
think it is as an example. The book is not just
for users of those languages.
The impact of the book was because of this
super-language level, I think. It was
conceptualizing (naming and framing) design
structures which existed but hadn't been
recognized and which couldn't be captured in just
a discussion of language syntax.
The role of Christopher Alexander in the book is
interesting. He may have been inspirational, but
there is hardly anything in it that depends on
his ideas, I think.
If he read it, I think he would have felt
disappointed, because of the lack of real use of
his ideas. Peter Gabriel has written stuff which
puts Alexander's ideas to work better, I think.

Actually, I get the feeling that the esteem in
which Alexander's ideas are held is little
consolation to Alexander for his inability to get
architects to take him seriously.
A better metaphor than architecture is genre
analysis. It fits in with the language metaphor.
On the first page they use the analogy of plot
structure and OO design decisions.
The book is kind of repetitive. It looks like
they wrote parts separately, and then put them
together. The motivations for each pattern are
often repetitions of the discussion in the Lexi
case study, which seems not to be a real program,
but a made-up example.
I've been reading the book in the kitchen, rather
than in front of the computer, and although I'm
doing something with iterators at the moment, I
don't think the discussion of Iterator pattern is
going to have much effect on what I'm doing.

Perhaps I'll regret not reading more carefully
when the book is back in the library and I'm
struggling with code.
Actually, they do a good job of teaching. The
problem is that the real work is done by the
learner.
In their brief history of the writing of the
book, they say in the final year they put a
greater emphasis on the problem a pattern solves.
This was connected to the difficulty of learning
the patterns. The only ones who could understand
the patterns were the ones who already used them.

This is an important observation. I can't really
connect my problems with the problems they are
solving, so I am not going to learn their
solutions.
For more serious learners, perhaps end-of-chapter
exercises will not help very much. The only way
for learners to learn the patterns is to
conceptualize everything as a nail and try to hit
it on the head with a hammer.
Only when they get a better feeling for what is
and isn't a nail will they have really learned
the patterns. Until then, they are trying them
out.
This is the reason for the complaint by
experienced programmers about the rigidity of
people who have just read the book. They are
still learning.
This is a higher-level learning than the learning
of how to code the patterns, but connected to
this lower-level learning.

I was frustrated by not being able to see a list
of the most recent journals while logged in, the
same way that you can when not logged in, so I
felt quite pleased with myself, realizing
http://use.perl.org/search.pl?op=journals gives
you that list, logged in or not.

At the same time, I wondered why it took me so
long to realize that I could enter by hand the
URL, looking at it from the link on the front
page.