variable declaration

[Alexander]

Привет Alex!

05 февраля 2005 в 17:00, Alex Martelli в своем письме к All писал:
 >>  AM> The fact that in Python there are ONLY statements, NO
 >>  AM> declarations,
 >> What is "global"? Statement? Ok, I fill lack of "var" statement:)
 AM> 'global' is an ugly wart,

Ok,
===
def hi():
  print "hello!"
===
What is it? Statement or declaration? After interpreter see this lines, it add
information about function "hi" and it's body to his memory. Look at this:
  var S
Interpreter see this line and add information about variable S to the memory. I
don't find big difference.
By the way keyword "def" is as bad as "var", from your point of view? :)

 AM> to all intents and purposes working "as if"
 AM> it was a declaration.  If I had to vote about the one worst formal
 AM> defect of Python, it would surely be 'global'.
Second worsest - 'def'? :)

 AM> What you keep demanding is a way to inject far worse ugliness, and in
 AM> a context in which the typical behavior of pointy-haired bosses will
 AM> be to make it unavoidable for many of the people who work with Python.
 AM> I am strongly convinced that, if you had your wish, the total amount
 AM> of happiness in the world would be quite substantially diminished, and
 AM> I will do anything I can to stop it from happening.

:) "Star Wars IX" :)
If your boss is rather smart, you can explain your position. Even if he is not
agree, he will give you freedom.
If your boss is stupid, find another one:)
Of course, if you will explain him in such a way "hey, boss, you will never
understand this language, go back to your playground", you have no chance:)

 AM> There IS no meaning to your (several) sentences above-quoted, that it
 AM> can help anybody to "try to undestand": it's simply an insanely bad
 AM> attempt at totally invalid parallels.
I understand your opinion. From my point of view, you don't even try to
understand.

 >>  AM> In brief: you're not just wrong, you're so totally, incredibly,
 >>  AM> utterly and irredeemably wrong that it's not even funny.
 >> Hey, take it easy! Relax, reread that piece of text. It was written
 >> with smile on my lips. Here it is for your convenience:
 AM> Do yourself a favor: don't even _try_ to be funny in a language you
 AM> have so much trouble with.  Your communication in English is badly
 AM> enough impaired even without such lame attempts at humor: don't made
 AM> bad things even worse -- the result is NOT funny, anyway, just totally
 AM> garbled.

But, I am friendly, even with my opponents. I think it is my good trait.

 AM> There IS no ``problem "in general"'': Python does a pretty good job
 AM> of
 AM> diagnosing as many errors as can be diagnosed ***without demanding
 AM> absurdities such as redundancy on the programmer's part***.  Period.

 >> again, the main idea:
 >> ========
 >> Or, maybe, we will ask interpreter to find and prevent as many
 >> errors as he can?

 AM> To show how absurd that would be: why not force every line of the
 AM> program to be written twice, then -- this would help diagnose typos,
 AM> because the interpreter could immediately mark as errors any case in
 AM> which the two copies aren't equal.  Heck, why stop at TWICE -- even
 AM> MORE errors will be caught if every line has to be written TEN times.
 AM> Or a million.  Why not?  *AS MANY ERRORS AS [it] CAN* is an
 AM> *ABSURD* objective, if you don't qualify it with *WHILE AVOIDING ANY
 AM> ENFORCED REDUNDANCY* introduced solely for that purpose.

Hmm. It's clever move. I can't resist here.
Well, I agree that keyword "var" is to long. Programs are not look pretty with
it, especialy in situations like this:
  for var x in xrange(10):...
But I still think declaration of variables is good idea. But with shorter
syntax. May be, smth like this: ~S, or `S or .S, or S`, S~ , S. , and so on. Of
course it must be optional feauture: use it if you want or don't use if you
don't want.


 >> You wrote about "substantial cost" of var declarations. Yes, you are
 >> write. But think about the cost of lack of var declarations. Compare
 >> time that programmer will waste on search for the reason of bug
 >> caused by such typo, plus time what programmer will waste while
 >> remembering exact variable name.
 AM> I've been programming essentially full-time in Python for about three
 AM> years, plus a few more years before then when I used Python as much
 AM> as
 AM> I could, even though my salary was mostly earned with C++, Visual
 AM> Basic, Java, perl, and so on.  My REAL LIFE EXPERIENCE programming in
 AM> Python temms me that the time I've "wasted on search" etc due to the
 AM> lack of variable declaration is ***FUNDAMENTALLY NOTHING AT ALL***.
 AM> Other hundreds of thousands of man-hours of similar Python programming
 AM> experience on the part of hundreds of other programmers essentially
 AM> confirm these findings.

 AM> Your, what, TENS?, of man-hours spent programming in Python tell you
 AM> otherwise.

