Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Perl 6 feature that scares me the most:

by Elian (Parson)
on May 29, 2003 at 18:23 UTC ( [id://261631]=poll: print w/replies, xml ) Need Help??

Vote on this poll

Continuations
[bar] 24/3%
Higher-order functions
[bar] 15/2%
Multimethod dispatch
[bar] 13/2%
Co-routines
[bar] 21/3%
Value properties
[bar] 11/1%
Variable Traits
[bar] 15/2%
Calling into Python
[bar] 86/10%
Zork->play($game_dat­a)
[bar] 61/7%
theDamian is trying to drive me mad!
[bar] 47/6%
Garbage collection
[bar] 36/4%
Dan's involvement
[bar] 19/2%
The whole thing
[bar] 122/15%
Lalalalalala, I can't hear you...
[bar] 359/43%
829 total votes
Replies are listed 'Best First'.
Re: Perl 6 feature that scares me the most:
by tune (Curate) on May 29, 2003 at 18:32 UTC
    The feature that most scares me is that its not-yet-releasedness :)

    --
    tune

      I haven't been following the Perl 6 topic too closely, but I remember last year, hearing something about totally rewriting the regular expression egine. If this is true, I'm going to run away and hide under my bed until it's safe.
      I am scared that someone will write a Python parser as a perl 6 regex.
        Nah, we'll run the grammar that exists through a translator and autogenerate it. Much easier... :)

        Well, someone on the CB did suggest that someone write a pythontidy script in Perl... ;)

        --
        Allolex

•Re: Perl 6 feature that scares me the most:
by merlyn (Sage) on May 29, 2003 at 20:46 UTC
      Yes, but think of the extensive retraining needs that'll be generated! :)
        And, having said that, I really ought to say that this isn't one of the reasons behind perl 6. The need to learn this stuff is acting as something of a brake on things in many cases--we don't want people to have to learn new things. It's inevitable, of course, but since we don't want it we're making sure that the changes have good reason behind them. (Whether the reasons are good enough is, of course, a matter of personal opinion...)
      Yes, but this is a Good Thing. (in some ways)
Re: Perl 6 feature that scares me the most:
by logan (Curate) on May 29, 2003 at 20:44 UTC
    The whole concept of Perl 6 frightens me. I fear that I'll have to relearn large chunks of the language. I fear that I'll have to do a major porting effort on my existing code should Red Hat, Sun, or SGI decide to ship with Perl 6 instead of 5. It's not so much that I fear change, just big change.

    The rational part of my mind tells me that if I took an afternoon and read the relevant web pages, I'd probably find that it's not going to be so bad. Thing is, that part of my mind also tells me to go to the gym, eat salad, and study C, so it clearly can't be trusted.

    -Logan
    "What do I want? I'm an American. I want more."

      The whole concept of Perl 6 frightens me. I fear that I'll have to relearn large chunks of the language. I fear that I'll have to do a major porting effort on my existing code should Red Hat, Sun, or SGI decide to ship with Perl 6 instead of 5. It's not so much that I fear change, just big change.
      It would be a disaster if installing Perl6 broke all Perl5 scripts. Since Larry has no desire to author a disaster, he has mandated that Perl6 be compatible with Perl5. The compiler will only go into Perl6 mode when encountering some Perl6 construct, like 'module'.
        I'd consider it a disaster if installing perl 6 uninstalled or overwrote any install of perl 5. Installing one won't automatically preclude installing the other, and I fully expect that anyone shipping a perl 6 install will ship a perl 5 install as well, at least for quite a number of years. (Much the same as when folks shipped perl 4 and perl 5 simultaneously)

        I personally don't plan on running my working perl 5 programs under perl 6 for anything other than testing purposes--they work, disk space is cheapish, and I loathe breaking things without a darned good reason.

