Ugh

TorgoX on 2004-05-07T00:48:58

Dear Log,

So, someone tell me something happy about Perl 6 and/or Ponie. Last I heard, it was looking like millions and millions of cubic meters of vaporware.


Mixed Blessing

chaoticset on 2004-05-07T01:08:41

There'll be plenty of time to learn it...

Patience

zatoichi on 2004-05-07T02:10:05

If you follow its development you would know that it isn't going to be anytime soon. Not this year definately.

Like Any Other Public Project...

chromatic on 2004-05-07T02:25:33

If one out of every ten people who complained about it actually did something useful, it'd be a lot further along.

(Yes, I realize that I'm making a huuuuge assumption that chronic complainers are remotely capable of doing something useful, but I'm an optimist that way.)

Re:Like Any Other Public Project...

TorgoX on 2004-05-07T03:05:06

Nessunpossible.

Even though it's not here yet...

Damian on 2004-05-07T03:24:02

...it's already having a great effect on Perl 5 development. For example, in the deprecation of pseudohashes, and in the incorporation of the // operator in 5.10.

And useful (and usable) parts of Perl 6 *are* available already – in the form of Perl 5 modules like:

  • Perl6::Parameters
  • Perl6::Interpolators
  • Perl6::Currying
  • Perl6::Gather
  • Perl6::Placeholders
  • Perl6::Form
  • Perl6::Say
  • Perl6::Slurp
  • Perl6::Export
To say nothing of the way that my own on-going struggle to implement the Perl6::Rules module is uncovering opportunities for use to improve the robustness of the Perl 5 regex engine.

And, as if all that isn't enough, the Perl 6 development effort has siphoned many of the more...err..."exuberant" folk from the P5P list, and thereby allowed P5P to function much more effectively. ;-)

Perl 5 took nearly a decade to design (if you consider Perls 1 through 4 to be prototypes). Perl 6 won't take that long, even though it's far more than twice as powerful. But it *does* take an enormous amount of time to get all the decisions right. And even more time to get them harmonious.

We understand how frustrating that delay can be. It frustrates us too. But any project that's being designed and implemented almost entirely by unpaid volunteers, and worked on nearly exclusively in their spare cycles, is inevitably going to be executed at low priority and subject to endless interrupts.

Re:Even though it's not here yet...

jordan on 2004-05-07T13:57:21

  • Perl 6 won't take that long, even though it's far more than twice as powerful.

Could you nail this down for us? Is Perl 6 180% more powerful or 400% more powerful than Perl 5?

Or are linear relationships of power difficult to quantify at this point? Could it be that the power of Perl 6 is ever increasing, exponentially proportional to the distance of its first release date?

It must be frustrating indeed to have to meet the goal of producing a language that is "far more than twice as powerful" as Perl 5, seeing that Perl 5 is, in itself, so powerful and that there are people busy working every day to increase the power of Perl 5. No wonder it's taking so long!

Re:Even though it's not here yet...

Damian on 2004-05-07T20:44:46

It must be frustrating indeed to have to meet the goal of producing a language that is "far more than twice as powerful" as Perl 5

That was never a "goal"; it's merely an observed outcome.

And, of course, it *is* nonsensical to try and nail down the exact increase in "power". But given that Perl 6 adds features like:

  • hyperoperators
  • junctions (superpositions)
  • coroutines
  • strong typing
  • subroutine overloading
  • multiple dispatch
  • declarative parameter lists
  • named parameters
  • currying
  • properties and traits
  • opaque classes
  • hierarchical construction and destruction
  • distributive dispatch
  • delegation
  • named rules
  • grammars
  • overlapping and exhaustive matching
  • named captures
  • parse-tree pruning
  • new operators
  • user-definable operators
  • macros
  • submethods
  • chained comparisons
  • a switch statement
  • full OO exception handling
  • state variables
  • polymorphic inner classes
  • universal aliasing mechanism
  • multi-versioning support
  • module meta-data and introspection
  • lexical exporting
  • declarative exporting
  • new aggregative I/O commands ('say' and 'slurp')
  • POD introspection within programs
  • autotopicalization in numerous contexts
  • smart-matching
  • regex matching against input streams

it doesn't seem entirely unreasonable to describe the power available to the average user as having more than doubled.

Nevertheless, thanks for pointing out the absurdity of trying to quantify such improvements.

Re:Even though it's not here yet...

jordan on 2004-05-08T01:28:36

  • Nevertheless, thanks for pointing out the absurdity of trying to quantify such improvements.

You're welcome.

I am, however, reminded of a quote that might be appropriate:


A language that doesn't have everything is actually easier to program in than some that do. - Dennis M Ritchie

Re:Even though it's not here yet...

Damian on 2004-05-09T20:44:16

A language that doesn't have everything is actually easier to program in than some that do.

