I think I still don't understand this claim. Does this mean Java bytecode that comes out from javac will run on Parrot and I won't need to install a separate JVM or .NET runtime for that matter ?
And all this on my mobile phone ?

Does this mean Java bytecode that comes out from javac will run on Parrot and I won't need to install a separate JVM or .NET runtime for that matter ?


Sure y not?
Java byte code can be converted to a PPFF(Parrot Pack File
Format) which assures that java bytecode will and can be
run on PVM(parrot virtual machine).
Thanks
Sasi Kumar

What does that mean some languages are dynamic ?

What are the business advantages of using dynamic languages?

What is the acceptance level of Parrot outside the Perl6 community?

What are the benefits for those other languages to use Parrot?

Would using Parrot for Python hurt the Python community? Did JPython hurt the Python community? And again, being able to run Python on Parrot doesn't mean Parrot becomes "the" vehicle for Python. It just means it's "a" vehicle for Python.

When is it going to be available?

Will code written today run on Parrot? It depends what code you mean. Yeah, there are promises that Perl5 code will run under Perl6/Parrot. But that's just a promise for *Perl* code. Not XS. XS code won't run on Parrot.

Sure, Ponie promises Perl5 compatibility. Hmmm, yeah, Ponie. If I go to www.poniecode.org, there isn't much more than a press release of a year and a half ago, and after some more clicking, one quite old download. Is anything actually going on with Ponie?

If I go to www.poniecode.org, there isn't much more than a press release of a year and a half ago, and after some more clicking, one quite old download. Is anything actually going on with Ponie?

Fotango are in the driving seat with Ponie. See: http://opensource.fotango.com/software/ponie/

--
I'm Not Just Another Perl Hacker

Yeah, that's what I mean with "after some clicking". The page you point at has four Ponie related links:
• The initial press release of July 2003.
• A 9 point FAQ, which would suggest Ponie is finished in summer 2005 (because the estimate is 2 years). Of course, this could mean the FAQ isn't being maintained.
• A plan with 3 milestones. No information on how many milestones have been reached.
• A download page, with a tarball of the very first snapshot. The files in this snapshot are dated August 21, 2003.
Now, there might be a flurry of activity round Ponie, and perhaps it's close to being released. But judging from the website, it's all but dead.

Nice slides but I am bit surprised about the claim thas Java runs on only 2-3 platforms and Parrot will run on at least 7. I thought Java runs on a lot more platforms (incl. phones), Perl runs on even more platforms (excl. mobile phones) and Parrot is planned to run on all the platforms where Perl currently runs.

What am I missing in the definition of platform ?

You're missing that Sun has three different Java platforms (J2SE, J2EE, and J2ME) that support different features and supports them on only a handful of operating systems (Windows and Solaris the best, Linux sort of second-hand, and everything else further down the line).

For example, I run Linux PPC. When will I see J2SE 1.5? It's worse if I run FreeBSD x86. For anything more "exotic", forget it.

Now consider where Perl 5 runs.

Anyways, I am , by far, no expert on the matter, but from what I can gather from my reading,it is that Parrot will be a "virtual assembler", which will make "assembly-style" programming cross platform. To me this is a "quantuum leap forward" in the way programmers will be able to think about data and program. No matter what architecture you are on, you will be able to visualize the cpu registers and memory to have the same structure, and write real cross platform code. It is in my opinion, the first real attempt to make a coding "standard". You will be presented with a set of cpu-registers, and some standard variable types, like interger,numeric,string, and binary. Programming just becomes pushing the data thru the virtual registers. I would thing you would get alot of the basics from parrot examples

I'm very excited about Parrot, eagerly await it's release. To me the only question is, "how fast can they make the virtual assembler run"?

What struct me about this question, is you say you have the topic, yet you don't know what to say? Were you assigned this topic?

Well, not really. I mean I have been planning for this presentation for some time now but it seemed I won't be able to talk on this conference. Now it suddenly changed and I have to actually put together the presentation in less than 48 hours.

I also have quite a lot to say by myself. I just really like to get the feedback of the community. You see I belive that by asking for your help and then picking up the right bits I can pull out a much better presentation than if I just said what I already know. Or think to know.

