"no variable or argument declarations are necessary."

[Steven D'Aprano]

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.

[snip]

> 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 
strict type-checking.

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.


-- 
Steven.