As you point out, perl5 has a complex syntax when compared to many other languages, which makes for a steep learning curve when you start out. but, if you persist long enough to get over the initial hump, the dividends are immense.

As you also point out, for many (most) programming tasks, a program that takes hundreds of lines and days to write in C, C++ or Java, takes only a few lines and a few hours (if that) to write in perl 5.

The question you have to ask yourself is why? Why is perl so productive when compared to those other languages with their simpler syntax?

I've personally thought about this a great deal. The conclusion I have reached is that the reason is totally down to that complex syntax, and more to the point, the design of that syntax. The syntax of nearly every other computer language was designed from the point of view of making it easy to parse. That is to say, easy for the compiler/interpreter to parse. This makes the process of writing the compiler easy for the developers, and means that they can produce great statistics of how many 100s or 1000s of statements they can compile per second. But it also means that each statement is only capable of doing very little work.

That means for any given task, the programmer must construct more statements. More statements means more opportunities to make mistakes. It means longer programs, with the active life of each variable in the program stretching over a greater physical distance within the source. I've read several studies that claim to show that the average human being can hold just 7 concurrent thoughts or ideas in their head at one time. With longer source files, and bigger physical distances between a variables instantiation and it's last use, the room for the programmer to forget a detail or loose sight of the direction of the code grows.

IMO, the power of perl 5 is that it's complex syntax means that each statement does more, and therefore requires less statements. Whilst each individual statement may require more thought to construct correctly, because in many cases, each statement, or closely grouped set of 3 or 4 statements completes an entire, complete part of the overall program, the programmer is able to concentrate on that without needing to scroll back and forth or dive off to lookup the syntax of yet another obscure API. That means that when he has finished or line, or a group of lines, another complete part of the program is finished. And that is the source of perl 5's productivity.

When you learn Perl 5's complex syntax, you are also learning a vast part of what other languages defer to their runtime libraries or API sets. If you never installed or used one CPAN module, you can still write a huge number of useful, productive programs. CPAN is the icing on the cake. Most other languages require their (usually extensive) libraries to be able to do anything useful at all.

The complex syntax, and the careful design that went into it is in large part exactly why perl is so productive. Moreover, when I say careful design, I don't mean "complying with some overarching, elegant master plan of orthogonal purity". I mean careful design in the sense that "Many programs and algorithms call for the programmer to do XYZ, so lets ensure that doing XYZ is not just possible, but as painless and concise as possible".

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

If you can accept that the complexity and learning curve involved in getting up to speed with perl 5 is a huge part of why you like using perl 5, then look again at the Apocolypsies, Exogesies and Synopsies that have come out for perl 6 and look at the care that is being taken to ensure that each part of the language, both the completely new stuff, and the revisions and re-working of the old stuff all meld together to produce a syntax that will continue the p5 traditions of letting you do what you need to do, as concisely, and with as little syntax as possible--once you get over the learning curve.

I'm not one for going on faith, nor of accepting something as good, just because someone tells me it is so. There are still areas of p6 that worry me somewhat. But each time I read one of the documents, I try to look at how it would change the way I write code to perform tasks that crop up in many of the programs I write. So far, with the minor exception of the new format stuff which I have barely ever had occasion to use what it replaces, I've seen how what is being proposed would simplify, clarify or otherwise enhance stuff that I currently write in p5. I watch as, one by one, each of the annoyances that crop up regularly when writing p5 code are being addressed.

