boolean true and false values.

[Albert Hofkamp]

On Mon, 26 Jun 2000 22:10 +0100 (BST), Tim Rowe <digitig at cix.co.uk> wrote:
>In article <slrn8lf3q9.us.hat at se-46.wpa.wtb.tue.nl>, 
>hat at se-46.wpa.wtb.tue.nl (Albert Hofkamp) wrote:
>
>> I understand that now.
>> However, I am not quite sure that that is what one wants.
>
>Maybe it isn't; then another language may be more appropriate. When it 
>/is/ what one wants then Python may be your choice.

:-)
Changing Python is not my goal, I am only trying to really understand the
differences between C-like declarations, and the Python approach.

Digging around by finding counter-arguments is one way to find the core reason
for the difference in approach. Once you have this on the table, you can
make a good judgement about the design rationale for the c-like approach as
well as the python approach.

With a good language, it should be really hard to find a valid argument for
which the language design rationale does not provide a reason.
If one does find one, that argument is a weak point in the language design, which
probably means that some more thought about that part of the design should be put in.


Until now, I like the basic idea of Python of variables not having a type, but
I don't really see the advantage.
That means that if I would design the Python language, I would like to change
something (although I am not quite sure what, changing anything at this
fundamental level is likely to break just about any existing program).
However, I am not one of the language designers of Python. The best I can hope
for is that one or more of them is reading this discussion, and takes it into
account for the next version.

>Folks don't seem to be able to get away from the notion of a "perfect" 
>language, ideal for all applications. I don't believe it exists, and if 

I am not talking about ideal for everything.
Python is supposed to be aimed at 'the masses' in the next project of Guido. In
that context, enforcing something like type-safety of variables in order to
have better support for invariants seems ok to me.
For example, Perl is aimed at experienced programmers. They want a fast hack
language, not a cleanly designed language aimed at learning how to program.
Consequently, I consider type-safety in Perl as quite not important (and that
is an understatement).

>you "improve" Python for some you may well break it for others. Surely the 
>competent programmer has a number of languages under his/her belt?

I am aware of that problem. For that reason alone, it is not very likely that
any change in Python will result in this discussion. However, in my opinion it
is a step forward to have weaknesses in the language exposed. That gives the
language designers (and not only those of Python) the chance to take it into
account, and users better equipment to judge usability of the languages.

>first language I was taught was FORTRAN and would consider INTERCAL to be 

Hmm, I read the Intercal manual, and am anxious to write something in it,
although the right program hasn't yet arrived. 
Fortran is also on the list of languages to read about.
[ please don't tell any one about my habit of learning eeky languages :-) ]

>> In other words, variables are in reality quite tightly connected to 
>> their
>> values because a meaning is given to the variable.
>> For example, pointing the variable to a value of another type does not 
>> fit in
>> the idea of invariants. For example, by executing 'total="kjerg"', the
>> invariant is not longer true, since "kjerg" is not the sum of elements 
>> (it is
>> not even a number).
>
>But that's /exactly/ right! If you execute 'total="kjerg"' then your 
>invariant is indeed violated!

So, why is it then that Python allows this ?
For a language aimed at professionals, I understand (although I wouldn't
introduce it), but for a clean language such as Python ?

>> Thus, to a good programmer, the dynamic nature of variables is not 
>> needed. To
>> bad programmers, it is a tool which can be used quite abusively.
>
>As can any tool, of course. The dynamic typing is indeed never /needed/ 
>(probably one of the things Dijkstra proved!), but it's often very /very/ 
>convenient indeed. If it's likely to be a problem to you -- or to the 

Hmm, why is it convenient then ?
Without declarations you can simply pick another identifier when you need a new
variable, rather than re-use existing identifiers, which may cause all kind of
bugs and/or hamper readability.


Albert
---
Look ma, windows without Windows !!