And is based on a framework that's no longer maintained outside the site because it had been superseded be newer and better ones.

I remember things a little differently. Everything's origins are in 1998 or so, when writing something this big and interactive and featureful was new (especially for the people doing it). In particular, the object-relational impedence in Everything is awful and the source of a lot of problems. It's also not well factored.

I've pondered a lot about how to write a similar system--because there are a lot of good ideas implemented imperfectly--and the basic ideas are solid. If I were to rewrite Everything today, I'd use Moose and KiokuDB and a fat model, naked object pattern. The only piece I haven't mapped out in my head is the URL routing scheme.

Everything stagnated after the parent company disappeared; it had never attracted much of a community, PM used a fork of the code, and there was no clear path for upgrades. Any one of those is a danger sign. All three together is much worse.

...you can't expect even the best mind to make such a thing "right" (for whatever definition of right) at the first attempt

I think it could be surprisingly direct and though there would be effort, most of it might be implementation, not design. Perl 5 has been getting it "right" for quite some time. By merely porting the Plack suite directly across we'd be a long weekend away from seeing frameworks start to spring up in Perl 6 or get ported from things like Dancer, Mojolicious, and more.

Perl 5 is a different language with different features and while there are similarities, when it comes to library interface design, the differences will matter a lot. It's not implementing the groundwork, it's the interface of the framework that will need a few iterations.

Jenda
Enoch was right!
Enjoy the last years of Rome.

Hmm, so are there any Perl 5 frameworks that would lend themsleves well to being ported to Perl 6 down the road?

Elda Taluta; Sarks Sark; Ark Arks

Thanks for your comment on this, Jenda. It does look like a serious obstacle.

However, as with other things, I'd prefer to see it as a challenge to be overcome, rather than assuming from the outset that it is a deal-breaker. I can envision at least two ways in which this problem could be mitigated, and I'm sure there are brighter folks out there who can come up with more/better ways.

I think I hear you saying that we should avoid repeating the mistake PerlMonks made in being based on Everything. Certainly it is the source of a lot of our pain. Nonetheless, I think it could be argued that it is also largely responsible for much of the success of PerlMonks. If "PerlMonks 6" ends up being built on "Everything 6" (so to speak), I don't think that's necessarily an outcome to be avoided. Probably anything we could choose to do in the next few years will look bad in 15 years. I don't think that should stop us from taking action now.