Perl 6: Apocalypse 6 Released

data64 writes "The latest Apocalypse talks about subroutines. Looks like we finally get type signatures which are way more powerful than the rudimentary prototypes available with Perl5."

Comments

Re:20-odd pages...

[albalbo]

No no no no no. I know that :) I mean:

foreach (@list) { $list[$i] = 'No jam today!' if ($_ =~ /jam/); }

... where $i is an index into the array. Like a for() loop, but without the gatepost error possibility. Yes, you can do it yourself with my $i=0 and $i++ in the loop, but it's a mess, especially if you next or last anywhere in there - it means you have to put the $i++ at the top, and start at $i = -1, which is bizarre.

Perl is turning into a completely new language

[siewsk]

I remenber the days of perl 5.004 and boy was that good and compact! Then as time so pass, more and more "features" are added into perl 5.004 and the result is that now you have too many features spoils the broth. As perl 5.004 it is PERFECT for replacing bourne shell, sed and awk. But instead of being stable (and not changing), it kept on changing. This is bad from a system admin point of view because you want to be sure that the script you wrote in 1999 will work in 2019 without any changes (just like bourne shell).

Instead if Perl kept on changing then you can't be sure and when you have literally thousands of little perl scripts everywhere this is intolerable.

Perhaps they should have kept Perl 5 as /usr/bin/perl5 and make sure that it stays static for all eternity. There are values in things which do not change, things you can depend on year after year without fear.

Re:Perl is turning into a completely new language

[terraformer]

Then as time so pass, more and more "features" are added into perl 5.004 and the result is that now you have too many features spoils the broth.

No, most of these "features" as you call them are not added into perl, they are added in as bundled modules. Perl's core is kept small for this very reason. As for Perl 6, that is going to be radically different but perl5 will be able to live on the same machine as perl 6 and I would imagine that a great deal of people will keep both around and maintain both for a great while.

ughgh

[Anonymous Coward]

This is why I hate Perl

multi *caller (?$where = &CALLER::_, Int +$skip = 0, Str +$label)

my brain can't grok that

Re:ughgh

[Kaa]

But a higher level scripting language should be as close to english (or another human language) as possible

No. That's conceptually wrong.

A (programming) language should make it easy to construct solutions for problems it has been designed to solve. Natural languages, such as English, are good for certain sets of problems and quite bad for other sets of problems.

Would you like to replace math notation with sentences in English?

Re:ughgh

[jbolden]

There is a language called COBOL which was designed in the 1950s to resemble logical english syntax as much as possible. The problem is sequences of instructions and human languages don't map very well. So surfacey kinds of simarity create languages that are neither good computer languages nor terribly understandable.

Actually from a grammer standpoint Perl is far closer to a real human language than almost any other language. For example the use of pronouns (implied variables) in Perl is very much like a human language and very unlike most computer languages.
The inventor of Python agrees with this assessement but since he considers this a bad thing he didn't emulate it in Python.

Re:ughgh

[vadim_t]

It's ugly indeed. But internals are rarely pretty. Just take a look at files in /usr/include, stdlib.h, for example. I wanted to paste here an example, but darn slashcode asks me to "Please use fewer 'junk' characters".

Re:ughgh

[kmellis]

"Actually from a grammer standpoint Perl is far closer to a real human language than almost any other language."

And let's not forget that Wall's education is as a linguist, and not as a computer scientist.

To my mind, the best computing language designer would be someone with extensive education and experience in: computer engineering, computer science, linguistics, mathematics, engineering and business processes, maybe psychology, and perhaps some other things I'm forgetting at the moment. My point is that a good designer would have a very strong comprehension of the problem space (the problems this tool is intended to solve), how the tool is likely to actually be used in the real world, how the problem space will evolve over time, all coupled with a very strong comprehension of the most efficient method of implementing this tool in the technology available. That's asking a lot.

