What is Python's answer to Perl 6?

[Michael Hoffman]

Re: What is Python's answer to Perl 6?

gabriele renzi wrote:[color=blue]
> well, they failed to implement all of the tests but those implemented
> actually run faster than CPython.[/color]

Just saying, they said they would deliver it by a certain date and they
didn't. I understand the team is mainly made up of volunteers so I am
sympathetic, but I will still believe their claims only when they prove
them. :)
[color=blue]
> Anyway they are at 0.1.1 or something like that. There is time to become
> faster or to disappear completely, I guess[/color]

There is also time for CPython or IronPython to become faster during
that time.
--
Michael Hoffman

[Josiah Carlson]

Re: What is Python's answer to Perl 6?


Reinhold Birkenfeld <reinhold-birkenfeld-nospam@wolke7.n et> wrote:[color=blue]
>
> 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?[/color]

I'd say Python 2.2, 2.3 and 2.4 are all answers to Perl 6. Python has
gotten incrementally faster, gained a larger standard library, and added
some language features without breaking backwards compatibility in a
major way.

Python is getting better /today/. Python is available /today/. Perl 6
won't be available for a couple years, meanwhile, Perl 5 doesn't seem
like it has undergoing any significant changes in a few years (I don't
follow Perl 5's development, but I haven't noticed any slashdot stories
on Perl 5).

- Josiah

[Peter Hansen]

Re: What is Python's answer to Perl 6?

Michael Hoffman wrote:[color=blue]
> Reinhold Birkenfeld wrote:
>[color=green]
>> C. Functions that could be made attributes of lists/sequences
>>
>> max, min, len, enumerate, sum
>>
>> But that would require to implement them for all sequence types or
>> implement a common basetype 'seq'.[/color]
>
> And iterators?[/color]

And dicts. And ....

[Reinhold Birkenfeld]

Re: What is Python's answer to Perl 6?

Peter Hansen wrote:[color=blue]
> Michael Hoffman wrote:[color=green]
>> Reinhold Birkenfeld wrote:
>>[color=darkred]
>>> C. Functions that could be made attributes of lists/sequences
>>>
>>> max, min, len, enumerate, sum
>>>
>>> But that would require to implement them for all sequence types or
>>> implement a common basetype 'seq'.[/color]
>>
>> And iterators?[/color]
>
> And dicts. And ....[/color]

Exactly the problem.

Reinhold

--
[Windows ist wie] die Bahn: Man muss sich um nichts kuemmern, zahlt fuer
jede Kleinigkeit einen Aufpreis, der Service ist mies, Fremde koennen
jederzeit einsteigen, es ist unflexibel und zu allen anderen Verkehrs-
mitteln inkompatibel. -- Florian Diesch in dcoulm

[Reinhold Birkenfeld]

Re: What is Python's answer to Perl 6?

A.M. Kuchling wrote:[color=blue]
> On 30 Oct 2004 15:42:46 +0300,
> Ville Vainio <ville@spammers .com> wrote:[color=green]
>> Well, if they are any good we'll just port them to Python. "import
>> re2" and we are all set. Everyone wins.[/color]
>
> I don't think so. Perl5 regexes are pretty independent of the rest of the
> language, but Perl6's are interweaved with the rest of Perl's syntax, so I
> don't think we'll ever see a Perl6-equivalent of PCRE.[/color]

The interweaving is only important if you "design your program as one
big regex" ;). There is the possibility of embedded closures, OK, but
one can live without it.

The assignment of variables in regexes can surely be reproduced in a
PCRE lib.

And I can imagine to wrap up the Perl6 concept of grammars in a class
that then can resolve referenced regexes.