Re: Perl 6 feature that scares me the most:
by enoch (Chaplain) on May 29, 2003 at 19:06 UTC
    As of right now, I am the singular voter for variable traits. I just don't really see it, yet. I understand it, when it is used like:
    my DVD $matrix is Scalar; # or my DVD @disks is Array; # or, even my DVD %disks is Hash;
    I just get a little wary when I see something like:
    my DVD $matrix is Media; # or my CD @disks is Media;
    I just don't know how that is going to work. For example, I know what this would do:
    my DVD $matrix is Scalar; $matrix = "I know Kung Fu";
    But, I have no idea what this does or how to define what it does in the whimsical world or Perl 6:
    my DVD $matrix is Media; $matrix = "There is no spoon";
    Anyone have insight?

    enoch

      And now you can also do this. *grin* All that this does is separate the interface from the implementation.

      my DVD @disks is Scalar; # or, even my DVD %disks is Array;
(jeffa) Re: Perl 6 feature that scares me the most:
by jeffa (Bishop) on May 29, 2003 at 20:40 UTC
    That Zork thingy ... i have a great fear of being eaten by a grue or two when my lamp gets stolen by that durn thief!

    jeffa

    > take bar
    bar ... bar ...

      You are in a maze of twisty Parrot calling conventions, all alike.

        Good thing Parrot hasn't even hit alpha yet, or that might be a problem...

      ... take the ceiling... the ceiling...

Re: Perl 6 feature that scares me the most:
by thelenm (Vicar) on May 29, 2003 at 19:10 UTC
    How about new syntax? It seems so simple, and yet in some primal part of my brain, having to get comfortable with a new Perl syntax freaks me out.

    -- Mike

    --
    just,my${.02}

      Syntax isn't a feature, as such. (According to the lisp folks, syntax is a mis-feature, but who listens to them? :)
        MC Carthy, when creating Lisp, decided on an abstract syntax that is fine and dandy for people doing program rewriting but never provided a human palatable concrete syntax. But normal people often don't deal at that level. The constraints to clearly display programs are different than those to programmatically manipulate them.

        On the other hand. Perl5 had never correctly tackled the problem of program manipulation/transformation. Source filters are a ugly hack; eval-string should be limited to deal with user output. Dealing directly with B:: modules with the "object" level, hum, the intricate plate of spaghetti generated whem compiling a Perl program is even worse.

        At last, with Perl6, we will have macros in the sense of Lisp (abstract syntax level rewriting) not in the sense of C (textual level rewriting, the C-preprocessor does not even know about C concrete syntax).

        Macro combined with concrete syntax will be a way to cast cleanly new programmatic patterns in the language.. Perl has always promoted growth and experimentation but had never provided an appropriate mechanism. To fully understand the power of macros in Perl6, one should read Paul Graham's book On Lisp while keeping in mind the stuff about macros in the last apocalypse.

        Perl6 macros will bridge the gap between abstract and concrete syntax. I have been told that it is not the first to do it but if Perl6 becomes popular, it will bring that power to general conciousness.

        Note also that the distinction between concrete and abstract syntax parallels the distinction made by Chomsky between surface and deep structures.

        But some will claim that Chomsky is a fraud in linguistic. This has nothing to do with his political opinions :)

        From modern compiler implementation in ML p 101:
        The notion of abstract syntax is due to McCarthy (1963), who designed the abstract syntax for Lisp (McCarthy et al. 1962). The abstract syntax was intended to be used writring programs until designers could get around to create a concrete syntax with human readable punctuation (instead of Lots of Irritating Silly Parentheses), but programmers soon got used to programming directly in abstract syntax.

        -- stefp
        Come to YAPC::Europe 2003 in Paris, 23-25 July 2003.

        shouldn't that be:
          "Syntax isn't a feature, as such.
          (According to the lisp folks, syntax is a mis-feature (but who listens to them? :) )" ? :-)

        Edit by tye, remove PRE around long lines.

