Python 1.6 The balanced language

[Manuel Gutierrez Algaba]

On  lobozc at my-deja.com <lobozc at my-deja.com> wrote:
>i'm commenting on this particular exchange:
>> > language. Although, I think our BDFL would lean more towards a
>> > Modula3+Haskell mixture =).
>>
>> Which only shows his good taste.
>>
>> pure-functional-programming-in-Modula3-is-a-pain-though-ly y'rs
>> Peter
>
>1) I'm very glad that Haskell seem to be in the picture. I'm even more
>happy that list comprehensions have been added to 2.0. Adding
>functional elements to Python - without sacrificing its imperative
>roots

Sometimes "imperative" is preferred to
 "the functional declarativeness". The only problem with lambda functions,
comprehension and so on is that you can build such a big and nasty
expression that you have to _run_ it several times in your
mind to understand what it does. 

This goes against the very nature of python : utter simplicity. 

Using comprehension , sometimes, you can write in 10 lines 
something you'd need 100 lines in imperative. But, for maintenance
purposes, those 10 lines may take two hours to understand while
100 lines of "normal" python takes 10 minutes. 

That's why Haskell, ML and so on will continue being "academic"
for _a long time_. Not everybody is a Ph. D. , nor is so "relaxed"
to play with long pseudo-mathematical expresions. 

Even so, Haskell, ML and Lisp... should be liked for anyone with
some love for Computer Sciences.

>interpreted one at that. It would make sense to have a quick look at
>other higher level imperative languages and see what can be borrowed
>from them for python.

>From which languages? and What ? 


>3) My particular favourite is Icon (see www.cs.arizona.edu/icon).
>Particular aspects of some interest to Python would be goal-directed
>evaluation [saves helluva lot of lines of code...] and, less
>importantly, generators and coexpressions. I have no idea how difficult
>it would be to move these ideas to Python.

Again, although, this sounds nice. The python-spirit is :
- no magic

If I rembember well, Icon treats equally exceptions and returns from
functions. Ok, this seems a bit of magic, and it kills exceptions.
And exceptions are important enough in OO for being respected. 

Again, you can't have three ways to deal with exceptions ( a la 
Icon, a la Java  and a la python ) without having a mess and 
spiritless language.

> But I (and many other
>people) can vouch that these mechanisms are very effective in writing
>very 'large' programs in a surprisingly small number of lines.

Except COBOL, everything can be written in a very small number
of lines, it depends if the programmer knows "the art" or if
he's a hardwirer !

> I must
>stress here that this happens not the way Perl does it - but rather
>like in functional languages. That is: because of the built in
>mechanisms of evaluation. So it is readable :-), not just terse.
>



-- 

MGA