So, faced with the choice between learning say, Java's "simple syntax" and various (incompatible) and huge libraries, or (re-)learning Perl's complex syntax that is going to allow me to do even more in each statement; write even less lines of overall code; and never have to learn to fight my way through the a huge "Standard Library" before I can write powerful, useful programs; I opt for the latter.

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:
• Essentially, weakly typed beyond the scalar/array/hash (LISP: atom/list) distinction.
• Functions easily take a flexible number of arguments
• Functions as first-class data objects
• Both lexically and dynamically scoped variables
• Built-in, or at least well-understood, operations for manipulating lists of values (e.g., map, the Schwartzian transform, foreach
• Flexible object-oriented features, including support for true multiple inheritance. And if you don't like what's there, it's easy to build your own.

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.

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 disagree with this stuff:

"...complex syntax ... which makes for a steep learning curve when you start out..."

"If you can accept that the complexity and learning curve involved in getting up to speed with perl 5..."

As a relative newbie, I found that the learning curve for Perl was much less steep than for other languages, because of the effort Perl takes to emulate natural language. You learn any language by making gradually more complex sentences using your dictionary; and by talking with native speakers. Perl makes this process easier than any other language I've encountered.

So Mr. BrowserUK and I get the same conclusion by radically different paths: Perl 5 was designed for the programmer.

Yes. I would say that Perl was designed for two different types of programmer. I recommend the article "The Tyranny of Choice" in the April issue of SciAm. It distinguishes "maximizers" from "satisficers". To a satisficer, the learning curve of Perl looks quite shallow because they don't have to learn it all at once. To a maximizer, the learning curve of Perl looks very steep because they do feel that they have to learn it all at once--but that's what makes a maximizer happy, after all.

I confess that I am a maximizer. I am so obsessively maximizing in my approach to life that I have to strike a careful balance between maximizing and satisficing. And that's good enough for me... :-)

After read the "Synopsis 3" I'm thinking that Perl6 is begin too much complex!

I don't think it is. Mostly it just discusses changes. Synopsis 3, point by point:

# -> becomes ., like the rest of the world uses. # The string concatenation . becomes ~. Think of it as "stitching" the two ends of its arguments together.

Just changes; no added complexity. Actually, . is much easier to type than ->.

# Unary ~ now imposes a string context on its argument, and + imposes a numeric context (as opposed to being a no-op in Perl 5). Along the same lines, ? imposes a Boolean context. # Bitwise operators get a data type prefix: +, ~, or ?. For example, | becomes either +| or ~| or ?|, depending on whether the operands are to be treated as numbers, strings, or Boolean values. Left shift << becomes +< , and correspondingly with right shift. Unary ~ becomes either +^ or ~^ or ?^, since a bitwise NOT is like an exclusive-or against solid ones. Note that ?^ is functionally identical to !. ?| differs from || in that ?| always returns a standard Boolean value (either 1 or 0), whereas || returns the actual value of the first of its arguments that is true.

Here things change a little and things do get more complex, but they're not as bad as it looks from this explanation. Hopefully this table makes things a bit more clear:

                         /    P e r l   6   \
                 Perl 5  Number  String  Bool
Impose context           +       ~       ?
Bitwise OR       |       +|      ~|      ?|     Logic OR:  ||, or
Bitwise AND      &       +&      ~&      ?&     Logic AND: &&, and
Bitwise XOR      ^       +^      ~^      ?^     Logic XOR: ^^, xor
Bitwise NOT      ~       +^      ~^      ?^, !  Logic NOT: !,  not
Bitshift left    <<      +<      ~<
Bitshift right   >>      +>      ~>
[download]

How often have you used | & ^ ~ << >> in Perl 5? Did you need them while you were still learning the language? I don't think beginners need to learn these operators. They'll discover them as they need them.

x splits into two operators: x (which concatenates repetitions of a string to produce a single string), and xx (which creates a list of repetitions of a list or scalar).

This again is only a change.

         Get a string,  Get a list
Perl 5   $foo x 5       ($foo) x 5
Perl 6   $foo x 5       $foo xx 5
[download]

# Trinary ? : becomes ?? ::. # qw{ ... } gets a synonym: « ... » . For those still living without the blessings of Unicode, that can also be written: << ... >>. # The scalar comma , now constructs a list reference of its operands. You have to use a [-1] subscript to get the last one.

Simple changes. I think «» will be easy to understand for beginners and the [-1] subscript has always been much easier than scalar comma.

Binary // is just like ||, except that it tests its left side for definedness instead of truth. There is a low-precedence form, too: err.

I don't think anyone will mind this new operator. Unless you love writing

$foo = $bar if not defined $foo;
$foo = $baz if not defined $foo;
$foo = $quux if not defined $foo;
[download]

Binary => is no longer just a "fancy comma." it now constructs a Pair object that can, among other things, be used to pass named arguments to functions.

No added complexity here, except that we get a neat Pair object, which makes learning how hashes work less complex.

^^ is the high-precedence version of xor.

Perl 5 should already have had this.

Unary . calls its single argument (which must be a method, or an de-referencer for a hash or array) on $_.

Just simple defaulting-to-$_ behaviour as Perl newbies already have to get used to.

... is a unary postfix operator that constructs a semi-infinite (and lazily evaluated) list, starting at the value of its single argument.

This in my opinion is needless complexity, but it does make writing things easier. 5... will be the same as 5 .. Inf. This will probably be used most as 0..., in foreaches:

for zip(@foos, 0...) -> $foo, $i {
    # Here, $foo is an element of @foo
    # and $i is its index.
}
[download]

# However, ... as a term is the "yada, yada, yada" operator, which is used as the body in function prototypes. It dies if it is ever executed.

It makes most of my code examples syntactically correct. I love it :)

