Parrot 0.1.1 'Poicephalus' Released

Pan T. Hose writes "The long awaited release of Parrot 0.1.1 "Poicephalus" has been finally announced on perl.perl6.internals newsgroup and perl6-internals mailing list simultaneously by Leopold Toetsch followed by an announcement on use Perl by Will Coleda and now also on Slashdot." (Read on for a list of changes since the last release, as well as a number of useful links.) Pan T. Hose continues "The most important changes since the previous version 0.1.0 (code-named 'Leaping Kakapo' and released in February) are:

• Python support: Parrot runs 4/7 of the pie-thon test suite
• Better OS support: more platforms, compilers, OS functions
• Improved PIR syntax for method calls and <op>= assignment
• Dynamic loading reworked including a "make install" target
• MMD - multi method dispatch for binary vtable methods
• Library improvement and cleanup
• BigInt, Complex, *Array, Slice, Enumerate, None PMC classes
• IA64 and hppa JIT support
• Tons of fixes, improvements, new tests, and documentation updates

The amazing project which no one had any idea would go so far from the original April Fool's Joke by Simon Cozens (also posted on Slashdot on April 1, 2001) to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few) is now available for download from CPAN and via CVS. Those who are not up-to-date with Perl 6 mailing lists can read This Week in Perl 6 weekly summaries by Piers Cawley to have some idea on how's the project been going in the last two years. It's important to read Apocalypses, Exegeses and Synopses together with RFCs and Parrot Design Documents for better understanding of the underlying rationale, especially the superiority of register-based Virtual Machines (like Parrot VM) over stack-based one (like JVM) for modern (dynamically-typed) OO languages with multiple inheritance, operator overloading, traits, roles and much, much more. Parrot Docs, FAQ and examples are also very helpful. This is a very important step in the direction of Perl 6 which we are all looking forward to."

Comments

Who's Poice?

[Anonymous Coward]

And isn't this name a bit inappropriate?

preview for readability before submit, perhaps?

[lambent]

Holy run-on sentence, Batman!

Re:preview for readability before submit, perhaps?

[Amiga Lover]

I'd like a preview that contains a tiny piece of information on just what Parrot is. I can google it, yeah, but I could also google and get just as much info as any story on slashdot if I just read

"New version of Parrot released".

It's reminiscent of badly written man pages, where a command has info like:

-n, --nfrtrt
enables use of nfrtrt.

And says no more. It's just a tiny addition, it would really help, and that's what we have editors for!

Re:preview for readability before submit, perhaps?

[Reducer2001]

It says in the "read more" section that it unites perl and python.

Re:preview for readability before submit, perhaps?

[Short Circuit]

Parrot is a virtual machine intended to be flexible enough to be used as a target for Perl 5/6, Java, Ruby, Python, Forth, Z-code...just about anything.

IIRC, it's expected to be primarily used for Perl 6.

It is bereft of life. It is a dead parrot!

[samberdoo]

Actually, all jokes aside it looks like a valiant try.

python performance

[lordofthemoose]

I am especially interested in python support. I love python but it is some times a tad bit slow. I've seen lots of interesting initiatives to really improve performance (the starkiller python to C++ "compiler" for example), and am now very curious to see how good this one will perform. Besides, it would be quite funny to have perl and python united :-)

Re:python performance

[Pxtl]

The problem is that Python's slowness isn't just from the interpreter, but the nature of the language. Notice how two similar objects don't require an interface to be used in the same way with the same methods? Because of that it will be hard to store members as anything but dictionaries, which are necessarily slow.

Either way Parrot will be an improvement, allowing shared Python/Perl/Ruby libraries, importing pure-python modules nicely, and most importantly: maybe we can finally sandbox Python. Rexec has been dead a long time, and Python is currently unusable as an embedding language without a lot of hacking because of that.

Re:python performance

[Anonymous Coward]

How the hell is that a troll? Possibly incorrect on some issues, but certainly not a troll.

Re:python performance

[fredrikj]

If Psyco isn't on the list of the initiatives you've checked out, I suggest you have a look at it. It speeds up most Python code by 50%-100%, and can improve performance more than tenfold in some cases (for example, tight loops that only do integer math or involve many function calls). And it's really easy to use, you just start it from inside your code (import psyco; psyco.profile()) and it automagically replaces the Python interpreter core in runtime!

As for the article topic, I'm really enthusiastic about Parrot and hope it'll provide some competition for Java. Java is OK, but has little to offer compared to Python (except for better run-time speed, though on the other hand it uses something like ten times more memory), and more generally, dynamic typing is far superior to static typing.

Re:python performance

[Anonymous Coward]

Notice how two similar objects don't require an interface to be used in the same way with the same methods? Because of that it will be hard to store members as anything but dictionaries, which are necessarily slow.

Not so. Consider OCaml, which also provides structural subtyping (two objects can be used interchangably if they implement the same methods, regardless of classes or inheritance), but does so statically, in native code, with no RTTI. I don't know how it's implemented precisely, but the implication is that it's possible to do it more efficiently than you think.

Re:python performance

[Anonymous Coward]

...more generally, dynamic typing is far superior to static typing.

Flamebait alert!

While there are arguments either way, I suspect the reason you believe dynamic typing is superior is that you like polymorphism and the lack of redundant type annotations. Guess what - Java's type system is antedeluvian.

Look up a modern statically typed language, like ML or Haskell; they provide most of the useful polymorphisms (you can't easily put more than one type in a container, but I can count the number of times I've wanted to make a list of mixed integers and strings on the fingers of one head), and type inference means you rarely have to specify a type - the compiler figures it all out for you. And you still get the safety that compile-time checking guarantees.

I'm not trying to start the flame-war you're inviting, just pointing out that most people who come down in favour of dynamic typing do so on inadequate information...

Re:python performance

[Ian Bicking]

To the degree that you can know type information statically, you can do many of the same optimizations that OCaml does. Starkiller is a (very experimental) package that does this in Python. Or, you can guess some and then check your guess at runtime, which is what many JITs do, as well as Psyco (another less experimental package for Python). I think Psyco phrases the process internally as partial evaluation -- where you try to pre-calculate any expressions that can be statically evaluated, like if there's the literal expression (1+1), you know that it will always be 2, no matter what else is happening in the system. If you apply this not just to the visible expressions, but also to the vtable (or equivalent) lookups for method access, you get a sort of implicit type inference.

Re:python performance

[Anonymous Coward]

"I can count the number of times I've wanted to make a list of mixed integers and strings on the fingers of one head"

You have fingers on your head?

why?

[spectrokid]

Why a new VM? Jython showed it is possible to "recycle" the java VM. Can anybody explain why this is better?

Re:why?

[BridgeBum]

Performance.

From the FAQ:

Why your own virtual machine? Why not compile to JVM/.NET?
Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that Perl would run more slowly there than on an interpreter geared towards dynamic languages.

The .NET VM didn't even exist when we started development, or at least we didn't know about it when we were working on the design. We do now, though it's still not suitable.

So you won't run on JVM/.NET?
Sure we will. They're just not our first target. We build our own interpreter/VM, then when that's working we start in on the JVM and/or .NET back ends.

Re:why?

[ThisNukes4u]

For one, the JVM is stack-based, which makes it hard to implement in hardware, while Parrot is stack-based like CPUs. This also has performance advantages for various reasons.

Re:why?

[Enucite]

"the JVM is stack-based ... while Parrot is stack-based ..."

Oh, that explains it. Thanks.

Re:why?

[Anonymous Coward]

Parrot is register based

Use the god-damn preview button ;-)

Re:why?

[Swamii]

For the uninformed, you can already run Python on .NET Common Language Runtime and Python on the Java Virtual Machine.

Re:why?

[Anonymous Coward]

Not as fast as it will run on parrot.

Re:why?

[GooberToo]

I think he means register based.

From one of the examples, we get:

set I1, 1
set N1, 4.2
set S1, "Resting"
print I1
print ", "
print N1
print ", "
print S1
print "\n"
end

Which seems to indicate a heavy use of register type functionality. This will map to hardware (thusly faster) better, much more so than a stack based (java) VM implementation. Especially for dynamically typed languages (perl, python, ruby, etc).

Re:why?

[Enucite]

Ahh, that makes a lot more sense.
Thank you for clearing that up for me.

Re:why?

[ajs]

The primary reasons for Parrot are:

• Language neutrality
  
• Support for very high level language inter-operation (e.g. you can sub-class a Python object in Perl and call a method on the Perl class that gets invoked fromt he Python class).
  
• Deep support for multiple character sets, not just ASCII and Unicode.
  
• Perl 6

The last item might seem odd, but Perl 6 is definitely a language which needed some serious support. It's very ambitious, and a VM that didn't support its needs as completely as Parrot does would have exponentially complicated writing a compiler for it.

That said, the combination of the two promises to be one of the most powerful development platforms released to date.

Re:why?

[Anonymous Coward]

Parrot is vaporware.

Re:why?

[Anonymous Coward]

There is noticeable condensation.

Re:why?

[Anonymous Coward]

Why the Java VM? There were other VMs around at the time.

Re:why?

[miguel]

The meme of `register byte code will map nicely
to hardware' is also rubbish.

For one, the type of the registers in parrot do
not map to the underlying hardware types (ints
and floats is all cpus can do), and second of all
not every CPU has all the registers parrot has.

So if you generate code that uses 32 registers,
you would still need to map to 6 registers on
Intel.

To make things worse, register allocation is
one of the hardest problems in a compiler, and
the one that probably has the most impact on the
performance of generated code.

So now every compiler author is forced to write
a register allocator, only to find out that
parrot will throw away all that information and
redo its own register allocation.

That is why Medium Level IRs do not use registers,
they are too high level to have any real effect.

As for lower-level IRs, most of them assume
infinite registers anyways as a simple way of
"labeling data".

---

Parrot comes with a system that will let
compiler developers not worry about register
allocation: you emit some kind of infinite
register, and a tool produces the IR registers
(which will later be discarded anyways).

Miguel.

Re:why?

[12357bd]

The meme of `register byte code will map nicely to harware' is also rubbish.

True, but the meme of 'stack machines are easier to tune because are conceptually simpler' is also a false.
The fact is that optimizing an VM is difficult, hell, after 50+ years of computer science we are stil trapped on a stack/register dicothomy!?.

Re:why?

[chromatic]

Why would people who write compilers have to write their own register allocators? I'd target PIR and use symbolic registers that IMCC will analyze and allocate automatically anyway.

That seems to be what the second half of your comment says, but I really don't understand what you mean here. Doesn't any IR have to emit some sort of unique symbols?

Re:why?

[lupus-slash]

IronPython is a demonstration that dynamic languages can run pretty well on mono: the fact that mono/the CLR implement a VM for a statically typed langauge (IL) would make mono not adequate has the same relevance as saying that C is not adequate to write a virtual machine and runtime for a dynamic language because C itself is not 'dynamic'.

As for parrot running some day on top of the JVM or .net: it's possible, but has a number of issues the first of which is that until the parrot internal design has been finalized no such effort can start:-) The other major issue is that currently any language that runs on top of parrot basically needs to be implemented in C, mostly because parrot doesn't provide a nice and powerful implementation language in the same way that, say, C# could be used in mono. This basically means that all the code needed to make a language run on top of parrot is very specific to the parrot C internals and hence parrot will not be usefully ported to any othger runtime that isn't the current C implementation.