Re: Perl 6 feature that scares me the most:
by Zaxo (Archbishop) on May 31, 2003 at 00:25 UTC

    My vote went to Garbage Collection. I wouldn't object to a well-tuned gc built into Perl6's memory management, but current thinking seems to involve delaying all release of system resources. Timely destruction is lost by dragooning mark-and-sweep gc into the quest for correct destruction of circular chains of reference.

    In On timely destruction?, Elian asked for opinions on the importance of a timely destruction guarantee. There were plenty of good answers supporting that need, but it soon became obvious that the decision had already been made.

    This is the frightening part.

    Without the ability to release system resources in a timely and ordered manner, Perl6 will lose Perl's greatest advantage - its ability to be useful for many purposes. Interaction with sockets, files, pipes, signals, and external processes all become subject to indeterminate delays and mysterious races. Exactly the sort of thing that makes Java so bad for such work.

    I think there is a path out of this.

    1. Keep gc for its strengths; levelling memory management overhead, and reducing memory fragmentation.
    2. Make object destruction as timely and ordered as we can.
    3. Civilize circular references some other way.

    No, I don't have a design for that last. I'm thinking about it.

    There is too much baby left in that bathwater. Don't collect it.

    After Compline,
    Zaxo

      Timely destruction is lost by dragooning mark-and-sweep gc into the quest for correct destruction of circular chains of reference.

      While I think that correct destruction of circular references is more than enough reason to move to a decent GC system it's not the only reason.

      A sane GC is also faster than reference counting for all but the most pathological of cases (you don't have to keep track of references and you get better use of your cache).

      It's also much more robust. Once you have it up and running it "just works". With reference counting add one feature that forgets to bump/decrement the reference count and you're in trouble.

      Personally, I think that the worries about timely release of resources and GC are overstated. I've spent a lot of time before Perl in languages with a decent GC. I can't recall a single instance of timely destruction being a problem. Arguing from personal experience is dodgy I know - but I really don't think you'll have problems. You might have to add a couple of extra techniques to handle things (e.g. block-exit handlers) - but it won't be hard or onerous..

      It will be a problem for some Perl5 code running in Perl6 - not a huge amount if my code base is anything to go by. I've got much more code that has to jump though hoops to deal with circular references. The thought of throwing all of that in the bin gives me the warm fuzzies :-)

      For new code there are several ways of manging timely release of resources in other ways. Perl6 has block-exit handlers, and probably other timely finalisation methods that we've not heard about yet.

      For me the advantage of a decent GC more than make up for the lost of calling DESTROY when something drops out of scope.

Re: Perl 6 feature that scares me the most:
by Anonymous Monk on May 30, 2003 at 09:38 UTC
    These don't scare but bother me:

    1. CPAN modules that will not work with Perl 6/Parrot.
    2. It seems that everyone is writing their very own VM these days (ex: java, .net, mono, parrot), which will (of course) run faster, better, etc than everyone elses. There is hardly a practical technical incentive (platform dependency excluded) to choose one VM over the other. Parrot will be just one in the crowd.
    3. Will not appeal to VM zealots because it is too late in the game.
    4. Will not appeal to perl programmers because it will probably be bigger, require more typing, run slower than perl 5.
    5. They are not really thinking about making extending/embedding easier than XS.

    Then again ... I might be completly wrong.

      CPAN modules that will not work with Perl 6/Parrot

      I would imagine that the perl5 compatability layer will take care of the majority of pure perl modules. AFAIK XS will need a rewrite.

      It doesn't really worry me. Important modules that lots of people use will get ported. Modules that I need myself I can port.

      It seems that everyone is writing their very own VM these days (ex: java, .net, mono, parrot), which will (of course) run faster, better, etc than everyone elses. There is hardly a practical technical incentive (platform dependency excluded) to choose one VM over the other. Parrot will be just one in the crowd.

      There are some specific reasons why JVM and .NET won't work for Perl6 (the need to support closures, continuations and polymorphic scalars).

      If others choose to implement languages on top of Parrot too that's just gravy :-)

      Will not appeal to VM zealots because it is too late in the game.

      And this is a problem why? :-)

      Will not appeal to perl programmers because it will probably be bigger, require more typing, run slower than perl 5.

      Speaking personally I find the "bigger" bit appealing. The features that are being added to Perl6 are features that I miss a great deal in perl5.

      It doesn't require more typing. Typing is optional for those who like it. TMTOWTDI and all that.

      So far I've not seen any evidence that it will be slower. Quite the opposite.

      They are not really thinking about making extending/embedding easier than XS.

      Yes they are. To quote from the perl6 architecture document.

      One of the major reasons to revisit Perl was to fix the mess that is XS (the way you extend Perl with C or C++ subroutines).  Perl5 has no API for extension, separate from the functions used to implement Perl, and extending Perl requires hideous amounts of work.  Dan and Larry are aiming to make C extensions as easy as they possibly can be (Brian Ingerson's excellent perl5 Inline modules give some directions for this).  Anyone who has used XS looks forward to its demise.

      If you take a look around the mailing list archives you will find people are thinking about this.

        And this is a problem why? :-)

        Because, for example, alternatives might be preferred in real world projects. This means less perl programming for us :(

        The features that are being added to Perl6 are features that I miss a great deal in perl5.

        Maybe after I learn perl6 will miss them in perl5 too :).

        Whether they will help us write better software remains to be seen.

        So far I've not seen any evidence that it will be slower. Quite the opposite.

        So far, parrot cannot handle everything perl5 does.

        As far as typing goes, the Python authors argue that this one of the reasons for Pythons success. I tend to agree.

        If you take a look around the mailing list archives you will find people are thinking about this.

        I'm looking at the lists (actually news) quite regulary.

        The java docs state that any new JVM implementation should start with good ideea of how JNI will work. I think it's a good advice that the Parrot developers should take.

        BTW, why is perl6-porters not gatewayed to nntp.perl.org any more? The last messages date February 2001.

      1. CPAN modules that will not work with Perl 6/Parrot.
      While this is not likely to be true at launch, within a year or so Parrot should be happy to load Perl5 code therefore making the majority (if not the entirety, depending on how XS dependant modules are handled) of CPAN available to Perl6.
      2. It seems that everyone is writing their very own VM these days (ex: java, .net, mono, parrot), which will (of course) run faster, better, etc than everyone elses. There is hardly a practical technical incentive (platform dependency excluded) to choose one VM over the other. Parrot will be just one in the crowd.
      For the reasoning behind Parrot as YAVMI1 see Elian's (Perl|python|Ruby) on (.NET|JVM), (closures) The reason for Parrot, part 2 and Why not a Lisp (or Scheme) VM for Parrot?.
      4. Will not appeal to perl programmers because it will probably be bigger, require more typing, run slower than perl 5.
      Slower than perl5? To quote the man himself - Parrot is an order of magnitude faster than perl 5 doing equivalent things. Without enabling any extraordinary measures. (see. Now I know how the Lisp folks feel).
      5. They are not really thinking about making extending/embedding easier than XS.
      Parrot won't use XS, so this is a non-issue.
      HTH

      _________
      broquaint

      1 Yet Another Virtual Machine Implementation

        While this is not likely to be true at launch, within a year or so Parrot should be happy to load Perl5 code therefore making the majority (if not the entirety, depending on how XS dependant modules are handled) of CPAN available to Perl6.

        Implementing that is definitely not trivial. I think it is more likely that they will end up providing *some* support for XS modules, with the recommendation that we use the new system. Some will not be able to rely upon this emulation layer and it will not move to perl6 until they are really motivated. Continuations and closures alone, won't cut it. If it were so, all those proprietary, never seen by CPAN but running in production environments XS modules, were written in Lisp/Scheme by now

      As far as I know, it is an explicit goal for Perl6 to run at about twice the speed of Perl5? Performance is a major reason we switched from compiling to an optree in 5 to compiling to VM bytecode in 6 after all.

      Makeshifts last the longest.

