What is Python's answer to Perl 6?

  • Thread starter Reinhold Birkenfeld
  • Start date
J

Jeremy Bowers

well, they failed to implement all of the tests but those implemented
actually run faster than CPython.

It is trivial to make something that implements a subset of the language
run faster than something that implements the entire language.

This is why while I am optimistic and hopeful, I don't consider current
running speeds to be evidence that they will win. Call me when they've got
the whole language.

Also, there is the counterarguement that they probably have debug code and
stuff still in there, or things easily optimized. (I hope so, otherwise
they are Yet Another Project to fall victim to premature optimization;
let me say this clearly, it would be a *bad sign* if their code is
currently optimized.) But that just reinforces my point about the current
code not being useful as a reference for how fast the final Parrot will
run.
 
J

Jeremy Bowers

What is Python's answer to Perl 6?

"Hi, welcome to the party.

Wow, you sure have an awful lot of cruft attached to you, considering you
can't do much more, if any, than me."

Perl 6 may be the best thing that happened to Python. Esp. if both run on
Parrot and people suddenly have a per-object choice about which language
to use. Ob-believe-it-when-I-see-it.

Perl 6, IMNSHO, represents the ultimate failure of the philosophy of Perl.
When you are a small language, a handful of exceptions for the common
cases might make sense. Even Python has its little exceptions, like the
"print" statement-not-a-function, and the resulting "print >>" syntax.

In the Python philosophy, those were warts. In the Perl philosophy, those
would be something to be embraced, and indeed they are:

print FILEHANDLE LIST
print LIST
print Prints a string or a list of strings. Returns true if success-
ful. FILEHANDLE may be a scalar variable name, in which case
the variable contains the name of or a reference to the file-
handle, thus introducing one level of indirection. (NOTE: If
FILEHANDLE is a variable and the next token is a term, it may
be misinterpreted as an operator unless you interpose a "+" or
put parentheses around the arguments.) If FILEHANDLE is omit-
ted, prints by default to standard output (or to the last
selected output channel--see "select"). If LIST is also omit-
ted, prints $_ to the currently selected output channel. To
set the default output channel to something other than STDOUT
use the select operation. The current value of $, (if any) is
printed between each LIST item. The current value of "$\" (if
any) is printed after the entire LIST has been printed.
Because print takes a LIST, anything in the LIST is evaluated
in list context, and any subroutine that you call will have one
or more of its expressions evaluated in list context. Also be
careful not to follow the print keyword with a left parenthesis
unless you want the corresponding right parenthesis to termi-
nate the arguments to the print--interpose a "+" or put paren-
theses around all the arguments.

Note that if you're storing FILEHANDLES in an array or other
expression, you will have to use a block returning its value
instead:

print { $files[$i] } "stuff\n";
print { $OK ? STDOUT : STDERR } "stuff\n";

Just the docs for the print statement have to tell you about the call
context of the calls in a list, there's a special case that requires a
block. Python's print doc is longer by word count, but is actually simpler.

http://docs.python.org/ref/print.html

plus the last paragraph is a wart.

The problem is the little exceptions start interacting exponentially, and
ultimately, exponentially beats anything that a human can produce. Perl 6
may be great to use, but it will be a long time before I trust it, and I
strongly expect that despite how rosy everything is presented in the
Exegeses and such, that if you try to combine two or three of the nifty
features you'll be pulling out your hair in nothing flat. I don't and
can't know this, this is just my intuition, based on experience, speaking.

And what on Earth does Perl 6 say about Perl 7?

As a user of both Perl and Python, I am not concerned about Python being
"wiped out" by Perl 6, nor do I see a strong need to change Python as a
result. So far, the Python implementation of the good ideas I see in the
Perl 6 docs have been trivial, and so far, despite having implementations
on hand I've never needed them. ("any" and related keywords come to mind.)

(I have a similar rant about software reverse compatibility, and why it is
a trap: http://www.jerf.org/iri/2004/06/20.html

I think the way Python does it is just about optimal; try hard, but
reverse compatibility is not job #1 and if we *have* to break it, do so.
By dealing with the problem head on, everything actually works out much
better than if you sweep the problem under the rug until you can't
possibly do it anymore, and your platform is bulging at the seams with
reverse compatibility code.

In terms of the essay above, Perl is headed for exponential pain, only
instead of it coming about because of reverse compatibility fixes/hacks,
it is coming about because of the interactions of all of the More Than One
Ways To Do It, and those Ways ultimately have the same effect as reverse
compatibility patches/hacks.)
 