Actually, I don't think that's appropriate at all. I doubt that many here would seriously argue that C or sh is actually easier to program in than Perl 5 (for most tasks). And yet Perl 5 has far more features than C or sh.

How much is "in a language" is very close to irrelevant. What matters is *what* is in it. That's why DMR says "some that do". It's not the magnitude of the feature vector; it's the direction it's pointing.

Larry has often pointed out his "Waterbed Theory of Programming Complexity" (try googling for it) and that definitely applies to this quote. Whilst DMR's observation might make sense when applied to some "large magnitude" languages, which increase complexity at one level without substantially decreasing it elsewhere, I think Larry has consistently avoided that mistake, and has almost always chosen a direction for Perl's feature vector than *does* make the higher levels of programming easier.

And, after two decades of getting that direction right, doesn't it seem unlikely that he's now going to turn around and head off in some random counterproductive direction. Hasn't he earned a little more of our trust than that?

Re:Even though it's not here yet...

TorgoX on 2004-05-09T22:15:08

And, after two decades of getting that direction right, doesn't it seem unlikely that he's now going to turn around and head off in some random counterproductive direction. Hasn't he earned a little more of our trust than that?

What? You're arguing from actual real-life experience instead of from aphoristic principles? Tut tut.

(See Voltaire's Bastard's for a rip-roarin' polemic against purely principlistic argumentation.)

Re:Even though it's not here yet...

jordan on 2004-05-10T21:18:58

  • Actually, I don't think that's appropriate at all. I doubt that many here would seriously argue that C or sh is actually easier to program in than Perl 5 (for most tasks). And yet Perl 5 has far more features than C or sh.

Well, I guess it's a good thing that neither I, nor as you point out, Dennis Ritchie, makes the point that a language that has more features is necessarily harder to program in.

I was reminded of the Ritchie quote, however, because, to me, you seemed to be implying that a language that has a lot of features is necessarily more powerful than one that had less features.

I also reminded that CAR Hoare made the very interesting point in his 1980 Turing Award Winning Lecture "The Emperor's Old Clothes" (not available on-line, it seems) that languages that add a lot of untested features - for example, Algol 68 and Ada - become problematic.

Look, I'm not really against Perl 6, but I am skeptical. The whole process seems to be the opposite of what has made Perl 5 so successful, incremental development with rigorous field testing.

Sure, I can see that a lot of cruft had accumulated in Perl 5 and perhaps for further progress, this needed to be cleaned away, but I don't see retreating to the Cathedral as necessarily a healthy step.

It's not really a criticism, just a concern. I have a lot invested in Perl 5 and I have to admit that a great deal of this investment is emotional. When people go around making invidious comparisons, stating that a new language will be "more than twice as powerful" when compared to Perl 5, it sets off alarms for me. It may not be rational, but this reaction has protected me from a lot of language snake-oil salesmen in the past.

It seems that the Lisp family of languages have an excellent claim to be languages that are relatively easy to add new features through their support of meta-programming, yet somehow, Lisp languages always seem to fall short for me for "real work". Perl 5 rarely falls short for me. I am hopeful that Perl 6 will be satisfying as well.

Re:Even though it's not here yet...

Damian on 2004-05-11T21:28:26

Look, I'm not really against Perl 6, but I am skeptical. The whole process seems to be the opposite of what has made Perl 5 so successful, incremental development with rigorous field testing.

But that's precisely how we *are* developing Perl 6. Almost all of the new features we're folding in are either taken directly from, or refactored from syntheses of, existing modules or programming idioms. Here's a partial list of the rigorously field-tested modules whose useful functionality we are incrementally incorporating into Perl 6 at some level:

  • Attribute::Handlers
  • Attribute::Types
  • Class::Contract
  • Class::Delegation
  • Class::DispatchToAll
  • Class::MethodMaker (et al)
  • Class::Multimethods
  • Class::Roles
  • Coro
  • Error
  • Exporter::Simple (et al)
  • Fatal
  • File::Slurp (et al)
  • Filter::Simple
  • Hook::LexWrap (et al)
  • IO::File (et al)
  • Inline
  • Inline::Files
  • Lexical::Alias
  • List::Util
  • Math::BigInt (et al)
  • Memoize
  • NEXT
  • PDL
  • POE
  • Params::Validate
  • Parse::RecDescent
  • PerlIO
  • Quantum::Superpositions
  • Readonly (et al)
  • Regexp::Common
  • Regexp::Fields (et al)
  • Sub::Lexical
  • Switch
  • Text::Reform
  • Tie::SecureHash
  • Time::HiRes
  • Unicode::Normalize
Not to mention all the parts of Perl 6 that we're specifically prototyping and experimenting with in Perl 5:
  • Perl6::Interpolators
  • Perl6::Parameters
  • Perl6::Currying
  • Perl6::Export
  • Perl6::Form
  • Perl6::Gather
  • Perl6::Placeholders
  • Perl6::Rules
  • Perl6::Say
  • Perl6::Slurp
  • Perl6::Variables
  • Perl6::Binding
  • Perl6::Classes

So why (you ask) not leave them as modules? Why bring them into the core of the language? Because the existence of these module point to deficiencies in the incremental design of the language, or gaps in the language's support for the way people actually want to program. And because many of these behaviours are nearly impossible to get right in an external module; they need core integration and support.

It's not really a criticism, just a concern. I have a lot invested in Perl 5 and I have to admit that a great deal of this investment is emotional. When people go around making invidious comparisons, stating that a new language will be "more than twice as powerful" when compared to Perl 5, it sets off alarms for me.

And thank heavens it does. We need skeptics to keep us honest. ;-)

