Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Thoughts on Perl6 - Love it? Hate it?

by mrmick (Curate)
on Jan 10, 2002 at 20:25 UTC ( #137752=perlmeditation: print w/ replies, xml ) Need Help??

Thoughts on Perl6 - Love it? Hate it?

Ever since hearing that Perl6 was forthcoming (eventually) and that it was a major rework (read: starting from scratch), I have been reading and playing with some of the new thingies that Dr. Damian Conway has come up with in his exeges. I've also been paying attention to the apocalyspes to get some foundation for what to expect.

I have come to look forward to any and all information related to Perl6. What I haven't heard, however, is much discussion about everyone's views on the inevitable changes tothe language. It looks like there will be significant changes both in what we will be able to do with Perl (more wonderful stuff) and on how we will be doing it. The addition of new data types and that everything will become an object in Perl6 will make us have to fundamentally change how to plan our Perl projects.

While I love Perl because you can use a scalar at any time to represent multiple "datatypes", I also look forward to being able to declare a data type within the language as part of the regular syntax when I need it. Also, I love the idea of replacing the -> operator with . to access object methods and properties, thus ensuring that the style is consistent with other OO languages.

I would love to hear what other Monks are thinking about this. What do you like? What do you hate? Personally, I think that this will be the best version of Perl yet. It may take a little getting used to but as long as it allows(nay - promotes) Impatience, Laziness, and Hubris, I will be happy.

Mick

Comment on Thoughts on Perl6 - Love it? Hate it?
(Ovid) Re: Thoughts on Perl6 - Love it? Hate it?
by Ovid (Cardinal) on Jan 10, 2002 at 20:45 UTC

    I know that a lot of people are nervous about Perl 6, but they shouldn't be. Yeah, there is talk about co-routines, curried functions and things like that, but that's going to make the language more powerful. Interestingly, even though many features are going to be added to the language, it's going to be even easier to use.

    Some things I like:

    The variable prefix notation will be based on the variable type and not on the access method:

    @foo[ $bar ]; # was $foo[ $bar ]; %foo{ $bar }; # was $foo{ $bar };

    Programmers routinely get those wrong when they're first starting with Perl. Now they'll get them right.

    More compiler hints and optional strong typing! This is going to overcome one of the biggest objections to Perl!

    my int @array; my INT @next_array;

    While this has not been nailed down, the first example above hints to the compiler that you will mostly be using integers in the array, so the compiler will optimize for it. However, you can stick the occassional string in there.

    The second example tells the compiler that there will only be integers in the array. This will likely throw an exception (maybe at runtime?)

    How about lexically scoped subroutines? Now, you'll be able to have truly private methods and ensure that they are only called as methods. No more letting people call methods as subroutines and getting things screwed up.

    Access to your caller's lexically scoped variables through a MY pseudo-namespace. While I'm not sure about this, it does mean that you'll be able to do exports to your caller's lexical scope without globals. Yay :)

    Parrot will be separate from Perl and we should have the ability to program directly in it for runtime benefits. In fact, if the work on byte-code compilers comes to pass, we'll be able to write Java applets in Perl. Look out Java, here we come :)

    There's a lot more, but that's all I can think of off the top of my head and I need to get to work. The only real downside I see to Perl 6 is that it likely won't be out until late 2003 or 2004 :(

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

      I fear Perl 6, as I fear all things new. :-)

      The variable prefix notation will be based on the variable type and not on the access method:
      @foo[ $bar ]; # was $foo[ $bar ]; %foo{ $bar }; # was $foo{ $bar };
      Programmers routinely get those wrong when they're first starting with Perl. Now they'll get them right.
      I won't get it right (at least for a while). I bought into the whole idea that the prefix showed what variable type is being accessed (though it does get a little fuzzy when dealing with references). It may help new Perl programmers, though.

      More compiler hints and optional strong typing! This is going to overcome one of the biggest objections to Perl!
      And add one of my strongest objections to virtually every other language but Perl. I realize that it will be optional, but so (in theory, at least) is 'use strict'.

      Actually, I'm looking forward to Perl 6. I've always hated the arrow syntax for Perl's object-oriented features, and I'm willing to give up the '.' concatenation operator to get rid of it. :-)

      Impossible Robot
