Are you worried about perl6?
You must be logged in to the O'Reilly Network to post a comment.

Showing messages 1 through 10 of 10.

• I don't think I want Perl 6
  2004-07-29 09:22:27  kbrannen [Reply | View]
  
  
  I was so thrilled as I went thru the first 3-4 Apocalypses & Exegesis; I could see some really good stuff. Great cleanup, simplification so reserved words weren't used multiple ways. I was very hopeful for Perl 6.
  
  Alas, then can the apocalypse on REs. My eyes glazed over about 4-5 pages in. I came away with a feeling of "why", but I know all the world's not ASCII -- I can play nicely with others". :-) Nothing's perfect, I could live with it.
  
  The came the next ones throwing stuff at me which I have trouble imagining good uses for, lazy evaluation would be a good example of that. Then came the trait stuff. Then the function and object changes. And don't get me going on about the new "<<" and ">>" operators; or changing "." to "_" (I understand why on this last one I just think that "_" was a really bad replacement).
  
  Yes, we need some change in the object area, and a few other small changes in other areas; but on the whole, Perl 5 is a good and functional language (minus those few warts. :-) If you have a decent Unix background, it's a snap to pick up, quite powerful, and noone has a resource like CPAN. It is by far my favorite language!
  
  If I had to summarize my misgivings about Perl 6, it would probably be that it's too much change too quickly. In a weak moment, I might also say there's a lot of new stuff going into it just so that people can say their language does "these cool things". As I read about the language now, I do NOT want to use Perl 6.
  
  Parrot seems very useful, I hope Dan & company continue making good progress; I think they'll make it. The Ponie seems like a excellent thing. Perl 6 excites me negatively -- nothing personal against Larry & the gang whom still hold in highest regards (everyone's allowed the ocassional mistake).
  
  I'm also afraid that enough others will feel like this and either stop contributing to CPAN or else the number of duplicate modules in there will increase significantly. I hope this doesn't happen; but what choice will we have we when need a module, and we're in Perl 5 (or at least P5 compatibllity mode if I'm forced to use P6) and there's only a P6 module using stuff that truely looks like line noise? I'll have to re-invent that module, add my changes to it, then instead of contributing them back to the author, they'll be checked in as a new module. Again, I hope I'm wrong about this.
• I think I absolutely do want Perl 6
  2004-08-01 20:01:44  aristotle [Reply | View]
  
  
  Are you serious? Other stuff had me slightly concerned; then Apocalypse 5 gave me the reason I want to play with Perl6 and a huge reason to believe Perl6 will be earth shaking. There is stuff being added that's hard to follow, but I thought that the traits/roles material in particular is exceptionally cool stuff. Someone needed to refactor the OO world, just like the regex world was due for a refactoring, and I think this team has managed to pick the right direction.
  
  There'll no doubt be things I won't like about Perl6. But by and large, I see some incredibly cool stuff coming down the line. Perl5 is not perfect modulo warts; I have more than a few annoyances with the language. It's just far less sucky than the other stuff that's about.
  
  I don't know. If you don't like Perl6, you can stick with Perl5. Noone's forcing you to play with the cool toys. :-) But I'm pretty sure Perl6 will soon after its appearance make Perl5 feel as ancient and rustic as Perl4 seems to us nowadays.