There is hope, though, that eventually the perl6 specification will emerge and that it will be possible to implement it efficiently in mono.

Re:why?

[lupus-slash]

I doubt parrot will be implemented in HW any time soon:-)
A virtual machine that is register-based makes for a faster implementation of an interpreter vs a stack-based VM. Of course, if the issue is performance using an interpreter is not ideal:-)
Once you jit the code it doesn't matter much if the bytecode was register or stack based (except that the register based code requires you to make harder and slower analyses of the code if you need to check for type safety, for example if you care about security). Of course a VM that is register-based should not limit the number of registers: that is a limitation of the HW that doesn't need to be imposed on a sw implementation.

What matters instead is that using a register-based VM actually makes for a slower implementation when speed matters. Register allocation is one of the phases of a compiler that takes more time: perl running on parrot would need to perform it two times, first when the perl code is translated to the parrot internal register-based bytecode and a second time when parrot jits the code to native code.
But that is not all: registers in a VM are a global resource and as such, the optimizations that can be applied to the code are limited if the semantics are respected. On the other hand, stack slots are local to the call frame so the jit can make more assumptions about their use. Also, deciding on a call convention becomes a hard task, because the decisions on it can't be changed once finalized (otherwise all the bytecode breaks) . The parrot internal call convention has been changed at least two or three times already and there are proposals to change it again, because call performance is very slow. A stack-based VM doen't have these issues, because changing the call convention doesn't break the existing bytecode and it can be made to map to the HW registers, which parrot can't do with the current design.

Re:why?

[Anonymous Coward]

First link 404ed. I think that you meant to type this instead.

Re:why?

[mewphobia]

Deep support for multiple character sets, not just ASCII and Unicode.

Excuse my ignorance, but what can't you do in unicode?

Re:why?

[GooberToo]

The meme of `register byte code will map nicely
to hardware' is also rubbish.

I don't believe this to be a true statement at all. It appears that they are using "typed registers", if you will. The optimizer is free to load ints and longs into registers while it can move pointers to strings into registers equally well. In other words, it maps VERY well to the underlying hardware.

Re:why?

[CTachyon]

I'm no expert on all the political nuances, but there are at least two groups of people that can't use Unicode.

The first is a subset of CJK (Chinese, Japanese, and Korean) speakers. CJK support has been a political minefield for years, and Unicode just made it worse. If you're not aware, each of those languages uses Chinese ideograms in its written language (Korean less so today), even though the actual pronunciations are completely different. The first mine is the PRC's creation of "Simplified Chinese" in the 1950's, and whether a character set favors Simplified or Traditional characters determines a broad swath of political implications. A second mine is how many literary characters a character set supports; to properly record classic Chinese literature, you need somewhere near 50,000 code points, but if you're just recording modern communication, you can get by with around 10,000 (Traditional) or 2,000 (Simplified). The latest mine is the Unicode Consortium's attempt at Han unification, which merged all 4 languages (counting Simplified and Traditional separately) into a single list of code points, without regard for the fact that the actual glyphs sometimes varied dramatically between languages; the expectation was that users would have the appropriate font for their local language installed, but it makes using multiple CJK languages (e.g. a list containing both Chinese and Japanese names) difficult at best and sometimes outright impossible.

The second group of people who can't use Unicode are people using languages that aren't in Unicode. Most of these are historical languages being studied by linguists, but there are even a handful of modern languages.

There are also some situations where, although Unicode works, using a different encoding is much more space-efficient. Ignoring the obvious example of the ISO-8859-N family, CJK text is very, very bulky when encoded in UTF-8 (3 to 4 bytes), but is easily represented by fixed-width 2 byte encodings, and sometimes Japanese can even be shoehorned into 1 byte per character (if it's all kana).

Re:why?

[ajs]

Another poster has covered the technical ground far better than I could have, so I'll skip answering your question directly. However, it is useful to note that while Parrot does not place Unicode in the role of sole character set (as, for example, the JVM does), it does use Unicode as the primary interchange format. If two character sets do not have any defined conversions between then, Unicode is used as a fallback (possibly resulting in an exception).

Re:why?

[miguel]

Notice that stack-based operations are nothing
but a linear representation of a tree.

It is in effect the output that you would get from
serializing a tree, so you turn internal compiler
representation, like for example the following
tree:

(assign var (add 1 2))

into a series of stack operations:

push 1
push 2
add
var_address
store

You can certainly "interpret" those bytecodes,
and for an interpreter it is debatable if there
is a performance improvement or not.

But for any self respecting JIT, the above is
only an MIR (Medium-Level IR) that must be
processed into something else.

The tree is reconstructed from the stack
operations (every JIT does that) and then you run
your standard optimizations, with register
allocation to the target architecture being the
last step of a long chain of operations.

Re:why?

[lupus-slash]

Parrot uses typed registers, yes, but they are not mapped to HW registers (and with the current design that would be very hard to do in an efficient way while preserving the current semantics).
The main issue is whether using a register-based bytecode is any better at helping with executing the code fast once you use a jit. And the answer there is that it doesn't help at all. Except Itanium, all the other arch have fewer registers than parrot, so you can't map them all. If you map a few fixed registers you may miss performance opportunities, because the bytecode could use other registers for the time critical code (note also that the actual number of mappable registers depends on the plaform so you could have ok performance on ppc and terrible performance on x86, exposing HW details to people producing the bytecode).
The only sane option left is to do whole-method analysis and map only the hot registers, surprisingly the same thing jits for stack-based bytecode do. The end result is that having a register-based vm doesn't help at all for this issue.

Re:why?

[lupus-slash]

Why would people who write compilers have to write their own register allocators? I'd target PIR and use symbolic registers that IMCC will analyze and allocate automatically anyway.

That seems to be what the second half of your comment says, but I really don't understand what you mean here. Doesn't any IR have to emit some sort of unique symbols?

The issue is that register allocation is one of the more complex but also more time consuming phases of a compiler (examples of degenerate cases of both can be found in parrot right now, check the threads on degenerate cases for the reg allocator). With the current parrot design a language like perl would create PIR code at runtime and imcc would spend time in the register allocator to map to parrot registers. Later the jit will need to spend again time to map to HW registers (I think the current parrot jit does this only in a very limited way, ie it doesn't actually map parrot regs to hw regs, but only temp values). So again you spend lots of run time doing again register allocation.
Of course you can avoid the last step and just don't do much optimization, but the code will run slowly. The end result is that using a register-based VM didn't help improve performance but it actually hurts it (a register-based design can make for a faster interpreter, but if you want speed you use a jit, not an interpreter).
It would be more sensible if parrot didn't contraint the number of registers, that way at least you don't need to pay for the register allocator in imcc: the register numbers would be simply what most compiler guys call virtual registers, leaving to the jit the duty of allocating them to hw registers as it sees fit.
The register-based design has also an impact on bytecode size: unless they are optimized they are going to take a significant amount of memory and disk space.

Re:why?

[dkf]

You should look at the latest Unicode specs which now allow the encoding of just about every kind of character ever conceived of by humanity (though some are not yet allocated code-points) instead of speculating wildly.

Re:why?

[12357bd]

Optimization is a complex issue, for instance, you can say, 'ok, in the end the program has to run on a given platform, so we can almost forget about intermediate representations, and focus our effort to create assemby code and then apply know platform optimizations'.

On the other side, you can say 'because we don't know apriori what the running platform is going to be, we better try to reformulate the program on his most optimistic expression, and only then proceeed to create assembly and re-optimize the code.

Of course, to take both levels at the same time, and optimze the code acording the 'high level sintax running on that given platform', is the best approach. Unfortunately to use information from both levels conplicates enormously the designs, and sometimes its benefits are not that evident.

We need a higher level of knowledge of hardware, ie curently, there's no difference between creating a low computational cost opcode (say shift), and a high cost one (say mult) both are just numbers, the program creating the opcodes has only euristics to choose between alternate representations, that's why optimization is so hard, because it depends on the idiosincrasies of the goven platfform doing a given piece of code.

I think we need programs that examine/change running programs to learn the best ways to execute the code. VMs are great for that, because we (those examining programs) can change at runtime the code creation procedures, and profile the results to extract useful information to be applied in succesive generations/versions.

Re:why?

[CTachyon]

I do, in fact, research my posts before I hit "Submit". I'm fully aware of just how big the Supplementary Multilingual Plane is getting in the newest specs -- hell, the undeciphered Indus valley script made it in there, albeit only as a preliminary proposal so far. However, there are still a handful of languages out there that aren't represented, including a few obscure but living languages (unfortunately I can't recall any of them, but we're talking <100 speakers left).

Re:why?

[Anonymous Coward]

Bah. And both are already stupid. single static assignment VMs like LLVM are the way forward: no registers as such (though one might argue each assignment is a "never reused register", that doesn't really convey their flavour), no stacks.

Re:why?

[GooberToo]

Interesting. Thanks for the clarification. I had assumed, register assignment, at hardware level, would be implemented via a per architecture optimizer via the parrot-jit-like technology. Therefore, allowing for optimial performance on each of the platforms that parrot ran on. Likewise, I assumed that architectures that had more registers would be yet more performance friendly to parrot.

Re:why?

[Kent Recal]

¼ß`æ ¼ w ££ j®½tsg >!!!

Re:why?

[Anonymous Coward]

Miguel, your insight is wasted on the Parrot folks. Let them live in their state of ignorant bliss - that way they won't hurt themselves or others.

Re:why?

[lupus-slash]

Using SSA in the bytecode is an interesting research field. The MS CLR apparently implements (or implemented) it: see references here and there on OptIL. Basically they augmented IL code with SSA annotations, phi functions etc.

I think there are two issues with it. First it requires the compiler writers to understand SSA and emit a correct SSA representation. The less burden is put on the frontends, the better, IMHO, I don't think the perl and python guys really want to deal with those kinds of low-level details.

There are also many security implications, beside the obvious correctness issues if the intermediate code is not in correct SSA form: proving that it is correct SSA may be a significant time sink if the VM has to provide type safety guarantees, for example.

The other issue is that there are several forms of SSA and deciding which one to use and finalizing it in the bytecode may prevent future optimizations opportunities (without re-creating the SSA form which sort of defeats starting with SSA in the first place). There is also the issue of having the SSA form apply to complex opcodes that the jit translates to several internal reprsentation instructions and it may be better to apply the SSA form to the latter instead of to the former coarse opcodes.

Using stack-based or virtual register-based (not the parrot limited register set) is both simple enough for the high level compilers to produce and simple enough for the jit to put in the preferred SSA form, that it's a better choice.
Mono takes the stack-based bytecode and turns it into SSA form to perform some of the optimizations: this allows us to adapt the SSA form to new needs as the research community comes up with better tricks in that area.
For example, if Java 8-10 years ago would have choosed and finalized a SSA form in the jvm bytecode, that form would be most likely outdated given the research on different and better SSA forms going on the last few years.

Re:why?

[ajs]

