"no variable or argument declarations are necessary."

[Antoon Pardon]

Op 2005-10-03, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> On Mon, 03 Oct 2005 13:58:33 +0000, Antoon Pardon wrote:
>
>> Op 2005-10-03, Duncan Booth schreef <duncan.booth at invalid.invalid>:
>>> Antoon Pardon wrote:
>>>
>>>> A language where variable have to be declared before use, would allow
>>>> to give all misspelled (undeclared) variables in on go, instead of
>>>> just crashing each time one is encounterd.
>>>
>>> Wrong. It would catch at compile-time those misspellings which do not 
>>> happen to coincide with another declared variable.
>> 
>> Fine, it is still better than python which will crash each time
>> one of these is encountered.
>
> Python doesn't crash when it meets an undeclared variable. It raises an
> exception.

Your nit-picking. For the sake of finding misspelled variables the
difference is irrelevant.

>>> Moreover, it adds a burden on the programmer who has to write all those 
>>> declarations,
>> 
>> So? He has to write all those lines of code too.
>> 
>> People often promote unittesting here. Writing all those unittest is
>> an added burden too. But people think this burden is worth it.
>
> Yes, but there is no evidence that pre-declaration of variables is a
> burden worth carrying. It doesn't catch any errors that your testing
> wouldn't catch anyway.

Maybe not, but it may catch them earlier and may make them easier
to recognize.

Declarations also allow easier writable closures. Since the declaration
happens at a certain scope, the run time can easily find the correct
scope when a variable is rebound.

They also relieve a burden from the run-time, since all variables
are declared, the runtime doesn't has to check whether or not
a variable is accesible, it knows it is.

And if you provide type information with the declaration, more
efficient code can be produced.

>> I think writing declaration is also worth it. The gain is not as
>> much as with unittesting but neither is the burden, so that
>> balances out IMO
>
> Speaking as somebody who spent a long time programming in Pascal, I got
> heartedly sick and tired of having to jump backwards and forwards from
> where I was coding to the start of the function to define variables.

I have programmed a lot in Pascal too and Modula II and other languages.
I never found declarations that much a burden. That you got heartedly sick
of having to use declarations says very little about declarations and
says more about you.

I think language matters shouldn't be setlled by personal preferences.

> It got to the stage that sometimes I'd pre-define variables I thought I
> might need, intending to go back afterwards and delete the ones I didn't
> need. When the programmer is having to to jump through hoops to satisfy
> the compiler, there is something wrong.

Maybe it was your way of working. I never thought I had to go through
hoops to satisfy the compiler. You have to satisfy that compilor anyway,
for the moment I have more problems with colons that have to be put
after an "if", "else" etc than I ever had with declarations.

>>> and worse it adds a burden on everyone reading the code who 
>>> has more lines to read before understanding the code.
>> 
>> Well maybe we should remove all those comments from code too,
>> because all it does is add more lines for people to read.
>
> Well-written comments should give the reader information which is not in
> the code. If the comment gives you nothing that wasn't obvious from the
> code, it is pointless and should be removed.
>
> Variable declarations give the reader nothing that isn't in the code. If I
> write x = 15, then both I and the compiler knows that there is a variable
> called x. It is blindingly obvious. Why do I need to say "define x" first?

Because it isn't at all obvious at which scope that x is. Sure you can
define your language that rebinding is always at local scope, but that
you need to define it so, means it isn't that obvious.

Also the question is not whether or not there is a variable x, the
quesntions whether or not there should be a variable x. That is not
at all that obvious when you write x = 15.

> Pre-defining x protects me from one class of error, where I typed x
> instead of (say) n. That's fine as far as it goes, but that's not
> necessarily an _error_. If the typo causes an error, e.g.:

> def spam(n):
>     return "spam " * x  # oops, typo
>
> then testing will catch it, and many other errors as well. Declaring the
> variable doesn't get me anything I wouldn't already get.

Yes it would have caught this error even before you had to begin
testing.

> But if it doesn't cause an error, e.g.:
>
> def spam(n):
>     if n:
>         return "spam " * n
>     else:
>         x = 0  # oops, typo
>         return "spam " * n
>     
> This may never cause a failure, since n is always an integer. Since my
> other testing guarantees that n is always an integer,

This is naive. Testing doesn't guarantee anything. If this is what you
think about testing, then testing gives you a false impression of
security. Maybe we should drop testing.

> it doesn't matter
> that I've created a variable x that doesn't get used. Yes, it would be
> nice for the compiler to flag this, but if the cost of that niceness is to
> have to define every single variable, I can live without it.

But we should decide what language features are usefull and which are
not by what some individual can or can't live without.

>>> Also there is 
>>> increased overhead when maintaining the code as all those declarations have 
>>> to be kept in line as the code changes over time.
>> 
>> Which is good. Just as you have to keep the unittests in line as code
>> changes over time.
>
> That is not the same at all. Changing variable declarations needs to be
> done every time you modify the internal implementation of a function.

Well now I'll nitpick too. No you don't. You only have to do so
if this modification needs other variables.

> Changing the unittests, or any other testing for that matter, only needs
> to be done when you change the interface.

Which will be often enough.

> In principle, if you have an interface designed up front before you write
> any code, you could write all your tests at the start of the project and
> never change them again. You can't do that with variable declarations,
> since every time you change the implementation you have to change the
> declarations.

This argument has very little value since all you are saying is that
if you were smart enought to choose the right interface to begin with,
you won't have to change interface related stuff like unittests, while
if you were not that smart in choosing your implementation, you will
have to change implemantation related stuff like declarations.

-- 
Antoon Pardon