Mike Meyer wrote: > Steven D'Aprano <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
