some comments for Python 3000

[lobozc at my-deja.com]

In article <3995E6D8.96DA23B4 at san.rr.com>,
  Courageous <jkraska1 at san.rr.com> wrote:
>
> > Examples here would be a) implementation of generators (like in
icon)
> > [they can be imitated by classes but generators are simply more
concise
> > for small things]; b) consideration of some form of goal-directed
> > evaluation [icon, again, saves plenty of coding]. Smaller examples
> > could be extension of the functionality of lambda functions [rewrite
> > model for them?] as well as consideration for some higher model of
> > string handling...
>
> With due respect, none of these things are particularly exciting
> to the mainstream programmer.

I agree with you! they are not _direcly_ 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.


 For Python to "get the attention it
> deserves," it needs a native compiler that compiles as effectively
> as ACL. Now *that* would get it the attention it deserves.

I do not argue that the language issues are the only ones - performance
may be important in some areas. For some programmers/problems - while
language is seen and used by all programmers using that language.
    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... So the implementation may automatically
parallelize the computations if multiple processors are present. You
can't do that with traditional code very well because it's difficult to
figure out sequencing.

>
> I would make a wholesale switch to Python for all softare development
> if I could use it in performance-sensitive environments.
>
> 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. If I need a
scripting language I need to write the smallest number of lines of code
to get the result.

Quest for speed... I'm not sure that concentrating on that would be in
Python's interest - if that would lead to abandoning language
improvements. Smalltalk at the end got quite decent speed and it didn't
help much.
>
> C//
>


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