does lack of type declarations make Python unsafe?

[Peter Hansen]

Anton Vredegoor wrote:
> 
> Let's have my view on it then, too. In my opinion the obsession with
> testing is a left over from the time one was concerned with type
> checking. It is as if one is not really ready to enter the world of
> signature based polymorphism, so one seeks the aid of different kinds
> of crutches, not realizing that these too, in the end, will prove to
> be just as much of a hindrance.

Wow!  I really thought you were joking, but I carefully read the whole
post to make sure and didn't see any hint of humour, except for the 
fundamental message you are trying to convey, which is in my opinion
quite subtly humorous, however you intended it.

> Further more, this seems to be intimately related to the excessive
> insisting on use cases before one is ready to accept new features. For
> example, what was the use case of the first car? There where no roads
> then, nor gas stations, and the things where really not very useful
> compared to proven, age-old methods of transportation. 

No roads?  What planet do you live on?  Where did the horses trot, and
the wagons roll, and people walk?  On the sidewalks, when they were just 
lone parallel strips of pavement running between the cities?  Of 
*course* there were roads!  In fact, it was the previous generation
of transportation which *made* the roads, deliberately or not, and
cars were just an innovative way to take advantage of them.

Let's see: use cases for early automobiles: they didn't get tired,
you didn't have to smell their dirty asses as you trotted along, 
they could go marginally faster (even at the early stage), on 
average if not in "burst mode", probably cheaper at that point too.
Any idea what it cost to maintain a horse and buggy in the city
when cars came out?

If there's no use case for a piece of software, it is pure research,
or purely speculative development.  That has a place in the world,
but it's not how most people should be spending their time, any more
than most people should speculate in the stock market or most 
companies should pour their shareholders' money into pure research.

> What's the use of replacing type checking with batteries of tests
> while the real advantage of coding in Python is its "executable pseudo
> code" character: "Look ma, no testing necessary!" 

While I agree that Python, more than most or perhaps any other language,
lends itself to a form of development which *doesn't* need testing
(because of it's uniquely "executable pseudo-code" nature and that 
well-known phenomenon of writing something that you aren't sure is
even supported by the language and "it just runs"), I do not agree
in the least that most software should be written without tests.

Most software has bugs.  Lots of them.  Most open source projects 
have huge bug lists, and are starting to spend entire weeks on 
"sprints" which are sometimes focused solely on bug-fixing!  How
effective is Python going to be at preventing that?  Not very:
as evidenced by the fact that the whole sprint concept, as near
as I can tell, is coming *from* the open source Python community
and its attempt to do mass bug fixes (as well as mass development,
but that's not the issue here).  

Without tests, you don't even *know* how reliable your software is.
Without tests, you don't even know you have fixed a bug properly,
sometimes.  Without tests, source code is a liability, not an asset.

> Now to go back to test driven development, is it necessary to
> formulate a plan first before springing into action? 

Uh, yes?  Was that a trick question?

> As logical as it seems this is again just a relic of the old static 
> typing fears. 

Probably not, but I suppose this is just a rhetorical comment and not
something that really needs debating.  If you want to debate it, you
should start by disproving the logic behind it instead of just stating
that it seems logical but is actually (you imply) false.

> Any linguistic expert - and I'm now using the term in a more psychological
> way - will tell you that speech production is "on the fly". 

All speech production?  Or casual speech in everyday conversation?
Ever heard of speech writers?  What about the (at least in English)
phrase "think before you speak"?  That advice came about for a good
reason.  Thoughtless speech is about as useful, most of the time,
as thoughtless programming - I mean programming without thinking 
at least somewhat about what you are trying to do in advance of doing it.
Heck, it's why Usenet is so bad for flames and off-the-cuff responses
(like this one :-), because people just don't think before posting.

> The same should go for a computer language, type in
> your thoughts (or speak!) and let the computer figure out how to best
> express it! Use a user platform to test the effect of your utterances
> or correct them using "live" feedback from the interpreter.

Well, that does start getting interesting, in that it's a neat 
discussion of future possibilities in programming.  If this whole
post of yours was really an introduction to this idea, then I take
back the part about thinking it was a bad, though subtle, joke
and I think there's some merit in discussing science fiction
like this.  Just don't go "dissing" my tests! :-)

> Python is not there yet, but a failure to notice the transformation of
> computer languages into languages of thought, and relying on excessive
> backtracking of all utterances, instead of concentrating on the
> content of what is to be expressed, is a sin against that what is yet
> to come.

Hmm.... "sin" is an evil word, but I'll leave that alone.  My question
is whether you think testing, in the worthy-of-a-better-label form it
has in "Test-Driven Development", is something which is really bad
to be doing, or whether you are simply saying that in the very long 
wrong, perhaps beyond our lifetimes, it will simply not be necessary.

>From a bit of what you've said, I'm under the impression you are really
just talking about "testing" in the traditional sense of writing tests
to make sure your code isn't broken, as opposed to what TDD means by
writing tests.  The two are only peripherally related, as best shown
by Robert Martin's quote from a recent thread.  Are you really just
against traditional "tests", or do you have a problem with the whole
concept of making sure software works right?  (Intentionally polarized
statement to elicit a response... :-)

-Peter