• a couple of things that should be pointed out about Perl 6
  2004-07-28 10:36:44  msouth [Reply | View]
  
  
  (1) Perl 6 is needed.
  
  Certain applications need the improved speed that the new subroutine model will allow. Many, many things will be easier to do--a switch/case type statement will be native, there will be macros, really beautiful things with subroutines in terms of specifying parameters and such. The Perl community wants these things and needs to know that they are coming.
  
  (2) Perl 6 is not needed yesterday.
  
  Perl 5 is still the best language, ever, for a human to work in. Development is still continuing with Perl 5. People who are developing in Perl 5 do not have to worry if they write a large application in it, because Perl 6 will be able to run Perl 5 code unmodified (trivially modified? I don't remember for sure on this).
  
  We could go for years and years with Perl 5 and still be thrilled that it was the language we were using.
  
  In another way of looking at it, you are right--it is very likely that some other scripting language is going to come along and replace Perl within a couple of years.
  
  It's just that the language is Perl 6.
  
  The fact that they are called Perl 5 and Perl 6 is a bit misleading, because Perl 6 is essentially a completely new language. I understand what you're saying--at first glance, it looks like maybe Perl development has gotten stalled between versions. But what is really happening is that the same people that made this amazing language that actually works with you to do your work rather than against you to enforce its theoretical model are writing a new amazing language that will replace it. That is going to take time, but it's worth the wait, and while you're waiting you've got the first amazing language the whole time.

• Wall, when will you make an end!
  2004-07-28 07:48:28  ebishopus1 [Reply | View]
  
  

  The worry about the time to do Perl 6 is somewhat reminicent of the story of "The Agony and The Ecstacy," when Pope Julius II kept screaming to Michelangelo for years while he was working on the Sistene Chapel: "Buonnarrati, when will you make an end?!" Michelangelo's answer: "When its finished!"

  
  
  

  Seriously, though, there is more involved than just the design of the Perl 6 language, there is the design of Parrott and by extension a unified platform for all open-source scripting languages that can put them on an even footing with compiled languages.

  
  
  

  As a systems software engineer for 20 years, I expected when Perl 6 and Parrott were announced that the effort would take at least 5 years, and it looks like I was off by a year (Damien Conway now projects Perl 6 completion in 2006). That is about the amount of time it takes to design and develop a new OS/Platform/VM. Microsoft arguably did it in less time with .NET becuase less original design and development was involved (thanks to Java), and the released .NET 1.0 product was far from complete anyway -- in fact, if .NET 2.0 is released in 2005 (one can never be sure with Microsoft) and is mature, it *will* have taken over 5 years!

  
  
  

  Perl 6 with Parrott can inherit Perl 5/CPAN (and possibly PHP/PEAR and repositories for Python and Ruby when Parrott implementations are completed) practially from day one! So in a great sense, Perl 6 gets born fully formed!

  
  
  

  So from where I'm standing, Perl 6 and Parrott are at PAR, or maybe 1 year over PAR. Now, up and comers like PHP, Python and Ruby have gained ground on Perl 5 (for instance, as measured on Freshmeat) during this period, but if the final design of Perl 6 is great, those stats can change back in Perl 6's favor just as easily.

  
  
  

  I'm less worried, because I have faith in the process of open source development as long as the technical direction is good, and right now I'm getting a warm fuzzy from the Perl 6 and Parrott teams.

• Parrot and Python
  2004-07-28 06:56:04  pkphilip [Reply | View]
  
  
  If I understand right, Parrot will infact be able to run scripts written in other languages as well as long as we have an intermediate byte code generator / compiler of sorts which converts down to parrot's byte code.
  
  So this could infact be the open source equivalent of the .NET framework but without all the patent issues that might plague Mono / Rotor.
  
  I am quite excited to see where this might take the whole LAMP scene to (P for Perl).
  
  For IT Research and Development - http://www.songbirdtech.com

• scripting languages - change is inevitable ...
  2004-07-27 12:18:24  mmnmm [Reply | View]
  
  
  I think that the jury is still out whether or not Perl 6 will catch on in the same way that earlier versions of Perl were adopted. It is certainly going to be a cleaner and more elegant language implementation but with that always comes the risk over of over-design taking too much time (the risk of being "good" and reasonably fast versus timely). The use of a bytecode virtual machine (parrot) to implement Perl 6 (also Perl 5 along with future versions of Python) is interesting but raises its own issues for real-world applications.
  
  Keep in mind that that the current release of Python is also reaching a state of maturity and that Guido van Rossum last year at OSCON suggested that a language update Python 3.0 will be backward incompatible with previous versions - "We're throwing away a lot of the cruft that Python has accumulated." Lack of funding appears to be the main reason holding back a major push for Python 3.0. Sounds a lot like the Perl folks ;-)
  
  Then there is always Ruby :-)
  
