Python not a Very High-Level Language?

[Stefan Schwarzer]

Hello all,

Boudewijn Rempt schrieb:
> Yes, I read that too, a while ago, and it got me thinking about what
> a language like he proposes would look like. He made two striking
> suggestions - being able to draw part of the logic, in the sidebar of the
> code, as it were, and having a sort of underlying representation of the
> code (he said xml, but that's what everyone is saying these days),

Because "everyone" sais it, it doesn't necessarily mean that it is
bad ;-) .

> so that
> a particular development tool could show the code in various helpful ways.
> 
> I think, however, that he has confused the language with the creation
> and maintenance tool (I hesitate to call it an editor anymore), Already
> in Steve MacConnels Code Complete, there was a proposal for an ideal
> programming environment. I do think even the best editors aren't
> getting close to the sophistication enjoyed by users of basic stuff
> like webbrowsers (the KDE2 general browser Konqueror is incredibly
> sophisticated) or office suites - so there he has a point.
> [...]
> I'd like to write a programming environment that not only included
> syntax highlighting, but also linking to documentation, a rich
> presentation of the program and its logic, but I suspect programmers
> will always go back to the ascii source.

This separation of code and maintanance tool is in part already
common: think of folding editors. An advantage of these is that you
can still view the code with a "normal" text editor and this
advantage should remain in future ideas. XML may be a good starting
point.

Of course, this approach rises the complexity of the "editor", and
would (as said) lead to a distinction of source and its view. On the
other hand, you can _still_ use a "usual" ASCII editor, in the same
way you can edit HTML with any text editor. The kind of editor you
use (plain text or a special program browser/editor) would be optional.

The other topics which the author on the O'Reilly site, Greg Wilson,
mentions might also be worth considering. For example, I never needed
tuples (explicitly) yet, i. e. in a sense that lists would not work.
(If tuples would be taken out of the language or their use deprecated)
tuple un/packing would become list un/packing and so on.)

The idea to provide "true" multidimensional arrays sounds also very
good to me. Treating multidimensional arrays as lists of lists (or
vice versa) complicates the use of them, and may it be that a
special wrapper module is needed to provide the corresponding
funtionality.

Stefan