Re: Re: Re: Synopsis 3 is out

[tachyon]

A large market for Perl 6 *is* existing Perl 5 users. The quesion is this. If you have to learn a whole lot of new operators is it easier to learn a new language or to learn perl 6?

I like javascript as a language limited though that may be. I hate actually working with it because, like many hacks, I have in the past had to make two almost similar languages (JScript and Javascript/Live Script) work. The major problem is that they are just similar enough to trick you.

Perl 6 will face this hurdle. There is a lot of perl 5 code and there are a lot of perl 5 coders out there. When/if perl 6 arrives there will be concurrent perl5 and perl6 code which is rather similar to the J(ava)script issue. Sure you can say use perl5 in perl6 but this is very similar to saying I will only code JS for IE.

Are there any examples of languages that have rather radically changed the API in the past? By radical change I mean breaking almost every existing progam more complex then hello world.

[TimToady]

Those are all good questions, and there's no perfect answer for any of them. On the subject of new operators, we try hard to look at how it will fail if people use the wrong operator. For example, in the case of changing "->" to ".", it's almost certain that you'll get a parse error if you accidentally use Perl 5's concatenation operator accidentally. In other cases, such as the case of changing "|" and "&" from bitops to junctional ops, you won't get a syntax error, but we felt that the new ops will be used so often that people will learn them rapidly.

Another thing going for us is that there will be a Perl 5 to Perl 6 translator, so it'll be pretty easy to learn the correspondences just by feeding your Perl 5 code in and seeing what comes out. Many awk programmers originally learned Perl by feeding their programs through a2p, for instance.

As for the confusion of switching back and forth, those of us on the Perl 6 design team have been switching back and forth for some time now. Yes, we do make occasional mistakes. And every time we do, we feed that back into the design process, and ask ourselves whether there was a way to prevent that mistake either by making the Perl 6 features fail-soft to the Perl 5 interpretation, or by differentiating the features further so that it's easy to keep them straight in your head.

But when it comes right down to it, we can't solve all these problems by design. We accept that there will be a certain amount of confusion over the short term. We also accept that a few people will abandon Perl for other languages. But we're not optimizing for the short term here. We're trying our durndest to optimize for the long term.

There's a very interesting article in the latest SciAm about the people who are "maximizers" vs. the people who are "satisficers". The essence of Perl is that it rewards you regardless of whether you're a maximizer searching for the best way, or a satisficer just looking for some way that's "good enough". This will not change in Perl 6.

And when it comes down to it, I don't actually care whether another language has tried it in the past, or whether it has succeeded or failed. I only know that my brain has this sweet spot in it where, if I'm happy with Perl 6, a lot of other people are going to be happy with it too. That's all I've got to go on, and sheer determination, and the help of a lot of other people who share that determination.

[shotgunefx]

I wonder how much you can change perl and have it still be Perl. I've got mixed feeling about Perl6. There's things I'm really looking forward to that are difficult or impossible now, but some of the semantic stuff, well I just don't know. Personally I'd like something to see something like Damian's Perl5+i