Perl 6 is too complex

[Anonymous Monk]

In Apocalyse 6 Larry Wall explains how subroutines are going to work in Perl 6. I have read all the Apocaplyses and Exegeses. I think this is the straw that broke the camel's back. I think this is the worst case of "second system syndrome" I have ever seen. I quote the Jargon file entry:
"When one is designing the successor to a relatively small, elegant, and successful system, there is a tendency to become grandiose in one's success and design an elephantine feature-laden monstrosity."
I think the language design shows too much influence of "Evil Damian". I want "good Damian" to work with Larry et al. to reduce the complexity of the language. Or (shudder) a subset of the language to be defined.
Please advise me as to how to proceed.

[grinder]

<rant>

The thing is, there are lots of interesting theoretical advances that have been made in computer language theory over the past 20 years or so, but you'll be hard-pressed to find them implemented in a mainstream language. Perl 6 looks like it will cover a number of them (I'm thinking of the 3 Cs, closures, continuations and coroutines). If you don't need them, well that's fine. But when you need them, you need them bad, and nothing else will do.

There is always the debate as to whether Perl is a mainstream language or not, but there are lots of very bright people who take it as their language of choice. There has to be something in that. Someone far wiser than I said that the most intelligent programmers tend to be attracted to Perl. I believe that Perl 6 is going to continue to be a pleasant language to use for small tasks, but it's going to scale nicely for programming in the large.

I know two things. I know I was good at Perl before I started frequenting Perlmonks, and now I know that I am twice as good at Perl as I was before I started frequenting Perlmonks (but I probably still suck). Seeing what other people do with Perl, here, on this forum, has been a tremendous kick for me, for seeing how aspects of the language that I ignored, or was dimly aware of, can be used.

And I expect the same thing will happen with Perl 6. Sure, we'll all continue to write more or less Perl 5 in Perl 6. But every now and then, reading a node, at your own pace, you'll suddenly figure out how a new feature of Perl 6 can make your (programming) life easier. It won't come overnight, but it will happen. It'll be a slow bootstrapping process, and then all of a sudden we'll all grow into the new language, and wonder how we did without it before.

And then, in 2008, someone will post a message about validating Checkpoint™ Inspect™®© rulesets but sorry, I'm not allowed to use Perl 6, it must run in Perl 5, and we'll all laugh and the poor deluded programmer (or rather, his/her poor deluded manager). And someone will consider the node for reaping.

Sure, you could program in Haskell, Scheme, Icon or Eiffel, but you'll have difficulty finding friends with whom to talk about it. These languages have met with, as they say, a succes d'estime. Very nice, but not for me. Mondo cred points, but it doesn't put food on the table.

I must confess that I didn't understand an awful lot in A6. I'll have to reread it more than once to comprehend out all that Larry has written. Bear in mind that the apocalypses are not tutorials; you are not expected to learn how to program Perl 6 reading them. For that you should wait for Damian's Exegis 6. Once you have read E6, watch for the little light bulb to go off ding! above your head.

</rant>

print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'

[crenz]

I'll have to reread it more than once to comprehend out all that Larry has written.

I guess Larry felt the same way.

Sorry, couldn't resist ;-)

Actually, I think someone should go and write an Apocalypsis-style essay about Perl 5, maybe about OO or XS. Just to show that Perl 5 isn't really that much simpler... I'm saying someone because I'm not familiar enough with the guts of Perl 5 myself :)

[TheDamian]