In general, Dan Suglaski got it right in a talk on Parrot, where he said (paraphrase), "I don't think that, as a language designer, I should have an ego so large as to suggest that I can choose which character set best encodes your language. Parrot will use Unicode as a Lingua Franca, but will support fully the use of your native character sets where needed."

It's not that Unicode can't "try" to support your needs, it's that Unicode should not be assumed to have succeded (lest it act as an instrument of stagnation rather than unification). Local character sets like ASCII, Big5, etc. have their own value in terms of efficiency and applicability to local domain problems. They should have core support for that reason, period.

Awesome april fools joke

[Anonymous Coward]

For those too lazy to click on the april fools links, the programming examples were some of the funnies things I've seen.

=====
Show us some Parrot code.

GvR: [...]

# copy stdin to stdout, except for lines starting with #
while left_angle_right_angle:
if dollar_underscore[0] =eq= "#":
continue_next;
}
print dollar_underscore;
}

[...]There's more than one way to do it, right, [...]

LW: [...]

while(@line = Sys::Stdin->readline()):
continue_next if $line[0] =eq= "#":
print @line;
}
============
From the minute I saw that I thought I'd love the language. Truely shows the power of open source.

what is parrot?

[egott]

from the faq:

Parrot is the new interpreter being designed from scratch to support the upcoming Perl6 language. It is being designed as a standalone virtual machine that can be used to execute bytecode compiled dynamic languages such as Perl6, but also Perl5. Ideally, Parrot can be used to support other dynamic, bytecode-compiled languages such as Python, Ruby and Tcl.

Re:what is parrot?

[Anonymous Coward]

I assume you mean IPv4.

Re:what is parrot?

[Kristoffer Lunden]

Not only is it supposed to support those languages and more (from Forth to Java via Lua and Lisp ;-), it is also meant to be easy to target with your own custom languages - in fact, several such beasts have been spotted on the mailing list, some of them very impressive already.

Moreover, libraries will (hopefully?) be possible to share code, especially libraries, across languages(!) so you could write your programs in ruby or python and still have access to all of CPAN, and vice versa. Talk about code reuse! :)

One of the big things I see a use for this, maybe to some extent already now, is scripting for game libs and engines. Those often have support for one or several languages, homebrewn or regular, in various stages of completion, with or without SWIG and it is all too often a huge big semi-maintained mess. With parrot bindings, you could use any supported language and possibly even mix - different languages are better at different things. Moreover, you could implement your own, custom languages to fit special tasks. Want a language that can handle 3d calcs, physics and AI interactions in a natural way? Just do it and reuse it for the whole series. :)

Ok, so maybe I am dreaming a bit, but having a powerful interpreter *made* for writing languages for, easily embedded, cross-platform and open source is something to really look forward to in so many ways! I just wish it'd hurry up getting there... and yes, I guess sometime I'll have to stop talking and start contributing myself. ;-)

And oh, there are already some simple games written using parrot and SDL, check em out. And do what I also should, join the effort! :)

Re:what is parrot?

[Ziviyr]

There are 10 kinds of people: Those that understand trinary; those that don't; and those that don't care.

What about the ones that count from zero?

Re:what is parrot?

[photon317]

There are 10 kinds of people: Those that understand trinary; those that don't; and those that don't care

Wouldn't that be "ternary", or am I mistaken?

Re:what is parrot?

[egott]

Sadly, I am an embarrassingly incompetent speller. I had hopped no one would notice on /.

Re:what is parrot?

[Vanieter]

Your sig is too much like mine : I'm suing you to oblivion and back.

Re:what is parrot?

[R.Caley]

Wouldn't that be "ternary",

Maybe he's a dolphin.

Unfortunate name

[carcosa30]

Isn't there already a New York plunger company named something like this?

Re:Unfortunate name

[Anonymous Coward]

There's also a bird species with a similar name.

Wow

[Anonymous Coward]

What kind of bizarre mind would think that parrot sits on an intimate part of a man's anatomy?

The world is very, very strange my friends. I mean, if that really were to happen, I think that man would no longer be a man. Consider the heavy claws of many parrots, and the sharp beak.

Re:Wow

[808140]

This is actually a reference to a picture hosted on rotten.com. It may seem surprising to you that I was able to detect the ACs meaning; but after you go see the picture, my friend, you will understand that it has a profound effect on your memory.

It isn't hard to find (it should be linked from the main page, called 'The Incident with the Bird' or some such). I'm too lazy to link.

Can I run .NET/CLR and JVM bytecode on it?

[Anonymous Coward]

If I can run those as well as perl&python this project will be a home run.

Re:Can I run .NET/CLR and JVM bytecode on it?

[belg4mit]

And do you expect to run a mac binary natively
on a P4? CLR, JVM and Parrot are all different virtual *machines*.

Re:Can I run .NET/CLR and JVM bytecode on it?

[Ollierose]

well, seeing as the .Net CLR and JVMs are currently built on top of a register based architecture (namely a CPU), theres no reason why someone (preferably not likely to miss their sanity) could port mono or an OSS JVM to run on top of parrot.

mmm... JVM on Parrot on CPU goodness

Re:Can I run .NET/CLR and JVM bytecode on it?

[smittyoneeach]

Uhh, while the parser/runtime might be the tip of the iceberg, wouldn't there be a lot of library below the waterline you'd have to magically port?

Re:Can I run .NET/CLR and JVM bytecode on it?

[Anonymous Coward]

Well, yes. but there are projects to JIT-compile java .class files into CLR bytecodes -- allowing all aspects of Java including dynamic loading of .class files to work in a CLR VM.

If Parrot has that as well, it'd be pretty awesome.

Re:Can I run .NET/CLR and JVM bytecode on it?

[julesh]

Well, given that many of the languages it targets support dynamic compilation, not just dynamic loading, it would have to support something similar.

Re:Can I run .NET/CLR and JVM bytecode on it?

[Ollierose]

I guess that depends on whether your libraries are written in the language that you're porting the parser for. If (for example) the class libraries were all pure c# and you ported mono to this new architecture, you'd automatically get the class libraries with a recompile. I think it would become self-hosting pretty quickly that way as well.

Mind you, I was just being flippant when I posted the original ;)

Explanations Please

[SomeGuyTyping]

When posting software projects (especially those whose version number 0) please add a quicky bit about the package for the lazy amongs us

Reconciliation

[Camel Pilot]

Now can we have perl articles without every python weeny jumping up and down and shouting "perl sucks"?

oh yes and vice versa - I hope.

Re:Reconciliation

[Larthallor]

No. No we cannot.

Most of the things that make people prefer Python to Perl have to do with the language itself, not the runtime.

To paraphrase a famous Simpsons quote: "My eyes...the runtime does nothing!"

Re:Reconciliation

[Anonymous Coward]

just because you are smart doesn't mean that your brother isn't an idiot because you have the same parents.

Re:Reconciliation

[OmniVector]

na. they both suck. use ruby instead :)

Re:Reconciliation

[Anonymous Coward]

Now can we have perl articles without every python weeny jumping up and down and shouting "perl sucks"?

Nope. Perl still sucks, just because it's now able to suck on a common VM doesn't make it any less sucky.

So how far do they have to go...

[Anonymous Coward]

I would love to be able to write in a combination of python and ruby. How long until we'll be able to do that? How long until we'll be able to use even one of them with Parrot?

And how many more years until they decide they're taking the April Fool's joke way too far?

Major progress towards open scripting standards

[Anonymous Coward]

"[Parrot's aim,] to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few)"

Thank goodness someone is rounding up all of these languages onto a signle virtual machine. This should make it a lot easier to obsolete the whole bunch of them in favor of VBScript.

Re:Major progress towards open scripting standards

[Ingolfke]

Although VBScript isn't a likely port... BASIC has been ported to Parrot. There's even a working Parrot-BASIC CGI script.

WTF is this?

[Meostro]

From reading the mini-summary of this wonderful new release, can anyone out there tell me what the hell this is?

NO! YOU CAN'T!

If you already know what it is, you could extoll its virtues to the world. If you know what it is, you probably already know about the new release and don't need to be told!. For the average /.er, my guess is they say "that's nice... whatever it is," and skip this one over.

Please, people: When you submit a story about the new release of XYZ version 12423 (stupid animal pseudonym here) put in at least some vague description of WTF it is!

For anyone who didn't RTFA, Parrot is apparently the bastard-child of Python and Perl, using/supporting elements of both languages. Perl is a ridiculous, intentionally obfuscated language, and a Python ate my sister, so I have no interest in this.

Re:WTF is this?

[lewp]

Everyone knew except for you. Haha.

Re:WTF is this?

[Bob of Dole]

That's not what it is. Perl and Python (and most "major" interpreted languages, I would suspect), first compile the script to byte-code, then execute the byte-code in a VM.

At some point along the line, someone said "Hey! Why are we writting VMs for every single language? They all do pretty much the same thing!".

So Parrot is that, a common VM. Perl6 compiles to Parrot bytecode, instead of the perl-only-bytecode it was using for Perl5.
Since that bytecode format is open, and the VM free, any other interpreted (or compiled, I guess) language (Python, Ruby, TCL, LUA, whatever) can make their compilers output Parrot bytecode.
That way they don't have to build and maintain their own VM, and they get the benefits of future optimizations to Parrot.

For example, I could write a just-in-time compiler for Parrot for my favorite platform, and every Parrot-enabled language could take advantage of that.
Doing that now, I'd have to pick a language to optimize. Do I want to make Python faster? Or Perl?

Python is going to use it in the future,last I heard. (probably as another backend like Jython or IronPython, not as a replacement for CPython)
I think they were waiting on the byte-code format stabilizing.

All in all, it's a very cool idea. Makes it a hell of a lot easier for people to make new interpreted languages, since they only have to target Parrot, and they've got a mature, debugged, VM that runs on multiple platforms. (in theory, at least. I don't think it's there yet)