This can rassure some of my views or clear them in a way that would be nearly impossible doing it alone

Well, virtual machines aren't exactly new. The JVM was succesfull long before Parrot was concieved. And that of course wasn't the only VM.

Parrot will be a "virtual assembler", which will make "assembly-style" programming cross platform.

But Parrot isn't intended so programmers can write assembler! Someone reading your words would think the reason higher level languages exist is because all assembler languages are different. The main reason the assembler exists is that is makes is easier to write compilers - the compilers just have to emit assembler code, instead of having to drive the VM. Just like gcc front ends output some intermediate code, instead of a native binary.

To me this is a "quantuum leap forward" in the way programmers will be able to think about data and program. No matter what architecture you are on, you will be able to visualize the cpu registers and memory to have the same structure, and write real cross platform code.

Well, it's not really cross platform. In fact, the code will target only one platform: Parrot's virtual machine. Note also that the decision whether Parrot should be stack based or register based was made after the idea of having a VM. It being register based was never a target. It's just an implementation detail in the larger scope of having a VM.

It is in my opinion, the first real attempt to make a coding "standard".

Hello? Where have you been the decades? What about Java? What about POSIX? What about any other language that only has one implementation and doesn't delegate to platform specific libraries?

You will be presented with a set of cpu-registers, and some standard variable types, like interger,numeric,string, and binary. Programming just becomes pushing the data thru the virtual registers.

Ah, there you have been! In the early 1950s! Now I understand the "quantum leap". It must be a huge jump to go from "pushing data thru registers" to "pushing data thru virtual registers".

It'll be a real seller! No more regexes! No more hashes! No IO-library! No devices! Just pushing data thru registers! I can hear SUN and Microsoft weep, soon noone will be using Java, C# or .NET. Everyone will just be pushing data thru registers.

It'll be a real seller! No more regexes! No more hashes! No IO-library! No devices! Just pushing data thru registers! I can hear SUN and Microsoft weep, soon noone will be using Java, C# or .NET. Everyone will just be pushing data thru registers.

Well the Parrot libs will still have to handle the drivers, etc, but it should become invisible to the programmer, and there will of course be alot of high-level libraries to do alot of the repetitive stuff, like regexes and hashes. And I DO see the end of Java and C#, and NET except for the corporate fools who will hang on to it, because they "invested their life's training" into it.

I admit I havn't been "schooled" by the mainstream college ideas since the 70's and I missed out on the all the Java stuff, but I'm glad I didn't waste my time with it. So yes, maybe a quantuum leap for me, isn't the same as for you. But at least I'm not "trapped in one of the quantuum energy-state-holes" called Java,C#,or NET.

For what it's worth, I've been seeing a parallel push in C++. As I read the newsgroups now, it seems they are developing a CPAN sort of library collection to make the simple things, easy and invisible to the programmer. Check out Boost It seems that there is this cone we are all in, all heading towards the "cone's vertex". That vertex, is a set of libs, that run cross platform, and allow you to handle data intuitively as humans understand it. We see data as "numbers,text,and binary bits". Dosn't it make sense to make a cpu that handles data in that form? Sure it has ultimately to be done at a binary level, but should programmers have to deal with that? I think all programming languages are going to "merge" into 1 "quasi-launguage" when that cone-vertex is reached. We are still quite a distance away, but Parrot seems to be taking those first steps, and that is what I like about it.

Maybe the world needs a "global conference" on "what would the "ideal cpu" should be, and go about creating it as a "virtual cpu" with a "virtual assembly language". Then when a new cpu is released, the low-level enginners use the real assembly for the cpu, to make libs for compatibility with the "standard virtual cpu". Then all programmers have to do is learn 1 cpu, and the associated ways of doing different tasks.

To me, that is what Parrot is all about. It's not about Perl. Perl is just going to be implemented using Parrot.

My only prayer is that they have some good assembly programmers to do the basic libs, so it's fast.

---

I'm not really a human, but I play one on earth. flash japh

Ah, there you have been! In the early 1950s! Now I understand the "quantum leap". It must be a huge jump to go from "pushing data thru registers" to "pushing data thru virtual registers".

