Python 1.6 The balanced language

[Manuel Gutierrez Algaba]

On Tue, 5  Alex Martelli <aleaxit at yahoo.com> wrote:
>"Manuel Gutierrez Algaba" < wrote in message
>news:slrn8r8cla.hrg.thor at localhost.localdomain...
>    [snip]
>> So types go against "functional".
>
>Most functional languages have (good) typesystems -- Haskell's being
>definitely worth studying, 

I have the doc printed, ready to be studied, but Haskell syntax
is almost as complex as Python 3000 syntax, so it's in the
 waiting queue.

>To continue your pipes/fluids analogy: not all fluids are safe to
>run in every kind of pipe.  A language with types basically *lets*
>you state that (some *make* you state that, but "good" typesystem
>implies some measure of type-inferencing, by definition of 'good':-).

A type is a way to prevent fluids to go thru wrong pipes. But,
the question is what happens when we are preventing it all the time.
We have building extremely limited functions , very robust,...
but not so robust if you have to write several versions of 
the same function for processing different types .

At the end , you get lot of particular things, of particular 
redirections for determined fluids. It's better to have general
treatments for general functionality. If I focus my effort in
general functionality what I'm doing is focusing in functionality.
If I focus my effort in types, what I'm doing is low form
of prerrequisites for every function, wasting the possibilities
some functions may provide. If I think in terms of types, It's
harder to think in terms of general functionality if we're focusing
all the time of particular fluids.

What's more? Ah yes, the cast. If you've ever programmed
in Java, you'll realize that 50 % of the time you're doing 
cast (type conversions), ... 


>that does not model materials-issues -- which doesn't mean it's
>*useless*, absolutely not: it's still very useful to model a fluid
>flow system even in a more abstract way, without consideration of
>materials' properties;

Abstract way === Functional way !!!! 

> but it would be silly to claim that being
>able to model materials as well (or, even, being _forced_ to do so)
>makes a fluid-flow simulation system useless or innatural.
>
>Somewhat-Haskellishly:
>
>myPipe    :: (Noncorrosive a) => [a] -> [a]
>myPipe []    =    []
>myPipe (x:xs)
>    | temperature x <  90    = x : myPipe xs
>    | temperature x >= 90    = error "too hot!"
>

It seems to me that everyones speaks Haskell in c.l.p!!

>I may have come (after decades of using many different
>languages, mostly rather typed and pretty anal-retentive
>about it) to a personal preference for dynamic typing, but
>that doesn't stop me from recognizing that being able to
>diagnose SOME errors at compile-time (and thus prevent
>them) also has its use...!  In functional languages just
>as well as in imperative or mixed ones.
>

Having types is liking trying to run a 100 m hurdles race with
a a heavy chain of  iron in your feet. types are useful but 
I don't want the extreme lack of freedom.

--- 
MGA