Python 3000 vs Perl 6

[Corey G.]

If Perl 6 ever does get on its feet and get released, how does it
compare to Python 3000? Is Perl 6 more like Java now with Parrot? I
just want to make sure that Python is staying competitive.

If this is the wrong mailing list, just let me know. Thanks!

 

[cokofreedom]

If Perl 6 ever does get on its feet and get released, how does it
compare to Python 3000? Is Perl 6 more like Java now with Parrot? I
just want to make sure that Python is staying competitive.

If this is the wrong mailing list, just let me know. Thanks!

Do you mean in terms of speed (parrot is a JIT?). I believe Python 3k
will (when out of beta) will have a speed similar to what it has
currently in 2.5, possibly with speed ups in some locations. But
competitive-wise I think the point is Python 3k tries to remove warts
from the Python Language to make it even more friendly to readers and
writers alike. In that way it should/will stay competitive.

However towards overall usage, the general advice is to stay with the
2.x series for now, trying to ensure your code style is moving towards
the Py3k style, and then make the jump to the 3.x series when it is
finialised.

Another point, is Perl 6 ever going to get released

 

[Corey G.]

What I meant, in terms of dealing with accurate or non-accurate rumors
is with speed, yes. There are plenty of comparisons where Perl is
4-15x faster then Python for 'some' operations regarding regular
expressions, etc.

For me personally, this means absolutely nothing because if I spend
50x more time comprehending spaghetti, obfuscated Perl code it's
irrelevant. The main concern (my concern) is whether or not Perl 6 is
more like Java with pre-compiled byte code (did I say that right) and
whether or not individuals without the ability to see past the surface
will begin to migrate towards Perl 6 for its seemingly faster
capabilities.

With Perl 6 taking 10+ years, if/when it actually gets released, will
it be technically ahead of Python 3000? Is Parrot worth the extra
wait the Perl 6 project is enduring? My own answer would be a
resounding no, but I am curious as to what others think.

-Thanks!

 

[cokofreedom]

What I meant, in terms of dealing with accurate or non-accurate rumors
is with speed, yes. There are plenty of comparisons where Perl is
4-15x faster then Python for 'some' operations regarding regular
expressions, etc.

For me personally, this means absolutely nothing because if I spend
50x more time comprehending spaghetti, obfuscated Perl code it's
irrelevant. The main concern (my concern) is whether or not Perl 6 is
more like Java with pre-compiled byte code (did I say that right) and
whether or not individuals without the ability to see past the surface
will begin to migrate towards Perl 6 for its seemingly faster
capabilities.

With Perl 6 taking 10+ years, if/when it actually gets released, will
it be technically ahead of Python 3000? Is Parrot worth the extra
wait the Perl 6 project is enduring? My own answer would be a
resounding no, but I am curious as to what others think.

-Thanks!

From a quick read of the Parrot Wiki page it would appear they hope to
one day allow the compilation of BOTH Perl 6 and Python, which could
be interesting.

Towards the speed, http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=all
puts Python ahead of perl, and Python Psyco ahead of Parrot PIR.
Though I haven't looked at each benchmark comparison so it is hard to
tell.

Towards what Perl 6 offers, the Wiki on it seems to indicate it will
be a clean up of Perl 5 as well as adding of many features from other
languages. It seems like Lary has gone for the TAKE IT ALL approach
which could work out well in providing practically any format for
creating Perl scripts. Or it could cause huge confusion as users ask
for help and received a 1001 different approaches...

Towards it being more advanced than Python 3k, time will tell. Both
are still active and getting updated. So while I personally will stay
with Python, others may move, or use both.

 

[Michele Simionato]

Towards it being more advanced than Python 3k, time will tell.

It is worth reminding that, in more than one sense, the most advanced
language is the one with less features ...

Michele Simionato

 

[bearophileHUGS]

(e-mail address removed):

I believe Python 3k will (when out of beta) will have a speed
similar to what it has currently in 2.5, possibly with speed ups
in some locations.

Python 3 uses by default unicode strings and multiprecision integers,
so a little slowdown is possible.


Michele Simionato:

It is worth reminding that, in more than one sense, the most advanced
language is the one with less features ...