Re: Thoughts on Perl6 - Love it? Hate it?
by japhy (Canon) on Jan 10, 2002 at 20:46 UTC
    (Update: @seen{...} is now %seen{...}) So long as I can write %seen{@data} ^= 1 and @histogram[map /\d/, $n] ^++, I will be the happiest person alive. Those will be Perl idioms one will be hard-pressed to find in any other language. The hyper-operators are, I feel, long overdue, and should be received with much celebration. The loops required to mimic them in current versions of Perl will be optimized into the Perl core, which -- apart from sounding nifty -- is nifty.

    Perl 6 is mainly about re-engineering our core processes and utilizing new paradigms for work efficiency and extending our empowerment to meet a wide spectrum of abilities.

    Oh, sorry, I was reading "The Dilbert Principle". Where was I?

    Perl 6 is about rethinking a lot that programmers want to do, but can't really, in Perl. The amount of "stuff" is measured by CPAN's growing number of Perl extension modules -- things like Switch and Attribute::Handlers and [insert favorite Damian module here].

    But it's also about making the language more inviting to people from other backgrounds (which is a good reason to make the -> to . change) and to make a good enough impression that first-time callers become long-time supporters.

    Anything I've found icky about Perl 6, I've taken with a grain of salt. Larry knows what he's doing, and one thing he's doing is listening to us. Another thing he's doing is milking the damned colon for all it's worth! STOP COLON EXPLOITATION NOW! But it will be for the best.

    _____________________________________________________
    Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
    s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

      That's pretty much the way I feel. When I read the Apocalypses (I read them both before reading either Exegesis), I must admit I was almost disgusted. The one thing I've grown so very fond of in Perl is the relation between %hash, @hash{@list} and $hash{$scalar}. My world broke down when I read that this is going away.

      But then, though I wasn't around then, I imagine that when people went from Perl 4 to Perl 5, they must have found themselves in an odd world too.

      That is what I think it's going to be like to move from Perl 5 to Perl 6. Perl 6 will have its own idioms. We will all have to change the way we think and get accustomed to them. For what price? Well - I doubt anyone would nowadays say things were better, back in Perl 4, without all the newfangled stuff.

      Perl 6 is going to have newfangled stuff as well - I predict that eventually we'll get used to it and will look down on Perl 5 as an inferior stepstone from the past, the same way we look down on Perl 4 now even if we remember it fondly.


      The hyper operators are one of the things I also am every excited about. Part of Perl I immediately fell in love with is map and grep. Now come to think about them - aren't they are basically "poor man's hyper operators"? And guess what - we will have dinner with silver cutlery in the future.

      Just out of curiosity, I know there's still a lot up in the air (err?), but won't this be a syntax error?

      @seen{@data} ^= 1;

      You have an @ to designate "seen" as an array (Perl6 terminology, folks!, I know that's not correct for Perl5), but you're using the curlies for a hash. I am assuming that what you meant to do was use a hash slice of elements in @data and set all elements to 1 (true). If so, I believe that would be:

      %seen{@data} ^= 1;

      For those not familiar with Perl 6 idioms, that would be the equivalent of the following in Perl 5:

      @seen{@data} = (1) x @data; # or foreach (@data) { $seen{ $_ } = 1; }

      Cheers,
      Ovid

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        Dammit. Old habits die hard. I'm going to get flooded with those error messages, I'm sure.

        _____________________________________________________
        Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
        s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Re: Thoughts on Perl6 - Love it? Hate it?
by Juerd (Abbot) on Jan 10, 2002 at 21:18 UTC
    1 - hate it
    2 - dislike it
    3 - neutral
    4 - like it
    5 - love it

    Exegesis 2
    Attributes - 4
    Strong typing - 2
    Input that outputs - 4
    Dereferencing using dot - 4
    That property thingy - don't get it :)
    Named arguments - 5
    Sigils for type instead of access - 2
    More contexts - 2 and 5 (My braincells are fighting)
    Exegesis 3
    Binary default operator - 5 (6 actually)
    Hyper operators - 5 (would also be 6 :)
    Underscore for string concat - 1
    Unary operator for stringingification - 4
    Stackable test operators - 4
    Only 1 error variable - 4
    Smart lazy lists - 5
    Diamond takes expression - 4
    Explicit flattening - 4
    Adverbial colon - 3
    Pairs - 4
    Tilde for xor - 3
    Binary tight xor - 4
    Aliases - 3 (Why not references?)
    Creating operators - 4
    Bye bye ?? - 3
    Lazy lists - 5

    2;0 juerd@ouranos:~$ perl -e'undef christmas' Segmentation fault 2;139 juerd@ouranos:~$

      I like your method of rating, Juerd .

      Some explanations as to why would be helpful for each of these. :-)

      Cheers,

      Mick
