Home Original page

Python 1.6 The balanced language

Steve Holden sholden at holdenweb.com
Thu Aug 31 01:17:57 EDT 2000 
lobozc at my-deja.com wrote:
> 
[Haskell praise snipped]
> 
> 2) Despite my predilection for it, functional programming is not
> everything... Python is an imperative language at heart and an
> 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.
> 
Possibly, though the language already has many features which would
suggest a wide-ranging review of the territory was undertaken in the
original design.  I understand the BDFL takes usability seriously.

> 3) My particular favourite is Icon (see www.cs.arizona.edu/icon).

Wonderful language.  For a long time Icon was my Perl-equivalent, as
the syntax is pretty clean and the things you can do in small programs
are amazing.

I even wrote a commercial system in it, involving formatting data
extracted from a relational accounting system being formatted into
the FrameMaker markup language.  Got paid good money for doing it,
too!

> 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. 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. 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.
> 

Much as I like Icon (and Python too, for that matter), I would humbly
suggest that these features of Icon just don't belong in Python.  The
overhead of supporting them in the many contexts in which they aren't
really required would reduce efficiency.

Plus, despite continued demand for many new features, I believe there
has to be a point beyond which you must accept you are changing the basic
nature of the language.

Surely the best approach accepts that some problems are best for one
language, others for another, so we should just use the appropriate
language for each problem.

A better way would be to work towards allowing Python code to be mixed
with Icon, so we could easily write programs which combine the best
features of both without having to turn either into a monster unrecognisable
even to its mother :-).  Then we could produce object-oriented programs
which used backtracking, generators and coexpressions.

regards
 Steve
> >
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
Helping people meet their information needs with training and technology.
703 967 0887      sholden at bellatlantic.net      http://www.holdenweb.com/
More information about the Python-list mailing list