Python 1.6 The balanced language

[Suchandra Thapa]

Manuel Gutierrez Algaba <thor at localhost.localdomain> wrote:
>And that's python, no more and no less.
>
>And that's the greatness of python. Of course, we could add in:
>* Functional features:
>- Patterns for lists: l [ head : lists]
>
>* OO features:
>- Design by contract 
>- Strong "typing"

    Actually, I would argue that strong typing is a functional language
feature.  The major functional languages like ML and Haskell all have 
strong typing.  OTOH, C and C++ are not strongly typed, although they
are mostly there.

> So, functional-guys,
>although may do a lot of _harm_ in dark lambda-map expressions,
>they can't add to _their_ expression-confussion  those "awful"
> patterns.

    What's so bad about patterns?

>So, Java-C++-guys, although they can write 200 lines-long-functions
>(a la Java ), they can't do too much harm because they can't use
>their most fearful weapon : hard typing. So , their code is
>still understable.

    I think a strong static type system is pretty useful.  With it you're
guaranteed that if the compiler/interpeter accepts the program then
you'll have no type errors at all.  In conjunction with an  expressive 
type system, you can encode program information into types.  For example,
with ML or Haskell you can are able to create types that can only accept
odd integers or lower case letters so that if you're using a variable of
that type then you're guaranteed certain properties.  Another example
would be to define a list of type x as being an element of type x prepended
to a list of type x.  This guarantees that an lists using this type will 
only have elements that have a certain type.


>So, academic-researchers-learners, although they can do
>of dict-tricky constructs, they can't do nasty corroutines, lexical
>scopes (a la Scheme), which would be ununderstable for the C++
>guys. 

    Do mean closures when you talk about lexical scope?  
C, C++, and java all implement lexical scoping.  They don't implement
closures however, but closures aren't that difficult to understand.  Just
think of them as state that follows the object in question.


>What will happen in Python 3000 ?
> Well, that balance will be broken and python won't make sense
>any more. Sure, it'll be the same language : python. But, people
>will experience __always__ some kind unrest, because  advanced 
>features of some of the families will pop up, and nobody 
>belongs to all the families. So Java-C++ guys will have hard
>times with functional, Functional-guys will have hard times
>with hard types...

    I disagree with you there.  Pulling in strict or static typing
would be useful for large projects and wouldn't confuse anyone with
with c, c++, or functional language exposure (okay, polymorphic types
and parametric types would confuse c and c++ people a bit). The functional
extensions to python seem to mainly consist of a few additions and refinements
to the current features.  I don't see any calls for adding the more "advanced"
features such as lazy evaluation or monads.  

>- Provide clear ways (with clear doc) to expand the language for
>any of the families or for some programs : Oracle, mails

    What do you mean by this?  There are already database and smtp 
interfaces available.  I wouldn't want python to start adding SQL or 
Oracle's version of SQL to its core.

>Thinking that python can be :
>Eiffel + Haskell + Java 
>is simply ___DUMB___ and irrealistic.
>
>Sometimes there are even technical drawbacks: if you use Stackless
>python (corrutines), you can use Jpython compatibility !

    I don't anyone including Guido wants to have python become an
amalgam of Eiffel, Haskell, and Java since their paradigms don't mesh.  I'm
not even sure how you would implement a pure functional object oriented 
language. Although, I think our BDFL would lean more towards a 
Modula3+Haskell mixture =).