One Python 2.1 idea

[Alex Martelli]

<rturpin at my-deja.com> wrote in message news:926ici$vi9$1 at nnrp1.deja.com...
    [snip]
> C++ does NOT provide the same level of abstraction as
> Python. It does not have sequences, dictionaries, nor
> memory management as built in parts of the language.

What difference does it make that std::vector, std::map,
and std::auto_ptr are in the Standard C++ Library rather
than 'built in parts of the language'?  While there _are_
valid points to what you say (memory mgmt just _can't_
be made quite as smooth in C++ as it's in Python), this
bit about 'sequences and dictionaries' makes little sense
to me (maybe it's the eggnog:-).

C++ is statically typed (like Haskell, ML dialects, Eiffel,
Java, Ada, Object Pascal, Modula-3, etc).  This is a
crucial difference (I believe latent typing gives me a
great boost in productivity) and Python (like Smalltalk,
Scheme, Erlang, etc) places itself in a different
category by choosing latent typing.  But I wouldn't
frame this as an issue of level-of-abstraction.

C++ offers lots of very-low-level constructs AS WELL
AS pretty high-level ones, and, as I said, the low-level
parts keep coming up then and again even when one is
trying to work more abstractly -- also, from the wide
range of abstractions supported comes in part the huge
complexity of C++, its worse practical defect (very few
can master it fully, and anyway, complexity breeds
errors).


But Python's dynamic, latent-typed character itself
militates against your preferences: that it should
expose just one sequence-abstraction, for example,
_without_ letting the programmer express what it
knows about how a certain sequence will get used.

RDBMS enjoy a crucial difference: the low-level
information on how best to optimize (e.g.) a join
is in full possession of the RDBMS; it does not so
much depend on what SQL queries I'm using now
or in the future, but on the physical arrangement of
tables, indices, &c, which the DB 'knows'.  Optimal
arrangements will depend on the set of queries that
are intended, and that's anything BUT a solved
problem -- have you ever seen, e.g., an Oracle DB
running before and after an expert human tuner got
to it, studying the tables and the queries and tweaking
things manually?  Orders of magnitude of difference!
But SQL itself is not where the tuning is expressed,
and definitely not the queries.

I like the general approach of Dylan: let me state
things as abstractly and dynamically as I like, to
get things started -- the compiler's ability to optimize
will of course be seriously hampered.  Then, one can
tune, adding constraints, expressing what the coder
*knows* and the compiler could at best *guess*.

I _don't_ like programs which try to read my mind
and "do what's best for me whether I want it or not".
The LACK of black-magic of this sort in Python is a
good part of its charm for me.  The highly distorted
coding one sees in high-level languages which LACK
such expressive ability, to snuggle into a sweetspot
where the compiler will match a pattern and make
nice code, is *far* to common... let me say what I
mean, and I undertake to mean what I say!

Which is why I'd like to see it move towards letting
me be just as explicit as I want to be, about the
'declarative constraints' my code is designed for,
and either insert code to check the constraints, or
use them as springboards for its optimizations.

Which, I think, is the crux of our disagreement,
and I think we can agree to disagree.


> want implementation directives, they should be
> syntactically distinct annotations, appended to the
> relevant code:
>
>     stopWords = {}     #PYDIR: nodeletes
>
> At least that way, programmers reading and debugging
> the code can (in theory) ignore the annotation. (The

Which is EXACTLY what I don't want!  IF I have a
semantic constraint about there being no deletes
on this object, it's a CRUCIAL part of my abstraction
for it -- I want to state it clearly and readably, and
let compiler and human readers make of my statement
what they wish.

> compiler can also ignore the directive, if it is wrong
> headed.) In my opinion, you get far more bang for the
> buck if the compiler makes these optimizations
> automatically.

The compiler may be able to notice that there are no
deletes NOW, but it's not going to broadcast this key
semantic fact to the readers of the program, and it's
going to be hard put to do so if the code can grow
dynamically at any time.  As the program designer, I
*know* whether I intend deletes to be 'forbidden' on
the object, or if it just happens accidentally that there
are none YET; I want to be able to state what I know
*in the language*, because it's important, first of all,
for people who READ my code and want to understand
what it's up to.  That such constraints -- as well as
helping readers -- can also be checked at runtime for
better debugging, OR used to effect optimization, is
just great... but in any case *they're part of my code's
semantics*, and I want to EXPRESS its semantics, NOT
have compilers or human readers have to guess it!-)


Alex

>
> (Apologetic prologue: This mind dump is occuring after
> Christmas eve celebrations. I hope everyone reads it
> generously, and that I am not too embarrassed when I
> read it tomorrow.)
>
> Russell
>
>
> Sent via Deja.com
> http://www.deja.com/