What is Python's answer to Perl 6?

[Reinhold Birkenfeld]

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?

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

[Cliff Wells]

On Sat, 2004-10-30 at 11:18 +0200, Reinhold Birkenfeld wrote:

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?

assert("Perl 6" < "Python 2")

Somehow I suspect that assertion will hold for the foreseeable future,
no matter how much the numbers change <wink>

--
Cliff Wells <cl************@comcast.net>

[Valentino Volonghi aka Dialtone]

Reinhold Birkenfeld <re************************@wolke7.net> wrote:

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.
Why do you say this? Did you read the whole Apocalypses? Anyway 15 days ago
freshmeat published this:
http://freshmeat.net/articles/view/1339/

Maybe, it's not that easier to read or write.
Is Python taking a similar step (-> Python 3) some time in the near future?

Why? What do you need to do in python that you can't do right now? Isn't it
read-write friendly enough?

Perl6 is, currently, a 4 year development effort that no one knows when will
be ended (I even read that it will take another 4 years), maybe, if it takes
so much to develop just the first version, it's really too complicated.

--
Valentino Volonghi aka Dialtone
Now running FreeBSD 5.3-beta7
Blog: http://vvolonghi.blogspot.com

[Dirkjan Ochtman]

Reinhold Birkenfeld wrote:

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?

Reinhold

The virtual machine underlying the Perl 6 language, Parrot
(www.parrotcode.org) will also support running Python. This will
probably incur performance benefits as well as allowing some interesting
interoperability between Perl 6 and Python-on-Parrot.

Whether Python-on-Parrot will become the official Python: I don't know.

Regards,

Dirkjan

[Reinhold Birkenfeld]

Valentino Volonghi aka Dialtone wrote:

Reinhold Birkenfeld <re************************@wolke7.net> wrote:

Perl is going to change dramatically to become a more powerful and
easier to (read|write) language.
Why do you say this? Did you read the whole Apocalypses?

Yes, I read most of the Apocalypses, the Exegeses and the Synopses.
Anyway 15 days ago freshmeat published this:
http://freshmeat.net/articles/view/1339/ Maybe, it's not that easier to read or write.

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.

A great plus will be the new regular expressions.

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

Why? What do you need to do in python that you can't do right now? Isn't it
read-write friendly enough?

Perl6 is, currently, a 4 year development effort that no one knows when will
be ended (I even read that it will take another 4 years), maybe, if it takes
so much to develop just the first version, it's really too complicated.

That's a point. The whole object system (roles, interfaces, etc.) is far
too complicated and almost no one will need it.

Reinhold

PS: I'm happy with Python, and I'm not going to complain about it. But
as a programmer who uses both languages, I'm just asking because I'm
curious...

--
[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

[Michael Hoffman]

Dirkjan Ochtman wrote:

The virtual machine underlying the Perl 6 language, Parrot
(www.parrotcode.org) will also support running Python. This will
probably incur performance benefits as well as allowing some interesting
interoperability between Perl 6 and Python-on-Parrot.

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:

http://weblogs.mozillazine.org/zach/...es/006129.html
--
Michael Hoffman

[Valentino Volonghi aka Dialtone]

Reinhold Birkenfeld <re************************@wolke7.net> wrote:

Yes, I read most of the Apocalypses, the Exegeses and the Synopses.
I hope it worths the effort :P
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.
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?
PS: I'm happy with Python, and I'm not going to complain about it. But
as a programmer who uses both languages, I'm just asking because I'm
curious...

I actually hope python 3.0 is not that far away, since there are some tiny
things that really need to be fixed in python2. Perl and Python, after all,
have a very different philosophy and the featurefulness of perl6 will be
matched with the extreme simplicity and clarity of python (which is also
a feature)

--
Valentino Volonghi aka Dialtone
Now running FreeBSD 5.3-beta7
Blog: http://vvolonghi.blogspot.com

[A.M. Kuchling]

On Sat, 30 Oct 2004 11:18:30 +0200,
Reinhold Birkenfeld <re************************@wolke7.net> wrote:

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

The list of features for Python 3000 is described in PEP 3000,
appropriately enough:

http://www.python.org/peps/pep-3000.html

Most of the suggested changes remove redundancy, such as removing
now-unneeded built-in functions and language features.

--amk

[Ville Vainio]

>>>>> "Reinhold" == Reinhold Birkenfeld

> <re************************@wolke7.net> writes:

Reinhold> A great plus will be the new regular expressions.

Well, if they are any good we'll just port them to Python. "import
re2" and we are all set. Everyone wins.
Reinhold> PS: I'm happy with Python, and I'm not going to complain
Reinhold> about it. But as a programmer who uses both languages,
Reinhold> I'm just asking because I'm curious...

Overall, there seems to be some kind of minor consensus (to the extent
it means anything in the internet) that perl6 is a disaster that is
taking way too long to happen. Implementing (rather making the design
decisions) py3k seems trivial in comparison.

--
Ville Vainio http://tinyurl.com/2prnb

[gabriele renzi]

Michael Hoffman ha scritto:

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:

http://weblogs.mozillazine.org/zach/...es/006129.html

well, they failed to implement all of the tests but those implemented
actually run faster than CPython.
Anyway they are at 0.1.1 or something like that. There is time to become
faster or to disappear completely, I guess

[Jonathan Ellis]

Reinhold Birkenfeld wrote:

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.

Perl6 has been in development since 2001 and isn't anywhere near done.
No doubt it will be done sometime but it reminds me of Gnu Hurd --
working alternatives are out there so it's hard to get excited about
vapor. (Which isn't exactly fair to the Hurd guys. :)

Perl6 will fix some of the worst broken-ness of perl5 but I haven't
seen anything indicating that Wall's TMTOWTDI philosophy has changed,
so it will still suck for anything nontrivial.

-Jonathan

[Jonathan Ellis]

A.M. Kuchling wrote:

The list of features for Python 3000 is described in PEP 3000,
appropriately enough:

http://www.python.org/peps/pep-3000.html

Most of the suggested changes remove redundancy, such as removing
now-unneeded built-in functions and language features.

I'm sure this has been brought up before, but a quick google search
didn't find anything on moving [has|get|set]attr into attributes of
object. Why wouldn't this be considered a Good Thing? Just because
Ruby people would like it? :)

-Jonathan

[Reinhold Birkenfeld]

Jonathan Ellis wrote:

A.M. Kuchling wrote:

The list of features for Python 3000 is described in PEP 3000,
appropriately enough:

http://www.python.org/peps/pep-3000.html

Most of the suggested changes remove redundancy, such as removing
now-unneeded built-in functions and language features.

I'm sure this has been brought up before, but a quick google search
didn't find anything on moving [has|get|set]attr into attributes of
object. Why wouldn't this be considered a Good Thing? Just because
Ruby people would like it? :)