Some points:
• There is no "Good Damian". There is no "Evil Damian". There is just me.
• There seems to be this notion that the design team is full of excessively smart people who have no ability to weigh the consequences of their ideas. In reality, we find ourselves only just barely smart enough, and sometimes not even that. And we're consumed with unravelling the ramifications of every decision we make. That's one of the reasons each Apocalypse takes so long to produce.
• Every idea I contribute to Perl is based on a real need that I, or someone I respect, has genuinely experienced in real programming tasks.
• Look at the many Perl 5 modules that I've written (and that 1000s of people now rely on every day), and then look at what's being added to Perl 6. Notice the correlation?
• Perl 6 is not taking resources from Perl 5. Since Perl 5 started we've seen the release of 100s of new Perl 5 modules (over a dozen by me alone) as well as Perl 5.8, which is unquestionably the best release of Perl 5 ever.
• The points that people have made about Apocalypses terrifying and Exegeses mollifying are particularly relevant. No Apocalypse can be fairly judged until the corresponding Exegesis has appeared.
• Apocalypses are diffs against Perl 5. So they naturally make Perl 6 seem totally different. But about 80% of the existing language is going through unchanged. I wrote an article on that very topic.
• We are working to reduce the complexity of the language. It's one of our primary goals.
• Yes, many of the features we're adding have not be hitherto seen in popular mainstream languages. That's precisely why we're adding them. Making advantaged programming techniques accessible to real programmers is a long Perl tradition. For example, earlier releases of Perl have done the same thing with closures, user-accessible symbol tables, tail recursion, tying, user-defined class implementations, dynamic inheritance structures, autoloading, etc. etc.
• Larry got Perl 1 right. He got Perl 2 right. And Perl 3. And Perl 4. And Perl 5. It's unlikely he's going to screw up -- or allow me to screw up -- Perl 6.
• That said, we really do appreciate your concerns. And the fact that you are willing to express them publicly, and without resorting to FUD. Such feedback keeps us ever mindful of our goals and responsibilities. Thank-you.

[BrowserUk]

Too complicated? Hmmm. Could be, but how good is your memory?

If I strain, really hard, to remember. Almost every time I encountered something new in my life, whether it was long division, Naper's Bones and logarithms at school, driving a car as a teen or Perl's regexes rather more recently, it always seemed too complex at the start. That usually continues for a period of days, weeks or months, and then one day I realise that I've stopped thinking about how complex it is. Often as not, what makes me realise that I have stopped thinking about the complexity, is when I find myself wishing that I could do something in a cleaner, more concise,more transparent or more efficient way. At some point in between, I made the transition from wishing it was less complex, to wanting to add a complexity to the syntax, in order that I might capture another semantic without having to restructure what I have.

The thing I personally enjoy about using perl 5, is that--more than any other language I have used or seen (with the possible exception of APL)--it allows me to express each step of an algorithm in the same way that I think of it, rather than having to break it down into a series of sub-steps. The reason that recursion is elegant, is that in many situations it allows us to specify the algorithm in a clean, concise manner which makes it easier to get right first-time, easier to understand for those that come along after. The penalty, unless the programmer (or compiler) takes special care, is efficiency.

The benefits I see coming from what I have seen of Perl 6, is that in your first pass, you can write the algorithm in a concise notation without needing to use the addition syntax. Then, when the thing is working, if it proves to be less efficient than required, the new syntatic elements allow you to add a few additional clauses to the existing code, that will allow the compiler to improve the efficiency without requiring you to substantially modify the original algorithm. You'll be able to indicate that this variable is a number and will never be used as a string, so omit all the overhead that allows me to use it as a string and the resultant code will become more efficient. Or this parameter will be used read-only, so the compiler can omit the overhead of creating an alias for it and again the same code becomes more efficient.

Efficiency isn't the only benefit that will be available from the new syntax. As LW indicated, for those S&M types (his phrase, not mine:), for whom strong typing, contract enforcement etc. are either desirable or essential, the new syntax allows (without requiring) much of this to be done by the compiler at compile time, rather than requiring additional statements at runtime. I can see some development shops adopting coding standards that will make some of these things obligatory for their coders. The beauty of it, if I understand what I have read so far correctly, is that Perl 6 will allow such strictures to be applied where they are needed, desired or beneficial, without requiring it where they are not. The proverbial "having your cake and eating it".

LW is walking a fine line. From my interpretation of what I see, he's well on his way to acheiving many of the desires of the many, whilst retaining the spirit of the language. Like many others, I could argue against some of the decisions, but I'm more than willing to keep an open mind and wait until I get the opportunity to use the language before I make any judgements. Perl's track record of adopting and adapting the best of the rest and inventing new where required, as well as backing out experiments that fail, is strong enough to allow me to swallow those fears I might have now, until I get to try things for real.