I don't agree, Scheme or Brainfuck may have less features, but this
doesn't make them more advanced, it just makes programming with them
slower and more difficult. An advanced language is one that already
contains the most useful abstractions. For example Python has
generators and other things that are possible if you use Assembly too,
but having them pre-built in Python avoids me to use my limited brain
power to re-implement them from scratch, and I can focus on the
complex algorithm I am trying to implement. Once the Python program
works, I am then able to translate it to D/C too.
If you want to see an advanced language, you may take a look at
PyMeta, that's a bit of the future of the computer science:
http://washort.twistedmatrix.com/

Bye,
bearophile

 

[Roy Smith]

The fact that
it still hasn't been released after 8 years of development (Larry
announced it in his State of the Onion speech in 2000 I think) makes
me think that I made the right choice.

Sometimes you gotta be patient. Wine took 15 years
(http://www.winehq.org/?announce=1.0). Not that I'm supporting Perl 6,
just saying that gestation time is not always an indicator of value

 

[Michele Simionato]

Michele Simionato:


I don't agree, Scheme or Brainfuck may have less features, but this
doesn't make them more advanced, it just makes programming with them
slower and more difficult. An advanced language is one that already
contains the most useful abstractions. For example Python has
generators and other things that are possible if you use Assembly too,
but having them pre-built in Python avoids me to use my limited brain
power to re-implement them from scratch, and I can focus on the
complex algorithm I am trying to implement.

Oh, you are taking my words too literally, relax and take them in the
context of
the thread. Also consider the famous Clinger's maxim
“Programming languages should be designed not by piling feature
on top of feature, but by removing the weaknesses and restrictions
that make additional
features appear necessary.”

Michele Simionato

 

[bearophileHUGS]

Michele Simionato:
Also consider the famous Clinger's maxim

“Programming languages should be designed not by piling feature
on top of feature, but by removing the weaknesses and restrictions
that make additional features appear necessary.”

I'm relaxed, don't worry
I know that maxim, but after learning Python, Scheme (and lot of other
things) I think it's often wrong.
Well chosen restrictions sometimes are very useful, they may act like
a scaffolding, you can build higher constructions on them (Python has
no macros, this is a restriction. But this restriction has some
advantages. One of the main advantages is that it makes the Python
code more uniform across different programmers, this is one of the
thinks that makes the Python world so full of pre-made modules to do
most of the things you may want to do).

Bye,
bearophile

 

[Kay Schluehr]

If you want to see an advanced language, you may take a look at
PyMeta, that's a bit of the future of the computer science:http://washort.twistedmatrix.com/

Er, no. The future of CS is also its past i.e. EBNF

 

[Kay Schluehr]

If you want to see an advanced language, you may take a look at
PyMeta, that's a bit of the future of the computer science:http://washort.twistedmatrix.com/

Er, no. The future of CS is also its past i.e. EBNF

 

[Eric Wertman]

Flaming Thunder FTW!!!


thank you, I'm here all week.

 

[Michele Simionato]

Well chosen restrictions sometimes are very useful, they may act like
a scaffolding, you can build higher constructions on them (Python has
no macros, this is a restriction. But this restriction has some
advantages. One of the main advantages is that it makes the Python
code more uniform across different programmers, this is one of the
thinks that makes the Python world so full of pre-made modules to do
most of the things you may want to do).

I am all in favor of *well chosen* restrictions.
However the meaning of "well chosen" depends on the context. For
instance, just today I was reading this
very interesting paper on PLT Scheme object system:
http://www.cs.utah.edu/plt/publications/aplas06-fff.pdf
The interesting thing is that the whole system
is built in pure Scheme on top of macros, and still
it has an acceptable performance. In Python I could never
do the same, I would need to resort to C. So, while
I agree that for the common use cases of the enterprise
programmer Python is much more productive than Scheme,
a computer scientists experimenting with object systems
will probably find Scheme more suitable then Python.
But I am digressing. The point is that a language
with very few well chosen features (say Scheme)
allows you to build everything else on top of it
(say an object system) without needing to resort
to a different implementation language.
I program in Python much more than in Scheme for many reasons, but not
because I think that Clinger's maxin is wrong.

Michele Simionato