You can take this step even further:

The builtin functions (that aren't doomed for py3k) can be classified in
those groups:

A. Constructors for built-in types

basestring, bool, complex, dict, file, float, int, list, long, object,
str, slice, tuple, type

These cannot be made attributes of some object.

B. Functions that can be attributed to some class or module

abs, divmod, round, pow -> math

ord -> str
In consequence: [uni]chr -> int
hex, oct -> int

super, *attr, isinstance, issubclass -> object

hash -> sys?

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

D. Other functions I cannot attribute to a class

eval
globals, locals, vars
iter
property
classmethod, staticmethod
cmp
[x]range
repr
__import__

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

[A.M. Kuchling]

On 30 Oct 2004 15:42:46 +0300,
Ville Vainio <vi***@spammers.com> wrote:

Well, if they are any good we'll just port them to Python. "import
re2" and we are all set. Everyone wins.

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.

--amk

[Michael Hoffman]

Reinhold Birkenfeld wrote:

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

And iterators?
--
Michael Hoffman

[Michael Hoffman]

gabriele renzi wrote:

well, they failed to implement all of the tests but those implemented
actually run faster than CPython.
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. :)
Anyway they are at 0.1.1 or something like that. There is time to become
faster or to disappear completely, I guess

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

[Josiah Carlson]

Reinhold Birkenfeld <re************************@wolke7.net> wrote:

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?

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]

Michael Hoffman wrote:

Reinhold Birkenfeld wrote:

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

And iterators?

And dicts. And ....

[Reinhold Birkenfeld]

Peter Hansen wrote:

Michael Hoffman wrote:

Reinhold Birkenfeld wrote:

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

And iterators?

And dicts. And ....

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]

A.M. Kuchling wrote:

On 30 Oct 2004 15:42:46 +0300,
Ville Vainio <vi***@spammers.com> wrote:

Well, if they are any good we'll just port them to Python. "import
re2" and we are all set. Everyone wins.

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.

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]

On Sat, 30 Oct 2004 12:53:13 +0000, gabriele renzi wrote:

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.

[Jeremy Bowers]

On Sat, 30 Oct 2004 11:18:30 +0200, Reinhold Birkenfeld wrote:

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

[Nelson Minar]

Reinhold Birkenfeld <re************************@wolke7.net> writes:

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!

[Max M]

Michael Hoffman wrote:

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

[Reinhold Birkenfeld]

Max M wrote:

Michael Hoffman wrote:

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.

..NET and Mono _are_ pretty much the same - Mono is an open-source
reimplementation 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]

On 2004-10-30, Reinhold Birkenfeld <re************************@wolke7.net> wrote:

another Perl/Python question: the subject says it all.
Python 1.5.2.
Is Python taking a similar step (-> Python 3) some time in the near future?

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]

In <2u*************@uni-berlin.de>, Reinhold Birkenfeld wrote:

(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

[John Roth]

"Jeremy Bowers" <je**@jerf.org> wrote in message
news:pa****************************@jerf.org...

On Sat, 30 Oct 2004 12:53:13 +0000, gabriele renzi wrote:

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.

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]

In article <10*************@news.supernews.com>,
John Roth <ne********@jhrothjr.com> wrote:

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.
--
Aahz (aa**@pythoncraft.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]

