"no variable or argument declarations are necessary."
steve at REMOVEMEcyber.com.au
Tue Oct 4 11:05:57 CEST 2005
Mike Meyer wrote:
> Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
>>Declared variables have considerable labour costs, and only marginal
>>gains. Since the steps you take to protect against other errors will also
>>protect against mistyping variables, declarations of variables is of
>>little practical benefit.
> As far as I can tell, this is as much hearsay and personal experience
> as the alternate claim that not having them costs you lots of
> debugging time and errors. If anyone has pointers to real research
> into this area (I've heard the TRAK folks did some, but haven't been
> able to turn any up), I'd love to hear it.
Sorry, I have no hard research to point to. If I did, I
would have referenced it.
> My gut reaction is that it's a wash. The time taken to declare
> variables in well-written code in a well-designed language - meaning
> the declarations and use will be close together - isn't all that
> great, but neither are the savings.
It isn't the typing time to declare variables, it is
the context switching. You're focused on implementing
an algorithm, realise you need to declare another
variable, your brain does a mini-context switch, you
scroll up to the declaration section, you declare it,
you scroll back to where you were, and now you have to
context switch again.
You've gone from thinking about the implementation of
the algorithm to thinking about how to satisfy the
requirements of the compiler. As context switches go,
it isn't as big as the edit-compile-make-run method of
testing, but it is still a context switch.
Or you just code without declaring, intending to go
back and do it later, and invariably forget.
> If I'm going to get compiler support for semantic checking like this,
> I want it to serious levels. I want function pre/post conditions
> checked. I want loop and class invariant checked. I want subsumption
> in my inheritance tree. Nuts - I want a complete, well-designed
> inheritance tree. Duck typing is great stuff, but if I'm going to be
> doing the work to declare everything, I want *everything* that can be
> checked checked.
We like to think of programming as a branch of
engineering. It isn't, not yet.
I've worked for architects who were involved in some
major engineering projects. One of the things I learnt
is that there are times when you need to specify
objects strictly. When only a 5% titanium stainless
steel alloy will do, then *only* a 5% titanium
stainless steel alloy will do. That's when you want
But the rest of the time, just about any stainless
steel will do, and sometimes you don't even care if it
is steel -- iron will do the job just as well. If the
nail is hard enough to be hammered into the wood, and
long enough to hold it in place, it is good enough for
the job. That's the real-world equivalent of duck typing.
Static typed languages that do all those checks are the
equivalent of building the space shuttle, where
everything must be specified in advance to the nth
degree: it must not just be a three inch screw, but a
three inch Phillips head anti-spark non-magnetic
corrosion-resistant screw rated to a torque of
such-and-such and capable of resisting vaccuum welding,
extreme temperatures in both directions, and exposure
to UV radiation. For that, you need a compiler that
will do what Mike asks for: check *everything*.
I don't know whether there are languages that will
check everything in that way. If there aren't, then
perhaps there should be. But Python shouldn't be one of
them. Specifying every last detail about the objects
making up the space shuttle is one of the reasons why
it costs umpty-bazillion dollars to build one, and
almost as much to maintain it -- and it still has a
safety record worse than most $10,000 cars.
That level of specification is overkill for most
engineering projects, and it's overkill for most
programming projects too. It is all well and good to
tear your hair and rip your clothes over the
possibility of the language allowing some hidden bug in
the program, but get over it: there is always a trade
off to be made between cost, time and risk of bugs.
Python is a language that makes the trade off one way
(fast development, low cost, high flexibility, moderate
risk) rather than another (slow development, high cost,
low flexibility, low risk).
We make the same trade offs in the real world too: the
chair you sit on is not built to the same level of
quality as the space shuttle, otherwise it would cost
$100,000 instead of $100. Consequently, sometimes
chairs break. Deal with it.
More information about the Python-list