N

Nelson Minar

Reinhold Birkenfeld said:
Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.
Is Python taking a similar step (-> Python 3) some time in the near future?

I sure hope not!
 
M

Max M

Michael said:
I'll believe the performance benefits when I see them. The Parrot people
promised they would be faster by OSCON 2004 or Guido would get to pie
Dan Sugalski in the face. If you don't already know what happened, you
can see a picture here:

I just wonder what the difference is between .net, Mono and Parrot?

To me they all seem to pretty similar goals.


--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science
 
R

Reinhold Birkenfeld

Max said:
I just wonder what the difference is between .net, Mono and Parrot?

To me they all seem to pretty similar goals.

..NET and Mono _are_ pretty much the same - Mono is an open-source
reimplementation of the .NET framework.

Reinhold
 
M

Marc 'BlackJack' Rintsch

(Perl6 proposes this sort of syntax for grouping regexes:

grammar Some_Grammar {
rule identifier { [a-z]* }
rule plus_expression { <identifier> \+ <identifier> }
etc.
}

I just think that the new RE syntax is much cleaner and easier to read.
We'll see how other languages adapt or not.

Looks more like a grammar than a pure RE. There are already Python
modules to write grammars.

Ciao,
Marc 'BlackJack' Rintsch
 
J

John Roth

Jeremy Bowers said:
It is trivial to make something that implements a subset of the language
run faster than something that implements the entire language.

This is why while I am optimistic and hopeful, I don't consider current
running speeds to be evidence that they will win. Call me when they've got
the whole language.

Also, there is the counterarguement that they probably have debug code and
stuff still in there, or things easily optimized. (I hope so, otherwise
they are Yet Another Project to fall victim to premature optimization;
let me say this clearly, it would be a *bad sign* if their code is
currently optimized.) But that just reinforces my point about the current
code not being useful as a reference for how fast the final Parrot will
run.

I suspect that the performance issue is being clouded by the
reference counting mechanism in CPython. Modern garbage collectors
are reputedly significantly faster. If Python 3.0 removes reference
counting it might speed up substantially. Note that IronPython is
reported to run at the same (or better) speed as CPython, even
though the CLR is not optimized for running scripting languages.

John Roth
 
A

Aahz

I suspect that the performance issue is being clouded by the
reference counting mechanism in CPython. Modern garbage collectors
are reputedly significantly faster. If Python 3.0 removes reference
counting it might speed up substantially. Note that IronPython is
reported to run at the same (or better) speed as CPython, even
though the CLR is not optimized for running scripting languages.

IronPython also doesn't have to worry about random C libraries. That's
one reason why refcounting works better in CPython.
 
M

Mike Meyer

Valentino Volonghi aka Dialtone said:
Correct, but breaking everything in the language will make Perl6 a
completely new one, just preserving the name. And the community will have to
relearn from scratch to love it. Are you ready to almost trash all the
current perl5 library?

They won't have to trash the Perl 5 libraries. Perl 5 is being
retargeted to Parrot, so that Perl 6 can call Perl 5 libraries, and
vice versa. And ditto for Python and Ruby.

<mike
 
A

Alex Martelli

Max M said:
Yes, I know that. But know that is both .net and mono, why parrot?

Parrot is a completely different and disjoint virtual machine wrt
Mono/dotNet, optimized to run several VHLLs, including Perl (both 5 and
6) and others, and without any of the constraints that Mono has because
of the decision to follow Microsoft's CRL standard.

There are, of course, several reasons for the Parrot people to do their
own VM rather than accept Microsoft's design (or Sun's, for that
matter). I don't understand your "why" question...!


Alex
 
A

Alex Martelli

Wilk said:
It was java, why .net and mono...
And finaly, there is python, why java ;-) ?

Sun had its own motivations, of course -- for example, they wanted C-ish
syntax and compiletime typing. That's generally the kind of motivations
for each new language invention -- a desire for a different mix of
features from the existing ones.

