|
in reply to Re: How to Sell Perl 6
in thread How to Sell Perl 6
The rhetorical question that I pose to you is: what makes it less than desireable for you? I'm sure that there were those who said the same during the Perl4 -> Perl5 migration; arguments that we see today as either crusty or silly. I'll admit that I'm not up on Perl6 at all. I see no reason to learn a language that won't see the light of day for a couple of years. Heck, I don't even know that the specification is done. So part of this question is asked in ignorance. What kind of code that you have written today breaks tomorrow?
|
Re: How to Sell Perl 6
by Abigail-II (Bishop) on May 04, 2004 at 12:26 UTC
|
What kind of code that you have written today breaks tomorrow?
- I use hashes, and I index in them.
- I use subroutine/method calls on the LHS of binary operators.
Almost all of the code I write uses one or both of the items
I mention. All of that either becomes invalid, or changes meaning.
my %hash;
$hash {key} = "foo"; # Illegal in Perl6, even after s/\$/%/
my $str = "99 miles to L.A.";
print length ($str) + 1; # Prints 17 in Perl5, 3 in Perl6.
This is very basic stuff to write, which I do many, many times in code (and I guess many people use hashes, and use subs/methods in expressions).
Abigail | [reply]
[d/l] |
|
|
| [reply] |
|
|
After reading through Apocalypse 12, I finally started to get a handle on Abigail-II's concern, but I can't buy the argument. The vast majority of Perl code that I see does not use whitespace in quite the way Abigail-II does:
%hash {foo} = 'bar'; # illegal in Perl 6, as Abigail points out
# versus:
%hash{foo} = 'bar'; # what the rest of the world does
Admittedly, some people might find this to be a minor annoyance. Further, sometimes programmers do what Abigail does when trying to format a bunch of variables neatly. However, you can get around that if you really need to (IIRC):
%hash .{foo} = 'bar'; # note the dot
This minor inconvenience seems a small price to pay for the benefits we gain. Many of those benefits, in fact, are involved with giving Perl a powerful, robust OO model. This is one of Abigail's main complaints about Perl 5 -- and a reasonable one at that -- so I'm rather suprised that there's not more acceptance of the minor inconvenience. That's why I'm a bit confused about what Abigail's objections really are because I can't see this as being a serious issue.
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
| |
|
What kind of code that you have written today breaks tomorrow?
- I use hashes, and I index in them.
- I use subroutine/method calls on the LHS of binary operators.
Perhaps I'm mistaken, but looking at your examples, aren't they both aspects of the whitespace-between-tokens issue that was discussed here recently?
Furthermore, I have been under the impression that old code was going to be parsed under a Perl-5-compatibility mode that presumably would use the old whitespace rules... Am I mistaken, or will this allow your old code to still work without change?
| [reply] |
Re: Re: Re: How to Sell Perl 6
by dragonchild (Archbishop) on May 04, 2004 at 12:22 UTC
|
Although I disagree with his conclusion, I have to agree with his statement. Most of my code will break under Perl6, too. The Perl5 -> Perl6 ease-of-migration stuff is for the simpler uses of Perl. Once you start getting into symbolic references and symbol table manipulations and beyond-the-surface objects ... this isn't going to migrate. And, I know that if I'm doing that stuff, Abigail-II is definitely doing it.
Additionally, every single bit of XS is going to have to be rewritten. Granted, it gets to rewrite it in Parrot which is much nicer, but it's still a big task. Ponie may or may not help this part.
------
We are the carpenters and bricklayers of the Information Age.
Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose
| [reply] |
|
|
Rumor control.
The point of Ponie is to provide an implementation of Perl on Parrot. Large documented pieces, like symbolic references, symbol table objects and so on are all going to be supported and will migrate just fine. If you're worried about that breaking, don't. And when you have Ponie, the Perl6 -> Perl5 compatibility layer will be, "just run it in Ponie".
The problem comes with corner cases. For instance you lose timely destruction mechanics. My ReleaseAction is an extreme example of something that breaks. There will be inevitable subtle changes that break various JAPHs. What will change, where, nobody can predict. But if you're sticking to stuff (other than timely destruction mechanics) which is in Perl's test suite, then you should be fine.
About XS, there as well you may be in luck. The Ponie effort has a plan to support XS out of the box. I trust that this will work. So if you're using XS stuff that only stuck to documented interfaces, then you should be fine. If you're using XS stuff that went mucking around with Perl internals, you're probably out of luck. However any major piece of Perl software, for instance DBI, will be considered a priority to support, and inevitably you will see fixes to one or both sides to get them to run.
So you'll have problems timely destruction mechanics, some obscure and undocumented corners to the language, and smaller XS projects that didn't stick to the API they were told to. Otherwise Ponie should mostly Just Work.
| [reply] |
|
|