Re: Thoughts on Perl6 - Love it? Hate it?
by redsquirrel (Hermit) on Jan 10, 2002 at 22:33 UTC
    I too have come to look forward to any forthcoming information about Perl6. I wonder when the next apocalypse/exegesis will be?

    I'm excited to develop applications in Perl6 and compare how it feels to developing in Perl5. Will it be as fun? Could it be any more fun? I'm particulary excited about Perl6 because Perl is my first (and only well-grasped) programming language. Thus, my programming worldview is based in Perl5. Will Perl6 rock my world? Time will tell.

(ichimunki) Re: Thoughts on Perl6 - Love it? Hate it?
by ichimunki (Priest) on Jan 10, 2002 at 22:38 UTC
    I don't care about the sigil stuff that much, although I agree that it is better in the long run not to have to shift the sigil to say what you mean. I prefer the Ruby use of sigils to denote things like scope levels ($ for global, @ for instance, @@ for class).

    I don't care about the dot much either: no other language I've used has -> for methods. I would prefer that references kept -> and. would get used for methods and properties and stuff. But I'll live.

    Everything as an object. Been there, done that. See also: Ruby.

    "Optional" strong data types. A natural extension of the previous point. But I doubt it will end up feeling optional after a few more C programmers are converted. One thing I like a *lot* about Perl is the ambiguity of the scalar. This is serious erosion of that, imho.

    I'm not sure I understand these hyper-operators. From japhy's example they look like pre-coded versions of the block/yield structure in Ruby with a bit of Tie thrown in (method overloading essentially). Which is fine with me if there are considerable performance gains to be had-- otherwise I think these will confuse Perl newcomers and oldcomers alike for quite a while.

    Totally unthrilled that _ will be the new concatenation operator since I use _ a lot in variable and sub names, but I tend to do most my concatenating using interpolated strings anyway. What I'd really prefer is a way for me to do something like $name = sub{ return 'My Name' }; print "$name\n"; without having $name return a darned coderef value rather than the results of $name->().

    Switch? Not terribly big deal to me either way. I can see it's value if you want to do some sort of goto-based dispatch, and yes I consider it an improvement over a hash full of coderefs since the conditions in a switch can be more involved that the simple labels that are hash keys. Enough languages have this that there's no reason to avoid it.

    The only thing that keeps from seriously saying "Yeah, but there is *already* Ruby available" (since 99% of the above seems to be already implemented in Ruby, which can be very Perlish if you want it to be) is the byte-code issue. And frankly, the byte-code thing scares me. Two reasons: Java seems to have taken off, but is this because it was an OO language with a good sense of community at a time when the alternative was obscurity and/or C++? Did Java succeed because so many people learned it based on the dreamy notion that it would allow web browsers everywhere to essentially become OS replacements-- only to find out that it worked much better as a locally compiled/executed language? But AFAIK Java is the best example of a language with a VM. And I don't still don't get a coherent sense of whether the public has made a real decision about the Java VM.

    And so I wonder if this isn't a major mistake for Perl. Will it actually be fast enough to follow through? Will it actually be portable? Will it promote the distribution of byte-compiled code under proprietary licenses?

    And those are my thoughts as a fairly uninvolved Perl user and one who thinks Ruby probably solves a lot of these problems already (in addition, from what I understand, extending Ruby with C neither requires the Inline module or XS hacking). If the byte compiler/vm comes to pass and I can truly write in other languages (such as the aforementioned Ruby-- and if Dan Sugalski has anything to say about it, I'm sure I'll be able to) for it, then I'll be very happy (other misgivings aside). A good vm would be much preferable to the shared library/dll situation, since it would make sharing Perl and Ruby code to Windows users who are not hackers a lot easier.

    PS: wrt to tilly's comments on byte code... woohoo! I have much more confidence in that aspect now. *grin*
      Switch? Not terribly big deal to me either way. I can see it's value if you want to do some sort of goto-based dispatch, and yes I consider it an improvement over a hash full of coderefs since the conditions in a switch can be more involved that the simple labels that are hash keys. Enough languages have this that there's no reason to avoid it.

      I have to disagree with you here. What's wrong with the following?

      my %SomeHashWithCoderefs = ( FOO => \&foo, BAR => \&bar, BAZ => \&baz, ); sub Switcheroo { my @conditions = @_; # Using the @conditions, return 'FOO', 'BAR', or 'BAZ' } # In some main area... $SomeHashWithCoderefs{Switcheroo(@args)}->(@otherargs);

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        Because FOO, BAR, and BAZ are not conditions, they are static labels. Is there a way to get them to behave as ranges or any sort of boolean? If so, I still don't have a problem with switch, but I would be glad to have another trick up my sleeve. :)
      In regards to the bytecode issue, how do you think that Perl works now? It turns out that Perl compiles your program to bytecode and runs that in a VM! We just don't advertise it that way.

      The current differences between Java and Perl on this issue are that currently Perl's bytecodes are not a standard that is written down somewhere, and Perl's bytecodes are designed around units of action that make sense for scripting. Java's are written down in detail, and are designed to create something that looks like a virtual machine. I don't think that making Perl's bytecode into a written standard is going to be that big of a problem.

      I would prefer that references kept -> and. would get used for methods and properties and stuff. But I'll live.

      Ageed.

      But I doubt it will end up feeling optional after a few more C programmers are converted.

      Converts from C already have to have for(;;) beaten out of them. However, IMHO the code that really matters is what everyone more or less has to use; in the Perl world, that equates to CPAN. Therefor I rest soundly at night (so long as I don't have other worries).

      I use _ a lot in variable and sub names, but I tend to do most my concatenating using interpolated strings anyway.

      Remember that the new concatenation operator will in effect be "space underscore space". Underscores embedded into identifiers don't get mistaken for concatenations.

      What I'd really prefer is a way for me to do something like $name = sub{ return 'My Name' }; print "$name\n"; without having $name return a darned coderef value rather than the results of $name->().

      You can already do something akin to this using overloading. It is extra code, but you can neatly package it away. (See "Falsify" scalar strings for a quick overview of how to use overloading for sorcery of this kind.)

      And as far as the bytecode is concerned, rest safe in the knowledge that every single modern interpreted language uses bytecode compilation in some way. As already mentioned by tilly++, but maybe not emphasized strongly enough, the difference between the Java and Perl bytecode is that Perl5's bytecode is very high-level - in fact, for a number of builtins, a call to them results in a single VM instruction. Java's VM on the other hand is very low-level and tries to mimic real hardware. That is the reason why Perl is fast and Java is slow. That's not going to change. Perl 6 is just bigger and better than Perl 5 in that respect. That's all there is to Parrot - more of the same, with some extra spice and lots of chilly.


      Maybe in contrast to my posts here so far, I don't think I'll enjoy Perl 6 as much as Perl 5 for a while to come. Perl 6 will be new, unfamiliar. I'm sort of an old dog in Perl 5, not nearly as much as others but I consider myself fluent in it and have no trouble finding my way around things and pronouncing ideas such that I can express them in a Perl5ish, idiomatic fashion. It will take everyone a while to achieve this level of familiarity in Perl 6. What I'm really looking forward to is using Perl 6, after having already used it for a year.

Re: Thoughts on Perl6 - Love it? Hate it?
by FoxtrotUniform (Prior) on Jan 10, 2002 at 22:42 UTC

    There are two things that I'm looking forward to about the release of Perl 6.

    1. The language itself. Hyper operators are bloody cool. Scalar typing is going to be fun, too. Grouped file-test operators, being N times easier to use, will probably make my code N times safer. Ditto multiway comparisons. I could go on, but you all get my point.
    2. The small, subtle incompatibilities between Perl 5 and Perl 6. I actually welcome these. They'll give me a very good and difficult to ignore reason to go back through my existing code and refactor it, or even rewrite it from scratch. So my code will get better, because of the review, and I'll have a relatively painless way to get acclimatized to Perl 6 (since I've already done the thinking to solve the problem, I'll be free to focus on the language). I hope.
    --
    :wq
Re: Thoughts on Perl6 - Love it? Hate it?
by mojotoad (Monsignor) on Jan 10, 2002 at 23:34 UTC
    I need some help with perl6.

    I'm using a module that employs the following statment:

    $stuff = 3.14;

    Question: Has anyone heard of the 14 method? Anyone else had any similar trouble with the 3 object?

    Yuk, yuk. ;-)

    Jest aside, I've always liked the -> notation merely because it *was* different and, once explained, made perfect sense to me.

    Having said that, I doubt I'll be heartbroken or anything once it goes away.

    Matt

      Yay. I'm not the only guy that likes the arrow notation! The "dot-notation" doesn't bother me in a big way though.

      What still kind of wrankles me (for no real reason I could articulate) is the sigil issue. I liked the fact that the sigil was different based on context.

      -Guv
Re: Thoughts on Perl6 - Love it? Hate it?
by petral (Curate) on Jan 10, 2002 at 23:49 UTC
    I guess I have most of the same thoughts others have.   I worry that Larry and Damian might overreach and get some really basic thing muddled.   I don't want to have to do $filehandle.autoflush(1) instead of $|++.   And '_' instead of '.' for concat?!

    But then I was reading exegesis 3 and came to Damian saying "in perl5 that would be...".   I had a momentary sensation like accidentally coming on some Fortran code or something and thinking: "Boy, I remember when we had to go through all that just to get something done".   So, now I've stopped worrying (and I'm getting impatient with perl5).

    (Maybe currying will transform Perl in perl6 like references did in perl5.)

      p
      I don't want to have to do $filehandle.autoflush(1) instead of $|++.

      Ugghhh! $++ doesn't do what you think. You think $| == 0 and that $|++ makes $|==1. Sure IFF $|==0. But what when some other fool does $|++. Then your $|++ doesn't do anything. Even worse $|-- doesns't set $|==0, because you blindly did $++. Now maybe your think this turns it into some sort of recursive lock type thing. No! because someone could have done $|=0 or $|=1 in another part or the code, cuz it's is the RightThing(tm).

      Just remember that $|++ is a SIN. Don't do it.

      BTW, what does $|==-1 even mean?

        'perldoc perlvar'

        The only values that count here are 0 and non-zero.
        $| is magic. It is always either 0 or 1. $|++ sets its value to 1 no matter what its original value was.

        However, $|-- is a bit trickier. $|-- toggles the value of $|. So, its actually a lot like $| = !$_

        % perl -le 'print $| and $|++ for 1..5;' 0 1 1 1 1 % perl -le 'print $| and $|-- for 1..5;' 0 1 0 1 0

        -Blake