In Wall's case, I think that he has a fair amount of experience as a practical coder, which is the impetus for his extremely strong emphasis on pragmatism in his language design. This would be a disaster for most designers, probably, but Wall's education in linguistics probably tempers that pragmatism with some comprehension of higher-level abstraction and some imposition of rigor. You can most clearly see this aspect of Wall's world-view coming through in the Perl 6 design.

However, even though in some sense the scientific view related to linguistics is an abstraction similar to the scientific view of computer science, they're fundamentally dissimilar. Linguistics is an attempt to comprehend and formalize a very complex and exquisitely functional system--human language. In contrast, Computer Science is not a descriptive science; it tends to be proscriptive--looking for the best way to do things, often from an ahistorical almost-Platonic perspective. As a result, it tends to be overly ideological. I chose the word "proscriptive" with some care, as in the realm of human language it identifies a fault line. Linguists tend to be notoriously relativist, asserting that what is "correct" is simple what exists. Proscriptivists, such as one's fourth grade English teacher, insist that there's truly "correct" and "incorrect" usage. In this sense, Wall's background in linguistics clearly has influenced his philosophy of computing language design; and, I think, computing language purists really are psychologically akin to the proscriptivist grammarians like the aforementioned fourth grade teacher.

For my part, in the realm of tools, I prefer aesthetic purity or elegance only when it serves utility (or, at least, doesn't interfere with utility). Perl is well-matched to its problem space, and in this it actually does have, in my opinion, some beauty. I mean, from one perspective a Swiss Army knife is god-awful ugly; but from another, its compact and wide-ranging utility is attractive. Because Perl is intended to operate in such a large problem space, I believe that simplicity, and the form of beauty that is a function of simplicity, is largely denied to it. So? We can't have everything. Ideally, there'd be a wide range of computing languages each perfectly and exquisitely engineered for their respective problem spaces. But, right now, computing isn't even close to being mature enough to support such a thing. In other engineering and science disciplines, there are a variety of tools and methods and specializations each well-suited to the problem domain they serve. And it works because a civil engineer isn't expected to do nuclear engineering work, nor an astrophysicist to do nuclear physics. But programmers are still expected to be jack-of-all-trades, and thus their tools are required to be as versatile--but also as unoptimized--as they are.

Perl, the new ADA

[ajm]

I used to think that perl might become the new COBOL. Now it looks like it's going to be the new ADA. Lots of nice features but such complexity and cleverness that even the people who use it don't like it. ADA's a good language, but no one uses it. It would be a shame if perl 6 went the same way.

Perhaps the cleverness of the ideas are not being tempered by real use at this point. A language does not become great by adding new syntax and semantics for each feature but by refining it to the essential units needed to express all the rest. We should not celebrate the fact that "will" and "is" are very similar ways to express traits in perl 6. We should ask instead why do we need both? Further, is it possible for me to define a new "wont" statement in perl, or are "will" and "is" special things only language designers can implement?

When did obfuscated code kill a language? Never

[Ars-Fartsica]

Gee, they hold an obfuscated C contest every year. You think C would vanish by now given the disgusting crap the coders write for the contest.

The original poster simply pulled something similar. There is no requirement that your perl look anything like that, nor is "powerful" perl more obfuscated than plainish looking perl. This is total FUD drummed up by someone who has presented a corner case....which I can assure you can be done for any language. In fact, I wouldn't touch a language for which this didn't hold.

Seeing the forest through the trees

[RichDice]

On first glace, the P6 syntax looks... scary. And I'm even someone who's been into P6 (at least marginally) for a few years now.

What I think though is important to remember is that if all you look at is the syntax, you won't appreciate the power -- and simplicity -- of the idioms. Taken out of context and put into cooked up examples meant to show off the new syntax, it looks bad... really bad. But once you actually start programming in it, you'll find that most of what you want and need to do will actually come quite simply.

That vast majority of all this new syntax will be applied in the vast minority of programming cases. Much of it will get sucked up into modules, classes, etc., that you'll use without worrying about what's actually going on under the hood. And "the rest of us" will just have an incredibly powerful language that is actually easier to program.

Cheers,
Richard

GCC Larry.pl -Wall

[smittyoneeach]

I'm waiting for Perl6 before I get too serious about Perl, as I don't want to have a lot of unlearning to do
Got about 10 pages into it before the /.ing. What a provocative language.

Question regarding:
my %pet is Hash of Array of Array of Hash of Array of Cat;

why not:
typedef my Hash of Array of Array of Hash of Array of Cat %pet;
IMHO, without typedef, C++ would be lost, particularly when the STL is on the loose...

Larry, your Boss is as good as mine... ;)

