Re^3: What's wrong with Perl 6?

what makes Perl Perl?

In no particular order:

Perl is context-based, or context-sensitive, or it decides what to do on code depending on in what context I expect my code to be treated (well, in the set of contexts Perl understands)
Perl allows me to code in the *first way* that comes to mind to solve a problem, yet allows me later to improve the solution in *another way*.
Perl makes it easy for me to visually distinguish variable types and interpolate them in string. This is one of things that made me fell in love in my early Perl days.
Perl allows me to have as many namespaces as I like (or need) and arrange them in a nested fashion. I can have them in one file, or in their own files. (I just can't stand to say CGI_Application_Plugin_Authentication_Driver_DBI).
Memory management. Well, this one was actually less relevant for me until I know (by literature) the pain in manually allocating and deallocating memory. So my praise to those who implement Perl in C but can stand the pain :-) (They can, can't they?)
Garbage collection, see also note about MM. I don't care whether it's implemented with reference counting or mark & sweep, or other techniques, as long as Perl provides GC.
CPAN, enough said :-)
Unimitable Regular expression
Optional parentheses, semicolons, and commas as long as they're not required
I love one-liners
Optional return in subs (TheDamian advices againsts it (PBP 9.11), though.)
POD!
Free-form syntax structure
Short-circuit in logical operators
~~(I don't know how to name this)~~ EXPR if STATEMENT and other statement modifiers ~~friends~~ (Updated per blazar below)
Closure, anyone?
Arbitrary (bare or named) block usage
Nested scoping

(Well, I can go on but that's what I can think of now. I could add TimToady's onion speaks but I'm afraid it's too much personal)

If Perl 6 preserves those characteristics, there's no reason to say Perl 6 is not Perl despite the change on the syntax. For example, I don't mind to write @array[1] instead of $array[1]. It's still Perl. And of course I can't mind to write:

given ($some) {
 when 'body'  { 'has to fight' }
 when 'thing' { 'has to give' }
 when 'day'   { 'they will know the truth }
 when 'where' { 'in a very near place to their mind' }
 when 'time'  { 'can only tell' }
 default      { 'yes, there is always a space for default' }
}
[download]

In the mean time, the only thing I can do now is stay with Perl (5) until the day when we do have that better Perl than Perl 5. In the future, we won't call it Perl 6 anymore, just Perl.

Update: now that I remember more, I added number 13 onward.

Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!

Comment on Re^3: What's wrong with Perl 6? Select or Download Code

Replies are listed 'Best First'.
Re^4: What's wrong with Perl 6? by blazar (Canon) on May 14, 2007 at 20:59 UTC
Perl allows me to code in the first way* that comes to mind to solve a problem, yet allows me later to improve the solution in another way.* Completely agreeing and pointing out so to underline the nice way into which you put this concept, which is often implicit! Perl makes it easy for me to visually distinguish variable types and interpolate them in string. This is one of things that made me fell in love in my early Perl days. Hehe, you will certainly fall in love with the twigils for even better visual distinction and the new finely-tunable interpolating rules, although I bet `:qq` will do the job 99.9% of the time. Perl allows me to have as many namespaces as I like (or need) and arrange them in a nested fashion. I can have them in one file, or in their own files. (I just can't stand to say `CGI_Application_Plugin_Authentication_Driver_DBI`). I'm not really sure if I understand what you mean. You are aware that in Perl 5 `Foo::Bar::Baz` bears no relationship to `Foo::Bar`, arent' you? What do you mean with "nested"? Unimitable Regular expression Oh, inimitable but not unimprovable. Indeed Rules smell like they will be impressive. More power and more clarity at the same time! Optional parentheses, semicolons, and commas as long as they're not required Agreed to the highest degree for parentheses. I even find myself doing stuff like `(func $arg)` rather than `func($arg)` in expressions in which I can't avoid them. That's just me, of course. Half hearted about commas, which is often at the end of a multiline list. Not really agreeing on semicolons, except in subs like `sub foo { Very::Simple::code @_ }` [download] (I don't know how to name this) `EXPR if STATEMENT` and friends "Statement modifiers." Closure, anyone? Stay tuned with 6 for more FP-like fun. Personally I'm quite fond of the `[ ]` meta-operator. Nested scoping Do you really see that as particularly perlish? I'm currently a Perl-only kinda guy, but I would rather qualify it as quality typical of most modern enough programming languages that are serious about themselves...	[reply] [d/l] [select]
Re^5: What's wrong with Perl 6? by naikonta (Curate) on May 15, 2007 at 16:19 UTC
Completely agreeing and pointing out so to underline the nice way into which you put this concept, which is often implicit! Actually, I merely rephrased that. I can't recall whom I cite it from and the exact word per word. I'm not really sure if I understand what you mean. You are aware that in Perl 5 Foo::Bar::Baz bears no relationship to Foo::Bar, arent' you? What do you mean with "nested"? Yes I am aware. That's just what I exactly meant by "nested", I can have `Foo::Bar` and `Foo::Bar::Baz` instead of `Foo_Bar` and `Foo_Bar_Baz` (no nested here). I didn't indicate anything between 'nested package name' and 'package relationship'. It's clear that `Foo_Bar` or `Foo_Bar_Baz` or `CGI_Application_Plugin_Authentication_Driver_DBI` are all under the same namespace, while `Bar` is under `Foo` and `Baz` is under `Foo::Bar`. But I do take advantage that I can arrange some classes/packages stucture within a suite of modules. Oh, inimitable but not unimprovable. Indeed Rules smell like they will be impressive. More power and more clarity at the same time! Thanks for the correction :-) That was not a typo, it was a mispell. "Statement modifiers." Thank you, it's indeed in perlsyn. Do you really see that as particularly perlish? I'm currently a Perl-only kinda guy, but I would rather qualify it as quality typical of most modern enough programming languages that are serious about themselves... At least based on my limited knowledge about other languages. I consider it as Perl's strength in providing high-granular variable scoping: file, package, block, inner-block, inner-inner-block, etc. Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!	[reply] [d/l] [select]
Re^6: What's wrong with Perl 6? by blazar (Canon) on May 15, 2007 at 18:54 UTC
Yes I am aware. That's just what I exactly meant by "nested", I can have Foo::Bar and Foo::Bar::Baz instead of Foo_Bar and Foo_Bar_Baz (no nested here). I didn't indicate anything between 'nested package name' and 'package relationship'. It's clear that Foo_Bar or Foo_Bar_Baz or CGI_Application_Plugin_Authentication_Driver_DBI are all under the same namespace, while Bar is under Foo and Baz is under Foo::Bar. But I do take advantage that I can arrange some classes/packages stucture within a suite of modules. Expect great improvements in that area too, with 6! Oh, inimitable but not unimprovable. Indeed Rules smell like they will be impressive. More power and more clarity at the same time! Thanks for the correction :-) That was not a typo, it was a mispell. Which correction? I didn't notice any typo nor misspell: I was agreeing once again with your point and "improving" it in a 6-enthusiastic fashion...	[reply]
Re^7: What's wrong with Perl 6? by jonnyfolk (Vicar) on Sep 19, 2007 at 21:42 UTC