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:Apocalypse Now

[rob-fu]

I love the smell of sub routines in the morning

...and it smells like unwashed, dirty programmers.

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.

Re:Perl is turning into a completely new language

[Enoch]

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.

I'm sorry. I think you are looking for this every-feature-is-in-the-core language.

Glad to point you in the right direction!

enoch

Re:Perl is turning into a completely new language

[Istealmymusic]

I'm reminded of a quote:

We biologists have a special word for stable. It is "dead".

Don't forget Parrot

[Ars-Fartsica]

The VM is showing 10x speed improvements in preliminary tests. Couple that in with Moore's law and Perl (or any languages that compiles to the Parrot VM) becomes a very attractive language for more types of problems.

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

Use what you need

[Ars-Fartsica]

Perl 5 already contains enough crap to confuse even perl "experts", yet this doesn't stop adoption. Take Bjarne's advice and only use the parts of a language you need, ignore the esoterica. Something else confuse you? Ignore it. Chances are you don't need it anyway.

Perl has always had a lot of esoterica. Don't let it bog you down. You can be amazingly productive in perl without ever knowing what a typeglob is.

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.

A completely different kettle of fish

[ralphclark]

The Perl 6 feature lineup even as it was two apoocalypses ago made it clear that the goal this time is a mature and fully-featured object oriented language that also retains all the neat high level features of perl-as-we-know-it.

This will make Perl an attractive contender for serious application development; something which it came reasonably close to in late Perl5 but didn't quite get there because while you could do most things in a consensually "proper" way, the roll-your-own methodology just wasn't convincing enough for pointy haired project managers.

The primary difference with Perl6 is that it will have full support for strict(ish) typing and object orientation which makes it suitable for large projects where it's impractical to expect programmer A to know anything about how programmer Z's module is implemented internally and vice versa.

The new feature set (together with Perl's availability on a wide range of platforms and the huge range of freely available interfaces on CPAN) means that Java and .NET will be facing some stiff competition in just about every conceivable application niche.

If the speed improvements are genuine then (assuming that one were in a position to choose) for probably the first time ever we will be in a position where there is hardly any real need to maintain skills in multiple languages as Perl will be at least adequate for the vast majority of implementations. It's not unreasonable to suppose the list of exclusions being limited to CPU bound code in high-performance content servers (eg RDBMS, HTTP) and real-time and embedded apps requiring hand-coded assembler or at least tightly optimised C.

Whether you agree with that or recoil in horror at the thought of your favourite language being marginalised, Perl is clearly not just a "glue" language any more. It's about to become a fully-fledged enterprise application development platform.

I'm sure you've already guessed, but for the record I am very much looking forward to this.

There is one fly in the ointment I guess. Perl, like C, is very free-form in terms of what it lets you do but the flip side of that coin is that such languages also let you write dangerously unstructured and unmaintainable code. They require good training and a degree of self discipline to use well. Self taught programmers who didn't have strict typing and nested scoping enforced on them at the beginning of their coding career almost inevitably tend to grow up writing code that is less secure and harder to read than do those who learned back in their college days to associate variable declaration at the wrong level of scope with lower assignment grades and some stern finger wagging from their tutor.

The new Perl will continue to make the impossible possible and the merely hard very easy, but for the first time it will provide support for a more formal structure where that is considered a good thing.

Remember though that Perl is still very much a grassroots phenomenon. Whether this hits anybody's radar screen out in the real world has to depend on how well and how rapidly it is taken up by the Perl community. i.e. upon the willingness of existing Perl code monkeys to grab the inevitable (presumably three-humped) Camel Book, learn the new features and use them deliberately to adopt a more structured and more scalable coding style.

It's on this point I think that Perl6 will succeed or fail. We will need plenty of real world examples out there so that new users have something from which to learn righteous coding principles, and so that sceptical project managers will see successful implentations from which to draw confidence and inspiration.

Perl is a Write-Only language

[Yossarian45793]

One problem with Perl, is that it's very hard to read somebody else's Perl code. Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers. If you've ever maintained a large Perl program written by someone other than yourself, you know what I'm talking about.

Adding more features to the language will only make this problem worse. Very few Perl programmers know more than a fraction of Perl's syntax. More syntax means more stuff that your average Perl programmer doesn't understand! This is a huge impediment to writing a large project in Perl.

Languages like C and Java stay alive precisely because they're not very expressive. You can write huge behemoth-sized projects and still have some hope of maintaining them, because there just aren't that many ways to obfuscate the code.

Re:Perl is a Write-Only language

[thoughtstream]

That's exactly why we made it possible to modify Perl 6's grammar. As paradoxical as it sounds, adding that flexibility gives us a way of overcoming the downsides of Perl's TMTOWTDI philosophy.

It will be comparatively simply for a coding team to create a "policy" module (say, Policy/Our/Preferred/Style.pm) that restricts coders to an agreed-upon subset of the language's syntax and features. Thereafter, so long as every module begins with use Policy::Our::Preferred::Style, the rest of the module simply won't compile unless it conforms to the team's coding standards.

And I suspect that enough groups will want to do this that it will make sense for someone to write a front-end module that simplifies the creation of such policies. So all your team will need to write will be something like:

module Policy::Our::Preferred::Style;

use Policy::Specification
blocks => 'K&R',
elses => 'cuddled',
disallow => << unless until statement_modifiers junctions>>,
# etc.
;

Re:Perl is a Write-Only language

[Fastolfe]

Most Perl hackers can write scripts that do amazing things in much less space/time than a traditional compiled language, but their code is indecipherable to even other skilled Perl hackers.

Concede the likelyhood that this is due to one of two things:

1. "Most Perl hackers" are incapable of reliably writing readable, maintainable Perl code.
2. "other skilled Perl hackers" are not very good at reading Perl code.

Try reading through some of the modules in the Perl core some time. More often than not, they are exceptionally well-written, documented very nicely and easily maintained.

In my experience, given a pool of developers in any language, it is usually very rare to find one that can write truly elegant, readable code. Perl's flexibility just makes it so that those that write unreadable code can write some really unreadable Perl. Perl's low barrier of entry is part of the problem, and generally companies don't know what to look for when selecting a Perl developer, so you get a lot of novices out there in these positions pumping out utter shit, but it runs, so it must be OK.

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.