Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Parrot, the future of dynamic languages ?

by szabgab (Priest)
on Dec 20, 2004 at 08:53 UTC ( #416135=perlquestion: print w/ replies, xml ) Need Help??
szabgab has asked for the wisdom of the Perl Monks concerning the following question:

It seems I'll have a chance on Wednesday (22 December) to give a 20-30 minute talk infront of a few hundred IT managers with the title Parrot, the future of dynamic languages. I just don't yet know what am I going to say....

I'd appreciate to read your thoughts.
I was thinking about questions such as

  • What does that mean some languages are dynamic ?
    ActiveState has a good white paper on dynamic languages. But what do you ppl. think ?
  • What are the business advantages of using dynamic languages ?
    Why is it good for a business (hi-tech or industry) to use a dynamic language ?
  • In what fields do the dynamic languages fit better than Java/.NET etc. ?
    I could just say they are better than Java, C#, COBOL and VBScript but first of all VBScript is I also in the dynamic category and besides such overall claim nevr works. And is not true either.
  • What is Parrot?
    And more importantly, how will that impact the dynamics of the dynamic languages ?
  • What is the acceptance level of Parrot outside the Perl6 community ?
    Some percentage of Perl5 people seem to have reservations about Perl6 and then probably also about Ponie/Parrot. Further more, what do we know about Python, PHP, Ruby, Tcl and other language communities ? How do they see Parrot ?
    I know I should ask this on forums of the respective communities too.
  • What are the benefits for those other languages to use Parrot ?
    The question is interesting both technically and business wise. E.g. Will Zend use Parrot for PHP ? Would using Parrot for Python hurt the Python community ?
  • When is it going to be available ?
    Sure, we don't have a dead-line for Parrot or Perl6 and I think the answer should be NOW. But this brings up the question of migration. Will code written today run on Parrot ? Sure, Ponie promises Perl5 compatibility. What about the other languages ?
So, what should I say about the above ? What else should I talk about ?
Your input is really appreciated.

Comment on Parrot, the future of dynamic languages ?
Re: Parrot, the future of dynamic languages ?
by mkirank (Chaplain) on Dec 20, 2004 at 10:14 UTC
    Check out the links given below
    Also you could give a brief about the architecture with some slides
    As per This Document (Page 23)
    An interesting side note--because we have such a huge range of opcode
    numbers, and because we have the capability to load in opcode functions as we
    choose, and because the bytecode loader may do a transform and is pluggable,
    we can run JVM and .NET code directly.


    Wiki
    Talks
      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
Re: Parrot, the future of dynamic languages ?
by sasikumar (Monk) on Dec 20, 2004 at 11:35 UTC
      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.

Re: Parrot, the future of dynamic languages ?
by Anonymous Monk on Dec 20, 2004 at 12:35 UTC
    I'm just going to throw in some thoughts about some questions.
    What does that mean some languages are dynamic ?
    Like many things, there isn't a clear cut definition. But typically, languages for which the types of all the variables are always determined at compile time are called "static". C and Java for instance. In dynamic languages it is possible that the types of variables are only determined at run time. Or that it's more values that are typed instead of variables (one could easily few Perl5 that way). Perl6 will be dynamic. While it is possible that the types of Perl6 variables are determined at compile time, the programmer isn't forced to reveal them (and hence they aren't know till runtime). In dynamic languages it's usually easier to load in new (source) code during runtime.
    What are the business advantages of using dynamic languages?
    That is not the same question as "Why is it good for a business (hi-tech or industry) to use a dynamic language?" Just because there are advantages of using a dynamic language doesn't mean that using a dynamic language is good for a business. There are also drawbacks of using dynamic languages (if there weren't, everyone would use dynamic languages). What language a business should use for a project will depend on the project - and the business. In-house expertise is a non-significant factor in deciding which language to use.
    What is the acceptance level of Parrot outside the Perl6 community?
    You write: Some percentage of Perl5 people seem to have reservations about Perl6 and then probably also about Ponie/Parrot. You seem to imply that people who have reservations about Perl6 necessarely have them against Ponie or Parrot as well. That's not true. Parrot will give use features totally independent from Perl6 (in fact, that's what Ponie is doing...). Perl6 is a change of the language - Parrot is a change of the implementation. The language could have changed without creating Parrot. Parrot could have been done without Perl6. I've heard many voices questioning Perl6 in one way or another. But I haven't heard anything against Parrot.
    What are the benefits for those other languages to use Parrot?
    Will Zend use Parrot for PHP? Does it matter? Making Parrot the main vehicle for other languages isn't its primary goal. Parrot will be a general purpose VM geared towards dynamic languages and Perl6 in particular. Being able to run PHP on Parrot means it's easier to interface PHP and Perl code. But a implementation specifically created for PHP (or whatever language) is likely to be "better" for that language than Parrot. For some definition of better (speed, memory footprint, portability).

    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?
    Sure, we don't have a dead-line for Parrot or Perl6 and I think the answer should be NOW. Well, it is available now. Just go to dev.perl.org and download what's there. But I wouldn't want to use it as it's far, far from complete.

    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.
Re: Parrot, the future of dynamic languages ?
by zentara (Archbishop) on Dec 20, 2004 at 13:22 UTC
    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?

    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"?


    I'm not really a human, but I play one on earth. flash japh
      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.

Re: Parrot, the future of dynamic languages ?
by dimar (Curate) on Dec 20, 2004 at 13:54 UTC

    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.
Re: Parrot, the future of dynamic languages ?
by Anonymous Monk on Dec 20, 2004 at 15:49 UTC
    You know, I'm not sure you could give a Parrot talk about it "being the future" when it has so little signs of existing "in the real" for most developers. How can it seperate itself from the Duke-Nukem-Forever vaporware feeling that Perl6 has achieved? I think the only way to do this is to get Ponie out very quickly and then build a working Python/Ruby implementation with increased performance, +1 or 2 other languages.

    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?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://416135]
Approved by Arunbear
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (13)
As of 2014-12-19 18:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (91 votes), past polls