---

Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.

[adrianh]

What exactly don't you like? My reaction was the complete opposite - perl6 will make it easy to do all the things that are quite hard to do in perl5.

There is also the fact that you can just carry on doing:

sub foo { my @args = @_; whatever() };

if you want. You won't get punished :-)

Please advise me as to how to proceed.

Come up with some concrete suggestions on how it could be improved. Take then to the perl language discussions lists (and post them here).

[zby]

I can see a problem there - while you will be able to write your programs the old style you'll much have to learn much longer to read and understand perl written by others.

[adrianh]

Yes, there is more to learn. Whether learning that extra syntax and semantics will be difficult is hard to say.

What people tend to forget is that the various Apocalyses are short (well, as short as possible to cover the content) technical documents concentrating on all that is new and different in perl6. They are not tutorials.

When the tutorial books and documents get written (I bet merlyn is busy) concepts will be introduced in a more appropriate order. For example, I can see a natural progression from the simple suck-up-an-array style of argument passing to the more complex styles.

Yes, the new arg passing style will need to be learnt by the people need its functionality. But will this be any more effort than learning the various perl5 styles:

sub double { map { $_ * 2 } @_ };
sub method { my ($self, %param) = @_ };

use Param::Validate;
sub validating { my @p = validate( @_, 1, { default => 99 });

.. etc etc etc..

The huge advantage of having a system built into the language is that it need only be learnt once - rather than having to learn to interpret the dozens of roll-you-own variants out there in the world.

[enoch]

I had the same initial reaction as AnonyMonk when I read it. But, then I found this little Perl 6 gem of code (formatting slightly changed):

my @squares := apply { $_ * $_ } 2..5;

multi apply(&func, *$head, *@tail)
{
    return func($head), apply(&func <== @tail);
}

That looked really nice to me. It was inherently perl-ish and elegant. As a mental exercise, I converted that Perl 6 code to Perl 5 best I could and came up with:

my @squares = apply(sub{$_[0] * $_[0]}, \(2..5));

sub apply
{
    my($sub, $refArray) = @_;
    return map {$sub->($_)} @$refArray;
}

As you can see, both pieces of code, version 5 and version 6, are remarkably similar. The Perl 6 version looks a little more tweaked... a little nicer... a little more elegant. Well... it looks like the appropriate evolution from Perl 5 to me.

After reading the Apocalypse, I wrote up a summary of all of (what I thought were) Larry's major points here. I just wanted to keep track of them, and others might find the summary useful.

enoch

[broquaint]

I converted that Perl 6 code to Perl 5 best I could and came up with

Here's a slightly more direct conversion

sub apply(&@) {
  ## ack, Class::Multimethods doesn't do variadic args :-/
  return if @_ == 1;

  my($func, $head, @tail) = @_;
  local $_ = $head;
  return $func->(), apply($func, @tail);
}

my @squares = apply { $_ * $_ } 2 .. 5;

print join(', ', @squares), $/;

__output__

4, 9, 16, 25

As the comment gives away, this isn't a direct conversion as it isn't using multimethods, so it uses an arg count hack to emulate the behaviour. Also to be an even closer conversion would require apply to tie @squares to a square generator (at least I think that's probably the closest thing you can get to binding to a lazy list in perl6 with raw perl5). So it's certainly no easy task to convert that wee but powerful snippet directly to perl5!
HTH

_________
broquaint

[broquaint]

Also to be an even closer conversion would require apply to tie @squares to a square generator

Ok, perhaps not a square generator, but maybe something like this

use strict;

{
  package Tie::Array::Apply;

  use overload
    '@{}'    => sub { $_[0]->{list} },
    fallback => 1;

  use Tie::Array;

  @Tie::Array::Apply::ISA = qw( Tie::StdArray );

  sub TIEARRAY {
    my $class = shift;

    bless { func => shift, list => [@_], array => []}, $class;
  }

  sub FETCH {
    my($self,$pos) = @_;

    return $self->{array}->[$pos]
        if exists $self->{array}->[$pos];

    return undef
        if $pos >= @{ $self->{list} };

    local $_ = $self->{list}->[$pos];
    return $self->{array}->[$pos] = $self->{func}->();
  }
}

sub bind_apply(&@) {
  tie my @ret, 'Tie::Array::Apply', @_;
  return @ret;
}

my @bind_squares = bind_apply { $_ * $_ } 2 .. 5;

print "bind_apply: ", join(', ', @bind_squares), $/;

__output__

bind_apply: 4, 9, 16, 25

That code will lazily evaluate a list where each indice is bound to a function which has the appropriate element in the initial list applied to it. But now it doesn't have the recursive behaviour demonstrated in the original perl6 function so no longer needs a funky prototype or multimethod dispatch. Ho hum.
HTH

_________
broquaint

[crenz]

I read the same A6 as you, but came to a very different conclusion:

The one thing that really excites and keeps me from despairing when seeing all that syntax is that essentially, Perl 6 will still be a simple language. You'll be able to use just what you need, just like with Perl 5. I like that.

While I agree that Perl 5 is successful (and very much so!), I challenge the notion of it being "small" and "elegant". Well, it is elegant in many respects, but it could be more elegant in some respects. I think the problem is that the Apocalypses have to define all the special cases, whereas people interested in learning the language have to ignore all the special cases first. That might make it more difficult to get an unbiased view of what bread-and-butter Perl 6 will look like.

[ichimunki]

Please advise me as to how to proceed.

You have at least two options, both of which are available to you today and neither of which is difficult: continue to use Perl5 or switch to Ruby (or any of a number of other scripting/programming languages). Lots of programs have come out with "Version 2" or 3 or 4 or 98 or 2000 or 9.1 or X or XP and lots of users continue to do quite fine on their existing software/platforms. Also, a quick look at your alternatives indicates that almost any programming language is about trade-offs. Choose tools which are suited to the task at hand (and to the resources-- time, knowledge, money-- available)... maybe Perl6 is the right tool, maybe it won't be.

[chromatic]

If your first introduction to poetry were doggerel such as "Roses are Red" or "Mary Had a Little Lamb", you'd probably think, "Hey, that's easy! I can do that!" If it were a sestina, you might think "Whoa, no way I'll ever be able to do that."

Apocalypse 6 is a sestina.

[elusion]

It seems like we get this response every time a new Apocalypse is released. Everyone looks at it, and barely anyone understands any of it.

Then, Damian releases an Exegesis and people realize that it's not that complex and that perl will be better. Just remember that when you're thinking about the apocalypse. Have faith in the design team too -- they're smart people.

Perl5 is in many ways more complex than Perl6, just wait and see.

elusion : http://matt.diephouse.com

[webfiend]

I don't get it, folks. It's Perl, the Patchwork language. This is the language which encouraged folks to resurrect the term "baroque" and use it in Computer Science class. TMTOWTDI means that this is a language which streamlines by becoming larger, and absorbing new ideas. But underneath all of those strange new ideas it's still Perl. "more than one way to do it" means that you can still write Perl 5 code if you want. Heck, you don't even have to upgrade to Perl 6 if you're that disinterested.

Nervousness about changing our familiar tool is understadable. A5 terrified me, and the Exegesis (sp?) did nothing to reduce that. A6 has me excited about new possibilities, but nervous about knowing what to do with it. But you know what? I'll be able to apply those newer thoughts as I see fit.

It's not like I push Perl5 to its limits. I only messed with my first psuedohash a couple of hours ago, and that was just because I was skimming through Programming Perl and thought it looked cool. I've been using CGI.pm for years. I couldn't work my way through a single line of code inside that module, but that fact doesn't reduce the usefulnes of use CGI!

To sum up: It's Perl. It's going to be big, baroque, and occasionally scary. You were expecting Scheme, maybe? Well, the different spelling should have tipped you off :-) Use you what you want from Perl6, and ignore the rest.

---

I just realized that I was using the same sig for nearly three years.

[Anonymous Monk]

(I am replying to my own post, after reading the responses by other peoplke up until now. I am a newcomer to perlmonks, but an experienced programmer. In Perlmonks I am stolkin -- but for some reason my posts show up as being from "Anonymous Monk".)

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 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.

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

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.

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.

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. 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 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.

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.

[TimToady]

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. :-)