Re: Thoughts on Perl6 - Love it? Hate it?
by Anonymous Monk on Jan 11, 2002 at 01:47 UTC
    I was concerned about Perl6 but then I re-read the Apocalypes and Exeges.

    Now I am trying to hold back my enthusiasm because I know it will be at least a year till there is something to use.

    The things I like:
    - Levels of competance/features. Like "use strict", but now for type checking and other stuff.
    - Object everything (not cuz I am a OO lover, but extending hashes will new features like "freeze the keys of a hash in place" are easier.)
    - try/throw/catch is great for network programs, errors are rare but they need to be caught; foo() or die; sucks after the first 300 repititions.
    - named and/or positional parameter declarations is going to be GREAT!. With some optional typeing, half my debugging code will disappear. And compile time errors, not just run time errors.

    Things I am not so hot about:
    - No explicit iterators, like my $iter := @a.iterator; $iter.getnext. What if I want to walk an array efficiently (ie no for(;;) loop) but be able to stop if one of the values requires immediate attention, then come back to the list. OR doing parallel operations on 3 or 4 or 200 arrays simulaneously.
    However, iterators may be able to be constructed with continuations. The Parrot guys have stated the goal that they want to have continuation support in the VM.
    - No mention of a standard Pre-Processor. I would like to have assert() and other simple macro expansions without haveing to take a runtime hit on production code.

      On iterators, I have released Tie::Array::Iterable, which allows arrays created into such objects to be iterable with iterator objects. I expect that with Perl 6, the mechanism for making iterators may be easier than having to cooerce the array as I did here.

      -----------------------------------------------------
      Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
      "I can see my house from here!"
      It's not what you know, but knowing how to find it if you don't know that's important