The shortest distance to a solution

[Ars-Fartsica]

Perl provides syntactic shortcuts and people use them. You do not need to use them. You can write Ada/Java-like incredibly verbose muck in Perl if you like. No one is forcing you to take the shortcuts....yet people do. Why is this? Because time is more valuable than code to many people.

Perl 6 is easier than Perl 5. Really.

[ChaosDiscord]

But a higher level scripting language should be as close to english (or another human language) as possible.

I certainly don't look forward to COBOLScript.

Human languages are an ambigious mess. Computers only want unambigious constructs. Having programmed in COBOL and and a few so called "fourth generation languages", let me say that writing in something that is close to English is really irritating. It's never quire English enough to allow me to express myself. You end up having to learn a specialized language that isn't really quite English. If I'm going to learn a specialized language, I might as well learn something that is easy to type and easy to scan visually.

Perl is a big, complex language, yes. But like real languages, you can learn it with very simple steps. You can get complex, productive things done with a just a quick introduction. If you want more power, it will take more learning, but it's available. Perl 6 aims to accomplish this evem better tham Perl 5.

Yes, the example given in the article are a bit convoluted. The entire point of the article is to explore all of Perl 6, not just the commonly used bits. In fact, one of main goals of Perl 6 is to make the common case and the introductory case less confusing than in Perl 5. Really. And everything revealed so far has supported this, it's just that Larry doesn't make it too clear.

Take for example expressing that a function takes three arguments in Perl 5. The best you can do is:

sub my_function($$$) {
....my($arg1, $arg2, $arg3) = @_;
}