(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.

Reinhold

--
[Windows ist wie] die Bahn: Man muss sich um nichts kuemmern, zahlt fuer
jede Kleinigkeit einen Aufpreis, der Service ist mies, Fremde koennen
jederzeit einsteigen, es ist unflexibel und zu allen anderen Verkehrs-
mitteln inkompatibel. -- Florian Diesch in dcoulm

[Jeremy Bowers]

Re: What is Python's answer to Perl 6?

On Sat, 30 Oct 2004 12:53:13 +0000, gabriele renzi wrote:[color=blue]
> well, they failed to implement all of the tests but those implemented
> actually run faster than CPython.[/color]

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 counterarguemen t 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.

[Jeremy Bowers]

Re: What is Python's answer to Perl 6?

On Sat, 30 Oct 2004 11:18:30 +0200, Reinhold Birkenfeld wrote:[color=blue]
> What is Python's answer to Perl 6?[/color]

"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.)

[Nelson Minar]

Re: What is Python's answer to Perl 6?

Reinhold Birkenfeld <reinhold-birkenfeld-nospam@wolke7.n et> writes:[color=blue]
> 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?[/color]

I sure hope not!

[Max M]

Re: What is Python's answer to Perl 6?

Michael Hoffman wrote:
[color=blue]
> 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:[/color]

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

[Reinhold Birkenfeld]

Re: What is Python's answer to Perl 6?

Max M wrote:[color=blue]
> Michael Hoffman wrote:
>[color=green]
>> 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:[/color]
>
> I just wonder what the difference is between .net, Mono and Parrot?
>
> To me they all seem to pretty similar goals.[/color]

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

Reinhold

--
[Windows ist wie] die Bahn: Man muss sich um nichts kuemmern, zahlt fuer
jede Kleinigkeit einen Aufpreis, der Service ist mies, Fremde koennen
jederzeit einsteigen, es ist unflexibel und zu allen anderen Verkehrs-
mitteln inkompatibel. -- Florian Diesch in dcoulm

[Grant Edwards]

Re: What is Python's answer to Perl 6?

On 2004-10-30, Reinhold Birkenfeld <reinhold-birkenfeld-nospam@wolke7.n et> wrote:
[color=blue]
> another Perl/Python question: the subject says it all.[/color]

Python 1.5.2.
[color=blue]
> Is Python taking a similar step (-> Python 3) some time in the near future?[/color]

Python took that step 10 years ago.

--
Grant Edwards grante Yow! So this is what it
at feels like to be potato
visi.com salad

[Marc 'BlackJack' Rintsch]

Re: What is Python's answer to Perl 6?

In <2uhpqlF2arp3cU 1@uni-berlin.de>, Reinhold Birkenfeld wrote:
[color=blue]
> (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.[/color]

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

Ciao,
Marc 'BlackJack' Rintsch

[John Roth]

Re: What is Python's answer to Perl 6?


"Jeremy Bowers" <jerf@jerf.or g> wrote in message
news:pan.2004.1 0.30.18.40.19.1 37063@jerf.org. ..[color=blue]
> On Sat, 30 Oct 2004 12:53:13 +0000, gabriele renzi wrote:[color=green]
>> well, they failed to implement all of the tests but those implemented
>> actually run faster than CPython.[/color]
>
> 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 counterarguemen t 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.[/color]

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

[Aahz]

Re: What is Python's answer to Perl 6?

In article <10o821fqaiahu3 1@news.supernew s.com>,
John Roth <newsgroups@jhr othjr.com> wrote:[color=blue]
>
>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.[/color]

IronPython also doesn't have to worry about random C libraries. That's
one reason why refcounting works better in CPython.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

WiFi is the SCSI of the 21st Century -- there are fundamental technical
reasons for sacrificing a goat. (with no apologies to John Woods)

[Mike Meyer]

Re: What is Python's answer to Perl 6?

Valentino Volonghi aka Dialtone <dialtone.##NOS PAM#$#$$#@gmail .com> writes:
[color=blue]
> Reinhold Birkenfeld <reinhold-birkenfeld-nospam@wolke7.n et> wrote:[color=green]
>> For average programs, it seems that it will. Just think about classes.
>> One thing the freshmeat article complains about is breaking
>> compatibility. Well, you can't correct design mistakes by keeping old
>> syntax around.[/color]
> 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?[/color]

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
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.