[pudge]

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.

It seems to me that Perl 5 maps well onto, say, English, but now it seems like you're trying to map (parts of) Perl 6 onto something else ... a way of looking at things. I don't quite have the vocabulary to explain it, especially this late on a Saturday night, but it seems to me that this sort of a mapping is odd. Topics and hypothetical ideas? 2 + 2 might equal 4, but only when not driving a truck?

[chromatic]

I disagree almost completely.

• Perl 5 gained a tremendous influx of new people and ideas after the announcement of Perl 6. PerlIO, Perl QA, the Perl6:: namespace on the CPAN, the defined-or operator, locked hashes, assertions...
• There have already been two "Perl 5 oriented Parrot" projects: Sapphire and Topaz. They were done much sooner in the sense that they've been long dead.
• Several of the features you call "theoretical" have had practical benefit, some for decades. I don't understand where to draw a line between "adding proven features from other languages and a few new features is good" and "adding proven features from other languages and a few new features is good". They both read the same way to me.
• I've met very few practicing programmers who could actually read code well.
• It's way too early to complain about Perl 6 error messages when they haven't yet been written.
• The original design of Perl was simple, if you had experience in Unix, sh, C, awk, and a few other languages you'd probably call "boutique".

I'm sympathetic to the fear that Perl 6 is hard to understand. I certainly haven't wrapped my brain around it, but it's starting to sink in over time. There are deeper consistencies you're not seeing yet, partly because the whole design hasn't emerged and partly because you're used to some of the quirks of Perl 5.