It's not that similar to the JavaVM (which is only designed to run Java, not a pile of different languages), but it is kinda like the .Net VM.
The developers of Parrot created Parrot instead of targeting .Net for two reasons:
1. .Net didn't exist when they began :)
2. .Net is designed for compiled languages (C++, C#, VB, etc), and supposedly that would cause a performance hit over a VM designed for interpreted languages. (Plus, it's not designed to be portable, like Parrot is)

Re:WTF is this?

[ArchAngelQ]

Actually, it's not compiled vs. interperated languages that are the problem: it's staticly typed vs dynamicly typed. The difference?

In C you say

int i;

and you have an int

in python, you say

i = 5

and you have an int

In C you say

char[] c;

and you have a string.

in python, you say

c = "somestring"

and you have a string.

In C, you have to declair what a variable is before you use it. In Perl or Python, you say something is something, and it's that type. They both have types, casts and so on, it's all a matter of when they get those types associated with them. Other than that, you are quite correct about Parrot.

Sorry if the C is wrong, my C is really rusty these days. It's a rare thing where my apps really require the fine tuned memory management that c provides and requires, rather than the speed and flexability of development time that languages like perl, python and (to some extent, imho) java provide.

Re:WTF is this?

[smcdow]

Actually perl goes farther:

my $a = "5"; # $a is a string

$a++; # now $a is both a string and a number. "6" and 6, respectively

my $b = $a + 1; # $b is a number

$b = "$b"; # now $b is both a string and a number

# these two statements produce the same output
printf( "\$b is %s\n", $b );
printf( "\$b is %d\n", $b );

Strong typing sucks.

Re:WTF is this?

[Deadbolt]

Obvious rejoinder time:

my $a = 5; # $a is an int
my $b = 3; # so is $b

$c = $a / $b; # $c is 1.66, yay

my $d = 5; # same deal
my $e = "three"; # whoops

$f = $d / $e; # um, what's in $f?

Not saying strong typing is inherently better, but that sometimes you REALLY, REALLY want to know if you're doing something stupid at compile time instead of run time.

Re:WTF is this?

[Anonymous Coward]

In your case, I don't see how accidentally setting $e = "string" is any different than $e = 0.000.

For Perl you'll get a devide-by-zero error for either values. I don't know about other languages, but I suspect they'd probably give you infinity or NaN if they don't generate an error.

Bottom line: You should always check the value of the denominator before you execute such code. If it's really that sensitive, you should check your inputs for valid values.

Re:WTF is this?

[Raffaello]

This is really a performance issue, not a type safety issue. If type safety is particularly important, then type checks can be done at run time. However, doing these type checks at run time has a run time performance cost. Doing these same checks at compile time means that compiled code will run that much faster since no type checks are being performed at run time.

Certain types of programs really benefit from compile time type checking - specifically, those where inputs are known at compile time, or are known to be of certain types, or are known to be safe (i.e., inputs are not coming at your program across the wire from a potentiall hostile source - think any web app that takes free form input from users).

It could be argued that in the modern GUI/networked era, many apps are going to be doing lots of run time checking anyway because they are exposed to data inputs from potentially hostile users on a WAN - i.e., the internet, and they are at the mercy of user GUI inputs (bizarre mouse clicks and drags, bogus text or numeric field entries, etc.). That being the case, being able to do type inference and compile time type checks doesn't buy one much in terms of saftey or performance for any such app, since you'll be doing lots of run time type checks on user input data anyway.

IMHO, the idea of compile time type inference and type checking is born of a model of computing that is becoming obsolete. It was how most computation was done just a few decades ago - the programmer controlled the input closely, and so could guarantee inputs of certain types in certain ranges, etc. We have now moved into an era where the most interesting inputs are essentially unknowable at compile time - these are user inputs, whether GUI, keyboard, or network in origin. Just as importantly, user choice destroys the notion of a fixed algorithm executing in a predicable fasion. We simply can't know what direction our programs will take once we allow the user sufficient choice in shaping the programs execution. This being the case, and increasingly so as we go forward, I think that compile time type checking is a backward looking paradigm for programming languages.

See Peter Wegner's home page for some related ideas on new ways of thinking about what it is that a program really does in the modern interactive GUI/network era.

Re:WTF is this?

[Anonymous Coward]

Er... your argument makes little sense to me, though it might not help that I'm reading it at 2 am.

How do you get from "modern applications have to check input for validity at runtime" to "there is no advantage in checking the program for validity at compile-time"? The program and the data are still separate in the vast majority of applications.

Checking the program for validity at compile-time DOES normally provide a slight performance boost, and it DOES help eliminate a large number of common errors. The fact that data may need checking at run-time to prevent another, different set of errors seems irrelevant. Yes, checking data at runtime takes time; but if checking types at compile-time speeds up the program, then it will also speed up the runtime data checks. Yes, invalid data at runtime is a source of errors that cannot be caught at compile-time; but why does that mean there's no point checking what you CAN check at compile-time? Those static checks still provide guarantees. I may not know whether I'm going to see an InvalidInputException, but why does that mean there's no point being able to PROVE that I won't see a NullPointerException?

I would be very interested to see an example of a real-world application where unpredictable user inputs can demonstrably render static type-checking useless, or where static type-checking makes a real-world application significantly harder to write. Because I sure can't think of one.

Re:WTF is this?

[eidechse]

Strong typing sucks.

This is NOT a strong vs weak typing thing. This is a static vs dynamic typing thing. The strength of a type system has no relation to when it's enforced.

You can have all combinations:

• strong/static (e.g. Java)
• strong/dynamic (e.g. Python)
• weak/static (e.g. C)
• weak/dynamic (e.g. Perl)

Re:WTF is this?

[miguel]

A few comments: .NET did exist when Parrot was announced, and more
importantly the work to turn .NET into an ECMA
standard had started way before this. .NET is designed for compiled languages as much
as the x86 is designed for compiled languages
(in fact the x86 is strongly typed and knows about
two types: ints and floats, nothing else).

So anyways, for those who can see further than
the end of their noses, .NET provides a lot of
sugar for strongly typed OO languages, but it
requires a strong effort to be as naive to think
that dynamic languages are not supported.

In any case, IronPython has demostrated that .NET can execute dynamic Python code as fast or
faster than the Python interpreter itself.

So those two stated reasons for Parrot are rubbish.

On the other hand, its perfectly fine to say
`We wanted to do something different' or `we
wanted to do our own thing'. Nothing wrong with
that.

Miguel.

Re:WTF is this?

[Raffaello]

I would be very interested to see an example of a real-world application where unpredictable user inputs can demonstrably render static type-checking useless, or where static type-checking makes a real-world application significantly harder to write. Because I sure can't think of one.

Static type checking is still useful for those portions of the program that are, well, static. Any part of the program that deals only with data that is known at compile time, can benefit from static type checking. For example, if your menus are not dynamic (their content does not change) then that portion of your code can benefit from static type checking, etc.

But by far the more difficult bit is dealing with data that isn't known at compile time. Let's take the same example. What if I have a menu item that lists the names of recently opened files with their full path - say in a File menu. However, the menu drawing code I use assumes that all menu items are less than a certain number of characters. There is absolutely no way that I as a programmer can know at compile time whether the type of that file path will be stringLessThan64Characters, or whatever the limit is. I must do a run time check of the data, and respond accordingly. The benefits of compile time type checking are lost for this portion of the code, because it is interactive. The nature of the data that my algorithms will be dealing with cannot be known at compile time because it is determined by user input.

This issue is multiplied in the sequences of user mouse and keyboard actions in, for example, a graphics program. The user can cut/paste/drag/drop/copy-drag etc. At each juncture, my code must check the nature of the data to assure that it can be handled by my algorithms. Static type checking here becomes of little utility. I end up with much of my data being of type "Untyped" and so, it must be type checked repeatedly at run time.

Note that this need to do run time type checking is unavoidable not only in practice but in principle. There is simply no way to know what the type of the data generated by a complex series of user actions will be. Remember that type in this sense is strict, and includes such things as data size and dimensions, not just the underlying primitive type of which it is made. It is not enough to know that I'm getting a slew of bytes, I must know that they are well formed wrt my application's algorithms, and that they are of the right range of size.

Now add to this multiple user interactions across the network, and realize that by far your most important task with regard to type checking is not the ivory tower theoretical exercise of type inference, but the very real world task of checking each and every piece of data that the users throw at your code, and the results of combinations of such user inputs that you may not have originally predicted ("Oh, it never occurred to me that the user would select that menu item, click this radio button, type in such -and-such and then click this other unrelated button").

The more interactive a piece of software is, the more choices the user has, the greater the use of network connectivity, the more the need for run time type checking. Since I'm doing all of these run time type checks, not because I want to, but because I have to I might as well use a language that is designed on the basis of run time type checking. I simply define the necessary constrained types I need, and throw an execption/condition when one of my functions/methods is called with the wrong type, as determined at run time.

The future belongs to interactive software, and interactive software demands run time type checking. It follows that the future belongs to languages that are dynamically typed.

Re:WTF is this?

[chromatic]

That's not entirely fair. I suspect that with the CLR guys concentrating on providing a better platform for dynamic languages, .NET is a much more attractive target now than it was three years ago. How well would IronPython have worked on the CLR from 2001?

Re:WTF is this?

[julesh]

Maybe the .NET CLR did exist and was publically documented at the time they started work on this; I'm sure you know more about that than me. However, their FAQ clearly states that they weren't aware of it at the time.

Also, I suspect they are right that a VM targeted at dynamic languages will be more efficient for running those languages than one that was primarily designed for static languages, if only because the dynamic method dispatch code that a dynamic language on a static VM would have to emit for each method call could be subsumed into a single VM instruction (I know nothing of the internals of .NET; I assume it doesn't support such an instruction). This would allow for smaller bytecode files, and therefore more efficient compilation when it reaches the JIT compiler, or more efficient interpretation when not using JIT compilation.

Mark Sparshatt is working on a Ruby project...

[tcopeland]

...that would compile Ruby programs into intermediate compiler code so they could be run on Parrot.

He's done a few releases and appears to be making good progress here.

Re:Mark Sparshatt is working on a Ruby project...

[Anonymous Coward]

Somewhat confusingly, Sam Ruby seems to be working on pirate (python on parrot).

Sterling Hughes and Thies Arnzton were working on project-pint (PHP on parrot).

It's going to rock.

I was wondering...

[Hank Reardon]

I just started going through the joke links on the O'Reilly Parrot pages and started to wonder...

What happens to the joke pages when (if?) Parrot becomes mature enough to actually warrant a book?

Re:I was wondering...

[chromatic]

Apparently, they stay in place: Perl 6 and Parrot Essentials, 2E. (Disclaimer: I did tech review on the book.)

Python support?

[WillWare]

Python support: Parrot runs 4/7 of the pie-thon test suite

Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 4 / 7
0
>>>

Ouch!

Now I'll get my thumb out of my ass and pass along my gratitude to everybody who's worked on Parrot. An open-source VM, particularly one targeted at existing open-source languages, is a mitzvah. It even has the nice side benefit of creating a little commonality between the communities. Thank you.

Re:Python support?

[Anonymous Coward]

I've never heard "mitzvah" used as sincerely as that before without following "bar" or "bat". Neat.

Re:Python support?

[aurelien]

aurelien@backup2:~$ clisp -q

[1]> (/ 4 7)
4/7
[2]>

ahhhhh ... :)

Re:Python support?

[Anonymous Coward]

Python 2.3.4 (#1, Jul 8 2004, 13:34:52)
[GCC 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import division
>>> 4/7
0.5714285714285714
>>>

It's no rational arithmetic but then Python's numeric tower has always been a little spotty.

Re:Python support?

[pragma_x]

Ditto. The geek in me wondered if this was even proper grammar (sans the 'Bar' and all).

mitzvah Audio pronunciation of "mitzvah" ( P ) Pronunciation Key (mtsv)
n. pl. mitzvoth (-vt, -vs) or mitzvahs

1.
1. A commandment of the Jewish law.
2. The fulfillment of such a commandment.
2. A worthy deed.

My vote is that he meant #2. Thanks to grandparent.

pasm rules

[Anonymous Coward]

Parrot assembler is the nicest asm dialect I've ever had the pleasure to work with. I'm looking forward to a new mod_parrot so I can do enterprise web apps, the way they should be done; in asm.

I spent far too long yesterday playing with parakeet, definately some interesting things happening in parrot land.

Re:PenisBird fans

[Anonymous Coward]

Or "Tarrowroot Head"

Right...

[Moth7]

For anyone who didn't RTF-non-april-fools-A: Parrot is a virtual machine which just happens to be able to run both of them. Get a bloody clue.

Re:Right...

[Meostro]

Which only supports my point further. I RTFA and I still got it wrong. How hard would it be to include this one simple line?

Parrot is a virtual machine which just happens to be able to run both of them.

Re:Right...

[Bob of Dole]

I'd rather they left that out, since that's not what Parrot is, really.
Yes, it runs Perl (and will soon run Python)
But it's designed so that any scripting language can use it, so a better description would be something like:
Parrot is a generic virtual machine for interpreted languages, currently planned to be used by future versions of Perl and Python.

Re:PenisBird fans

[beanluc]

Or...

wait for it...

Pudd'nHead

Another funny virtual machine

[descubes]

The Virtual Virtual Machine is, if I understand correctly, a virtual machine to build virtual machines.

A truly interesting project

[Coryoth]

Parrot is a very interesting project indeed, and it looks as if it is now starting to seriously pick up steam. What we're looking at here is VM that works, and is optimised for Perl, Python, Ruby, Forth and all those other lovely scripting languages.

Given all the current debate raging over JVM vs. .NET and Java vs. C# people seemed to have missed Parrot creeping up from behind. Potentially Parrot can pull together Perl, Python and Ruby - imagine CPAN that works with all of those languages at once, but pulls in all the interesting Python and Ruby libraries too.

In general scripting languages have been looked down upon, but realistically the gap between scripting languages (and what you even mean by "scripting language") has been drastically narrowed to the point where it is increasingly less relevant. The only serious remaining issue is speed - and that's something Parrot can help fix, putting Perl, Python and Ruby code on a similar footing as Java and C# code running on their VMs. You'll take a small hit for using a higher level language, but it won't be as drastic as it is now.

Maybe all that GNOME discussion about .NET via Mono or Java via JVM shoudl start considering Perl/Python/Ruby via Parrot as a very serious choice for doing the high level application programming.

Jedidiah.

Re:A truly interesting project

[GooberToo]

Potentially Parrot can pull together Perl, Python and Ruby - imagine CPAN that works with all of those languages at once, but pulls in all the interesting Python and Ruby libraries too.

You know, I never thought of that aspect of it. That is certainly exciting.

+1 Insightful!

Re:A truly interesting project

[Anonymous Coward]

> C# people seemed to have missed Parrot creeping up from behind

"creeping" indeed. C# is here now, and you can write real apps in it now. Parrot still hasn't gotten out of the gate. It just happened to move a little.

Re:A truly interesting project

[Anonymous Coward]

C# is a programming language, parrot is a register based VM. If you were comparing parrot and the CLR or mentioned that they are very different runtimes you may sound a little less like a fool.

Assuming you identified dynamic languages as not being suitable, you may be able to code in C# and target the CLR now, but for most projects with large existing codebases that is still some way off. Not to mention that; if managed code were suitable for an existing project, it's probably written in Java anyway!

So even the point you tried to make is bogus.

Re:A truly interesting project

[Coryoth]

"creeping" indeed. C# is here now, and you can write real apps in it now. Parrot still hasn't gotten out of the gate. It just happened to move a little.

And 4 years ago the Java people could happily say exactly the same thing about C#. If Parrot offers real advantages (and it does) then when it does arrive it is going to shake things up. Laugh now, but honestly, wait a few years and see if you're still laughing. I'll put rather good odds that if you are it will be very very nervous laughter.

Jedidiah.

Re:A truly interesting project

[Kristoffer Lunden]

Maybe all that GNOME discussion about .NET via Mono or Java via JVM shoudl start considering Perl/Python/Ruby via Parrot as a very serious choice for doing the high level application programming.

That could be a very nice descision indeed, and something for other libs (whether GUI, game, or whatever) to ponder also: when you are powered by parrot, you suddenly have a lot of potential languages to choose between for development, even your own(!) so you can use the ones most fit for any special task, and you'll have access to all those different libs.

One of the big wins is that there is no need to maintain lots of different language bindings either, if you support parrot, you get those other languages automatically. At least in an ideal world. ;-) SWIG is great when it works, but can be such a royal pain when it doesn't... and this would be one step up indeed.

Re:A truly interesting project

[Hard_Code]

It's a project based on a Monty Python skit. Aren't we supposed to laugh?

Re: A truly interesting project

[gidds]

...the gap between scripting languages... has been drastically narrowed

Not sure what you mean here -- I suspect you mean the gap between scripting languages and traditional ones.

If so, then I'd like to disagree :-) (And if not, please ignore the rest!)

While scripting languages have certainly closed the gap in terms of speed, and language features, there are more important considerations where they're still very far apart (and rightly so). I'm thinking particularly here of areas such as methodology, security, portability, and especially maintainability.

Take typing, for example. Dynamic typing is easier to write for: you don't have to restrict yourself to particular types, you don't have to decide things like that in advance, and you don't have to repeat information. But that freedom comes at a price: you don't know what types you'll have to deal with, so you can't guarantee you'll be able to handle them. It's much easier to make subtle bugs. And, what's worse: you can't spot any of this until runtime. You've traded ease of writing for difficulty of testing and fixing.

Similarly, the 'there's more than one way to do it' philosophy is often seen as a plus. How could choice be bad? The trouble is that that choice is the writer's choice -- but the writer isn't the only person to work with the code. Something like 80% of the time spent on code is in maintenance. And if there are 10 subtly different ways to do everything, then the maintainer is 10 times more likely to misunderstand what the code is doing, or to have trouble following the idiom. That's where the argument that 'the programmer doesn't need to understand the whole language' falls right down. And a language that allows the writer the freedom to write an incomprehensible mess isn't one that allows the maintainer much peace of mind!

I could go on about many other aspects too. The roll-your-own object model and we-trust-you data hiding are hardly suited to million-line systems. And so on, and so on.

Of course, I'm not saying that dynamic typing or supernumerary language features or whatever will necessarily lead to bad code. I'm sure some Perl code is a model of elegance, clarity, discipline, and correctness. But is all of it? Hardly... I'd far rather rely on a compiler than a developer to find bugs, any day. And I'd far rather rely on a language to encourage clarity than on the self-discipline of some developers I've worked with...

In short, while the facilities of what used to be known as scripting languages have improved tremendously, their philosophy is now what limits them -- that's what makes them unsuitable for huge, complex or critical systems.

Re: A truly interesting project

[chromatic]

But is all of it?

Nor is all code written in static languages elegant, clear, disciplined, or correct. You can't give a bad programmer enough tools to prevent him from making mistakes if you want to allow him the possibility to do anything interesting.

I'd far rather rely on a compiler than a developer to find bugs, any day.

In my experience, the bugs that compilers can't find are much more important. I'd rather use a more expressive, higher-level language that gives me the flexibility to do my work more productively and quickly and rely on disciplined coding to prove that I've accomplished what I intended to accomplish.

Re:A truly interesting project

[Anonymous Coward]

Most of us largely ignored Microsoft when they were spending 3 years talking about "NGWS" and "Project COOL" and "ASP+". Some of us even ignored the 1.0 release for a year and still have no problem getting C# job opportunities. In short, they's plenty of time to ignore Parrot left.

Re:A truly interesting project

[Shillo]

> "creeping" indeed. C# is here now, and you can write real apps in it now. Parrot still hasn't gotten out of the gate. It just happened to move a little.

But the languages covered by Parrot have been around long before .NET was even conceived of, and there is a huge pile of software already written in each of them. Parrot simply ups the ante to the whole new level.

--

Re:A truly interesting project

[archeopterix]

In general scripting languages have been looked down upon, but realistically the gap between scripting languages (and what you even mean by "scripting language").

I think that not being dependent on another language (including VM written in another language) is what discerns the scripting languages from the umm.. other ones.

So when the Parrot VM will be written in Perl (and compiled to Parrot bytecode by a Perl-to-Parrot compiler written in Perl and then presumably compiled by a Parrot-to-native compiler also written in Perl) Perl will become a nonscripting language. By this definition C/C++ is a nonscripting (by lack of any other name) language, Java is a scripting language (as far as I know all Java VMs are written in C).

Now don't get me wrong, I don't think the lack of this feature is a reason to frown upon a language. (This feature could only affect your choice of the first "bootstrapping" language for a totally new platform, which would be C anyway :-) ) I am only saying that this maps well on what languages I consider the scripting ones.

Re:A truly interesting project

[Anonymous Coward]

Compiling is an issue too. I had to figure out par before my company would let me write utilities in perl for the outside world. And par is not a phenomenal solution.

Re: A truly interesting project

[juhaz]

there are more important considerations where they're still very far apart (and rightly so). I'm thinking particularly here of areas such as methodology, security, portability, and especially maintainability.

You are indeed correct. They are very far apart, since "scripting" languages, whatever they may be, have already long surpassed "traditional" ones in (most of those) areas <g>.

Of course all the ranting on either side is of no use unless you define a "scripting language" is, since they're as much different from each other than from the rest.. Java one because it's bytecode interpreted? If so, it's just as static as C, and strongly typed to boot. What comes to security... if you somehow screw up, due to dynamic typing or anything else, you'll usually get an exception, not potentially exploitable flaw you would in C. Does Perl engourage clarity? Perhaps not, but Python most certainly does, again much more so than C.

Re: A truly interesting project

[gidds]

I was counting Java on the traditional, large-scale side of things -- in fact, it's one of my favourite languages!

I know lots of folks round here don't like it much, for various reasons (most of which I'd rather not get into yet more arguments about!). But it does seem to have been designed by people who 'get it', who understand what it's like not just to write little bits of code, but to write large systems, and to maintain them.

