Note: this is not intended as a serious question, just a little fun!
Q: Given that perl6 appears to be *very* different from perl as we know (and love) it, should it be called perl6 or something else?, please add your suggestions or vote!
- perl6
- perl++
- turbo perl
- perlthon
This is not a Signature...
your code, your rules.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.
I'm not really a human, but I play one on earth. flash japh
Martin
Or even this Vista - who have a horrible programming language called Vista-4GL.
--
Oh Lord, wont you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, wont you burn me a Knoppix CD ?
(Missquoting Janis Joplin)
NG = Next Generation if you like it, or No Good if you don't.
In any case, I agree that it should not be called Perl 6.
Remember: There's always one more bug.
TOS = The Original Series, for all you non-Trekkies out there.
CountZero
"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
Not sure, but ... is the difference between Perl5 and Perl6 really that much bigger than the one between Perl4 and Perl5 was? I think it's actually smaller, but that's just me.
In any case, maybe they has this same disscussion then as well.
This is not a Signature...
is the difference between Perl5 and Perl6 really that much bigger than the one between Perl4 and Perl5 was?
Yes.
Much Perl 4 code still runs unmodified on Perl 5. While much of the internals changed, the language did not really change much. It got new features, but almost none of the existing language was changed.
Perl 6 code is always different from Perl 5 code. There is a different operator precedence table, operators themselves are different, it lacks some (deprecated) Perl 5 features, and even has a different vocabulary.
From 4 to 5, most of the source was rewritten. From 5 to 6, all will.
And it was about time.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
You are and are not right. Yeah you can run Perl4 scripts by perl5 while you ... well, they all say you'll be able to run Perl5 scripts by perl6 ;-) But conceptually I think there was a huge gap between Perl4 and Perl5. You've got real references, real datastructures, real lexical variables, objects ... an improved shell became a fullblown general-purpose language. So yes, you'll get some new operators, you get different precedence (ack?!?), you get some more OO features, you get what non-perl-people call function prototypes, you get a brand new source tree, but ... well, it's hard to compare :-)
they all say you'll be able to run Perl5 scripts by perl6
For that, plain old Perl 5 is used, albeit automatically. This is a feature of the implementation as it is planned, not of the language.
But conceptually I think there was a huge gap between Perl4 and Perl5. You've got real references, real datastructures, real lexical variables, objects
Those were all additions to the existing language. Yes, it was a big step, and there was a huge gap in between. However, the change was almost fully backwards compatible. It's like changing your house by adding a few floors on top of it. Perl 6 on the other hand will redesign the bottom levels as well, because the Perl 1..5 house was built with Jenga blocks. I think the change from 5 to 6 is more than a huge gap; I think a new language is being designed.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
I agree with Jenda here, actually. Whether the code written for the older version runs on the newer one is not really the determining factor in my mind.
What counts is that idiomatic Perl 5 is very different from idiomatic Perl 4 in architecture, whereas idiomatic Perl 6 wont be nearly as different from idiomatic Perl 5, at least in everyday code that does not strain against the limitations of Perl 5 too hard. Perl 4 was really more of a scriptable tool, whereas Perl 5 is a serious language.
Perl 6 does not really reform the way systems written in Perl are to be architectured, it just makes these architectures easier to implement by putting various and sundry premanufactured, well-designed nuts and bolts into the language, so you dont have to spend so much time building them all yourself.
In syntax, it is much bigger departure from Perl 5 than Perl 5 was from Perl 4; but in spirit, Perl 6 is much closer to Perl 5 than Perl 5 is to Perl 4.
Makeshifts last the longest.
What counts is that idiomatic Perl 5 is very different from idiomatic Perl 4 in architecture, whereas idiomatic Perl 6 wont be nearly as different from idiomatic Perl 5, at least in everyday code that does not strain against the limitations of Perl 5 too hard.
Do we know enough about Perl 6 code to say what's going to be idiomatic or not?
Perl 6 does not really reform the way systems written in Perl are to be architectured, it just makes these architectures easier to implement by putting various and sundry premanufactured, well-designed nuts and bolts into the language, so you dont have to spend so much time building them all yourself.
I wonder if we'll see an equivalent of the the "people writing C in C++" problem in Perl 6. While there isn't a huge amount in Perl 6 that's impossible in Perl 5, there are certainly a lot of things that are much easier - including things that are fairly marginal in the Perl 5 world like roles, design by contract, etc.
Combine this with things like macros that don't have any Perl 5 equivalent then I suspect (hope indeed) that Perl 6 solutions are going to be as different from Perl 5 ones as the Perl 5 ones were from Perl 4.
Do we know enough about Perl 6 code to say what's going to be idiomatic or not?
I think the 42_000+ lines of existing Perl 6 code are a nice show case, showing that even without working roles support, idiomatic Perl is already different. This is an old count of Pugs' tests and examples, and doesn't include the brand new lrep engine yet.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
Note that I was talking about architecture, not individual constructs. Those will indubitably change dramatically. But Perl 6 does not introduce new data structures. In accordance with the famous Show me your tables and conceal your flowcharts qoutation, I believe P6 code wont be architected in fundamentally different ways from P5 code. If, say, Perl 6 was to introduce a tree data type alongside scalars, hashes, arrays and functions, then I could see how things could drastically shift around. Compare to how Perl 4 has no references, which means that the architecture (architecture, not syntactical expression) of an ideal Perl 4 solution is very, very different from an ideal Perl 5 one.
Makeshifts last the longest.
But Perl 6 does not introduce new data structures
Well, apart from P6opaque, properties, classes (as first class objects), rules, continuations, Complex, Bit, arbitrary precision float/integer types, Rat, Inf, NaN, Signatures, packages (as first class objects), modules, grammars, lazy lists, control exception, tokens, Bool, polymorphic types, structs, Junctions, Enums, ...
Not following Perl 6 development in detail some of these might be wrong, but I've probably missed some too :-)
At to be honest - with my Lispish code-is-data hat on you can look at traits, macros, types/roles as data instead of code too.
In accordance with the famous Show me your tables and conceal your flowcharts qoutation, I believe P6 code wont be architected in fundamentally different ways from P5 code. If, say, Perl 6 was to introduce a tree data type alongside scalars, hashes, arrays and functions, then I could see how things could drastically shift around.
Let me pick two examples.
I know that if I start developing in Perl 6 that I'm likely to take advantage of the new OO frameworks ability to do multiple dispatch when I think that it would make things simpler. In Perl 5 I'd probably do double (triple, whatever) dispatch instead. To me that's a fairly large architectural difference.
Now that I have grammars/rules and can extend the Perl language itself I'm much more likely to build Domain Specific Languages on top of Perl (so that they're really just Perl with extra syntax) rather than with Perl (where Perl just parses and interprets a completely separate language.) To me that's a very large architectural change.
As ever YMMV :-)
What counts is that idiomatic Perl 5 is very different from idiomatic Perl 4 in architecture, whereas idiomatic Perl 6 wont be nearly as different from idiomatic Perl 5
Really? Many of the (already frowned upon) idioms are abstracted into functions or operators. This takes away a lot of the (in)famous line noise.
Perl 6 does not really reform the way systems written in Perl are to be architectured
Really? Of course, you can still use the same architectures you used in Perl 5 (as you can still use the architectures you used in Perl 4), but there's a wealth of new paradigms entering the language, with roles hopefully shifting around the idiomatic OO landscape forever. That's just one example, but there are many more architectural possibilities new in Perl 6. Many of which go further than the addition of references, namespaces and lexical variables. (It's not entirely accidental that I name three features that PHP does not have. People manage to use PHP and Perl in much the same way, while PHP lacks these things. Try, to use roles, hyperoperators, or environmental variables, in Perl 5 or PHP...)
but in spirit, Perl 6 is much closer to Perl 5 than Perl 5 is to Perl 4.
Agreed, but then, so is Ruby, which is fortunately not called Perl.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
The OO stuff is what I precisely was referring to when I said Perl 6 will just make things a whole lot easier to build by providing default mechanisms that would have to be built manually Perl 5. Class::C3, Class::Trait, NEXT: all built in or easy to achieve, and more powerful and flexible. But you do have all of those in Perl 5 in some form it just takes way more effort, which most people are unwilling to expend (hardly surprising).
Really, if you think the Perl 6 we have now should have been called something other than Perl 6, then what kind of language should have been called Perl 6?
Makeshifts last the longest.
Really, if you think the Perl 6 we have now should have been called something other than Perl 6, then what kind of language should have been called Perl 6?
That's a very interesting one, but only answer I can honestly give is that Perl's time is up. It has been for a few years. Perl 6 could be a rewrite of Perl 5 with some extra features, for those fanatics who keep using the language.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
But hey, that just frees up the perfectly good four-letter word "Perl" for other uses. :-)
Logically, the answer is simple. We'd have to name it 'Swine' (Perl before swine, after all)...
Pfarcically Excruciatingly Reactionary L... it's not done yet? oh.
Note: This post is completely in jest. I truly DO value the hard work all of those who really DO contribute put into Perl6 and FreeBSD and all other open source projects I use and love!
Don Wilde
"There's more than one level to any answer."
I asked the same question many moons ago. It got some interesting replies.
Considering that Perl6 will run Perl5 code directly, I don't think the very different moniker really works. Perl6 is the next version of Perl after Perl5 -- I don't see why it should be a different name.
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
Perl6 will run Perl5 code directly
The implementation of Perl 6 will probably have some heuristics for detecting Perl 5 code, and can (if compiled with support for it) invoke an (external or embedded) interpreter for it. However, the language Perl 6 is not compatible with Perl 5.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
I noticed TheDamian's recent linux.conf.au 2006 talk in Dunedin was titled:
Sex *and* Violence: Technical and Social Lessons from the Perl 6 Development (or why Larry gets the colon and we should not have called it Perl 6)However, I don't know what he suggested it should have been called or why he asserts it shouldn't have been called Perl 6. If any monk attended the talk, please let us know. :-)
I found two links describing the talk:
If anyone knows of better talk links or slides, please let us know. Ta.- Dromedary (one hump camels)
- Bactrian (two hump camels)
- Pteriidae (the Oysters that produce pearls with value)
- Nacre (mother-of-pearl)
- Black Perl
- Perl of Power (from D&D)
- PoP (Perl on Parrot)
- Perl RFC Forever (ala Duke Nukem)
- Marble Madness!! =:-)
- LAMPost
- P++
scalar list object programming
to conch
comprehensively orchestrated neo computational hybrid
or something ... :)
Allan
A picture is worth a thousand words, but takes 200K.
*chirping crickets*
What, it's being used already? Who knew?
--
tbone1, YAPS (Yet Another Perl Schlub)
And remember, if he succeeds, so what.
- Chick McGee
Gives Perl6 a claim on the mysteries of the universe and the soul...
Also, depending on the number of bugs in any given piece of code, it can be Good Juju, Bad Juju, or BAD Juju (goes either way to the extreme...inflection required for meaning). BAAAAAAAD Juju is the best, while "BAD JUJU!" is the worst.
PerlPants
Simply because resumes and job postings would become that much more amusing ...
PPerl
Who knows what that first "P" is...which adds one more letter to the mystery that is P E R L.
What
Nobody knows for certain anyway and it will be great fun in conversations.
Who knows what that first "P" is...which adds one more letter to the mystery that is P E R L.
exists, and the first "P" stands for persistent.
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
Or, we could just call it "42".