I may want to stay with Perl 5 rather than go to perl 6. But there is a problem in staying with Perl 5. Due to Perl 6 the Perl 5 community is deprived of the resources of several key people, e.g. Larry, and also "Good Damian".

I think a case could be made that the Perl 5 community is rather more stable for the lack of us radicals, because if we weren't off inventing Perl 6, we'd be trying to turn Perl 5 into Perl 6 in situ, and that would be a mess.

I wonder if Parrot will be further delayed due to the need to support Perl 6, when a Perl 5 oriented Parrot might be done much sooner.

You're welcome to work on the Perl 5 port to Parrot. Otherwise one of us will have to do it eventually, and we're lazy... :-)

Ruby holds little appeal for me, and Python even less.

My sincere thanks for not playing the take-my-marbles-elsewhere card as others have done. Myself, I find that there are aspects of Ruby and Python that I like, and aspects that I don't like. I plan to steal the ones I like.

I think it is telling that most of the responses to my email are a technical discussion, e.g. how to make Perl more like Scheme. But Scheme, while elegant, is still a "boutique" language whereas Perl is widely used.

This is a red herring. The reason Scheme isn't widely used is not that it has interesting theory, but that it forces that theory on everyone whether they like it or not. We will only force it on maintenance programmers. :-)

As we know, when Larry designed Perl he took the best parts of awk, C, sh, etc., plus added a few excellent new ideas, and produced a language that was a mixture -- but a mix based on features that had been proven to be good.

You didn't finish the thought. "...a mix based on features that had been proven to be good for particular applications." For Perl 6 we're trying to do exactly the same thing, only with a few new applications in mind.

In contrast Perl 6 is a mixture of a variety of theoretically desireable features, e.g. multimethods, functional programming, logic programming, aspect oriented programming, design by contract, etc. that have not been proven in widely used languages. I agree that these features are theoretically desirable.

I think that they have been proven--for certain applications. But you seem to be using the term "theoretical" to mean "impractical". I think a great deal of theory is quite practical, as long as it's not forced on people who are not ready for it...or think they're not ready for it.

But that does not mean they should all be put into one language. The thrust of the second system syndrome is the temptation to add all those other truly good features that the first system did not have.

The slogan for Perl 6 is "Second system syndrome done right." :-) Seriously, I think the design team has a pretty good respect for the problem. If I'd just gone and said, okay, we'll implement a bunch of these RFCs, that would be "bad" second system syndrome. Instead, we're taking the time to rationalize every decision and inspect the ramifications with respect to the system as a whole. Please note, for instance, that we aren't actually adding many of the "theoretically desirable features" you list. We're merely making it possible to add them in the future with a consistent interface that people won't have to reinvent in 18 different ways. Certainly that's true for FP, LP, AOP, and DBC. On the other hand, the core will be relying heavily on multimethod dispatch to Do What You Mean in ways that Perl 5 can only emulate with lots of conditional code in its internals.

The claim that people will still be able to program in Perl 6 using a Perl 5 like subset is disingenuous. Most people read as much code as they write. The new language is much larger, and much harder to understand. It is likely to produce odd error messages, at least odd to people who have not taken courses in formal program language semantics.

It's certainly larger in some respects, and smaller in others. And it's true that we can only hide some of that from Perl 5 programmers. As for much harder to understand, I'm not sure that's going to be the case. Whenever I add a new theoretical feature, I always evaluate it to see how it maps onto natural language, and try to express it similarly. You already know how topics work in English, so we try to take advantage of that. You know how to express hypothetical ideas, so we'll try to take advantage of that too. You know how to explain something in terms of something else. That's how the classes and properties and traits are supposed to work together. Perl 6 will work more like a natural language than Perl 5, but it's still nowhere near the complexity of English or Japanese. Or Swahili, for that matter.

The original design of perl was simple. I learned Perl 4 from its man page -- yes there was one long man page that completely described the entire language. Apocalyse 6 included almost 30 pages discussing the new ==> and <== operators! This is not a good sign.

Sure, it spent lots of pages flailing about to give some idea of the thought processes that lead to it. It's a rationale, or an irrationale, if you like. But you can give the gist of it in one sentence: "The pipe operators evaluate an expression that produces a list and feed that list to some list operator that is missing its list." As for which direction the data flows for each operator, I think people can figure that out just by looking.

But I admit that the Apocalypses are scary stuff when taken on an empty stomach. I expect everyone to panic at least once, on average. Some of us have already panicked several times to make up for those who haven't yet. :-)

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.