As we've said, you can't enforce good coding, but so many features of Java seem designed to encourage it as much as possible. JavaDoc, for example, makes it as easy as possible to document the big picture and the API issues, to keep them up to date, and to use them. The packaging (namespacing) and source code file layout makes it easy to locate the source code for almost anything the code references. There's no preprocessor to obfuscate things, so you know that what you see is what's actually being run. The enforced exception handling makes it less likely that shortcuts and oversights will come back to bite you. The strong encapsulation makes it straightforward to rework and refactor. Parts of the standard library are a masterclass in the design and documentation of a reusable library. And so on.

Of course, it has its drawbacks, and things it's not suited to. But I'd far rather maintain a large system written in Java than one in C++, C, Perl, or just about any other language I know.

Oh, and I should have included a disclaimer with my last post: I know quite a bit of Perl, but very little Python and Ruby. (And the little I do know makes me want to know more, but there are only so many hours in a day...) So apologies if I'm characterising them wrongly.

To ellaborate on the FAQ

[pavon]

As it said, Python, Perl, Ruby, Smalltalk, Lisp, and most of the languages targeted by Parrot are dynamically typed and have dynamic message passing (method calls). This means that typechecking is done by the run-time environment, not by the compiler. Likewise, it is not known untill runtime which if an object has a method. Therefore, the runtime has to do a fair amount of checking (mostly symbol table lookups). If you were to do this with a VM designed for static languages (JVM, .NET) that do not do this checking for you, then you would have to implement all of it as byte-code in the VM - in effect you would be writing a big chunk of a Perl interpretor in Java.