I just don't think the facts really support your other arguments, though.

[janx]

I think the problem is that many people don't really grasp all the concepts of Perl5 (I know so many programmers at the company I work for who fall into this category...) so they're scared of what Perl6 might bring along.

But those are not the types that read the Apocalypses anyway.
Then there are those who know Perl5 well and are content with their possibilities. They are probably best off using that part of the language they know. Then there shouldn't be the need to learn more (except details, but hey those can even change in maint-releases in Perl5).

And then there's us.
I'm not content. I want to do more with less (syntactic hassle that is). I like to see theoretically desireable features in Perl6 because I'm missing some of them, or don't know some and would like to try them out.
Without turning to some exotic language I can't find support for, and no application at hand.
I know a couple of people that are like me: Try those sick things because they're there to play with.
I learned quite a lot by just doing stuff I didn't grasp when I began playing and then gradually getting the hang of that.

Of course it's a problem if that's the only way of learning one is capable of, but I find it's one of the most effective ways there are.

To people who don't grasp error messages caused by using concepts they don't understand, I like to quote MJD to: "Well, if you don't know what it does, why did you put in your program?".

If they want to know I always have the time to explain.

Over lunch or a decent malt. On weekends, too.

janx

[adrianh]

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.

With the exception of AOP I would say all of those have been proved widely. Multimethods are core to C++, which can hardly be called a minority language. Functional programming concepts have permeated many languages including perl5 (map, grep, closures, etc.) Design by contract is a programming methodology. It is done all the time in many languages - it just has little explicit support in most of them.

I agree that these features are theoretically desirable. 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.

They're not just theoretically desirable. I have some very concrete desires for many of the features in A6 because they will mean my code will become smaller, easier to understand, easier to maintain and considerably more elegant.

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.

I don't think it's "much larger". Larger certainly, but not much larger. There is a lot in perl 5.

I don't think there is evidence that it will be harder to understand. From what I have seen there is a lot of orthogonality in the design, and natural progressions from the simple to the more complex cases. What we don't have yet are the tutorials to make these progressions obvious.

While the perl6 stuff may seem more complex the thing people seem to forget is that doing the same thing in perl5 is even harder.

For example, multimethods in perl 6 introduce some new syntax. Writing the equivalent code in perl5 means more code and a more baroque design, or using Class::Multimethods. Both of which, I would argue, are harder to understand than the new syntax.