$(...) imposes a scalar context on whatever it encloses. Similarly, @(...) and %(...) impose a list and hash context, respectively. These can be interpolated into strings.

I dislike the use of the @ for something that has to do with lists here and think * should be used instead. This does add to complexity.

The Unicode characters » (\xBB) and « (\xAB) and their ASCII digraphs >> and << are used to denote "hyperoperations" – "list" or "vector" or "SIMD" operations that are applied pairwise between corresponding elements of two lists (or arrays) and which return a list (or array) of the results.

It's either this or get people to understand map. Complexity, yes, but for a very good cause.

my @sums = @foo »+« @bar;
[download]

my @sums = map { $^a + $^b } zip(@foo, @bar);
[download]

|, &, and ^ are no longer bitwise operators (see Operator Renaming) but now serve a much higher cause: they are now the junction constructors.

This also adds to the complexity, but also makes many every day tasks much easier.

if $foo eq 'bar' | 'baz' | 'quux' { ... }
if $foo eq any « bar baz quux » { ... }     # Other style
[download]

if $foo eq 'bar' or $foo eq 'baz' or $foo eq 'quux' { ... }
[download]

Perl 6 supports the natural extension to the comparison operators, allowing multiple operands.

Simple maths. No complexity here, imo.

A new form of assignment is present in Perl 6, called "binding," used in place of typeglob assignment. It is performed with the := operator. Instead of replacing the value in a container like normal assignment, it replaces the container itself.

In other words: we get aliases. Aliases aren't hard to grok.

Since typeglobs are being removed, unary * may now serve as a list-flattening operator. It is used to "flatten" an array into a list, usually to allow the array's contents to be used as the arguments of a subroutine call. Note that those arguments still must comply with the subroutine's signature, but the presence of * defers that test until runtime.

Experienced Perl hackers are used to the fact that arrays flatten automatically. For beginners and users of other languages, this is strange. How often do people ask us how one can pass or return multiple arrays with a sub?

The new operators ==> and <== are akin to UNIX pipes, but work with functions that accept and return lists.

I'm not sure I like these. They make things very complex and I don't think they're needed, as for left-to-right writing you can also choose to use array methods.

An appended : marks the invocant when using the indirect-object syntax for Perl 6 method calls.

Explicit indirect object syntax reduces complexity by much. That, and it reduces the number of discussions in this Monastery :)

Perl 6 has a zip function that interleaves the elements of two or more arrays.