• scripting languages - change is inevitable ...
  2004-08-01 20:08:48  aristotle [Reply | View]
  
  
  Note that Perl5 already uses something best described as a VM. Perl5 already has distinct compilation and execution phases. It's just all a lot less explicit, because that machine is part of the innards of Perl and offers no interface other than through the compiler frontend. People therefor do not tend to notice its presence.

• Perl6 becoming like Algol98
  2004-07-27 09:51:16  Richard_Hainsworth [Reply | View]
  
  
  I've been trolling the Perl6 fora and reading the summaries since they began. More and more I get a horrid feeling of deja vu. When I was a student, Algol was supposed to be THE language to replace Fortran. Then Algol68 came out, chock-full of othogonal stuff and "thunks".
  
  I tried Algol68: it was so cumbersome, it was useless. Admittedly many of those "new" concepts are now in modern languages. The problem was compiler technology and computer power. But Algol68 was not the language developers used. C is the language of choice. Fast, simple, amenable to elegant code. Moreover, C today is not the C I first learnt. The compilation sophistication of make files is awesum.
  
  So I wonder whether all the wonderful intentions to use UNICODE and the labarynthine scopes and calling chains of multis (I dont really know how to describe that discussion), whether all this will make perl 6 into a slow cumbersome dinasaur. And to get it to work at all will need inelegant clunky code.
  
  Perl 6 looks as if it will be unfit for todays machines, but useable in 40 years. But by then, it will be python or ruby or something else that is the developers choice, combined with something like a killer IDE.
• Thunking && Perl6 becoming like Algol98
  2005-05-10 08:13:31  NevilleDNZ [Reply | View]
  
  
  I developed in used Algol68, C, C++ and Python. Maybe I can step in heer and make a few comments.
  
  Thunking is basically allowing you to pass argument to a procedure WITHOUT any procedure type declarations. Kind of like a #define func() in C and a Template in C++.
  However... thunking was allowed to be RECURSIVE and TYPELESS!!! (Try a recursive #define in C?? ;-)
  
  Algol68 did not have ANY thunking because it was just too tough. Indeed Buroughs has to implement Thunking in special Hardware op codes for Algol60.
  
  Algol68 was picky about coercing (known as casting in C) and had a hierarchy of coercing/casting rules:
  soft-weak-meek-firm-strong as follows:
Context strength Allowed coercions
soft deproceduring
weak dereferencing or deproceduring, yielding a name
meek dereferencing or deproceduring
firm meek, followed by uniting
strong firm, followed by widening, rowing or voiding
  
  The reason for this was to avoid having to specifically/manually coercing/cast with a type operator. eg in C you sometimes need to for a type change with something like (float)1, or *str to get a type char, or funct() to yield the return value.
  
  C was nice because you had to do most casting manually, and so you knew exactly what type you were dealing with type coercing/casting. C++ is nice because you can define your own coercing/casting rules on classes.
  
  In a strange sort of way Algol68 was kind of the "missing link" between C and and C++. For example, in Algol68 the coercing/casting rule for REAL to COMPLex could not be defined by the programmer, it was build into the compiler. In C++ the programmer has (almost) total freedom to define this casting rules, and even some context/syntax checking. In C, even to this day the coercing/casting from REAL to COMPLex must be done manually.
  
  Python pains me because it is like Algol60 thunking all over again, but interpreted, not compiled. I dont want to be cruel, but it is kind of like turning the clock back 45 years to 1960. In python the "compiler" is impotent to pick up many "type" bugs at compile time (that in other languages would be simple syntax errors)
  
  BTW: Python DOES have some nice stuff that I won't cover here... :-)
  
  NevilleDNZ
  
  BTW: Microsoft reinvented the word Thunking to describe running win16 programs on a Win32 subsystem. Stand by for Thunk64s on Itanium.
• Worry Later
  2004-07-27 14:10:12  chromatic | [Reply | View]
  
  

  I think it's a little silly to worry about the performance of code that doesn't exist yet. Parrot, which does exist, tends to be much faster than Perl 5, Python, and Ruby.