This approach would inevitably be slower than the existing Perl 5 interpretor, while the Parrot approach has managed to be significatly faster than the current Perl 5 interpretor. The reasons are that 1) all of the runtime checking is highly optimized native code 2) after the complex perl code is translated into a simpler form, the traditional compiler optimizations can be applied to the code.

Re:To ellaborate on the FAQ

[lupus-slash]

Note that writing a big chunk of the perl interpreter in java or C# is not necessarily a bad thing:-)
One of the reasons parrot was born was to make for a cleaner runtime vs the current perl5 internals.
Whether parrot will succeed in this is still waiting on the jury (or better on parrot reaching at least some sort of beta quality release).
People may want to read the slides at http://www.research.ibm.com/vee04/Hylton.pdf by a Python developer. He writes:

It's not much fun to implement Python in C

In relation to the time and lines of code it took to implement CPython and IronPython.

Implementing perl in C# or Java would also have the advantage of defining some sort of specification for Perl the language which is currently defined more or less as what the current perl C implementation does (even if the perl test suite work is also helping define a more formal specification).

Poicephalus

[EdmundSS]

Did anyone else read this as PolicePhalus?

Re:Poicephalus

[Anonymous Coward]

Yes.

Re:Poicephalus

[Anonymous Coward]

Did anyone else read this as PolicePhalus?

I know I wanted to...those thoughts of hot sexy studs in police uniforms sticking their batons and you know whats up my tight anus...ooohhh yeaaaah!

If they hadn't taken my site down maybe I could've taken pictures and shown ya!

Python VM?

[erikharrison]

Does anyone know why Perl 6 didn't start with the Python VM? It's certainly designed for dynamically typed languages, and is (as I understand it) pretty divorced from the bytecode generator

Re:Python VM?

[Anonymous Coward]

I'll hazard a guess or 2:

1. Stack based
2. not JIT'ed

Thanks. (no I've never looked at the source code)

Re:Python VM?

[JohnFluxx]

The faq mentions that the python vm is stack-based, and parrot is register-based.

Re:Python VM?

[Anonymous Coward]

> Does anyone know why Perl 6 didn't start with the Python VM?

Because it's dreadfully slow. Or was when parrot got started. It's also full of assumptions about a pythonic object model, whereas perl's is altogether different -- yes, perl6 still has the concept of scalars and scalar vs list context.

Re:Python VM?

[julesh]

In addition to the other responses, there is a fairly serious architectural flaw with the python VM, that is apparently difficult, if not impossible, to fix without either seriously degrading performance or completely rewriting it from scratch (as this project is doing). It is not threadsafe.

I, for one, consider this a serious flaw that needs to be fixed before the language can be used for serious projects, as it presents a fundamental limit on scalability (adding additional processors will not make your application run faster).

While this may be solved by other reimplementations (like Jython and IronPython, which targets the .NET CLR), there remains a chance that Parrot will be officially adopted by the Python team, at which point my last remaining problem with the language will disappear.

Re:Python VM?

[cakoose]

The Python VM is a directy bytecode interpreter. It doesn't do JIT. Trying to retrofit JIT on a interpreter doesn't save you much work.

Holy Cow

[Anonymous Coward]

I told my perl buddies how perl could affect the readability of their day to day life language usage. Now we have this post as example :)

A question

[Hortensia Patel]

And no, it's apparently not a FA one.

Will Parrot, at some hypothetical point in the distant future, be able to decouple languages from libraries in the same way that .NET does? This is IMO the most exciting thing about .NET - once new languages are no longer guillotined in their infancy by the "but there aren't any libraries for it!" hurdle, a veritable renaissance in language design becomes possible, and maybe we can finally crawl out of the backward-compatibility tarpit.

Re:A question

[magefile]

Yes. That's the whole point of using the same runtime for all three (IIR(eadTFA)C, Ruby will also be supported).

Re:A question

[beppu]

That's the plan.

Re:A question

[Anonymous Coward]

Scheme too, and possibly lisp (hmmm(bet that would please you))?

Re:A question

[Kristoffer Lunden]

Yes. You should be able to use libraries freely no matter what language they were written in, so python users get to use CPAN, perl users get access to RAA, and so on... it's all bytecode in the end. :)

Potentially, you might even be able to switch and mix languages mid-file too, though that probably is not useful all that often. ;-) (Evals might be able to give a language as a parameter if I understood it right).

Re:A question

[multi io]

That's the whole point of using the same runtime for all three [languages]

The point of that is also that you have only one debugged runtime and don't have to write your own for each language.

A very important fact hasn't been mentioned here: When you compile multiple languages to the same VM, you don't automatically get interoperatibility between those languages. Interoperatibility is a different concept that must be separately achieved, mostly by defining additional rules and standards on-top-of the VM specification.

For example, look at different C or C++ compilers on Linux/x86. They all compile to the same machine code, but Intel machine code has no concept of "symbol names", "class names", "type names" etc., so, for the compiled codes to be interoperable, they must comply to additional specifications like ELF or some C++ ABI ("name mangling").

Parrot bytecode may define some or all of those concepts, but some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot, so additional conventions to represent those things in Parrot must be agreed upon. The .NET CLS ("common language specification") is another example of such a set of addional rules to provide for language interoperatibility.

Re:A question

[zorander]

Except when you find a bug in some library written in some dead/weird/etc language and all you have is the bytecode...I mean, in theory it sounds great, but when there's a potential for different objects to be implemented in a wide variety of languages, can you imagine the barrier for entry? I mean, python/perl/ruby is one thing, but what about these new 'renaissance' languages?

Re:A question

[Anonymous Coward]

Potentially, you might even be able to switch and mix languages mid-file too, though that probably is not useful all that often. ;-)

I've been doing this for several years now and find that it is quite useful.

Re:A question

[Anonymous Coward]

And what do you do if it's not really a bug but a difference in the semantics of the language the library is written in, and the language you are using? I suspect they are going to have to do what .NET does and cram all suuported languages into the same mold, basically creating a bunch of new language dialects that happen to have identical semantics.

Re:A question

[Kristoffer Lunden]

Examples please? I couldn't think of any off-hand.

Although, all those Inline::* modules on CPAN is allowing you to do just that, so apparently people find it at the very least amusing. ;-)

Re:A question

[mewphobia]

You rock. If i hadn't already commented I would have modded you straight to the top! :)

The answer, as far as i understand it, is YES! It's going to be bloody brilliant to be able to use the CPAN libraries from any language.

But it makes me wonder if .net will be microsoft's destruction? If open source oses can run .net then why pay for windows? Microsoft has controlled the market because they have controlled the implementation of the most popular API - win32. Sure, they will try and control their new API, .net by things like windows forms that are tightly coupled with win32 - but how long till there is a viable opensource alternative? So i'm guessing microsoft's drawcard is palladium. Digital media is their leverage.

I guess we'll see how it pans out.

Re:A question

[GooberToo]

but some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot

So? That just means that they are not using Parrot. Big deal. What's you're point? You're point is that some people will use Parrot and others will use a different VM? I think we all, already understood this.

Re:A question

[chromatic]

...some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot

Point taken, but all three of those have (or will have) representations in Parrot.

Re:A question

[cakoose]

but some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot

So? That just means that they are not using Parrot. Big deal. What's you're point? You're point is that some people will use Parrot and others will use a different VM? I think we all, already understood this.

So much anger...so clueless...

The parent post was talking about a situation where other languages do run on Parrot but there's still an interoperability barrier. Here's the situation:

1. You created a programming language and you wrote a compiler that targets Parrot.
2. You want your language to have enums.
3. The Parrot VM doesn't have a native concept of enums (this may or may not be true).
4. You see that there are many techniques to simulate enums using existing Parrot constructs.
5. You choose one of those techniques.

Now you have enums and you're running on Parrot. But you might not be able to pass your enum values to code written in another Parrot language. Why not? Because the compiler-writer for the other language may have used a different (though equally valid) technique to encode enums.

That's no problem, we'll just define a standard for all enum types so that all compiler-writers can use the same encoding technique. Let's do that for all the language constructs we can think of! The only problem is that new languages introduce new/better concepts and we can't define all those in advance. The JVM and CLR are good examples of this problem. They're both lacking functionality that would be required to support better type systems (my biggest gripe is the lack of discriminated unions). All interoperability happens at the level of the crappiest type system.

Re:A question

[GooberToo]

So much anger...so clueless...

I'm so glad you're willing to admit this about your self. Admitting you have a problem is the first step.

The rest of your garbage can be ignored because it shows your ignorance. If you have a language, which can not "natively" run in the parrot VM, then you're not running the parrot VM. That's the whole point of my comment, which went WAY over your ignorant head.

Re:A question

[cakoose]

I may have misunderstood your post, but this is what you said to the parent poster:

What's you're point? You're point is that some people will use Parrot and others will use a different VM? I think we all, already understood this.

The parent poster did not say that others will use a different VM. They will run on Parrot. They will just have to interoperate at the lowest common denominator.

If you have a language, which can not "natively" run in the parrot VM, then you're not running the parrot VM.

What does that even mean? Even if you have come up with a new way of representing enums, you'll still only be using the standard Parrot VM instructions. If you have a program that compiles exclusively to Parrot bytecode and runs entirely within the Parrot VM with no JNI-type extensions, wouldn't you say that it runs on Parrot?

BTW, your "I'm rubber, you're glue" comeback brings back memories...

Re:A question

[GooberToo]

The parent poster did not say that others will use a different VM. They will run on Parrot. They will just have to interoperate at the lowest common denominator.

No, he said some will run parrot and others will run other scripting languages which do have have native features of parrot. Well, duh, if you're running a scripting language which does not have native support in parrot, you're running a different vm. Either the "feature" will run "natively" in parrot, or it's not running in parrot. Or, at a minimum, some language hybrid-parrot-vm. Either way, you're not running, "parrot". Which means, what was his point.

Re:A question

[GooberToo]

err...supposed to say, "does not have native"

Re:A question

[cakoose]

Parrot is a instruction set and a runtime environment. I think that running entirely on that instruction set qualifies as "running on Parrot".

For example, most people would agree that Java runs on the JVM. However, the JVM instruction set doesn't have an if-then-else bytecode instruction. It only has asm-style branch/goto instructions. The Java compiler has to translate 'if-then-else' into bytecode. Because of that, would you consider Java to not run on the JVM?

Why do you use the term "[language] runs Parrot" instead of "[language] runs on Parrot"?

Re:A question

[GooberToo]

No. And that is exactly my point. A language which runs on top of parrot is generating parrot byte-code. If it's not generating parrot byte-code, it's not "native", and therefore, not running on parrot.

So, you're stuck with either running parrot vm, not running the parrot vm, or some hybrid. And frankly, if you have some hybrid environment, that's not parrot's fault.

You seem to be looking for someone to argue with for absoluetely no reason. Frankly, YOU seem to be the angry one here.

Re:A question

[cakoose]

Ok, now it seems like you might just be screwing around and I probably shouldn't reply, but I can't help myself...

A language which runs on top of parrot is generating parrot byte-code. If it's not generating parrot byte-code, it's not "native", and therefore, not running on parrot.

Ok, back to the original example. Let's say you're writing a LanguageX to Parrot compiler. Assume that Parrot doesn't have specific bytecodes for enum support but that the compiler can encode enum types using existing Parrot bytecodes. This compiler will produce only standard Parrot bytecode. Parrot will not need to be modified at all to run the compiled programs.