Re: Perl 6 feature that scares me the most:
by Beatnik (Parson) on May 30, 2003 at 20:21 UTC
    If you ever heard theDamian explain perl 6, you'd realize instantly why they call him 'The Mad Scientist of Perl'. If you haven't had the pleasure of seeing him live, I can REALLY recommend it.

    Greetz
    Beatnik
    ... I'm belgian but I don't play one on TV.
      And if you're in the U.S. you'll be able to see me this (northern) summer. The official tour t-shirt has all the details.
        It is generally inappropriate to ask one to reveal one's vote, but assuming you made one, and being who you are, I am very interested in hearing what, of the choices given, scares you the most about Perl6...
Re: Perl 6 feature that scares me the most:
by TStanley (Canon) on May 30, 2003 at 00:08 UTC
    TheDamian is trying to drive me mad

    After the last couple of days, he has. Although in my case it wasn't a drive, just a short putt. :-)

    TStanley
    --------
Re: Perl 6 feature that scares me the most:
by mrpilot (Curate) on May 29, 2003 at 20:40 UTC
    I'm just starting to learn Perl 5, and now (well...at some point) I'm going to have to learn new stuff when Perl 6 comes out. I can't take this pressure! Gah! :-)
Re: Perl 6 feature that scares me the most:
by wolfger (Deacon) on May 30, 2003 at 11:05 UTC
    What scares me the most is that I'm not seeing a lot of acceptance of Perl6 from the perl community. I haven't really looked at it myself, but to hear other people talking, it's virtually a new language. My question is, why are they even doing a Perl6? There doesn't appear to be a need (or even a desire) for it.
    Believe nothing, no matter where you read it, or who said it - even if I have said it - unless it agrees with your own reason and your own common sense. -- Buddha

      I want it! I want it now!

      Perl6 is a lot closer to Perl5 than most people think. Since most discussions on the language revolve around the features that are different, rather than talking about what doesn't change.

      I'm looking forward to it. It adds the things I miss from other languages, and keeps the things I like about Perl.

      You don't know how badly I want it. I'm certainly scared of some things, but I can't sit still wanting to get my hands on the new pattern matching language.

      Makeshifts last the longest.

