Python 1.6 The balanced language

[Manuel Gutierrez Algaba]

On Tue, 5 Sep  Alex Martelli <aleaxit at yahoo.com> wrote:
>"Manuel Gutierrez Algaba"  wrote in message
>news:slrn8rae8k.atn.thor at localhost.localdomain...
>> On Tue, 5  Alex Martelli <aleaxit at yahoo.com> wrote:
>> >"Manuel Gutierrez Algaba" < wrote in message

>
>> 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.
>
>Nope: typeclasses of fluid materials -- Noncorrosive, for example.
>
>You do have the notion of typeclasses in Python: "a sequence",
>for example, or "a file-like object"; you just lack the way to
>*EXPRESS* this notion simply, directly, and explicitly _in the
>language itself_.  So you express it in docs & comments, but
>those are often not as precise as one would wish (and as an
>expression in a formal language might make things): when
>somebody says 'you pass a file-like object', what methods are
>going to be called on it -- write? read? writelines? readlines?
>close?  _Good_ docs would say that -- but why not have a
>way to say it in the language itself?

No, an object that implements those methods required to be 
considered a sequence is not a type(object )= sequence

Fortunately,  the notion of objects that accomplish certain 
behaviours is far more general and flexible than types.

>have the same need to know).  But who will supply the
>equivalent information for libraries that are nowhere as
>popular or well-documented as the Python language and
>its builtin libraries...?
>
>Now THIS is 'wasting the possibilities some functions
>may provide' -- because the language is not expressive
>enough to supply a notation for the typesystem it is
>in fact using...

Ok, in python apart from ints and char , we don't use types,
not at all, we don't need them and they're ugly. If we really
need to do some checkings we can check the properties of the
object, that is much flexible and exhaustive than type. 


>debatable choice regarding coercion syntax.  Visual Basic,
>for all of its defects, is defensible in letting the QI call
>be implicit when syntactically needed, e.g.

I wouldn't defend Visual Basic even if it were defensible.

>> >*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 !!!!
>
>No, 'more abstract' modeling of a physical system only equals 'more
>abstract', that's all. 

This is an end  point. You say not and I say yes.

>
>> 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.
>
>Having a *good* typesystem need be nothing as confining as
>that; you don't seem to have much experience using such
>typesystems -- I strongly suggest you try out a few before
>expressing such trenchant judgments.
>

I have programmed in C for countless years, a bit in C++ and 
a bit in Java. And in Pascal .  And yes, I won't like types, ever.

The two brightest languages that come to my mind ( LISP, python)
don't use types. 

While three of the worst languates have types (ADA, Java and C++).

It's suspicious that Smalltalkers don't like types . Somewhat
types represent a "hackerish" (low form of Computer Science)
way of doing thing rights. 

Sure, types are a good tool for certain things. But, sure, we
have better tools for that sort of things.

--- 
MGA