(The "...." represents spaces because Slashdot's code filter is crap.)

In this example, Perl will not check that callers do the right thing. In Perl 6, you get this:

sub my_fuction($arg1, $arg2, $arg3) {
}

A clear improvement, and Perl will actually verify that callers do the right thing when calling you, usually catching an error at compile time!

In general Lary's Apocalypses have been a bit obscure. He's focusing on the big picture and the little details. Damien's Exegesis's is generally alot easier to read for people less interested in deep thought and more interested in concrete details. Wait a week or two for Exegesis 6 and give that a read. I think you'll find that the common case is slightly simplier and more obvious than in Perl 5, while the system also allows for more complex expressions that weren't well supported in the Perl 5.

Re:Perl 6: Replacing old cruft with new cruft!

[gmuslera]

Instead we get stuff like this:
sub *print (*@list)
Talk about confusing! * signifies a glob, but in the above example the first * signifies a sort of 'package wildcard' meaning that the subroutine is global! The second *, however, is a glob, as in Perl 5. WTF? Perl 6 looks almost as inconsistent as PHP already, and it's only in draft!

Perl is more based in natural languages than in "traditional" programming languages. In natural languages, what you are saying depend on the context, the same words say different things if they are used in diffeerent situations or positions inside a phrase.

Well, in perl that also happens (in perl 5 you'll find a lot more examples of this, starting with the "$" in $a, $a[1] and $a{"red"}).and I think that it was more common in the previous versions (at least in Perl 6 I believe you'll have $a, @a[1] and %a{"red"})

Re:Don't forget Parrot

[evronm]

I agree. When parrot comes out, there will essentially be 4 development platforms:

• JVM
• MS.NET
• Parrot
• low level (I'm lumping C and ASM here for the sake of brevity)

The fourth will be used for applications where speed is really key (real time, database engines, OS's, etc.)

For all other apps, it will be a matter of choosing one of the other 3 environments, and a language.

This choice will be particularly interesting given the fact that some languages (e.g. perl) will work with more than 1 of these environments (.NET and Parrot).

It's going to be an interesting world...

Why Perl6 matters

[Anonymous Coward]

Perl6 is the only mainstream language that will have a first-class parser and lexer as part of its syntax. This is extremely powerful. Basically, Perl6 will be the language of choice to write not only one off flat file transformations but entire compilers. Having seen dozens of new languages in the past 10 years looking pretty much the same as each other I can tell you that Perl6 is the only language that appears to be forward looking and casts off baggage of years gone by. Larry Wall is truly a visionary.
Having said that, I believe Parrot is a disaster that will never actually function correctly. No matter - someone will write a better Perl6 VM. I would not be surprised if it came out of ActiveState, Ximian or Microsoft.

I think it is safe to say

[Anonymous Coward]

That Larry has now COMPLETELY LOST HIS MIND:

I suppose you could also write that as:

my Array of Array of Hash of Array of Cat %pet;

but for linguistic reasons it's probably better to keep the variable name near the left and put the long, heavy phrases to the right. (People tend to prefer to say the short parts of their sentences before the long parts--linguists call this the "end-weight" problem.) The Hash is implied by the %pet, so you could leave out the "is" part and just say:

my %pet of Array of Array of Hash of Array of Cat;

Another possibility is:

my Cat %pet is Hash of Array of Array of Hash of Array;

I'm really glad I learned Ruby..

Ever hear of APL?

[m11533]

It was a great language, originally created to DESCRIBE and design computer hardware architectures, but a few of the wizards at IBM's Watson Lab decided to implement it as a programming language. Still the only language I know of that can multiply a pair of matrices with a single NATIVE operator! No user coding required.

Of course, with all of this power APL also invented the write-only program and the one-liner, both predecessors to the obfuscated C contest... and I must say that those using C and C++ can only dream of approaching the unreadability that was APL. Then again, only APL used its own character set... it used single symbols derived from mathematics as its operators. No constructing multi-character composite operators in that language... just custom terminals, or... a special type-ball for your selectric based 2741 terminal (there's a trip down memory lane).

To return to my point, though.

APL died for a number of reasons, but probably the biggest was how totally undigestible its code became with very little effort. I wrote some fairly simple programs, relatively well written for APL, avoiding the tradition of making everything a one-liner, actually including comments... you know those things written in intelligible English that explains what a program does... oh, yeah, I haven't seen any of those in years in my C/C++ shops... and yet as little as a few months after I wrote those beautiful, elegent APL programs I had no clue how they worked and could only change them by re-writing them. A very good reason for a language to die.

The shame of it all is the APL was probably the best language ever invented for solving hard-core math and arithmetic problems, yet it died before it could even run on its natural platform, the super-pipelined vector processors such as the Cray-1 and its relatives.

Sand

[ajs]

Perl 6: The reason I've finally gotten off my butt and am writing Sand.

Sand is a programming language I've been planning for a long time, but its timetable has picked up as I'm more and more convinced that Perl 6 is going to fill a niche that I don't work in. Plus, I've really never been comfortable with bytecode interpreters.

That's not to slight Perl 6. I'm sure it will be a fine language, but I'm looking at moving on to a design that focuses on maintainability and compilability (that is: to machine code). Since none of the languages out there satisfy my desire for these attributes plus the flexibilty that I've come to love in Perl, I have to write it myself. ;-)

Re:Perl 6: Replacing old cruft with new cruft!

[angel'o'sphere]

The interesting thing about Larry Wall is: he is a linguist. That is a scientist researching how the human mind works with language, how language is structured and how language works.

I have heared that he explained in his first books how perl works from natual language point of views.

In the Apocalypses I saw also a lot of reasoning about how something is seen by a the human mind.

I can not help myself. But PERL transforms even more into a unreadable language.

I wrote a lot of perl scripts in Perl 4, about 300k LOC. After not looking at them after 1 or 2 years C++ coding, most of the tricks I used I did not understand anymore ... erm, thats 6 years ago, Perl4 is nealry 10 years ago.

Every time when I see a post about a new language I jump on it as I was a language geek when I started programming.

As soon as I see more than one $ or % or # sign in a sinlge line of code, I just trash the language.

I simply can not get why this is needed. I fully agree with the one who said programming languages should approach english. (probably because I learned Pascal as first true programming language, after BASIC and assembler)

I think a programmer should be able to read any program in any language. Or at least should be able to get a clue about what a program does, and how it does it.

Thre are so few constructs: variables, declarations, definitions, statements, structures, arrays.

Around that some programming concepts are woven .. imperative, declarative, functional ....

Why to make that more complex by silly abreviated keywords? (sub in perl, def in python) By useless and meaningless (for a uneducated reader) $ and # and % signs?

Perl is a language you an not learn by examining perl programs. You need a geek explaining it or time to read ALL docs. Thats a true draw back .... everybody who knows Pascal, C, C++, Ruby, Python, Ada can read Java.

Thats basicly why I stopped using perl. When Perl4 emerged I thought, better than C-shell definitly ... now I write bash ...

Well, and I left C++ and went to Java :-) With Java 1.5 I have all a language needs, except multiple inheritance :-/

angel'o'sphere

Re:More Information

[Skald]

On another note, is Perl 6 even going to be relevant with next-generation languages like Ruby and Python already fairly mature? ;-)

If Perl6 goes according to plan, absolutely. In fact, it'll be particularly relevant to Ruby and Python.

More than any other thing, in my opinion, Perl has CPAN going for it. Other languages have tried similar code sharing projects, and none of them have come close to matching CPAN's breadth and (despite the occasional wonky module) usefulness.

More than any other thing, in my opinion, Java has the JVM going for it. Not that it's the only virtual machine out there, but it's the only one which really has broad distribution. The ability to distribute compiled bytecode, and to run it in a "sandbox", are two of Java's biggest selling points.

If Perl6 succeeds, neither of these languages will keep their greatest advantages. Perl6 is merely to be a Parrot compiler... and where Sun has actively tried to keep other languages off of the JVM, the Parrot developers want to entice other languages onto the Parrot. Any languages rewritten to target the Parrot, then, should (given some hooks, perhaps) be able to take advantage of the CPAN modules which are the wealth of the enormous Perl community.

To the extent that Perl6 succeeds, Python, Ruby, Scheme, O'Caml, and who-knows-what other languages stand to find themselves able to "write once, and run anywhere". Potentially, this could lower the bar for new and interesting languages to compete, since they'd primarily be competing as languages, with the runtime environment issues (more or less) abstracted away. In the same way that Mozilla allowed for today's proliferation of browsers, Parrot could be a very good thing for languages.

But while Perl6's progress will certainly be relevant, in the long term it risks obsolescence by virtue of its own ambitions. Frankly, if that were the case, I don't think it'd bother Larry all that much... however the Perl community doesn't seem to be ready to go gentle into that good night. A lot of Perl6's remarkably ambitious agenda seems to me an effort to stave off the possibility of the danger that Perl will become a victim of its own, and Parrot's, success.

a short story...

[Anonymous Coward]

my Cat $felix;
&foo.do

push(@foo, "rapidly", 1,2,3)
my macro sic { ... }
leave Block;

&foo.returns = sig(Num);
will do { return +@many[$one] }

From lines in the article. try it! it's fun!

Type declarations already in perl5?

[Ed Avis]

In Perl 5 you can say:
my Cat $felix;
to declare a variable intended to hold a Cat object.

You can?

Why didn't anyone say so before? I've never seen this in Perl code until now.