Exegesis 6 (Perl 6 Subroutines) Released

chromatic writes "Perl.com has just published Damian Conway's Exegesis 6 which gives practical examples demonstrating how to use the new subroutine and method semantics in Perl 6. This is the companion to Larry Wall's Apocalypse 6 which discussed the changes planned for subroutines in Perl 6."

Comments

Keywords

[Gortbusters.org]

The one thing that I always found unpleasant when moving between languages was the keywords... so, I picked up a C book, migrated to C++, then Java, picked up PHP along the way. Everything was fairly similar with keywords and syntax, and then perl threw a monkey wrench into the mix. I've never looked at python, are there similarities there or are the perl gurus guiding us through their path of enlightenment?

seems like

[butane_bob2003]

the language is becoming more obtuse if thats possible. The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax. Even coming from C, Perl syntax is unnatural. Seems like once you go Perl, you can never go back (or try to learn a new language). I've never met a perl programmer who could tell me what a design pattern is either. I guess they don't go for re-use much in perl progging. I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

Re:seems like

[jdavidb]

I viewed a presentation about design patterns at YAPC::NA::2002.

I once had a software engineering professor who over a period of several weeks refused to believe me that Perl was an object-oriented language (like C++, not like Java or Smalltalk). He was finally convinced when he taught design patterns, giving the factory class as an example, and I said, "I did that this morning in Perl." His jaw dropped.

I still consider myself a Perl programmer, but I was laid off last November and moved to a new job that is primarily Oracle PL/SQL programming. I only knew the bare minimum of PL/SQL, but already I am one of the guys people go to in this office when they have PL/SQL questions. I've helped about six people more experienced than me through fixing mutating table problems, and I'm learning more constantly through reading and experience.

I credit my experience with Perl extensively for helping me to be a good PL/SQL programmer. In my experience, good Perl programmers (the ones you're likely to see speaking at a conference or writing a book) use the right tool for the job, constantly pick up new languages (Ruby and Python are pretty popular), and do a better job programming in those languages because of their Perl experience.

Re:seems like

[Angst Badger]

Even coming from C, Perl syntax is unnatural. Seems like once you go Perl, you can never go back (or try to learn a new language).

I came from C (not that I exactly left it) and I didn't find Perl unnatural, and it hasn't crippled me for other purposes, unless you count involuntarily prepending '$' to variable names in C after a long session of Perl coding. As far as I am concerned, there are only three major problems with Perl:

1. Type sigils. The underlying theory necessary to implement variables without special leading characters dates back, oh, thirty years or so. (This is particularly egregious with PHP, where there is only one generic sigil for all types rendering them pointless anyway, but that's a separate gripe.) The '$' notation for shell scripts existed to simplify the ad hoc parsers most shells use; it has no place in a full-blown language.

2. Complex data structures. Even C syntax for deeply nested pointers is cleaner than Perl. Mostly because of 1, above.

3. Writing large applications in Perl depends totally on intense self-discipline as a programmer, and everything about Perl actively encourages you to break that discipline. TMTOWTDI, past a certain point, is a liability, especially with large development teams.

Obviously, Larry and Co. feel differently about these things, but they drive me up the fnarking wall.

I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

If Satan really wanted to put the screws to you, he'd require yacc. (The inside joke, for those who aren't deeply into compiler design, is that Perl can't be parsed by a yacc parser because it's not even remotely context-free. Whether that's a good idea or not is a debate that goes back to the days of the ALGOL design committee. The practical effect is that the syntax of Perl is described not by a formal grammar but by the implementation itself, which makes it all but impossible to validate a competing implementation.)

Any Sufficiently Advanced Language...

[Vagary]

A disclaimer: I used to program Perl for a living, but we had a falling out some years ago (around 5.0?). So if you don't think there's any merit to what I'm saying, then feel free to consider this a troll:

Shortly after I started reading Exegesis 6 I was somewhat frightened by how complex Perl had become since I stopped keeping track of updates. Of course scripting languages have always been known for borrowing the best from other programming languages, so I kept reading in the hopes that I'd recognise something. I saw some features like the is constant declaration and started worrying that maybe they'd decided to borrow some features from the very popular but insanely evil Visual Basic. But then I saw this:

type Selector ::= Code | Class | Rule | Hash;

and realised that, just as Python is (alleged to be?) adding Lisp-like features, Perl is adding ML-like features! That line above is (minus the '::' and ';') straight out of a Haskell program. Then I started to notice more Haskell-like syntax:

• Anonymous function declaration syntax: -> $animal { $animal.size < $breadbox } would be (\animal -> animal.size < breadbox) in Haskell
• Multisubs are like pattern matching: multi sub feed(Cat $c) {...} multi sub feed(Lion $l) {...} would be
  feed (Cat c) = ...
  feed (Lion l) = ...
• New infix operator definitions: infix:~|_|~ would be the function named (~|_|~)
• Junctions are like list comprehensions: all(newvals) would be [x | x <- newvals] (it almost seems like junctions are lazy from the way Damian talks about them?!)

And I'm sure a more thorough reading would turn up even more. (For example, the smart-match operator reminds me of the type inferences done in a Hindley-Milner type system.) So it appears that any sufficiently advanced language contains an implementation of a purely functional language, not specifically Scheme. :) Has Damian (who certainly has Haskell exposure) or Larry ever mentioned any of these influences?

The World Needs Idealised Perl

[Vagary]

In the denotational semantics community it was long ago decided that real programming languages are too messy and too much of moving targets for serious theoretical research. As a result, the most popular language is known as Idealised Algol which is a simplified and cleaned-up version of Algol-60 (I'm told Algol-W is the closest implementation).

Now that Perl 6 has a rich operator definition system*, we can look forward to Idealised Perl (IP). IP would be a version of Perl stripped down to only the necessary syntactic building-blocks. Even if much of Perl 6 were implemented in C, it'd be possible to define all the syntax in terms of IP. If you're writing code for maintainability instead of prototyping, using IP as much as possible will ensure a smaller learning curve for non-gurus. IP will be simple enough to actually allow teaching Perl in universities.

IP could be the elegant yet expressive language we all (whether we like Perl or not) wish Perl would be.

* This is, IMO, the only really neat and elegant thing to come out of Perl 6 so far. If operators can be defined to the point where most mathematical formulae are executable, Perl will become a revolutionary tool.

A sharp detour from past Perls

[Junks Jerzey]

I like Perl. I use Perl often. I also know and use a variety of obtuse languages, including wacky ones like Forth, J, and Haskell, plus more traditional languages such as Python, C++, various BASIC derivatives, etc. In short, I'm not an anti-Perl troll. Blind language advocacy is for newbies.

That said, I can't help but think that far too much thought has been put into Perl. One of Perl's real strengths has always been that it wasn't designed up front so much as accreting things have have been proven to work: hashes, formats, regular expressions, dynamic typing, back quoting, evaluation of variables inside strings, and so on. But Perl 6 is getting years of forethought, and all of that forethought is beginning to weigh things down. The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,

In short, this is the kind of thinking that begat PL/1 and Ada and other spectacularly complex languages.