I'm following the list traffic for Perl6 and I'm getting a little worried. . .

Perl was my first real language. I programmed HTML, BASIC, Delphi, and started learning C and noticed how cool perl was. If they rip out the internals as the following suggests, how much will I have to relearn to keep with Perl?

> And I'm *really* against . as an attribute access mechanism :-)

This is my stance as well. 

One thing to remember is that we're ripping the internals out
completely. This means we can redo everything, including the fact that
Perl OO is basically "bolted onto the side" as you mention (it is,
indeed).

I absolutely hate . as well. I always have, even in other languages. The
-> notation is much clearer that "hey, we're doing something with a
member attribute".

If what you're looking for is something like this:

   $foo->bar = "hello";    # ignoring if bar() is a func, or hash, or
???

I don't see why we can't do that. Just rewrite the internals (hey, we're
doing that anyways!). And personally, I'm for this type of thing because
you can say:

   ($foo->bar, $foo->bar2) = split;

Without having to worry "is it a function? hash? array?". And we can
still leave:

   $foo::bar = "scalar";
   @foo::bar = ("array");

For people that want tight control over this stuff.

I agree with Damian. I think the idea of putting two distinct OO methods
in Perl is a very bad idea, at best. Fixing some stuff about the current
mechanism is, however, a very good idea. I think the RFC would be much
better spent if it listed annoyances and proposed fixes, rather than a
second whole OO scheme. Remember, we're trying to *decrease* bloat here.
:-)

I wouldn't worry about breaking stuff at this point. That's a next-stage
decision - benefits vs. costs. We're still in the "developing ideas"
stage. Remember, we're got conversion scripts, FAQs, Camel-4, and lots
of other ways to bring people up to date on changes.

-Nate

I'm not sure I want to relearn Perl and I'm not sure I'll like the new Perl as much as I like this one. I'm sure lwall knows what he's doing, Nate knows what he's doing, Randal is keeping an eye on things and all are very good, but I'm concerned about the effect this rewrite will have on my daily life, on script usage, and the like.

J. J. Horner
Linux, Perl, Apache, Stronghold, Unix
jhorner@knoxlug.org http://www.knoxlug.org/

Replies are listed 'Best First'.
RE: Ripping out Perl internals in Perl6
by coreolyn (Parson) on Aug 14, 2000 at 19:27 UTC

    I'm not going to worry about it, and if it worries you I'd avoid watching that traffic. It'd be like 2nd guessing the doctor's before an operation. This is all discussion and extreemly healthy for the language. The fact is that cleaning up perl is analogous to spring cleaning, you have to make a mess in order to clean it up.

    Let's face it at some point you just have to trust the doctors, even if they are going to take a knife to you :)

    coreolyn Duct tape devotee.

RE: Ripping out Perl internals in Perl6
by athomason (Curate) on Aug 14, 2000 at 20:20 UTC
    You aren't alone. Check out RFC 28. I've been reading the p6-language list, too, and the impression I've been getting is that most people largely agree with you that the language shouldn't be changed as much as extended. Deprecated uses aside, I expect very few well-written scripts scripts will break during the transition, since there's such a huge population of functional scripts out there which the Perl 6 developers can't afford to break for the sake of cleaning up the source.

    That being true, you won't have to learn anything new if you don't want to. But that's true now: very few Perl users know everything about p5 that there is to know. That's one of the great things about Perl: it's learning curve is as steep as you want it to be.

    No matter what, your concern is premature. Until v6 has been proven as a solid platform, there will still be community support for the 5 series. The rough timetables I've seen project completion within about 1 1/2 years, but getting through the bugs for a full overhaul will require some time more. So you can keep using Perl for at least that long without needing to learn a thing.

    Overall, I don't think anyone is going to lose out during the change. There are a lot of good reasons for reimplementing the interpreter, but the language designers seem determined to keep it accessible to its current fans and new users alike.

      Actually, I think it's very likely that lots of code will ``break'' in that it won't run without modification. The key issue is how automatic we can make that modification.

          -- Chip Salzenberg, Free-Floating Agent of Chaos

RE: Ripping out Perl internals in Perl6
by mikfire (Deacon) on Aug 14, 2000 at 23:31 UTC
    I was present for the perl4 to perl5 shift. It was pretty fierce. Lots changed and there was a great wailing and nashing of teeth. In the end, most of the old scripts continued to work ( albeit with strange new warnings and errors ) and there were many docs written to support you translating your scripts from perl4 to perl5.

    The downside of this is I know people who are still saying they need to learn the new perl5 features and still write their code as close to perl4 as they can.

    Wait to see what happens. Experience says you will not have to do it overnight - very few places will immediately upgrade. Other experience says the perl6 developers will try to keep a good balance between breaking needlessly and breaking for the sake of real advances. Most things will be depricated in perl 6.0, and will outright break on perl6.1.

    mikfire

RE (tilly) 1: Ripping out Perl internals in Perl6
by tilly (Archbishop) on Aug 15, 2000 at 10:31 UTC
    So my one real suggestion sank without a trace?

    What can you say when the person suggesting it described it as, "A bad idea whose time has come."? :-)

    For those who don't know, I was the ijit who suggested pluggable front ends so that I could continue to use what was essentially the language I love, but if someone wanted to write a parsing front end for something that looked like Japanese, or Python, go right ahead.

    I still think that this is an inevitable step that some language will have to take with the growing internationalization of computers...

      I suspect that a proper rearchitecture of the language will make pluggable front-ends much easier to do. I suspect that nobody is trying to make multiple front ends because we're too concerned about making just the first one. :-)

          -- Chip Salzenberg, Free-Floating Agent of Chaos

        Easier != possible.

        Not many concessions need to be made internally, but you do need to be able to tag specific things to compile with which front end gets it. Otherwise you cannot reuse code written for one front end in another...

RE: Ripping out Perl internals in Perl6
by knight (Friar) on Aug 14, 2000 at 23:53 UTC
    Keep in mind that "ripping out Perl internals" doesn't automatically imply that the changes will be externally visible. They could, in theory, completely rewrite Perl's internals from scratch and still make the rewrite pass all the existing regression tests...

    Now, to the extent that rewriting the internals gives them the mental freedom to consider an externally-visible change like using "." instead of "->" as an attribute accessor, there's some cause for concern. But given that I believe there's a stated goal for Perl6 to be able to run 95% of Perl5 scripts, I agree with the others about letting the discussions run their course and not worrying too much until we know there's something to worry about.