Valentino Volonghi aka Dialtone <di*********************@gmail.com> writes:

Reinhold Birkenfeld <re************************@wolke7.net> wrote:

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.

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

[Max M]

Reinhold Birkenfeld wrote:

Max M wrote:

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.

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

[Wilk]

Max M <ma**@mxm.dk> writes:

Reinhold Birkenfeld wrote:

Max M wrote:

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.

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

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

--
Wilk - http://flibuste.net

[Alex Martelli]

Max M <ma**@mxm.dk> wrote:

Reinhold Birkenfeld wrote:

Max M wrote:

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.

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

[Alex Martelli]

Wilk <wi******@OUTflibuste.net> wrote:
...

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

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

[Carl Banks]

Reinhold Birkenfeld <re************************@wolke7.net> wrote in message news:<2u*************@uni-berlin.de>...

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.
--
CARL BANKS

[Max M]

Alex Martelli wrote:

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

[Nick Craig-Wood]

Reinhold Birkenfeld <re************************@wolke7.net> wrote:

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!

--
Nick Craig-Wood <ni**@craig-wood.com> -- http://www.craig-wood.com/nick

[Josiah Carlson]

Nick Craig-Wood <ni**@craig-wood.com> wrote:

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

That is my vote for Quote of the Week.

- Josiah

[Roy Smith]

Nick Craig-Wood <ni**@craig-wood.com> wrote:

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.

[John Roth]

"Max M" <ma**@mxm.dk> wrote in message
news:41*********************@dread12.news.tele.dk. ..

Alex Martelli wrote:

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.

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

--

hilsen/regards Max M, Denmark

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

[Dirkjan Ochtman]

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

People have also been working on running PHP on Parrot, a Forth-like
language is reimplemented on Parrot, and Parrot developers are taking
Ruby into account as well. I don't know how much of an afterthought
Python-on-Parrot was, but it's certainly not a minor subject right now.

Regards,

Dirkjan

[Jon Perez]

A.M. Kuchling wrote:

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

The list of features for Python 3000 is described in PEP 3000,
appropriately enough:

http://www.python.org/peps/pep-3000.html

Most of the suggested changes remove redundancy, such as removing
now-unneeded built-in functions and language features.

Which I heartily concur with as being what should be one of
the primary goals...

TIMTOWTDI and ad hoc feature development are exactly what
makes Perl source code so unwieldy and inelegant.

[Y2KYZFR1]

Reinhold Birkenfeld <re************************@wolke7.net> wrote in message news:<2u*************@uni-berlin.de>...

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?

Reinhold

nice troll bait . . .

Python has always been the most READABLE and WRITABLE language, and
will continue to be extremely MAINTANCE friendly.

Perl has always been a WRITE only, MAINTANCE nightmare language. For
MANY reasons.
Nothing in the Perl 6 docs leads me to believe that it will be any
less cryptic and obfuscated and propeller head appealing than 5. More
complicated if anything.

[gabriele renzi]

Dirkjan Ochtman ha scritto:

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.

People have also been working on running PHP on Parrot, a Forth-like
language is reimplemented on Parrot, and Parrot developers are taking
Ruby into account as well. I don't know how much of an afterthought
Python-on-Parrot was, but it's certainly not a minor subject right now.

don't forget that they can run brainf**k :)

Anyway, an interesting reading on the subject is the blog from dan sugalski
www.sidhe.org/~dan/blog
especially when he goes deep in how to work out stuff like 'how to call
finalizers in languages that have totally different concepts of it'

[Peter Maas]

Jeremy Bowers schrieb:

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.

To expect someone to fail who wants to reimplement a faster Python fulfils
my definition of pessimism. ;)

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel [phone]
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------

[Reinhold Birkenfeld]

Y2KYZFR1 wrote:

Reinhold Birkenfeld <re************************@wolke7.net> wrote in message news:<2u*************@uni-berlin.de>...

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?

Reinhold
nice troll bait . . .

Yes, I confess, the article was intendedly trolly. But I got interesting
views on the issue, and for that I want to thank you all.
Python has always been the most READABLE and WRITABLE language, and
will continue to be extremely MAINTANCE friendly.

Perl has always been a WRITE only, MAINTANCE nightmare language. For
MANY reasons.
Nothing in the Perl 6 docs leads me to believe that it will be any
less cryptic and obfuscated and propeller head appealing than 5. More
complicated if anything.

I read through the Apocalypses, etc., and my first thought was: Wow, so
many features! But afterwards I realized that this featurism combined
with Perl ideology MUST lead to a total confusion in programming.

Perl is neat as long as it does what you mean - it helps you in that,
but once the DWIMmyness is too dumb to realize what you want, you have a
double-hard time finding a solution.

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

[Stefan Behnel]

John Roth schrieb:

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

IronPython 0.6 happily runs on Mono without recompiling. I only tried it
under Linux, but their web site states that it also runs under
Mono/Windows (and maybe other ports of Mono).

The problem is that it is currently more or less unusable because of the
missing stdlib, assert statements and many other things.

Stefan