Do you ever wrote programs for engineering calculations? Dozens of variables
with names like lambda_1, phi_k, epsilon, d2f_dx2, grad_z and so on. You wrote
it, start it and see that it work wrong. You start debugging. Look at every
line, and attentively compare written in the screen and in the paper: is it
correct? My experience say that often errors caused by typos in names of vars
(more precisely, writing one name instead of another).
You may say: give better names for your variables! Ha, I'am often don't
understand that they mean! They are written for me by an engineer! He is
thinking in that terms, they is natural for him. He and his collegues want to
see error messages as "lambda_1 must be between 2 and 75".
So I'am sure: any checking will help. If I'am sure that interpreter can't
create "epsElon" I will not check the left side of "=" operator. If I can't be
sure in it, I will check it. It will take time. That's all.
Recent years I'am not often work with engineering calculations, but I want to
use Python for them also - if they will be.

 AM> Fine, then *USE ANOTHER LANGUAGE* and be happy, and let US
 AM> be just as happy by continuing to use Python -- almost all languages
 AM> do things the way you want, so ***leave alone*** the few happy oases
 AM> such as Python and Ruby where programmers can happily avoid the
 AM> idiotic redundancy of variable declarations, and not even PHBs can
 AM> impose otherwise.

Bad boss will find a way to make your life worse:)  With, or without,
availibility of variable declarations.

 >> Compare it with time for looking on message:
 >> ===
 >> Traceback (most recent call last):
 >>   File "<pyshell#16>", line 5, in -toplevel-
 >>     epselon
 >> NameError: name 'epselon' is not defined, in strict mode
 >> ===
 >> and fixing it, plus time on typing three letters (or less).

 AM> Like experience shows in all cases of such idiotic redundancies, the
 AM> real waste of time comes in the BAZILLION cases where your program
 AM> WOULD be just fine -- except you missed one redundancy, so you have to
 AM> go and put it in to make the gods of redundancy happy again.  That
 AM> happens with VASTLY higher frequency than the cases where the enforced
 AM> redundancy saves you a comparable amount of time by catching some
 AM> error earlier.

 AM> Plus, the FALSE confidence coming from redundancy works against you by
 AM> kidding you into believing that a BAZILLION other typos can't still be
 AM> lurking in your code, just because you've eliminated one TINY subset
 AM> of such typos (typos in names of variables that happen to leave the
 AM> mangled names syntactically valid BUT different from any other
 AM> variable) -- and *ONLY* that tiny subset of such typos which happened
 AM> on the left of a plain '=' (since all others, happening on the RIGHT
 AM> of an '=' or on the left of an _augmented_ '=', were already caught),
 AM> and ONLY regarding barenames (such typos on any but the rightmost
 AM> component of compound names were already caught intrinsically, and
 AM> catching those on the rightmost component is trivially easier than
 AM> introducing a {YECCCCHH} 'vars' as you so stubbornly insist)...

 AM> Basically you're focusing on maybe ONE IN A MILLION of the errors you
 AM> could make and want to pervert the whole foundation of Python, and
 AM> seriously hamper the productivity of hundreds of thousands of Python
 AM> programmers in every normal case!, to save maybe two minutes in such a
 AM> one-in-a-million case.

 AM> I consider this one of the worst ideas to have been proposed on this
 AM> newsgroup over the years, which _IS_ saying something.  Oh, you're not
 AM> the only one, for sure -- there must have been a dozen before you, at
 AM> least.  Fortunately, even though almost each and every one of them has
 AM> wasted more of everybody's time with such ideas, than even their
 AM> scare-tactics claim of ``wastes of time'' due to lack of declarations
 AM> could account for, Python is still intact.  A few of the stubborn
 AM> lovers of declarations tried doing without, and, to their
 AM> astonishment, found out that everybody else, with years of Python
 AM> experience, was right, and they, without ANY such experience, were
 AM> wrong (just incredible, eh?!); others have gone away to find their
 AM> bliss in Perl, PHP, or whatever -- good riddance, and don't let the
 AM> door slam behind you as you go, please.

Don't be so ... I don't find the equivalent english word. Smth like: Take it
more easy.


Alexander, zatv at bk.ru