Woohoo! It's back to the future! Or forward into the past. Or something like that.

Anyway, when all's said and done (and Parrot's in a state to be rolled out now for many languages, which is a bizarre thought, though nonetheless true) nobody should care that there's Parrot under the hood of their favorite language. We're the plumbing. All you should ever care about the plumbing is whether it works and whether it fits in with whatever you need to hook up to it. If anything more's required then we've failed at least a little.

You mention this is about a half hour presentation. Based on the range of ideas you present, that probably means you intend to narrow it down to one or two bullet points to stay within the time allotment.

Not knowing the background of the audience, here is a perspective from a 'bean-counter' type manager who cares most about Business Advantages: 1) what advantages in terms of total cost of ownership; 2) what benefits and momentum would encourage a switch to Parrot instead of (say for example) dotNet (or are the two mutually compatible); 3) what advantages do you see in terms of product lifecycle, production process and acquiring and maintaining personnel who are competent with this technology.

As with any presentation, the know your audience rule surely must apply here ... so the preceeding is just one perspective assuming you are talking to a not-necessarily-perl-centric crowd that may not be intimately familiar with the technical details, but still interested if you can present a compelling strategic, business value proposition.

The audience is expected to be IT managers, people whom are mostly see Perl stereo-typed. They probably have never heard of most of the other languages, maybe only PHP and about Perl they have misconceptions (shell replacement language))

Actually Zeev Suraski of Zend will talk about an hour after me, so they will hear about PHP a lot.

I think your questions were really in place, so what are the answeres ?

I'll probably get downvoted for this, but even after many years of using Perl, I still think of it as a shell replacement language. Heck in the interview for the job I have now, I even said I don't bother with bash scripting, I just use perl.

The real question I have is .. why do executives care? They shouldn't. Parrot is about making language development easier and possibly reduces install footprint by not having VM clones, but it's not a big impact to anyone who is not a language developer.

The real question I have is .. why do executives care? They shouldn't. Parrot is about making language development easier and possibly reduces install footprint by not having VM clones, but it's not a big impact to anyone who is not a language developer.

There is a huge reason why executives should care - it makes their developers more productive. If you have two languages, say Perl and Ruby, and you are programming in one and want to use a library in the other ... Perl can do it because we have Inline. But, what if you have a bunch of code in Ruby and want to use a Perl library like, say, the Template Toolkit? If both languages target Parrot, you can. If they don't, you can't. End. Of. Story.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

If Parrot is significantly more embeddable than Perl (and that doesn't take much!), then it will be highly relevant to me. I have a system for which we hope to get 3rd party developers to produce content. When I needed to add a scripting language, I chose Perl because of CPAN and my personal familiarity with it. It has proven to be a major PITA getting it to really work well with C++, and Perl is limiting my potential audience drastically. For applications like this, Parrot would be a lifesaver: better embeddability, and multiple front-end languages.

I suspect we'll see a working Python, Ruby, PHP, or Tcl front-end well before Ponie or Perl6, btw. They're smaller and more regular.

Update: by "regular" I mean the definition "orderly, even, or symmetrical" (from dictionary.com). Fewer exceptions, more orthogonality. Python seems to be built from a small handful of concepts that you constantly reuse and build ever higher towering edifices of abstraction and bothersome structure. Ruby picks a slightly different set of basic constructs, and provides more opportunity to be concise when you want to, but still has fewer special cases and shortcut constructs than Perl. PHP seems to gain regularity by discarding some of the more irregular parts of Perl. Tcl, at least the one I used many years ago before they object-ified the internals, was a tiny, simplistic string-based language. The core language was very regular, although the various things built atop that core were all over the place. But for Parrot, only the core really matters.

Note that I was not using "regular" as a value judgement. I really like many of Perl's irregularities, although (especially when you're implementing or embedding a language) there is a lot to be said for minimalism and regularity too. I don't think Perl has gotten the balance exactly right, nor have I encountered any other language that feels to me that it might.

Sorry for doubling the length of this node with an update, but I wanted to respond to sth's reply, but the response felt more like a clarification than an independent node.

.. More Regular?? Can you elaborate more?