Re: Thoughts on Perl6 - Love it? Hate it?
by TheDamian (Priest) on Jan 11, 2002 at 05:29 UTC
    [I'm on the road, so this will have to be brief]

    Re: Next Apocalpyse/Exegesis

    I've seen Larry's first draft of A4 and it's brilliant. We're working through a few rough edges and that will continue on Perl Whirl '02 next week. I'll write E4 on the ship (no holidays for Perl serfs!) and the A4/E4 pair should appear late Feb.

    Re: Worry's about Larry and Damian muddling something fundamental

    We worry about that too. But we have Nat Torkington, Jarrko Hietaniemi, Dan Sugalski, Simon Cozens, Hugo van der Sanden, and Jon Orwant on the design review team. Very few mistakes survive that calibre of scrutiny.

    Then we have the entire Perl community giving us feedback on the decisions once they're made public. And we listen to that feedback very closely. Remember how the <> input operator was going to go away? Well, the outcry was so overwhelming (and so many good points made in its favour) that Larry reversed that decision.

    The future of Perl is (collectively) in very safe hands.

    Re: Scary changes in Perl 6

    I have an article in the next Perl Journal (out next month) entitled "And Now For Something Completely Similar..." that illustrates that Perl 6 is going to be very much like Perl 5 for a large number of coders. And is going to feel entirely Perlish, even where it does differ from Perl 5.

    I take five real-world programs (written by members of the Perl 6 design team) and port them to Perl 6. The gimmick is, of course, how little these typical (small) Perl programs actually change.

    Edited 2002-01-10 by dvergin to fix use of square brackets

        Re: Worry's about Larry and Damian muddling something fundamental

      Actually, I'm not worried about that (especially, because of the reasons/people mentioned), I was just giving examples of thoughts that cross my mind while reading.

      What I do watch for is some things for the simple-things-easy end of the see-saw over against all the furniture on the hard-things-easier end.   But putting in those sorts of shortcuts now certainly seems akin to premature optimization.

        p
Re: Thoughts on Perl6 - Love it? Hate it?
by Sweeper (Pilgrim) on Jan 11, 2002 at 11:32 UTC
    Since I have read RFC 48 (http://dev.perl.org/rfc/48.html), I have the biggest hopes for Perl 6. At last this wart inherited from C will disappear!

    I even hope this RFC will be in effect as soon as Perl 5.8.0.

      If you like that RFC, you really should check out Time::Piece which implements most of the ideas presented there....

      -Blake

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://137752]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (13)
As of 2014-07-30 14:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (234 votes), past polls