Simple and elegant.

Minimal Whitespace DWIMmery

Less difference with interpolated hash/array element syntax, so less complexity. I must admit that I never understood why anyone would like whitespace between aggregate and index. That style is extremely hard to read, imho.

So, summarized: we get some new operators that make our daily tasks easier. These are welcomed by everyone, I think. We also get some new operators for things not many people use. These are welcomed by the people who do use them, because even though the operators will be different and uglier, they will give the coder more control. And there will be some new operators that aren't needed, but probably are nice to have. (Perhaps one day I will like <== and ==>. That day has yet to come, though.)

You refer to other languages that KISS. This keeping it simple makes those languages HARD to use for anything that is complex. Simple and easy are not the same thing. Very often, simple means hard. PHP and Java are good examples.

Where in language design a decision needs to be made between simple and easy, PHP went for simple. This resulted in many, MANY built-in functions to make things a little easier. Java also went for simple. Count the classes and methods. Perl 6 chooses ease over simplicity. It will have many operators, but not as many as PHP and Java have functions/methods.

If the language is simple, the code will be complex. If the language is complex, the code will be simple. I have to deal with the code, so I don't mind the language to be complex.

I must admit that I never understood why anyone would like whitespace between aggregate and index. That style is extremely hard to read, imho.

Don't let Abigail-II hear you :)

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

This will probably be used most as 0..., in foreaches:

  for zip(@foos, 0...) -> $foo, $i {
      # Here, $foo is an element of @foo
      # and $i is its index.
  }
[download]

This would be better written using an array's "kv" method:

for @foos.kv -> $i, $foo {
  # $i = index; $foo = value
}
[download]

I think my biggest concern is with the split-vertical-bar operator: strange syntax is most confusing when its only rarely used. "zip" is only 3 chars, and I don't see the huffman benefit of using a single unicode char (which probably requires 3 keystrokes to type, and multiple double-takes to distinguish from a non-split-vertical-bar).

Dave.

For what it's worth: There's a discussion on perl6-language about why the broken-bar alias for zip is a bad idea. It may well come to pass that zip is alternately spelled ¥ (neumonic: Looks like a zipper. Downside: May cause Japanese people to be confused, because of old hacks that put the ¥ character where \ should be. Type as: AltGr-Shift-Z, German keyboard, xfree86).

if $foo eq 'bar' or $foo eq 'baz' or $foo eq 'quux' { ... }
[download]

Or, the non-hardcoded version ...

my %isAcceptable = map { $_ => 1 } qw( bar baz quux );

if $isAcceptable{$foo} { ... }
[download]

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Or, the non-hardcoded version ...

Which sometimes is handy, sometimes not. In any case, this kind of ugly lookup hashes is no longer needed in Perl 6, as any(*@array) will DWYM.

$isAcceptable{$foo}

You mean %isAcceptable{$foo}. $foo{$bar} is $foo.{$bar} ($foo->{bar} in Perl 5).

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

After read the "Synopsis 3" I'm thinking that Perl6 is begin too much complex! Just take a look in the number of operators that Perl6 have ("Synopsis 3" talk only about operators)! Man, this is a lot compared to Perl5, and imagine compared to other common languages.

I don't think there are that many more. Most of them are just existing Perl operators renamed. Many of the new ones fit a regular pattern (e.g. the use of ~, + and ? for string/numerical/boolean context) and should be fairly simple to remember.

But now I think that make a syntax even more complex, with a lot of different operators, basic data structures, and etc... will make the language hard to teach and read!

I think the problem that complexity problem that most people are seeing with Perl 6 is due to the lack of pedagogical documentation. The Apocalypses, Exegesis and Synopsis are not tutorials, they're information dense summaries. Once we get the Perl 6 equivalent of Learning Perl I think a lot of fear will disappear.

Here for any system that we develop, actually for any technology or code, we use the concept K.I.S.S., Keep It Simple and Stupid!