Re: Perl 6 feature that scares me the most:
by chantstophacking (Acolyte) on May 30, 2003 at 22:47 UTC
    I heartily approve of polls that are directly about Perl. This discussion has been quite valuable to me.

      /me notes that you can now vote directly on the poll, either ++ or --, and that elian, as the proposer, will get the XP.


      Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

binding a slurpy rw hash
by jonadab (Parson) on Jun 08, 2003 at 20:31 UTC

    The prospect of binding a slurpy rw hash worries me, because if it scares Larry, I figure there must be something frightening about it. I can imagine folks here on Perlmonks fooling around in the obfuscation section reminiscing about when obfuscated code was mostly a bunch of punctuation and you could just read it carefully and deobfuscate it in your head.

    I'm also a little bit on edge about the whole subrule thing. I mean, that's powerful, sure, but it could be another way to make code hard to follow, also, because the subrules can be changed between calls of the main rule. I envision self-modifying code that breeds new generations of itself, tests them for efficiency and terseness, picks the "best", rince, repeat...

    "Back in my day, anyone could deobfuscate a good JAPH in twenty minutes... we didn't have these fancy new-fangled recursive genetic JAPHs... those things turn your brain to mush, you know..."

    OTOH, I'm thoroughly excited about the Perl6 object model.


    {my$c;$ x=sub{++$c}}map{$ \.=$_->()}map{my$a=$_->[1]; sub{$a++ }}sort{_($a->[0 ])<=>_( $b->[0])}map{my@x=(& $x( ),$ _) ;\ @x} split //, "rPcr t lhuJnhea eretk.as o";print;sub _{ord(shift)*($=-++$^H)%(42-ord("\r"))};