Am I the only person in the world who think perl6 is going to make code simpler, not more complex? :-)

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.

Ah that's just language designers for you - they're not like us normal folk :-) Larry was discussing the rationale, background and all the ramifications. I bet the final POD will be something much more reasonable. For example:

LIST ==> LIST-OPERATOR

The ==> operator forces its left hand side into list context and passes it as *@ to the list operator on its right, forcing all other arguments of the operator into scalar context. So the following are all equivalent:

@foo ==> bar ==> ni($x);
ni($x, '*@' => bar('*@' => @foo));
ni($x, bar(@foo));

LIST-OPERATOR <== LIST

The ==> operator forces its right hand side into list context and passes it as *@ to the list operator on its left, forcing all other arguments of the operator into scalar context. So the following are all equivalent:

ni($x) <== bar <== @foo;
ni($x, '*@' => bar('*@' => @foo));
ni($x, bar(@foo));

would seem to cover it.

[fruiture]

As others said, the Apocalypses only highlight the changes. A real over-complication would mean e.g. to invent new assignation operators, make Hashes and Arrays just Objects held in scalars (%hash{foo} becomes $hash.get('foo')), to throw away all this list stuff at all ( @a = (@b,@c) becomes $a = array_merge($b,$c) like in PHP, bäh) . That would be horrible.

What does Apocalypse 6 introduce: Subroutines signatures, at last subroutine calls can be optimized at compile time, no more Perl's-subroutines-slowyoudown-trolls. This is nothing impractical, nearly every popular language has that "feature". Even more: named arguments, we're movng towards completely self-documenting code, and they can and will be optimized by the compiler as well: no memory- and time-consuming hashes to extract named arguments. This is no artificial invention, we know and love it from Perl5, a language with a lot of cool features we shouldn't forget ;)

Marking Arguments as constant: nothing new, plain old C 'const'. Marking them as rw: good old Perl5, access to parameters without messing around with pointers/references, no more than 'is rw', just as 'var' in Pascal. Slurpy lists using the * character: I already find that natural as the array flattening operator is the * as well.

Making arrays arrayrefs in scalar context: How logical, i didn't count how often newbies ask why 'function(@a,@b)' woudn't do what they want. It is straight-forward.

Seperating methods from subroutines does not only improve readability, it solves a lot of problems we had with OO (inheritance, private stuff, shooting your base class in the foot). It again allows optimizations at compile time. Other languages don't allow you too: In Java it's all methods, in Perl5 it's all subs; Perl6 lets you decide and get the optimum, you even have submethods.

Macros, old thing, known to be powerfull. They are no new concept.

Shortcut arguments ($^a ...) reduce the complexity without breaking the principles or would you rather like:

sort sub ($a,$b) { $a <=> $b } whatever
#instead of
sort { $^a <=> $^b } whatever

The latter is more or less nearly Perl5, only that you cannot break things when you use $a and $b somewhere.

In the end, it's not more complex than Perl5, but it can do more than Perl5 (and faster). As a parallel story: When I look at Perl5 formats, i think they're strange and their use is too complex (think of all the strange variables). I never used formats, and they never disturbed me for a few years of excessive Perl programming, althought they were always there. They'll be removed in Perl6 core (see Apocalypse 7 ;), because they've proven not to be too interesting for the majority of tasks. Why should things that turn out to be bloated theory disturb you in your work with Perl6? Just don't use them.

--
http://fruiture.de

[parv]

So i read A6. Now is my time to show what came up in my mind.

It seems by the time Perl 6 comes out, i would be better served by learning Lisp and gaining ever more knowledge of C++. Then decide if i should really use Perl 6 for its new features.

There would be need for two kinds of books on Perl 6: one which takes version 5 experience in account, and another one which asks to abandon that experince at least for major/large number of concepts. I think i would buy both versions.

[Aristotle]

Eh. Pointless worries, if you ask me. Consider the way a Perl 4 programmer might have thought of the new doodads - my? References?? Modules??? Objects?!?!? Well, have they made Perl 5 a feature laden monstrosity? Uh, hardly..

Makeshifts last the longest.