Does Python really follow its philosophy of "Readability counts"?

[Paul Rubin]

Mark Wooding <mdw at distorted.org.uk> writes:
> Some people (let's call them `type A programmers') have decided that
> they want to be assisted with writing correct programs...
> Other people (`type B programmers') don't like having their (apparently?
> possibly?) correct programs rejected....
> I think trying to persuade a type A programmer that he wants to work
> like a type B programmer, or /vice versa/, is difficult, bordering on
> futile.  Type A stereotypes type B as a bunch of ill-disciplined
> reckless hackers; type B stereotypes type A as killjoy disciplinarians.
> Meeting in the middle is difficult.  (`We just want to add a little
> safety.'  `You want to take away our freedom!'  Etc., /ad nauseam/.)

That's an interesting analysis.  You know, I think I'm really a type B
programmer, interested in type A techniques and tools for the same
reason someone who naturally sleeps late is interested in extra-loud
alarm clocks.

Also, the application area matters.  There is a difference between
programming for one's own enjoyment or to do a personal task, and
writing programs whose reliability or lack of it can affect other
people's lives.  I've never done any safety-critical programming but I
do a fair amount of security-oriented Internet programming.  As such,
I have to always assume that my programs will be attacked by people
who are smarter than I am and know more than I do.  I can't possibly
out-think them.  If I don't see problems in a program, it's still
plausible that someone smarter than me will spot something I missed.
Therefore, my failure to detect the presence of problems is not
reassuring.  What I want is means of verifying the absence of
problems.  

Finally, your type-A / type-B comparison works best regarding programs
written by one programmer or by a few programmers who communicate
closely.  I'm working on a Python program in conjunction with a bunch
of people in widely dispersed time zones, so communication isn't so
fluid, and when something changes it's not always easy to notice the
change or understand the reason and deal with it.  There have been
quite a few times when some hassle would have been avoided by the
static interfaces mandated in less dynamic languages.  Whether the
hassle saved would have been outweighed by the extra verbosity is not
known.  Yeah, I know, more docs and tests can always help, but why not
let the computer do more of the work?

> Haskell is interesting: it can provide a surprising degree of
> freedom, but it makes you work /very/ hard wrangling its type system
> in order to get there; and again, I found I had most fun when I was
> doing extremely evil unsafePerformIO hacking...

I've found Haskell's type system to work pretty well for the
not-so-fancy things I've tried so far.  It takes some study to
understand, but it's very uniform and beautiful.  I'm having more
trouble controlling resource consumption of programs that are
otherwise semantically correct, a well known drawback of lazy
evaluation.  The purpose of unsafePerformIO is interfacing with C
programs and importing them into Haskell as pure functions when
appropriate.  Anyway, at least for me, Haskell is fascinating as an
object of study, and a lot of fun to hack with, but doesn't yet have
the creature comforts or practicality of Python, plus its steep
learning curve makes it unsuitable for projects not being developed by
hardcore nerds.

The ML family avoids some of Haskell's problems, but is generally less
advanced and moribund.  Pretty soon I think we will start seeing
practical successor languages that put the best ideas together.