Re: Perl 6 feature that scares me the most:
by gmpassos (Priest) on Jun 03, 2003 at 02:11 UTC
    Perl6 is just one of the languages of Parrot, and this is wonderful.

    "The vision for perl6 is more than simply a rewrite of perl5. By separating the parsing from the compilation and the runtime, we're opening the doors for multiple languages to cooperate. You'll be able to write your program in perl6, or perl5, or any other language that there's a parser written for. Interchangable runtime engines let you interpret your bytecode or convert it to something else (e.g., Java, C, or even back to Perl)".
    --Larry Wall.

    So, we can play and create our own language, or just keep using Perl5 on it.

    The bigger problem will be to rewrite the Perl modules at CPAN, specially modules with XS. But just imagine to have CPAN working with Parrot, and Parrot working with different languages!

    Graciliano M. P.
    "The creativity is the expression of the liberty".

      So, we can play and create our own language, or just keep using Perl5 on it.

      I think that it's even better than that. You should be able to write your code in multiple languages that integrate together completely since they're running on the same VM. I worked in an environment that allowed this earlier in my career (more info here) and it's really nice.

      The bigger problem will be to rewrite the Perl modules at CPAN, specially modules with XS.

      An evil solution to this occurred to be last night. Keep Perl5 around, create a Perl5 server, and use RPC/IPC from Perl6 to run the XS code that you need.

      Now, if only there was a language that allowed you to hack stuff like that together really quickly :-)

Re: Perl 6 feature that scares me the most:
by tbone1 (Monsignor) on May 30, 2003 at 12:56 UTC
    Personally, the scariest thing is the video of Larry dancing around on stage like a monkey who took the brown acid, shouting "Give it up for me!!!"

    (Go to http://www.ntk.net/ballmer/mirrors.html if you need context.)

    --
    tbone1
    Ain't enough 'O's in 'stoopid' to describe that guy.
    - Dave "the King" Wilson

Re: Perl 6 feature that scares me the most:
by nite_man (Deacon) on Jun 05, 2003 at 15:59 UTC
    Two things scare me in Perl 6:
    • Perl 6 still is not released;
    • Perl 6 will not sequential of Perl 5.
    In my mind, Perl 6 is a new language with new philosophy ... and it scares me ... slightly ... ;-)
          
    --------------------------------
    SV* sv_bless(SV* sv, HV* stash);
    
      It's just like the CofE, if you can't marry the woman you want change your religion until you can!
Re: Perl 6 feature that scares me the most:
by BrowserUk (Patriarch) on May 30, 2003 at 17:39 UTC

    The feature that scares me the most is... the lack of access.

    Why is the only way into the development process through an antiquated mailing list system?


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


      Because we're a bunch of neo-luddites bent on world domination, and plan on destroying everything electronic once we achieve our goals! Bwahahahahahaha!

      Seriously, it's the least bad of all the options, by a rather significant margin. If you want to just follow around, there are web-based and NNTP archives of the mailing lists, and Sean Burke set up an RSS feed for them. Things are about as open as you can get.

        it's the least bad of all the options, by a rather significant margin

        Hmm. Can you (or anyone) point me at a discussion of what makes it the least bad option? Not necessarially for Perl related stuff, just why mailing lists in general, (which from my perspective have so many inherent problems and literally zero benefits), are the preferred choice. I'm not trying to start a debate *here*. I'd just like to understand the rational.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


Re: Perl 6 feature that scares me the most:
by Petras (Friar) on Jun 30, 2003 at 02:44 UTC
    I'm just scared I'll be dead before it gets released!
    Cheers,
    Petras
    Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats.

    -Howard Aiken

View List Of Past Polls


Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2024-03-19 04:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found