That's "Keep It Simple Stupid" not "and Stupid" :-)

This, of course, depends on your definition of "simple". I can already see many places where the hyper and junctive operators are going to make the intent of my code far clearer.

I say that because other languages like Java, have a simple syntax

I'm reminded of the time when people were saying you wouldn't be able to drive more than 50 miles/hour in a car because the human reaction speed would be too low to be able to drive reliably at that speed.

People will adapt. Maybe it's not "our" generation that will be able to use this new technology. But that's not important.

In my opinion, Parrot assembly will replace C as a tool for development of programs that need to have speed. And languages based on the Parrot runtime engine, will replace all other languages out there, whether they're interpreted or compiled.

Perl 6, in my opinion, will be the language of choice for the future. But please remember, even to this day, people are maintaining programs developed in languages that are now over 40 years old. That's not going to change.

And I'm sure someone will create a module like YAPE::Regex::Explain for explaining Perl 6 code to us. ;-)

Liz

Here for any system that we develop, actually for any technology or code, we use the concept K.I.S.S., Keep It Simple and Stupid! And we know that this work very well. I just think that Perl6 completely forgot that when talking about the syntax.

You're not developing a general purpose language, though.

The Perl 6 design team is.

I think that if Perl6 will make it and some 100 programmers will start using it for real projects, it will have the potential to become a language of the elitarian programmer.

However, Perl6 reminds me of PL1 (never programmed it). In a CS lesson, our prof gave two examples.

• BASIC - the intersection of all existing HLL languages.
• PL/I - the union of all existing HLL languages.

I can remember of some article I read about comparing PL/I to languages and found, that it already does compare very well to Perl.

My best wishes for Perl6, but before our company starts to use it or migrate from Perl5 - many things have to happen first after the availability of P6...

Your reply somehow seemed to me the most insightful of all in this thread.

It got me wondering if we're gonna end up divided into those who have understood & embraced currying, rules, junctions and the like and those who continue using good ol' Perl.

"Perl6 - your way to ensure job security". Haha, only serious.

We already have those two different sets of people happily using Perl 5. I don't see how Perl 6 is going to be much different on that subject.

As for PL/I, it might actually have succeeded had it been an open source language. But PL/I was too complicated to reimplement in an age where reimplemention was the only way to port it.

Not that I like PL/I all that much. As far as I know, Perl only borrowed one feature consciously from PL/I, which is the ability to iterate over a list of values. In many respects PL/I was not a well-integrated language, and it also didn't have the benefit of several decades of language research to draw on. PL/I did most things in an almost right way, from a modern perspective.

I believe we have all been focusing on the aspects of Perl6 that differ from Perl5, and while there are many, it is a reasonable argument that the operators and syntactic changes are for the better, which means a more consistent and clean language.

What we have not been focusing on is that Perl6 will still look like Perl5. The simple programs will not alter much at all. The larger and more complex programs will alter more, but in a way that makes them simpler and shorter.

I believe the biggest challenge is for the Perl6 implementors, and the language definers. As a mere user of the language, I am continually awed by the thought and care being taken to bring us Perl6. I have no problem waiting for Perl6, I have faith that those bringing it to us are the best people to be doing so, and I welcome the renewed interest and future prospects of a fresh Perl.

A lot of these discussions sound like a general fear of the unknown. You are going to get a better language, and you have an enormous head start in already knowing Perl5.

Oh, and it will perform better, too.

One thought that might keep you slightly sane is that you shouldn't even try to compare Perl 6 with any version before it. Yes, Perl 6 is still Perl, but it is much different than anything that came before it. You say it is hard now, but I'm sure the official releases (in 2007 or whenever Perl 6 is 'complete') will be well documented :). And really... it can't be harder to learn than C++. I hope not anyhow...

Perl6 syntax being too much complex?

How we will teach and read that?!