"no variable or argument declarations are necessary."

[Antoon Pardon]

Op 2005-10-04, Mike Meyer schreef <mwm at mired.org>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>> 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:
>> 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.
>
> If it happens at runtime, then you can do it without declarations:
> they're gone by then.

That depends on how they are implemented. "declarations" can be
executable statements.

It is not about can we do without or not. It is about are they
helpfull or not. Python would be a whole different language
if it never adapted something it could do without.

> Come to think of it, most functional languages -
> which are the languages that make the heaviest use of closures - don't
> require variable declarations.

But AFAIK they don't work like python which makes any variable
that is assigned to in a function, local. Which is a problem
if you want a writable closure.

>> 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.
>
> Not in a dynamic language. Python lets you delete variables at run
> time, so the only way to know if a variable exists at a specific
> point during the execution of an arbitrary program is to execute the
> program to that point.

It is not perfect, that doesn't mean it can't help. How much code
deletes variables.

>> And if you provide type information with the declaration, more
>> efficient code can be produced.
>
> Only in a few cases. Type inferencing is a well-understood
> technology, and will produce code as efficient as a statically type
> language in most cases.

I thought it was more than in a few. Without some type information
from the coder, I don't see how you can infer type from library
code.

>> I think language matters shouldn't be setlled by personal preferences.
>
> I have to agree with that. For whether or not a feature should be
> included, there should either be a solid reason dealing with the
> functionality of the language - meaning you should have a set of use
> cases showing what a feature enables in the language that couldn't be
> done at all, or could only be done clumsily, without the feature.

I think this is too strict. Decorators would IMO never made it.
The old way to do it, was certainly not clumsy IME.

I think that a feature that could be helpfull in reduction
errors, should be a candidate even if it has no other merrits.

> Except declarations don't add functionality to the language. They
> effect the programing process.

It would be one way to get writable closures in the language.
That is added functionality.

> And we have conflicting claims about
> whether that's a good effect or not, all apparently based on nothing
> solider than personal experience. Which means the arguments are just
> personal preferences.

Whether the good effect is good enough is certainly open for debate.
But the opponents seem to argue that since it is no absolute guarantee,
it is next to useless. Well I can't agree with that kind of argument
and will argue against it.

> Antoon, at a guess I'd say that Python is the first time you've
> encountered a dynamnic language. Being "horrified" at not having
> variable declarations, which is a standard feature of such languages
> dating back to the 1950s, is one such indication.

No I'm not horrified at not having variable declarations. I'm in
general very practical with regard to programming, and use what
features a language offers me. However that doesn't stop me from
thinking: Hey if language X would have feature F from language Y,
that could be helpfull.

Now if the developers think such a feature is not important enough
fine, by me. It is however something different if people start
arguing that feature F is totally useless. Now my impression is
that a number of people regard python or at least some aspects
of it as holy and that suggesting that some specific features
could be usefull is considered sacriledge. 

> Dynamic languages tend to express a much wider range of programming
> paradigms than languages that are designed to be statically
> compiled. Some of these paradigms do away with - or relegate to the
> level of "ugly performance hack" - features that someone only
> experienced with something like Pascal would consider
> essential. Assignment statements are a good example of that.

I think we should get rid of thinking about a language as
static or dynamic. It is not the language which should determine
a static or dynamic approach, it is the problem you are trying
to solve. And if the coder thinks that a static approach is
best for his problem, why shouldn't he solve it that way.

That a language allows a static approach too, doesn't contradict
that it can work dynamically. Everytime a static feature is
suggested, some dynamic folks react as if the dynamic aspect
of python is in perril.

> Given these kinds of differences, prior experience is *not* a valid
> reason for thinking that some difference must be wrong. Until you have
> experience with the language in question, you can't really decide that
> some feature being missing is intolerable. You're in the same position
> as the guy who told me that a language without a goto would be
> unusable based on his experience with old BASIC, FORTRAN IV and
> assembler.

There seems to be some misunderstanding, I don't remember stating that
missing declarations are intolerable, I certainly dont think so. I
wouldn't be programming in python for over five years now if I
thought so. But that doesn't mean having the possibilty to
declare is useless.

-- 
Antoon Pardon