Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: Perl 6 is too complex

by Anonymous Monk
on Mar 14, 2003 at 23:37 UTC ( #243207=note: print w/ replies, xml ) Need Help??


in reply to Perl 6 is too complex

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


Comment on Re: Perl 6 is too complex
Re: Re: Perl 6 is too complex
by chromatic (Archbishop) on Mar 14, 2003 at 23:50 UTC

    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.

Re: Re: Perl 6 is too complex
by janx (Monk) on Mar 15, 2003 at 00:12 UTC
    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

Re: Re: Perl 6 is too complex
by TimToady (Parson) on Mar 15, 2003 at 03:24 UTC
    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. :-)

      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?

Re^2: Perl 6 is too complex
by adrianh (Chancellor) on Mar 16, 2003 at 00:18 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://243207]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (15)
As of 2014-07-31 13:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (248 votes), past polls