That was the situation the original poster was talking about. And since there are probably many ways to encode enum types using pure Parrot bytecode, the compiler for LanguageZ might use a different technique. Both compilers have enum support, both compilers produce only pure Parrot bytecode, but programs written in the two languages may not be able to pass enum types back and forth.

Nobody is saying that this is Parrot's fault. They're just saying that you need more than interoperability issues don't end with the creation of a VM. They'll need to define an "official" encoding for every the various categories of data types (classes, enums, function pointers, etc.).

Re:Am I the onle one who read that as...

[Anonymous Coward]

No.

premature

[Bill, Shooter of Bul]

Java's been in release for almost 10 years, .NET for 5 and the Parrot VM has made it to beta yet. So no, its not time to consider Perl/Python/Ruby via Parrot as a very serious choice for doing any high level application programming.

Re:premature

[Chandon Seldon]

I don't know about .NET being 5 years old. By that math Parrot is like 3 now.

Re:premature

[Anonymous Coward]

I don't know if you're being sarcastic, but the Parrot project has been going on for over 3 years. It started the same time as the Mono project.

What is a "Poicephalus"

[El]

"The Genus Poicephalus are small to medium sized, stocky birds with short, squarish tails and proportionately substantial bills." I guess it's just your basic African parrot, then. Funny, with the word "phalus" in it, I thought it would be something else...

Re:What is a "Poicephalus"

[Dorothy 86]

proportionately substantial bills

it makes sense to me!

Concerning your sig

[Anonymous Coward]

The word you're looking for is ternary. The "bin" in binary comes from the Latin distributive numeral bini (meaning two each). Of course, the word decimal is derived from the ordinal decimus (meaning tenth), so you might also make a case for using tertial to describe a base three number system, but there's no need to do that when the word ternary has already existed for a long time.

What do you mean

[AnEmbodiedMind]

What do you mean by unusable as an "embedding language" because of a lack of sandboxing?

I realise there could be some applications where you want to sandbox embedded python - e.g. in webbrowsers, but surely not for most applications...

Still an april fool's joke

[jasoegaard]

> The amazing project which no one had any idea
> would go so far from the original April Fool's
> Joke by Simon Cozens (also posted on Slashdot on
> April 1, 2001) to really unite Perl and Python one
> day (not to mention Tcl, Scheme, ...

Saying that it in it's current state supports Scheme is, well, at best a joke (and I am in a good mood today). Havin a subdirectory named Scheme, doesn't actually mean they work.

Re:Still an april fool's joke

[Anonymous Coward]

So you're volunteering?

Subscribe to perl6.internals and let them know.

Re:Still an april fool's joke

[Anonymous Coward]

Well, perhaps the guy's already working on the perl compatibility module of the Guile scheme system. It's roughly in the same state as the parrot scheme compatibility. As a matter of fact, the published plans for Guile seem very similar to the Parrot hype... now we only need the Python guys to start their own VM project. Oh wait, the Python guys are using the Java VM via Jython. Great, isn't it?

a brilliant project

[dgym]

With so many open source language implementations around these days, developing a VM that any of them can take advantage of is a fantastic idea.

One focussed effort on providing efficient JIT compilation will improve performance, and similarly this one layer to address portability could do more to break down OS barriers than java managed.

I'm excited about Parrot just for that, but if there is any possibility that different languages will be able to make use of libraries written in others, then that would be the icing on the cake. I can't tell if it should be possible, but if I could make use of someone else's library written in their favourite languge, from my favourite languge (by virtue of them both running on Parrot), software would be a whole lot more fun.

Re:a brilliant project

[chromatic]

It's not just possible, it's a goal.

Any existing language running on Parrot right now can use the SDL bindings, if the language has syntactic support for loading the appropriate library and calling class and instance methods.

As well, Tim Bunce's plans for DBI 2, Perl's almost ubiquitous database module family, includes porting it to Parrot to make it available to any language running on Parrot.

Everything compiles down to Parrot bytecode, so if your language has the syntax for interoperability, you'll have it.

Re:a brilliant project

[javaman235]

I'm a python freak, so I think this is good news. But damn we have a lot of platforms growing out under us and I'm confused.
1) will existing python code using the current API run on parrot? There a load of C modules wrapped in python. Will it matter?
2) Will code that runs on Parrot run in the .NET/mono CLR?
There is a new Python called Ironpython targeting that, I and I know it can't include the current library...Or doesn't right now. There is also Jython, which runs on the java platform with a different API. Python is a great language, but if none of the API my code is based on exists on these different platforms they're not very useful, because I have to write from scratch anyway...might as well be doing it in some other language.

Uhm...

[wedg]

I read the topic, and only thought to myself: What the hell is a Poice Phallus? Those perl developers sure are kinky!

Re:Uhm...

[Anonymous Coward]

A Poicephalus parrot is a small african parrot. They tend to be very friendly. The most popular poicephalus species as a pet is the Senegal: http://www.petbirdpage.com/senegal.htm . Other poicephalus parrots are the Jardines, Meyers, and a bunch of others I can't think of right now.

Re:Uhm...

[Anonymous Coward]

A Poicephalus parrot is a small african parrot. They tend to be very friendly.

Oh yes, they are very friendly indeed. They look more or less like this:

|:<o)
|:(V\
|8=EE=D

You can find much more info and photos on Google.

Now I wish somebody port SmallTalk.

[Anonymous Coward]

I just love:this and:that style.

Like Mathematica...

[Ayanami Rei]

Really.

Parrot's runtime sounds a whole lot like what Mathematica does internally: dynamically typed language which compiles JIT into a bytecode for a register-windowing VM.

Readability?

[Pan T. Hose]

Holy run-on sentence, Batman!

That's funny you mention it because quite frankly I did preview it and in fact it was not until then when I decided to turn a list of comma separated values into a bullet list as well as brake the second then single-sentence paragraph into three separate sentences exactly because I was somewhat concerned readability-wise--though to be fair braking it into two parts and adding "Read on for a list of changes since the last release, as well as a number of useful links" we owe to Timothy, who has also removed quite a few important links for some reason--but nevertheless I am quite surprised if not outright disappointed that anyone who is even remotely interested in Perl 6 might lack basic linguistic skills to parse a paragraph of simple English, however on the other hand I can understand that for some people interested in the subject my story might indeed contain not nearly enough whitespace.

Re:Readability?

[Kell_pt]

Actually, I should say that I found that the article provided LOTS of links to foreign resources (that would answer whatever doubts someone could face when reading it). It is also well-presented in terms of visuals and well worded.

I've seen MANY an article on slashdot without such a degree of atention to form, contents and references, and I definitly haven't seen many this good, so I REALLY don't understand the comments on the above posts.

Maybe it's one of those personal-vendettas that I'll always be ignorant as to why people make a point in pursuing.

The fact that I did enjoy the article and that I think it's well written would probably not be enough for me to post something like $this post, but the fact that someone actually chose to pick on an article that I find of high-quality is worth putting up with the likely flames that will follow for actually supporting "someone in power" (read - an editor) - not that he needs it.

Cheers.

Re:Readability?

[Anonymous Coward]

Funny you mention the run-on sentence.

I did preview the article.

As I previewed the article I decided to turn a list of comma separated values into a bullet list and broke the second single-sentence paragraph into three separate sentences.

I did these two actions because I was somewhat concerned about the readability of the article.

Timothy, the editor, added and removed a few links for some reason, and added the "read on" section.

I am disappointed that anyone who is interested in Perl 6 might lack basic linguistic skills to parse a paragraph of simple English.

Some people do not contain enough whitespace.

[Not sure why Pan would mention whitespace in conjunction with people.]

Du-u-u-u-u-u-u-ude. Seriously, you need help. If I ever actually had to read your documentation on a day to day basis you would have a bad accident. Oops.

Re:Readability?

[Anonymous Coward]

as well as brake
braking it into two parts

"break", "breaking".

Re:Readability?

[ggvaidya]

He did it again!

(Applauds)

Re:Readability?

[Gabe the Programmer]

Who? Timothy? He posted another dupe?

Nothing inappropriate

[Pan T. Hose]

Who's Poice? And isn't this name a bit inappropriate?

There is nothing inappropriate in poicephalus as e.g. poicephalus gulielmi is just a Latin name of Red-fronted Parrot, well known for every bird lover, just like agapornis pullarius is a Latin name of Red-headed Lovebird, another proposed code-name for this release. You are probably thinking about phallus for some reason but instead of looking for Freudian connotations you might want to read more about parrots.

Re:Nothing inappropriate

[Anonymous Coward]

The suffix -cephalus means "headed" or "pertaining to the head" - as any fan of Aphex Twin would know!

PHP support coming too

[1110110001]

Sterling Hughes and Thies Arntzen are working on getting PHP to parrot with their project Pint. They want some stuff in PHP and parrot would fit perfectly, but havin access to modules from perl or pythong is a nice extra bonus.

b4n

Sam Ruby

[Anonymous Coward]

I hate Sam Ruby, he screws up all my google searches for ruby stuff. :(

Actually, you can

[egarland]

The funny thing is that, as far as I remember, it will run java and .net bytecode. It's a little swiss army VM.

Re:Actually, you can

[Anonymous Coward]

The funny thing is that, as far as I remember, it will run java and .net bytecode. It's a little swiss army VM.

And I'm Lucky the Leprechaun! The Parrot story gets better and better with each new post. If this project is never completed - there is no limit to what Parrot can do!

Re:Actually, you can

[lupus-slash]

Well, "it will run" is more whishful thinking than anything. Having actually implemented a .net runtime (mono) and knowing a bit about the parrot internals, I can say you that parrot won't run any significant .net program anytime soon and even if it will it will be very slow. Significant changes would be needed in the design to make it work and I don't expect that to happen any time soon.

Re:Actually, you can

[egarland]

Well, "it will run" is more whishful thinking than anything

Right. It's my understanding that it's not a complete Java or .Net implementation, just that it can interpret and run *some* bytecode from those VM's. I didn't mean to imply that you could run Java or .Net programs under Parrot, just that there was some translation capabilities in there.

I'd like to see someone put complete support for Java and .Net bytecode into parrot but it's not worth thinking about until Perl 6, Python, Ruby and PHP are all stable and working well on Parrot and Parrot developers have nothing better to do.

Re:Actually, you can

[javaman235]

My question is why? Why on earth should we make a separate platform for running .NET and Java, OR python and perl when we have mono? Through the CLI in mono Python could call perl or perl could call python, or c#, or visual basic, or ANYTHING, including java. Why make a platform to run the two together when we have a platform to run all of them together, including VISUAL BASIC and other code written on windows???

Lisp on Perl VM!: Blasphemy

[Anonymous Coward]

The one true computer language on a VM built for PERL? RMS must be rolling in his grave!-- I know he's not dead yet but it strikes me as something RMS might like to do.

Parrot-Python Performance Test

[randallman]

A simple performance test.

i = 0

limit = 1 * 10**7
print limit

while i < limit:
i += 1

Parrot ran in approx 3 seconds and used approx. 12 MB RAM.

CPython ran in approx. 8 seconds and used approx. 4 MB RAM.

Re:Parrot-Python Performance Test

[chromatic]

How did you compile Parrot? Right now, the default is to disable the JIT to help find bugs in the non-JIT codepaths. An optimized build might be even better.

Re:Parrot-Python Performance Test

[randallman]

I just followed the instructions in the README.

Re:Parrot-Python Performance Test

[randallman]

How would I compile it to use the JIT?

Re:Parrot-Python Performance Test

[chromatic]

Issue:

make clean

to clear out all old objects, then:

perl Configure.pl --optimize --jitcapable

to build an optimized build with JIT enabled. The latter works best on x86 platforms. Then make and test as normal.

Parrot VM makes no assumptions about language

[Anonymous Coward]

it runs all of them equally vapor-like.

Okay, perhaps I'm a bit harsh - it runs 4/7ths of any given language.

Ah, but...

[TheLink]

"Python support: Parrot runs 4/7 of the pie-thon test suite "

But does Parrot run Perl as of now? ;).

Re:Ah, but...

[Anonymous Coward]

There are two Perls to speak of - Perl5 and Perl6. Perl6 is still under development - there isn't even a basic grammar yet. As for Perl5, there is a project called Ponie that will retarget Perl5 to Parrot. The problem is that Parrot still doesn't have all the features needed for Perl5, such as Namespaces. From the latest news I've heard, Ponie should have a first cut done sometime early next year. (I hope!)

Dragonchild

WE DON'T HAVE EDITORS

[EnglishTim]

We don't have Editors. We have Site Maintainers.

What's The State Of INTERCAL Support

[R.Caley]

I can't wait to include some INTERCAL modules in our applications. Sometimes perl is far to maintainable.

Parrot has a dotgnu OPS section

[Gopal.V]

dotgnu .ops in Parrot CVS .

Volunteers needed :)