New VMs generally have different motivations, tied to performance more
than to features per se. Though I could see wanting a new VM for such
reasons as supporting some new and different threading model, say.


Alex
 
M

Max M

Reinhold said:
.NET and Mono _are_ pretty much the same - Mono is an open-source
reimplementation of the .NET framework.

Yes, I know that. But know that is both .net and mono, why parrot?

--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science
 
C

Carl Banks

Reinhold Birkenfeld said:
Hello,

another Perl/Python question: the subject says it all.

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.

Is Python taking a similar step (-> Python 3) some time in the near future?

When Perl 6 arrives, Python's answer to it will be so profound and so
amazing that it will utterly meet and defeat the challenge; it will
put all pitiful hopes of Perl 6 to rest; it will expose Perl for the
fraud that it is.

What will this answer be?

To do nothing.
 
M

Max M

Alex said:
There are, of course, several reasons for the Parrot people to do their
own VM rather than accept Microsoft's design (or Sun's, for that
matter). I don't understand your "why" question...!

"Why" as in "what is the difference, and the advantage of parrot", not
as in "Why do they want to do something as stupid"

All the virtual machines seems to boost the same advantages for all the
languages.

So I just wondered if anybody had a few practical examples of the
difference, and why I should get excited over Parrot.

So far, it seems like a better idea to get Python running on .net/mono,
as I cannot seem to get around the Windows platform in my professional
work.

However, I can easily get around Perl, so if Python on Parrot dosn't
have a big advantage it is hard to get excited about.

Making Python run faster is not that big a deal to me.

--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science
 
N

Nick Craig-Wood

Reinhold Birkenfeld said:
Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.

Actually Perl6 is one of my major reasons for retooling my brain in
Python. I've been using perl for a long time - I have 3 revisions of
programming perl on my bookshelf. I first learnt Perl4. Perl5 seemed
a reasonable way to cludge on some OO stuff etc without completely
redoing the language. However Perl6 completely misses the target as
far as I am concerned. Its too byzantine, too big and just tries to
be too clever. Yes its fun to have a programming language you can
write techno-puns in (and yes I've enjoyed that part of perl too).
However I found through personal experience that TIMTOWDI isn't good
for large projects and I don't see Perl6 making this better.

To sum up, Perl6 made a perfect opportunity for me to migrate to
Python!
 
R

Roy Smith

Nick Craig-Wood said:
Perl5 seemed a reasonable way to cludge on some OO stuff etc without
completely redoing the language.

I would hardly call perl's OO stuff "reasonable". A cludge, for sure.
But I think reasonable would be stretching it. Anyway, the {}-> syntax
looks more like a smiley face to me than a programming language
construct.
 
J

John Roth

Max M said:
"Why" as in "what is the difference, and the advantage of parrot", not as
in "Why do they want to do something as stupid"

All the virtual machines seems to boost the same advantages for all the
languages.

Actually, they don't. Jython runs at about 1/3rd the speed as CPython.
I'm surprised that IronPython runs as fast as it does, although Microsoft's
attitude at making the CLR a multi-language platform (as distinct from
Sun's deliberate direction to make the JVM a single-language
platform) may be part of the difference.

Given that nobody in the Perl camp is going to spend more than
a few chuckles at the idea of tying Perl 6 to a proprietary Microsoft
product, and the proven poor performance of the JVM for
dynamic languages, they really didn't have much of a choice in
rewriting their already existing virtual machine.
So I just wondered if anybody had a few practical examples of the
difference, and why I should get excited over Parrot.

Parrot was originally intended to run both Perl 6 and Perl 5. Adding
Python was an afterthought, and somewhat a consequence of an
April Fools joke. Some people think it still is.
So far, it seems like a better idea to get Python running on .net/mono, as
I cannot seem to get around the Windows platform in my professional work.

Shrug. I cannot get excited about a proprietary Microsoft platform.
If anyone wants to port IronPython to Mono, I suspect the path is
clear (although maybe not - I don't know the license for that.)

John Roth
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,210
Messages
2,571,091
Members
47,692
Latest member
RolandRose

Latest Threads

Top