|
citromatik has asked for the wisdom of the Perl Monks concerning the following question:
Hi monks,
Recently I've been messing around with Pugs and Perl 6. AFAIK, Perl6 is not only an upgrade of Perl5, but a new language that starts from Perl 5 but that has a (notably) modified syntax and a bunch of new features. Like Corion said recently: The main thing wrong with Perl 6 is the name. It poses as a version upgrade like from Perl 4 to Perl 5, but it's a completely different language with largely incompatible syntax.
(For those that are not familiar with Perl 6 syntax, here is a small example of code extracted from Perl 6 documentation:)
#Example1
use v6-alpha;
method render ($x=1,$y=1,$z=0){
for @.filter (@.items){
say .draw (:$x, :$y, :$z);
}
}
#Example2
class Dog is Mammal does Pet {
my $.count where 0..*;
has $!brain;
has &.vocalize = &say;
has $.name is rw = "fido";
has $.fur handles Groomable;
has $.tail handles <wag hang>;
method owner () handles s/^owner_// {...}
More examples can be found in the Perl 6 cookbook
In this thread there is an interesting discussion about Perl 6
I noticed in the documentation that one can mix Perl 5 and Perl 6 code in the same script, for example:
use v6-alpha;
# ...some Perl 6 code...
{
use v5;
# ...some Perl 5 code...
{
use v6-alpha;
# ...more Perl 6 code...
}
}
Or even use Perl 5 modules in Perl 6 scripts, like:
use v6-alpha;
use perl5:DBI;
use perl5:Template
... ## Rest of Perl6 code
Does this mean that all the modules available from CPAN for Perl 5 will be available for Perl 6 too without modification? This seems great for those of us that already know Perl 5, but if this is the case, when Perl 6 becomes available, those who are new to Perl and want to learn it, will have to learn 2 different languages instead of only 1 (Perl 5 + Perl 6), or they won't be able to understand all the Perl 5 stuff that is already done (and still in use in Perl 6 scripts). Am I completely wrong?
Surely, mixing Perl 5 and Perl 6 code will be a nice thing for those who already use Perl 5. But won't be a mess for those learning the basics of Perl? (I'm afraid we will have to explain many (more) times the difference between $var[0] and @var[0])
citromatik
|
Re: Perl 5 <-> Perl 6 compatibility: a benefit or a mess?
by Util (Priest) on Jun 18, 2007 at 17:29 UTC
|
Does this mean that all the modules available from CPAN for Perl 5 will be available for Perl 6 too without modification?
All the modules? "All" may be unrealistic, but a percentage in the high 90's is what I am expecting. The most valuable thing about Perl is all the code already written on CPAN; it will *not* be abandoned. Perl 5 may not be able to use Perl 6 CPAN modules as of 5.8, (the current use v6-alpha is deep non-generalizable black magic, I think), but I *hope* 5.12 (the version with Parrot underpinnings) will run Perl 6 modules, and I *expect* and *depend* on Perl 6 to run Perl 5 modules on day one of its release.
...will have to learn 2 different languages instead of only 1 (Perl 5 + Perl 6), or they won't be able to understand all the Perl 5 stuff that is already done (and still in use in Perl 6 scripts).
Just because you *can* include inline Perl 5 code, does not automatically mean you *must*, or even that you *should*.
A new Perl programmer, trained only in Perl 6, tasked to write only new code, should not need to know or use anything of Perl 5 syntax,
except perhaps to understand example code embedded in the POD of Perl 5 modules on CPAN. Likewise, some people programming Perl 5 today will have the option of doing maintenance of just Perl 5 code for the rest of their careers; businesses hate re-writing bread-and-butter code.
I expect that the mix-and-match coding of Perl 5 and 6 in a single program will mainly be used by programmers who *already* *know* both 5 and 6, and will only stay mixed during a transition of the program to 100% Perl 6. The inline mix-and-match ability, if actually delivered in Perl 6 1.0, will be invaluable when converting a program of any significant size; piecemeal refactoring with incremental automated testing will go so much smoother than all-in-one-shot rewrites.
Also, I encourage you to study the final section of the first Exegesis. It focuses on how much of Perl 6 is *unchanged* from Perl 5, if you do not use the new optional features.
Am I completely wrong?
Not *completely*; there will be time lags in training, mis-matches in skill sets, bad decisions on partial re-writes in some IT departments, and many other 5=>6 issues. Those are all worth giving thought, so that guidelines can be written for those who will be converting their code over time.
None of that is reason to remove the capability to do inline mix-and-match coding. The Perl TIMTOWTDI philosophy guides us; better to provide too much function than too little.
| [reply]
[d/l] |
|
|
Just a random moose...
Why should a perl 6 implementation not be able to run all perl 5 modules?
After all it will have to have a perl 5 interpreter linked to the core (because an eval($perl_5_code, :lang<perl5>); could always occure somewhere), so if the bridge between 5<->6 is good, there shouldn't be a problem.
Or is it that hard to build the 5<->6 bridge?
| [reply]
[d/l] |
|
|
For the same reason Perl-5-on-Parrot has (or will have) problems running some Perl 5 modules: XS.
Some modules are partially implemented in C, and are hooked into Perl code via a combination of C macros and Perl pre-processors collectively called XS.
This process relies on particulars of perl internals that pure Perl code (and pure Perl programmers) never need be aware of. Those particulars are monumentally different in Parrot.
Since the macros define a sort of API to the perl internals, replacement macros should be able to be written to create a work-alike interface into Parrot. Last time I checked, this was expected to be the major sticking point for the someday-release of 5.12, the first official Perl 5 to run on Parrot, with the old virtual machine internals ripped out and left on the trash heap. This re-macroed API is a tough job, but looks definitely do-able.
Unfortunately, some of the C code in some of those modules does *not* use the API macros; the programmer instead wrote the C code to *directly* communicate with the perl internals. This may have been for performance, ignorance, or the absence of an API macro at the time of the writing. It is these modules that are the true thorns that keep anyone from promising 100% compatibility with Perl 5 modules. Such code will require changes that only the original author might be qualified to make. Such code will also be very difficult to identify by inspection; after the replacement API macros are written, you will only know you found a XS thorn when it fails to pass its tests. Those lacking tests will only be spotted when they fail to *run* correctly.
Caveat: I've not been deep in the Parrot guts for over a year; any of this could be *completely* wrong.
| [reply] |
Re: Perl 5 <-> Perl 6 compatibility: a benefit or a mess?
by doom (Deacon) on Jun 19, 2007 at 00:36 UTC
|
In essence, I think you're correct: embracing multiple languages is something of a mess. It's the kind of mistake that programmer's are prone to, they're inclined to think that supporting multiple languages is just a technical problem, when really it's also a social problem, and having to deal with code bases that are mixtures of perl5 and perl6 will tend to produce subdivisions in the perl community (which already, to some extent, has to deal with a certain amount of sub-specialization in C, SQL, HTML/XML, and so on).
All of that said, though, it's worth remembering that perl6 really is intended to seem like "perl", so the cost of context-switching between the two is likely to be lower than it would be even for languages like Ruby or Php (which have clear perl roots). And stasis isn't really an option for programmers: even if we all decided that perl6 was a bust, and we all stuck with perl5 for the foreseeable future, there would still be a constant stream of new modules to become familiar with and so on.
I would venture to guess that switching between perl5 and perl6 code will be easier to deal with than, say, switching between Class::MethodMaker and Class::InsideOut code.
| [reply] |
Re: Perl 5 <-> Perl 6 compatibility: a benefit or a mess?
by eric256 (Parson) on Jun 18, 2007 at 17:02 UTC
|
You don't have to know C to use compiled modules, so we can just treat perl5 modules are compiled and magic boxes. ;) The documentation for them will have to be updated/converted or at least a cheat sheet for how to use perl5 code and make it perl6.
| [reply] |
Re: Perl 5 <-> Perl 6 compatibility: a benefit or a mess?
by Bro. Doug (Monk) on Jun 18, 2007 at 16:35 UTC
|
Esteemed monks,
It seems to me that this is sort of a mess, though understandable and, in the end, good for us. True, a perl programmer beginning now will be in a tight spot, but backwards compatibility is a must. Also, we need to move forward and keep up with the best technology.
Unfortunately, sitting still in a permanent code freeze isn't a viable option. There are plenty of things we'd all like to see fixed, and Perl6 is just another attempt at this. As the code changes, we keep up. Being able to tag code as being perl5 is a nice feature, however, when we just can't get Stuff to work.
If you're new to Perl, I'd say start with 6. There are plenty of us around to help you with perl5 integration should it become a necessity. In a couple of years, 6 will be the norm. In a few years, most of the old perl5 code won't be used anymore except in legacy systems.
This, of course, is just my opinion.
Peace monks,
| [reply] |
Re: Perl 5 <-> Perl 6 compatibility: a benefit or a mess?
by Zen (Deacon) on Jun 18, 2007 at 16:44 UTC
|
I was under the impression perl 6 couldn't run all (some) perl 5 modules/scripts, and that there would need to be many porting efforts. Has this changed?
FWIW, depending on your job description, knowing perl 5 is never a bad thing. (Opinion incoming): It's the best way to tame *nix and many dinosaur *nix systems. | [reply] |
|
|
Well, Pugs has some issues with running Perl 5 modules atm., but that functionality is specced, so ever "official" implementation has to implement that as well.
And we do need that feature in order to get Perl 6 adapted quickly.
I don't think that there will be too many not-ported perl 5 modules used in Perl 6 for a long time, because porting Modules from 5 to 6 is a good way to learn Perl 6.
| [reply] |
|
|
Well, Pugs has some issues with running Perl 5 modules atm., but that functionality is specced, so ever "official" implementation has to implement that as well.
I don't know, but last I heard... wasn't $Larry working on a 5-to-5 translator which should be the basis for a 5-to-6 one? IIRC he stated that the goal was to have it working 90% of the times, doing it right also 90% of the times, or something like that.
Re CPAN, I quoted it before but I'm doing it again here: "CPAN is my programming language of choice; the rest is just syntax." (Audrey Tang)
| [reply]
[d/l] |
|
|
Nah -- major version often means revolutionary change
by Moron (Curate) on Jun 19, 2007 at 13:39 UTC
|
The idea of what is a major version and what is a minor version has changed over time. A major version for most software products has always been necessary for revolutionary developments in the language. Minor versions used generally to be invisible to the public until the 1980s. To take a couple of examples from history ... Fortran 77 converted Fortran IV from a fixed format punched card dinosaur into a free format new one with all the block structured bells and whistles of Algol and later Pascal. A particularly interesting thing happened to Sybase version numbering. It went from 4.9 to 10 and then 11, because the minor versions were becoming major and the minor-minor needed to be upgraded to just "minor". 10 was a rewrite of the engine whereas 11 introduced revolutionary new language features such as declarative referential integrity.
Backward compatibility may be commonly found for compiled languages (C programs compile under C++ and Fortran IV under Fortran 77) but this tends no longer to be true for some major SQL versions. But to say that you need 100% backward compatibility or a new language name. I don't see any precendent for that. On the contrary, the most famous interpreted language of all, BASIC, makes Perl 6 look like a Paragon of compatibility.
The original Dartmouth BASIC programs wouldn't scan (parse) under any of the minicomputer implementations of the 70's and 80's. In particular, by the time all the PDP-11 BASIC+ BASIC+2 and BASIC-11 (which required $ on the end of strings and % on the end of integers) were assimilated into the Borg (a.k.a VAX BASIC), where variables could be declared and, like Fortran 77, lots of block structured gadgets appeared, you had something a Dartmouth BASIC programmer wouldn't even recognise from one word to the next. (Update: and I might as well ignore VB as not really trying to be a compatible derivative of BASIC!)
Update: note that I couldn't find a really analogous unix interpreted language - hence all the VAX references, but unix didn't have a "killer" interpreter like VAX BASIC - that is until Perl came along!
On that basis and in conclusion, I feel that Perl 6 doesn't really set any new precedents by not offering 100% upward-compatibility and that BASIC sets the precedent the other way!
__________________________________________________________________________________
^M Free your mind! | [reply] |
Re: Perl 5 <-> Perl 6 compatibility: a benefit or a mess?
by Anonymous Monk on Jun 18, 2007 at 20:50 UTC
|
It is definitely a mess. Even with Python, a language that's much more modern, between its current stream and the future P3K stream, there is a need to break the backward compatibility. To entertain P5 in P6, the penalty will become clear very quicklya, and it certainly makes P6 much less attractive in lots of people's eyes.
On the other hand, to look at this from a higher level, the opportunity of success is not very good for Perl 6. With Python and Ruby around, less people will appreciate P6, which is similar and less sophisticated. P6 is taking too long to deliver, and the world does not stop and wait, the moment P6 comes out, it is probably obsolete already in many ways.
| [reply] |
|
|
With Python and Ruby around, less people will appreciate P6, which is similar and less sophisticated.
I'm exceedingly curious as to how Ruby and Python are more sophisticated than Perl 6. For one example, Perl 6 right now (in both the Pugs and Perl 6 on Parrot implementations) has working Unicode support, which puts it well beyond what Ruby can claim. I don't believe the Perl 6 on Parrot implementation quite has lambdas working (but it's close)... but even Perl 5 supports those better than Python does.
I could go on, but neither is an exotic feature by any means. (If I were sneaky, I'd ask "Can Python or Ruby catch automagically declared variables yet?")
| [reply] |
|
|
