some comments for Python 3000

[lobozc at my-deja.com]

In article <3996F17F.BE84F0CB at san.rr.com>,
  Courageous <jkraska1 at san.rr.com> wrote:
>
> > I agree with you! they are not _directly_ of any interest to the
> > programmer - their results are. List as first class objects,
functions
> > like map, reduce etc were of no interest to the mainstream
programmer -
> > if you'd ask them nobody would vote for them - yet they were put in
> > Python. Nowadays they allow much shorter as well as much safer code.
>
> I'm not sure how many people are using these functions, actually.
> But no matter; I do like them, don't get me wrong. As a lisp
programmer,
> map, reduce, remove-if, lambda, et al. are my friends.
>
welcome to the club :-)
agreed, lambdas may not be used frequently - but lists are :-)

> > > Python ... needs a native compiler that compiles ...
>
> > I do not argue that the language issues are the only ones -
performance
> > may be important in some areas.
>
> Your average Python program is outperformed by C by 6:1 and
> in some cases this is worse. It's an issue.
>
So is Java :-) and they are still popular.
Seriuosly, I'm afraid of trying to speed up Python too much - the
effort may detract from making the language better. And may constrain
further evolution of the language.

And speed is not all. From all reports Eiffel is very fast (C++ class)
and obviously so much better yet nobody's using it. Because it tried to
attack established langauge (C++) in its niche.

This is why I think [and may be greatly mistaken] that Python is safer
growing in its own niche first [like java did] before taking on others.
And Python's niche seems to be that of a 'scripting' language but good
enough for rapid mainstream programming esp. prototyping - not just
scripting. In that niche higher level language constructs are what can
tilt the balance - and what could differentiate it further from, say,
Perl (which is just a scripting language).

Universities want to have some other language to teach other
programming concepts (than the ones from Java). Academics wouldn't mind
having something to write quick prototypes in etc. An python could be
ideal in that role. [ but I don't think it is _now_ - Java is the
mainstay and current python is different from it but not by 'enough'].
With the way python is developing in can be used to show - without
frightening students - some functional language concepts. If goal-
directed eval would be somehow added... and some others... That would
be an ideal teaching tool for all the concepts which java can't teach.
And if you get students interested... sky's the limit.




> >     I would also propose that having higher level constructs may
lead
> > to speed improvements - as it enables different mappings into
> > underlying implementation code. For example - far fetched, just to
show
> > the concept, the map function can be applied in parallel to all
> > elements of the list - each in a separate thread. Not much win in
the
> > single processor environment - but Python is also used for
scripting in
> > multiprocessor servers...
>
> This will become more important very, very soon. Within 2 cpu
> generations, on-die SMP will be mainstream. Go to http://www.ibm.com
> and do a search on "POWER4" to get a preview of things to come.
>
> > > It doesn't have to be as fast a C, mind you.
> >
> > I wouldn't mind Python being faster - for free :-). But if I need
> > something _running_ fast I'll use C++ - hard to beat.
>
> But that's the point! Python is a wonderful environment! It's a
> shame to be *forced* to switch. Makes me wanna cry, veritably.
> Every time I write Python for a while and then have to go do
> write in Lesser Languages (tm), I feel *dirty*. :)-
>
> Anyway, regarding your comments via features versus performance:
> I believe that the compiler effort has the right idea with optional
> type tags and optional "strict" objects. Personally, I like the
> notion of "strict"; it's a way for the programmer to say, "hey, I'm
> done with this now". I think the concept could be deeply exploited;
> one or more optional keywords which disable entire categories of
> python dynamism both because doing so speeds things up and also
> because it's no longer needed in that section of the code.
>

i think that the history of the Icon programming language could be
analysed before any great effort is spent in that area. [I'm not
proposing any solutions here as I wasn't close enough - just a user].
It's a similar situation - a vhll interpreter which later went into
compilation effort. I don't know what the results were and what were
the biggest problems.


> C//
>


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