But I probably write more Perl 6 than anyone else (even Larry). And every time I do, I'm astonished at how much easier even everyday tasks are in Perl 6. "Twice as powerful" isn't meant to be invidious. I love Perl 5. But it wasn't until I started coding in Perl 6 that I realized how awkward and difficult Perl 5 can still be. And how it doesn't have to be that way. Switching back from Perl 6 to Perl 5 now feels about the same to me as switching back from Perl 5 to C.

Perl 5 rarely falls short for me. I am hopeful that Perl 6 will be satisfying as well.

My experience so far is that Perl 6 is unquestionably a satisfying language to program in. And whenever I find it isn't, I report that to Larry and we fix it so it is.

*That's* incremental language design. :-)

Re:Even though it's not here yet...

jordan on 2004-05-13T10:51:07

  • And thank heavens it does. We need skeptics to keep us honest. ;-)

Thanks. I'm less skeptical now. Uh, does that mean I'm less likely to keep you honest? :-)

Re:Even though it's not here yet...

jordan on 2008-12-28T20:33:34

Is it OK to be sceptical again?

Re:Even though it's not here yet...

Aristotle on 2008-12-28T22:45:22

Now that you can download the latest Parrot release, build Rakudo, and actually play with a large and ever expanding subset of the language?

Re:Even though it's not here yet...

jordan on 2008-12-29T15:09:21

In this thread, Damian reported to be productively programming in a useful subset of Perl 6 4.5 years ago.

Re:Even though it's not here yet...

Aristotle on 2008-12-29T18:10:55

Who cares about 4.5 years ago? Who cares about Damian? I said you can work with Rakudo right now, and the size of the subset has been expanding at breakneck pace since last spring.

But if you want to play the sceptic, go ahead. You’ll be back anyway.

Re:Even though it's not here yet...

TorgoX on 2009-02-19T22:32:07

KING'S

LEAD

HAT

was a mother to desire

It will come!

It will come!

It will surely come!

Re:Even though it's not here yet...

hfb on 2004-05-07T15:45:15

And, as if all that isn't enough, the Perl 6 development effort has siphoned many of the more...err..."exuberant" folk from the P5P list, and thereby allowed P5P to function much more effectively. ;-)

I think it was Joseph Hall who said it best..."Perl6 is the best thing that ever happened to Perl5." :)

Re:Even though it's not here yet...

TorgoX on 2004-05-09T22:08:37

Thanks for all your replies. As I was writing my initial mope, my general crankiness was spilling over onto everything, making everything in the world seem intractable and impossible. Then I remembered that I hadn't eaten in twelve hours, and that my blood sugar was about nil, turning me into a cranky woozy mess.

Next time I go brain shopping, I'm getting one with a UPS.

Re:Even though it's not here yet...

pudge on 2004-05-12T00:01:47

Not to ne a noodge, but I find it humorous that the first good thing you mention about Perl 6 is that it prompted the removal of a feature -- that no one used or understood -- from Perl 5. :-)

I am not complaining. Keep up the work. You're right, it's produced some good fruit, and someday may be a nice language to use. I don't think TorgoX was complaining either (as someone else implied), but some of us do get idly curious about it from time to time.

Publishers

clintp on 2004-05-07T13:08:57

The delay is keeping the publishers off my back. Back in (99? 00?) when Perl 6 was proposed, I got deluged with requests to do Perl 6 tutorials. I told them to "wait a couple of years". (Second-Systems do not come fast or cheap.)

By the time Perl 6 is ready for Prime Time I'll have my landscaping done, my kitchen remodeled, and the house painted; this'll leave plenty of time to write a book or two.

Short answer... pretty damn soon

Elian on 2004-05-07T15:05:29

As I'm getting tired of all the cranking.

First target's a perl-5 compatible regex compilation module, followed by a perl 6 compatible one, followed by perl 6 in stages. I expect the non-OO stuff will come first, followed by the object system stuff.

No, I'm not sure of when exactly. The regex stuff's reasonably simple (modulo fights over string representation) with the rest a bit less simple. Perl 6 being parsed by a perl 6 grammar probably won't happen for quite a while, though.