Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much


by batkins (Chaplain)
on Dec 09, 2002 at 01:41 UTC ( [id://218423] : perlmeditation . print w/replies, xml ) Need Help??

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
by Ovid (Cardinal) on Dec 09, 2002 at 02:37 UTC

    As of this writing, your post is at negative six reputation and will likely wind up much lower. Perhaps people might agree with your reasoning, but you haven't provided it. Had there been a cogent argument, you may have swayed some people or at least started some interesting discussion.

    Perl 6 is intended to be the community's rewrite of Perl -- it really is what many in the community want, but there are bound to be those who disagree with it. At the risk of being a broken record (I say this a lot): Utopia is a place that someone is guaranteed to hate. Clearly you are one of them. I am not sure, however, what it is that you disagree with. While I see similarities with some things in Python, Perl 6 is not going to be more like Python, but there may be more points of similarity between the two. Of course, comparing it to VB is, to be charitable, quite a stretch. Have you ever used VB? If you can come up with the even the slightest justification for the comparison, I would be surprised.

    Now, back to what you were saying. If you feel that Perl 6 is heading in the wrong direction, why? I love what I see happening with the language, but others don't. Like Perl in general, dissension is fine, but a Rebel Without a Because is going to get a lot of downvotes.


    New address of my CGI Course.
    Silence is Evil (feel free to copy and distribute widely - note copyright text)

      I would assume that the similarity to VB 6 is that method calls use the dot. Another similarity is that with the ability of Parrot to run .NET byte code you can choose to integrate (a bad implementation of) C# with Perl 6 on all platforms where Perl runs.

      These are not important similarities, nor are they negative ones, but they are similarities that Perl 5 does not have.

      Well there is a spotty dotty syntax similarity
      value =




by BrowserUk (Patriarch) on Dec 09, 2002 at 05:39 UTC

    It's a real shame you didn't take the time to express your doubts regarding the Perl6 proposals so far in a more coherent fashion.

    You are not the first person I have heard who has their doubts, and some of them are people with considerable knowledge and experience of Perl-to-date and many of the other languages upon which it draws. Had your start been more coherent, it might have brought out some of the concerns which others have alluded to but not fully expressed, at least not on this site that I have seen.

    If you know anything about the Perl language history, you would realise that it already draws upon many other languages for its syntax. From Dec Basic Plus from way back when, to C, Lisp(ish) stuff, to shell scripts and utilities like Awk and SED and many more. What makes perl the language it is today, is the rational approach that has been taken down the years to include those features that are useful, adapting them where possible to fit the general feel of the rest of the language, but not getting bogged down with trying to become the "perfect language"; be totally orthoganal; be complete in some academic way (like Pascal and its Backaus-Naur language definition, smalltalk with it "everythings an object" or Java with its strong typing).

    The thing that makes Perl unique among all of these are the basic premises upon which it combines all these seemingly disperate features.

    You yourself note that there is room " improve perl5...". I think that most people that use perl 5 have there own set of improvements that they would like to make. I do. For some it would be to remove some of the scarier DWIM features, others to increase the orthoganality of the built-in routines. Some would like to the ability to curtail its propensity for trading space for speed. And yet others would like to discard some of it legacy features or improve its built-in support for OO.

    From what I've read, most of these points and many more have been raised for consideration in the development of Perl 6, and its now up to Larry Wall and his team to sift through these RFC's and sort out which ones should be taken forward and which ones are best discarded. I seriously doubt that if you put any 10 Perl people in the same room and asked them to put ticks or crosses against the RFC's being considered that you would get any 2 that would agree, never mind a concensus. Given all the different directions that the language could be pulled in, it is going to be a monumental task to sift through them and arrive at a cohesive end product that remains true to the basic premise of Perl. However, given that LW got the language thus far, it seems impertanent to pre-suppose that he will do any less good a job than he has done till now.

    You say that "It should be started from scratch...". It has been hasn't it?

    Personally speaking, if Perl 6 aquires some features from either or both Python and/or VB, I would not be at all disappointed. Both languages have some features that I think could be useful additions to Perl. Especially if they are adapted to fit with the DWIM nature of existing perl constructs and features.

    For me, the thing that sets perl apart from most of the other languages I have used is that with very few exceptions, whatever I try to do with it, once I find the right one, it seems to have a feature, construct or idiom that seems to be specifically designed to deal with my particular problem in a concise and efficient manner. A few notable exceptions are

    1. A case statement.
    2. A mechanism for constructing portable, standalone applications
    3. A concise and transparent mechanism and syntax for defining and constructing objects.
    4. I'd also like to be able to nest statement modifiers. This was possible in Basic Plus II which was the successor to the original insiration for the modifier forms of if, while, and for.
    5. I'd also like to see the ability to use anonymous code blocks as the first argument to a sub extended to the general case for all arguments, and in other situations.

    I'm sure others would argue against some of these, and would add their own. Some of the above are muted for inclusion. Others may just be to far of the scale. Whatever the final decisions are, I'll make my judgement on whether I think they were the right one's once they have been made. You might like to try the same tack.

    Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
    Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
    Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
    Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.

      One thing most everyone with objections to Perl 6 seems to overlook is that it will allow the programmer to actively interfere with the parsing and compilation: the Perl 6 grammar will be available as a built-in Perl 6 pattern grammar and we'll be able to work on the underlying Parrot VM level. It may be awkward at first, but so was source filtering in Perl 5, and that has been addressed by way of modules, some of which made it into the 5.8 core.

      I am wary indeed of the possibilities for abuse this opens up, much like define macros offer in C, but on the other hand I shiver (with anticipation) to think what the likes of TheDamian will be able to do this way.

      In addition, I'm fairly certain that if Perl 6 gets something wrong in a way most of us dislike and which is fixable by way of such low level interaction, then a module or several will sooner or later be written and, if they meet expectations, be widely adopted by the community.

      I am, surprise surprise, not 100% satisfied with all of the proposed changes for Perl 6 myself but I quickly got over my fear. For one thing, I realized that many features in Perl 5 must have looked just as bizarre to the Perl 4 crowd, meaning I will likely get used to the "strange" stuff and eventually take them for given. And ever since Apocalypse 5, I'm absolutely optimistic that if there's anything I feel is really awful, I will be able to fix it for myself - the sky is the limit. That, and your imagination.

      Makeshifts last the longest.

        It's my understanding that Perl 6's syntax mutation capabilities will be a good deal safer than using C #defines. In fact, I'd argue that the current state of the Perl syntax munging art, Source Filters, are more like C macros than Perl 6 rules will be. Perl 6 rules are so much safer, they take away the need to do your own (possibly fallible) parsing of Perl source code, you just modify the rules at the appropriate level in the grammar and away you go. Also, rule based syntax modification is lexically scoped, which is definitely handy...
by mt2k (Hermit) on Dec 09, 2002 at 05:12 UTC
    Argh!!!! Okay, I spent over half an hour writing a reply to this node, and then my computer shut down and restarted on me for no reason after I'd typed a heck of a lot (including a sample of code that showed what I hope Perl never looks like). Anyhow, I'll shortly sum up what I had before...

    For starters, I make no claims at having read enough of the content regarding the subjct of Perl 6. I've glanced at a few of the new/modified features, such as the perl 6 regex scheme, which (from what I've seen) scares the heck out of me. So if you are an enthusiast about Perl 6 and think I'm dissing Perl 6, don't take me too seriously. I'm much too ignorant about the subject in order to provide a solid foundation on which to base my personal opinion as being more than that: a personal opinion on my current knowledge. I suspect this may also be batkins problem. I wonder if he is well-informed of the changes to the language, or if he's just afraid of what he has read/heard. As for me, I plan to read up more on it soon, so as not to be so ignorant. Besides, I'd much rather be prepared for the new stuff rather than being surprised when it is released!

    I support a new version of perl (especially one that the perl community is rebuilding), but have a couple of concerns. First of all, backwards-compatability. Will Perl 6 be 100% entirely compatable with perl 5.6.1+ scripts? (I chose 5.6.1 because of popularity). Will I be able to run perl 5 scripts with perl 6? Or will I have to spend hours working on porting it over? Even more importantly, how will modules be affected? Will they all have to be rewritten in perl 6 code before they can even be used?

    Second, I assume (yes, assuming is bad), that the majority (if not all), of the people rewriting perl are perl/system gurus. This makes me fear that the simplest of tasks will be difficult for a newcomer to the language to execute. To further explain, a new implementation in Perl 6 might seem like the easiest of tasks for one of these gurus, but will puzzle and frustrate newcomers to no end, perhaps making them give up one the language and turn to one of its competitors.

    And just a very shortened example of what perl had better never look like. I'm not scared perl will turn out to be like this... I did this more for entertainment than for truth! I just made this up... no language is this ugly :) :

    #--include module Perl8 export('declare', 'print', 'new', 'call', 'str', 'int'); #--include module CGI export(':standard'); sub main::main { declare lexical q as scalar; q = new Object ( Package => CGI, Method => 'new' ); print { SRC => STDOUT, BUFFER => int(0) }, call( Object => q, Method => header Params => str(text/html) ), str(Hi there, this is a sample CGI script); }
      Will Perl 6 be 100% entirely compatable with perl 5.6.1+ scripts?

      No -- that's why it's called Perl 6. That's the answer if you're asking if Perl 5.6.1 is forwards compatible with Perl 6. If you're asking about backwards compatibility, read the next question.

      Will I be able to run perl 5 scripts with perl 6?

      That's the plan, yes.

      Even more importantly, how will modules be affected? Will they all have to be rewritten in perl 6 code before they can even be used?

      Since Perl 5 scripts and Perl 5 modules are written in the same language, it's the same answer.

      Second, I assume (yes, assuming is bad), that the majority (if not all), of the people rewriting perl are perl/system gurus. This makes me fear that the simplest of tasks will be difficult for a newcomer to the language to execute.

      Why? These are the same people who made Perl 5.

      Your code example reminds me of a .signature Simon Cozens had. It reads something like "Allowing programmers to program in English will only prove that programmers can't write English."

        I hadn't seen that .sig, but from I found what I suspect is the original, The only advantage in making computers understand English is that it will prove once and for all that programmers can't write English. -- Mike Taylor
by batkins (Chaplain) on Dec 09, 2002 at 15:34 UTC
    i apologize for my rather immature first post. i clicked the "make your petition" link and was under the impression that i was beginning a petition. it seems i am not :)

    i will concede that i don't know too much about perl 6. i am relying mostly on the exegeses on here are some of the problems i've seen:

    1) to me, parrot seems frivolous and unnecessary. it reminds me very much of java's virtual machine, which, from my experience seems pretty bad. why should we concern ourselves with making a platform that can run different languages? perl 6 should be about perl, not about a virtual machine

    2) the use of . instead of -> and _ instead of . utterly disgusts me. why should this be changed? unless objects are no longer references in perl 6, there's no reason for this switch except to appease vb and java programs. at the very least, . and -> should be synonyms. and _ is an ugly way to concatenate:

    print "sdsd" _ "dsdsd";

    i'm not saying that perl 5 can't be improved upon. XS could be made much prettier, and better module exporting methods could be used. but rewriting the whole thing and twisting its syntax to ugly javaness is hardly necessary.

    also, i am not a troll (at least not intentionally :) )

      Your points:

      ...parrot seems frivolous and unnecessary

      I am glad we're making a platform that can run different languages. Parrot has the potential to pull much of the dynamically typed language community together and can give it a solid footing. If there is a great Python library that I want to use, I can run it through Parrot and use it from Perl without much effort. You can also use Parrot assembly directly from Perl and get the performance benefits without being forced to learn C. And the JIT compiler will be a godsend for many programmers. It will be wonderful to compile and distribute an actual application, rather than many of the hodgepodges that we have now.

      the use of . instead of -> and _ instead of . utterly disgusts me.

      The underscore is there because the dot operator no longer represents concatenation. As for the dot operator, once I became used to the change, I was happy for it. First of all, it represents less punctuation. Whether justified or not, many people gripe about Perl's excessive and sometimes confusing punctuation and this will help to alleviate that concern. Of course, if one is going to reduce punctuation, one should do it for commonly done things. The arrow operator is one of those things and since everyone else already uses the dot, it's a pretty natural conversion.

      Incidentally, take a look at some VB6 or VBScript code and compare it to the code written for Win32 modules. Quite often, lines of code are identical, except for the difference between the arrow and the dot. This makes less of a barrier for people coming to Perl. We shouldn't be here to be elitist. We should be here because Perl Gets Things Done. If switching from an arrow to a dot improves that and makes Perl seem less intimidating, so be it.

      Returning to the punctuation problem, the shift from arrow to dot is part of the overall plan to extend Perl yet make it easier to learn. This has led to standardizing the sigils of variables so that they denote type instead of what the variable is returning. For instance:

      # Perl 6 (possible typos ahead) my @array = qw(foo bar baz this that the other thing); my $word = @array[0]; # a single value my @words = @array[5,6,7]; # an array slice

      The above syntax is already what many new programmers expect out of Perl5. We have to violate their expectations to explain the difference between accessing a single array value or an array slice. Further, the following monstrosities in Perl 5 can hopefully go away:

      @_[1..$#_]; # all but the first element of an argument list @{$var}{qw(foo bar)}; # a hash slice of a hash reference

      (out of time and need to get to work ... I'm sure others can come up with better examples and show how they'll look in Perl6)


      New address of my CGI Course.
      Silence is Evil (feel free to copy and distribute widely - note copyright text)

        Just a quick note. _ is no longer being used for the concatenation operator, now it's ~.
        "hello " ~ "world"; $str ~= "!!!"; # which is different from =~ (if =~ isn't changed)
        Also, the "." syntax has one big advantage: topics. When calling a method on the topic ($_ (also $self in OO -- see article on, a lone dot looks much better than a lone arrow. .method vs. ->method And it fits my brain better for assignment.

        elusion :

        now, wait just a tick. are you saying that parrot will allow the use of non-perl libraries and that it will allow true executables (not perl2exe or perlapp packages, but real exe's)? if so, then i just might have to retract my anti-parrot sentiments.

        but i'm holding my ground on the symbols issue. :)

      ++ for coming back :-)

      to me, parrot seems frivolous and unnecessary. it reminds me very much of java's virtual machine, which, from my experience seems pretty bad. why should we concern ourselves with making a platform that can run different languages? perl 6 should be about perl, not about a virtual machine

      There are lots of reasons people are paying attention to parrot (in addition to the fact that playing with VMs is fun :-)

      Most important is probably the fact that the perl5 VM is a god awful mess. It's hard to understand. It's hard to extend. It's hard to maintain. It was a very obvious component of perl that needed a complete re-write.

      Personally, I think multiple-language support is a good thing. Writing code in multiple languages is useful, and very few environments allow you to do it in any meaningful way. I talked about this a little bit elsewhere if you're interested. Supporting multiple languages in this way is, to me, a natural extension to Perl's TMTOWTDI attitude.

      Also, making the VM more explicit and straightforward makes things like writing JIT compliers a much more practical goal.

      Finally, having explicit access to the VM and various compilation phases from perl6 enables you to do really cool things. Not more messing with subroutine prototypes or source filters. You can actually write your own syntax.

      (Actually, I'm not 100% on this being in the perl6 goal list - not having to spare time to do more than read the weekly summaries... but it's certainly possible).

      the use of . instead of -> and _ instead of . utterly disgusts me. why should this be changed?

      Well, these sorts of decision are, to some extent, a matter of taste. However the changes were not made arbitarily. Three good reasons come to mind.

      • Typing two characters all the time when one would do is a waste of time and space.
      • The fact that practically every other language on the planet uses the "." notation for this sort of thing adds a pointless comprehension barrier for people who switch between languages.
      • I believe (not 100% on this) that perl6 changing so that the syntax for method access and direct attribute/field access is the same (so $foo->method and $foo->{field} would be written $foo.method & $foo.field). This is a very good thing since it allows you to change your implementation without changing your APIs. Sensible languages like Eiffel have been doing this for years (see this article for more info on why this is good.)

      I remember similar arguments when "::" replaced "'" as the package separator. With the exception of Klingon, I don't think anybody worries about it any more.

      If you're interested (and have the spare time) I would spend some time wandering around the perl6 mailing lists. There's a lot of interesting stuff, and it will give you more background on why certain decisions have been made.

      Personally, from what I can see so far, perl6 is going to provide me with many of the features that I have sorely missed in perl4 and perl5 (proper OO, ability to write your own domain languages, simple currying, etc.)

      There is also the fact that so much of perl5 stays exactly the same in perl6. Only the changes get talked about.

      While I don't agree with every design decision that's been made the changes are certainly not being made just to annoy. If I had more of that mythical substance known as "spare time" I would contribute to the implementation effort (and get some input to those designs decisions I'm not 100% happy with). If you have the inclination, and feel that you have something to contribute, maybe you should consider it.

      s/Two good/Three good/

      to me, parrot seems frivolous and unnecessary
      You've not spent any time dealing with perl 5's VM, then. The current virtual machine (and it is a virtual machine, make no mistake there) has a number of... issues that make extending it, changing it, or otherwise doing much to (or with) it really painful. This is in part because of some issues with the original design, and in part because of seven or eight years of continuous hacking on it by a wide variety of people.

      Just because the JVM (and the .NET VM) made some fairly fundamentally bad design decisions doesn't mean that all VMs are bad. (And I'm interested in what similarities you see, as there's almost no overlap at all, from an architectural standpoint)

      Others have already implicitly mentioned this, but I think it's worthing noting once more explicitly because a lot of people misunderstand this point.

      Perl 5 runs on a VM.

      It just doesn't have a name and is hidden in there along with the compiler. The result is that next to noone seems to notice that Perl5 has a VM just like - and is no more interpreted than - Java and others.

      Be careful about your assumptions.

      Makeshifts last the longest.

      It seems your first experience here has been a trial by fire, but it's good that you haven't taken it personally :^)

      With respect to your comments about Parrot, it is important to note that Perl has always been an interpreted language, and therefore run on a virtual machine, namely perl. The difference in Perl 6 is that the compiler and interpreter (VM) are separated from one another, something like the difference between javac and java. So the question is not whether there should be a VM, but what it should do and how it should stand in relation to other tools and languages. My understanding is that the affordances made that allow Parrot to run multiple languages (after compilation to bytecode) also enable functionality like syntax modification, which pushes Perl toward Wall's goal of a metalanguage. So the design choice both increases Perl's flexibility and provides greater options to other languages.

      As to the aesthetics of -> vs . and . vs _, these debates ultimately must take a backseat to what works. When I started coding in Perl after using Java for a couple years, I was mortified by sigils ($, %, @, etc.) and the arrow syntax. After three years of Perl, I've gotten used to them and often compulsively type them now regardless of language. Besides, there are always source filters and various pragmas to enable you to customize the way you want to write your code.

      (Note that this is all based on my limited knowledge of Perl 5 and 6 as they are now.)

      Syntax, as I recall, will be alterable at the file level (and others), and so the changes will then be to the default syntax, as opposed to the only syntax. Also, I disagree with you about Parrot not being good; I would very much like to be able to, say, write programs in Ruby and be able to access the vast library of Perl modules in CPAN, or write programs in Perl but using a few Python modules. Perl 5 already does use a virtual machine of sorts; it's just not explicitly exposed, which makes it less orthogonal and more difficult to at-get in a standard fashion.

      From what I've read of the Apocalypse and Exegesis series (which, admittedly, was only the first few a long time ago), I think some of the 'punctuation' changes you talk about were being made because of ambiguities in the perl5 syntax. Certainly, any change that allows the programmer to get his wishes across to the compiler with less confusion can't be all bad.

      This area is for discussion of the Perl Monks site. If you want to start a discussion about Perl 6, that should probably go under Meditations, unless it is a specific question in which case it goes under Seekers of Perl Wisdom.
by Aristotle (Chancellor) on Dec 09, 2002 at 02:10 UTC
    Perl 4 is still around if you didn't like Perl 5.

    Makeshifts last the longest.

      I prefer Perl 1. It's like comparing New Coke and Original Coke. The new recipe wasn't popular, and they had to go back to the old version. Maybe that's what the Perl community should be doing.


        What do you find appealing about Perl 1?
by MZSanford (Curate) on Dec 09, 2002 at 14:58 UTC

    One worry i must say that i have about Perl6 is speed. I know there is alot of talk about how we are not to the point where speed matters yet, and we should be concerned with stability, etc ... but i think we are in danger of reproducing the errors done with Tcl. I am not against Perl6, but there was a point in Tcl development where they decided it would be a good idea to make everything an object, much like alot of the Perl6 ideas ... what this did was make me the winner of the speed arguments against Tcl coders... oh, and make Tcl more useful... but, somehow that gets lost now.

    I have been really suprised by some of the changes with Perl6, and how much it resembles Java. I mean, if i wanted to write Java, or any OO-Dependant language, i would. I do write OO-Perl, but i like the option not to. I fear that we are building Yet Another Object Oriented Language.

    I understand that many of the changes will make the language easier for new people to learn. But, while it is really nice to woo people away from other languages, and it may make people feel good to develop a language this easy to use, i thought that VB tought us that making coding easier, tends to make code worse. Well, i guess thats the end of my feelings.

    I look forward to Perl6, but i really wish they would have just called the language something else, and let it co-exist with Perl as it is ... thus making the rather large existing community happy, while creating this new, easy-to-learn language. I am sure that a reply (and a downvote) will say that "Perl5 will still be around", but, hey, when is the last time your CTO said "lets use the last version of the language, becuase my technical experiance shows it to be better for what we are doing" ? -- They didn't ... they normally choose the newest technology, even when it is not best suited to what you are doing *cough* java *cough*

    Just my €0.02
    from the frivolous to the serious
      The numbers on Parrot vs The Perl VM make interesting reading. Parrot is currently trouncing the Perl VM by at least an order of magnitude (unless my memory is playing me false...). Yes, the P5VM is doing more, but Parrot has a hell of a lot of headroom right now. I will be extremely surprised if Dan and his team don't deliver on the 'as fast or faster than Perl 5' promise.
        In terms of arithmetic and other primitive operations, I'm sure Parrot will trounce the P5VM. This will be helpful in coding loops and testing limits and so on, the nuts and bolts of what holds a program together.

        But individual features may get bogged down. For example, a while back I mused that Perl 6 Patterns would be much slower than Perl 5 Regex's because you can't tell it not to capture everything, and Abigail pointed out that this is not something you can optomize at compile-time without solving the halting problem.

        So in Perl 5, I try and use built-in stuff even if in clever ways because it's faster than coding an explicit loop; in Perl 6 that will not be the case, but will I avoid grammars like the plauge because they are far slower than procedural code? That's my worry.

      Not only will perl5 still be around and useable, perl6 will continue to be Perl. Object Orientedness is not being forced on anybody, from what I can tell. There may be improvements going on in that area, causing much noise to be made, but the rest of the language is not going to disappear. I feel reasonably confident that perl6 will possess the spirit and nature of the Perl you know and love today. After all, look who's making it -- Larry and the gang didn't suddenly gain a dislike for the language they've spent all these years creating.

by beretboy (Chaplain) on Dec 09, 2002 at 02:16 UTC
    batkins: If you think something is wrong with perl6, at the very least you could propose alternatives.

    "Sanity is the playground of the unimaginative" -Unknown
by PodMaster (Abbot) on Dec 09, 2002 at 02:33 UTC
    There is plenty of things that I dislike(d)?(things change) about Perl6, but hey, perl5x development won't stop any time soon, and I won't stop using it any time soon. I am satisfied with the way perl6 is going, cause if it stays too much like perl5x, ie, less like pythong/vb, then it'll be harder to learn, cause there'll be tons more stuff to learn/remember.

    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    ** The Third rule of perl club is a statement of fact: pod is sexy.

by adrianh (Chancellor) on Dec 09, 2002 at 01:57 UTC
    Perl 6 is headed in the wrong direction.


    It should be started rom scratch and written to improve Perl 5, not to make it more like Python or VB.



by Elian (Parson) on Dec 09, 2002 at 16:29 UTC
    So fix things the way you want. There's nothing stopping you, and you'll find a fair amount of company for that undertaking. Sourceforge is there for pretty much anyone to use.

    The work other people are doing on what is essentially a standalone project doesn't affect perl 5, and neither will it affect your rewrite.

    Go for it, good luck, don't forget to write.

by dbp (Pilgrim) on Dec 09, 2002 at 07:49 UTC

    I don't know much about Perl 6. I haven't spent the time to read up about it. But if I were going to, I'd probably start here. You don't seem to have done much research either and I think doing so is warranted before posting another meditation.

    Update: I seem to be a victim of subconscious sarcasm. Well, I meant to be a tad caustic but I was under the impression that this actually was a *meditation* when I posted this. In light of this new (to me) evidence, I'm sure this is a troll.

by bronto (Priest) on Dec 09, 2002 at 09:47 UTC

    You sound like a good candidate for a new level of experience :-)


    # Another Perl edition of a song:
    # The End, by The Beatles
    END {
      $you->take($love) eq $you->make($love) ;