in reply to Re: Perl6 syntax being too much complex? How we will teach and read that?!
in thread Perl6 syntax being too much complex? How we will teach and read that?!

Why is perl so productive when compared to those other languages with their simpler syntax?....IMO, the power of perl 5 is that it's complex syntax means that each statement does more, and therefore requires less statements.
This is a good question, but I have to disagree with the answer. What makes Perl so darn productive is not the syntax, IMHO, but the semantics. LISP (particularly Common Lisp, and the Zetalisp of the lost and lamented LISP Machine) is the only language I've ever worked in that matched Perl5 in terms of expressive power, yet you can't get much further away from LISP syntax than Perl. But semantically, the two langauges have a lot in common:

These are the qualities (along with numerous others) that make Perl so expressive, so flexible, and, let's face it, so enjoyable to program in. It doesn't matter that we're writing foo(\&subname) or foo(sub { blah; blurfle; }) rather than (foo #'subname) or (foo '(lambda () (blah) (blurfle))). What matters is we didn't have to create a define an interface and create a stupid anonymous class just to pass the function!

As for the syntax of Perl 6, based on what I've seen a little of it is some general tidying up, more of it adds some useful orthogonality (string/integer/boolean, e.g.), but the bulk of it (junctives, >><<, sub vs method vs multi, etc.) is being introduced to support new semantic power. And that has got me seriously jazzed up.

In other words, Perl 5 was design for the programmer, not the compiler.

Amen, brother.

Replies are listed 'Best First'.
Re: Re: Re: Perl6 syntax being too much complex? How we will teach and read that?!
by BrowserUk (Patriarch) on Mar 23, 2004 at 03:08 UTC

    I think your probably right re: syntax versus semantics. Though perl does have a lot of syntax compared to other languages. And without that large syntax, I don't think it would be possible to have the powerful semantics without hiving much of the native power off into a RTL/Class library as other languages have done.

    I also reached the conclusion that it the rise in complexity of the syntax (p6 -v- p5), as perceived by the OP and many others, is required to allow the further enhancement of the semantics.

    The devil is undoubtably in the detail. Balancing the Huffman principle; with the (natural) calls for orthoganality; with the desire for greater OO-ness; with the extension of the Lisp-ishness; with an overarching desire (and need) to maintain the perlish usability, is a knife-edge balacing trick that reminds me of an old joke about flies sliding down razor-blades, using their ...er...anatomy... as brakes.

    I've recently been forced into re-aquainting myself with C++ (complete with MS' overdefined types and class libraries, hungarian notation and 5 lines per statement example code!), and it is painful. I was never much enamoured with C++ from either the syntactic or semantic level. It took the very simple, elegant syntax of C and 'stuck on' a lot of complicated syntax that barely worked. It also tried to apply braces and a plaster cast to the simplistic C semantics (roll your own:), and resulted in a complexity that made it like using three languages all at the same time--(almost untyped) C, strongly-ish typed, multiple-inheretance OO, and templates. The result is a very powerful, but hugely difficult language to do well.

    Like natural languages, perl needs to evolve. I'm not a latin scholar, but I hear testimony from many that are, that latin is a very elegantly structured language. Which begs the question, why did it die? My conclusion (which has no more authority than that of a casual observer) is that it died because the civilisation that evolved and regulated it died, and it therefore failed to evolve further.

    If perl stayed static and didn't evolve, it too would die. Sure, there would be some hard core enthusiasts that would keep it from dying out completely just as there are with many ancient natural languages, but newer languages would simple overwealm it.

    From my perspective, the only hard part is not being able to use it now, but in nature the only things that have short gestation periods also have short frenetic, lives, so I watch and wait with (tempered) eager antisipation.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail

      I'm pretty certain the fact that Perl has a lot of syntax isn't key to its usefulness. It is key to its readability (when the programmer actually puts effort into expressing himself naturally), but not to usefulness.

      Look at the usefulness of the aforementioned LISP, which doesn't have very bare syntax, but rather really has no syntax (the programmer is basically writing raw parse trees in textual representation). Yet LISP didn't have to syphon all that complexity into class libraries to be useful; it is right there in the core of the language.

      Remember that Perl6 is doing a lot to orthogonize Perl syntax — sometimes adding by adding to it, but not rarely by dropping cases that so far have been special or by integrating multiple special cases in a unifying frame.

      The elegance of C is its minimalism in assumptions — it doesn't do any of your work for you, but it also doesn't prevent you from doing anything. C++'s failure is that it implements the restrictions necessary to implement a higher level world view without offering any higher level constructs to get work done easier. You still have to do as much legwork to get places as in C, but suddenly you're no longer allowed (nay, even able) to walk across the field. You get no car, not even a bike, but you have to stick to the roads now.

      Makeshifts last the longest.

        I think we are saying much the same thing, but quibbling over terms :) I'd only note that there is a difference between "useful" and "usability".

        I like the "raw parse trees" description of LISP. I'd never really thought of it that way, but it is a very accurate description from my less than comprehensive knowledge of the language. I assume that there is some mechanism for code re-use in LISP? Even if it is only something like include files? I also have no idea how you would read/write a file in LISP. I keep meaning to get around to installing a build of Scheme and playing.

        P6 is definitely doing some things to orthoganise the language--consistant use of $, @, % comes to mind--but there are other areas where calls for orthoganality have been rejected. The most obvious example I can think of is length. I don't think that we are likely to see

        my $sizeOfArray = @array.length;
        or
        my $sizeOfArray = length @array;
        nor
        my $lenOfString = scalar @$scalar;
        (though I personally still hanker for my $substring = $scalar[ 3 .. 7 ];).

        So, whilst P6 is regularising the language in many places, it's being done not for sake of orthoganality itself, but to simply the use of the language. If it also makes it more elegant, thats great, but I don't think that is the primary drive for change.

        Let me add, I think that Perl 5 can be elegant. Some of Abigail's recursive solutions are extremely elegant. Likewise some of your code. But as you've noted about some of my P5 in the past, it's also possible to produce stuff which is "Yuck!":)

        As for C++. I've fairly recently discovered a language that I think achieves most of what C++ set out to achieve (except backwards compatibility), but that does it with much less complexity. It's still evolving, and I haven't had opportunity to make a great deal of use of it in larger programs yet, but the simplicity of its objects, the automatic memory management, built-in associative arrays endear me to it strongly.

        The fact that I can still get down and dirty with the machine as with C, but have a few more HLL features to simplify things, plus the compiled-to-native performance make it really interesting to me.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "Think for yourself!" - Abigail