Hardly an improvement

[Pan T. Hose]

My version:

Holy run-on sentence, Batman!
That's funny you mention it because quite frankly I did preview it and in fact it was not until then when I decided to turn a list of comma separated values into a bullet list as well as [break] the second then single-sentence paragraph into three separate sentences exactly because I was somewhat concerned readability-wise [...]

Your version:

Funny you mention the run-on sentence. I did preview the article. As I previewed the article I decided to turn a list of comma separated values into a bullet list and broke the second single-sentence paragraph into three separate sentences. I did these two actions because I was somewhat concerned about the readability of the article. [...]

Please take no offence but your version is hardly an improvement, not only because the dissonance between sentences (or impedance mismatch, if you will) makes it sound like a homework written by a six years old child, but most importantly becuase in addition to changing style you have also removed content by dropping quite a few important subtleties and overtones in the form of relations of different parts of the original sentence, as well as my emotional relation thereto. Why not "correct" more texts while you are at it! They might really need their "run-on sentences" broke into infantile series of three-word statements!

Now, on a much serious matter:

[...] I can understand that for some people interested in the subject my story might indeed contain not nearly enough whitespace.

Some people do not contain enough whitespace. [Not sure why Pan would mention whitespace in conjunction with people.]

You have probably parsed it as: "I can understand that some people interested in the subject of my story might indeed contain not nearly enough whitespace" or "I can understand that for some reason people interested in the subject of my story might indeed contain not nearly enough whitespace" instead of the literal and correct "I can understand that for some people interested in the subject my story might indeed contain not nearly enough whitespace" which is parsable only one way, using dashes instead of whitespace for indentation:

- I can understand that
- - [that] my story might indeed contain not nearly enough whitespace
- - - [enough] for some people
- - - - [people] interested in the subject

It might be disambiguated using punctuation: "I can understand that, for some people interested in the subject, my story might indeed contain not nearly enough whitespace" or "I can understand that--for some people interested in the subject--my story might indeed contain not nearly enough whitespace" but even without such punctuation marks this part of the sentence is unambiguous nonetheless, fot there is no other way whatsoever for it to make any sense assuming it was written correctly in the first place, while you have presumably assumed otherwise (which itself is an insult).

Still, I am most disappointed (if not outright outraged) by the fact that you have completely missed the humour therein! I can only hope that some people who use some language named after a certain BBC show from 1969 are a somewhat better parsers because otherwise I would have to consider the time spent on writing that comment--and indeed submitting the whole story--completely wasted.

Re:Hardly an improvement

[Kent Recal]

Gah. Has anyone read this comment to the end and can provide a short summary?

No

[Anonymous Coward]

> Isn't that the bird that sits on your dick? I think they should've called it Penisbird instead of Parrot.

No. You are thinking about 'Poicephallus' with double L:

| <o)
| (V\
| X
|8====D

Known from links to http://smoke.rotten.com/bird/

More info:

[Anonymous Coward]

Dear rotten.com,

I am unsure if you are aware of the problems that your "Incident with the bird" picture has caused on the popular technology website slashdot (http://slashdot.org). Many users of this site's messageboards are posting links to http://smoke.rotten.com/bird and making text based representations of a bird on a man's penis. Frankly, while I am pro-freedom, this type of photo sickens me. Could you please move the location of the bird page on your site to keep slashdot readers from seeing things that are completeley unrelated to computers and technology? I'm not asking you to remove the content, just to relocate it.

FYI the text representation of the bird is:

|:<o)
|:(V\
|::X
|8====D

with a link to the offensive site (http://smoke.rotten.com/bird) underneath, these "Penis Birds" are posted by Penis Bird Guy, Penis Bird MAN and several other users

Regards, Andrew J. Tosh

[quote source]

Moron

[Anonymous Coward]

http://www.google.com/search?hl=en&lr=&safe=off&q= ruby+-sam&btnG=Search

Close, but where's the cigar?

[Anonymous Coward]

Hmm, perhaps one of these days the Parrot people will even think of making their code readable...

Poicephallus

[Anonymous Coward]

"Poicephalus" is Latin for PenisBird

No. You are thinking about poicephallus with double 'L'. Google for "The Incident With The Bird" for more info. For those who are too busy to follow links, here is a little ASCII-art version I have just made:

|:<o)
|:(V\
|::X
|8====D

Isn't it cute? I think it should be the official logo of Parrot project and a default prompt of Parrot debugger. What do you think?

Confusing?!

[Anonymous Coward]

Somewhat confusingly, Sam Ruby seems to be working on pirate (python on parrot).

Confusing is a serious understatement. When I first read that porting Python to Perl's VM is done by Ruby I was seriously considering quitting smoking crack. Seriously, I had a terrible headache just trying to think about it because I was sure it is some kind of sick Damian-Conway-style self-modifying or self-parsing or self-writing code idea or something like that... Frightening.

mod_parrot is not a joke!

[Anonymous Coward]

Parent was modded as Funny but in fact mod_parrot is not a joke! See Google. People should know that it is in fact a real project with very serious purpose. It won't be used for writing web apps in PASM or PIR (though it will be possible and sometimes even preferable to write Apache modules in PIR) but to use it in the future for what we use mod_perl today (and mod_php and mod_python and... you get the idea). It will be the most important Apache-Perl integration in the future for Perl 6 and Perl 5 (Pony) and indeed for Python, Ruby, PHP and Intercal. THIS IS NOT A JOKE.

Is everyone here illeterate?

[Anonymous Coward]

It is phalus - not phallus for heavens' sake! Can't you people read Wikipaedia before you make stupid erotic jokes or even use Google for God's sake? Don't know how does poicephalus look like? Fine, then click here to see some pictures. But don't embarass yourself by showing your ignorance like that not being able to count L's in poicephalus! This is not funny.

Positive Response?

[doodaddy]

Holy Crap! I must say that I looked toward the comments in this thread with a cringe. I've been a big fan of Perl 6 and Parrot, if for no other reason than that I'm interested in great (and proven) people trying to solve hard, polemical problems.

However, usually there is so much negativity about these projects on Slashdot, that I tend to lose faith in people's curiosity and gumption. (I believe the usual reply is, ".Net/Java are better.")

Will miracles never end? Congratultions to the Parrot team for picking up steam and converting the unwashed, gnashers of teeth! (-:

Is it limited by PHYSICAL MEMORY because of GC?

[Anonymous Coward]

Does Parrot use References Counting (limited by virtual memory)? or

Does Parrot use Mark-Sweep Collection or Copying Collection (limited by physical memory)?

open4free ©

No reference counting

[Pan T. Hose]

Does Parrot use References Counting (limited by virtual memory)? or
Does Parrot use Mark-Sweep Collection or Copying Collection (limited by physical memory)?

Unlike Perl 5 today, Parrot will not use reference counting. This is one of important difficulties which the Ponie project has to overcome. Please let me quote the most relevant parts of Parrot documentation.

Parrot FAQ:

You're not using reference counting. Why not?

Reference counting has three big issues.

1. Code complexity
2. Every single place where an object is referenced, and every single place where a reference is dropped, must properly alter the refcount of the objects being manipulated. One mistake and an object (and everything it references, directly or indirectly) lives forever or dies prematurely. Since a lot of code references objects, that's a lot of places to scatter reference counting code. While some of it can be automated, that's a lot of discipline that has to be maintained.
3. It's enough of a problem to track down garbage collection systems as it is, and when your garbage collection system is scattered across your entire source base, and possibly across all your extensions, it's a massive annoyance. More sophisticated garbage collection systems, on the other hand, involve much less code. It is, granted, trickier code, but it's a small chunk of code, contained in one spot. Once you get that one chunk correct, you don't have to bother with the garbage collector any more.
4. Cost
5. For reference counting to work right, you need to twiddle reference counts every time an object is referenced, or unreferenced. This generally includes even short-lived objects that will exist only briefly before dying. The cost of a reference counting scheme is directly linked to the number of times code references, or unreferences, objects. A tracing system of one sort or another (and there are many) has an average-case cost that's based on the number of live objects.
6. There are a number of hidden costs in a reference-counting scheme. Since the code to manipulate the reference counts must be scattered throughout the interpreter, the interpreter code is less dense than it would be without reference counts. That means that more of the processor's cache is dedicated to reference count code, code that is ultimately just interpreter bookkeeping, and not dedicated to running your program. The data is also less dense, as there has to be a reference count embedded in it. Once again, that means more cache used for each object during normal running, and lower cache density.
7. A tracing collector, on the other hand, has much denser code, since all it's doing is running through active objects in a tight loop. If done right, the entire tracing system will fit nicely in a processor's L1 cache, which is about as tight as you can get. The data being accessed is also done in a linear fashion, at least in part, which lends itself well to processor's prefetch mechanisms where they exist. The garbage collection data can also be put in a separate area and designed in a way that's much tighter and more cache-dense.
8. Having said that, the worst-case performance for a tracing garbage collecting system is worse than that of a reference counting system. Luckily the pathological cases are quite rare, and there are a number of fairly good techniques to deal with those. Refcounting schemes are also more deterministic than tracing systems, which can be an advantage in some cases. Making a tracing collector deterministic can be somewhat expensive.
9. Self-referential structures live forever
10. Or nearly forever. Since the only time an object is destroyed is when its refcount drops to zero, data in a self-referential structure

mod_parrot up!

[Anonymous Coward]

mod_parrot up! I mean, mod parent up! Seriously, this is a very informative post raising many important points.