First Perl 6 Book is Out

prostoalex writes "O'Reilly Publishing presented Perl 6 Essentials, the first book to be dedicated to Perl 6, at the beginning of this month. Looking at the table of contents, it hardly looks like a valid replacement for Llama or Camel books. Chapter 1 is available online. The whole book is available to Safari subscribers." I'm sure we'll review it sooner or later.

Comments

PERL is dying!

[Anonymous Coward]

PERL is dying, just like BSD. That is why no one is posting on this thread.

Ummmmmmmmmm DUH!

[metalhed77]

Perl 6 aint even out yet. Of course its no camel yet. This is just for those people who HAVE to know what's going on in perl 6 dev.

Perl 6 is a mistake.

[Anonymous Coward]

I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD ^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Re:Perl 6 is a mistake.

[JohnFluxx]

um, regex's aren't nfa's. nfa's can do, for example, make sure a string has the same number of opening ('s and )'s.

so you'd have:

String -> '(' String ')' | ...

try doing that with a regex

Re:Perl 6 is a mistake.

[vcv]

>> Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal [lysator.liu.se] does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

The reason for this is because if you tell the interpreter what sort of data it is, it helps the interpreter do more optimizations with that data. Sure, it's not truly an integer, but at least you're helping the interpreter out but telling it how it can deal with the data.

>> Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions.

Of course, there is a lot of features in Perl. 200 ways to do one thing (which couldnt be considered a bad thing), but it's actually really cool, because it lets you stick to your own style more than other languages. Face it, perl should not be used unless you know what you are doing with it. It can get ugly, but it's powerful and can do certain tasks amazingly well, and better than any other language.

Sure, it's bloated.. but the way it's being designed should make it so the bloat doesn't affect the speed or power.

And you won't truly be able to appreciate Perl (especially 6), until you learn all the shortcuts [features] (not all, but..) . There is a lot to learn about the language before utilizing it's full power, but once you master it (if possible with perl), it becomes really fun.

Re:Perl 6 is a mistake.

[larry bagina]

regular expressions *are* [ND]FAs. Maybe you're thinking of Context Free grammer (FA + stack so you can do brace matching)?

Re:Perl 6 is a mistake.

[cakoose]

So few words, so much ignorance...

String -> '(' String ')' | ...

try doing that with a regex

Try doing that with an NFA, dumbass. An NFA cannot detect matching parentheses. A pushdown automaton can. This should be pretty obvious since your example is a grammar production of the context-free grammar style. PDAs are related to CFGs like NFAs/DFAs are related to regexes (though the relationship isn't as clean in the former case).

Regexes aren't NFAs but regexes can be used to describe any regular language (and only regular languages) and NFAs can recognize any regular language (and only regular languages). They are "equivalent" in terms of theoretical computational power (the traditional definitions state that regexes generate languages and NFAs recognize them). Also, DFAs can recognize all and only the regular languages.

However, I still don't understand why the grandparent poster said:

I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code.

If "linear code" means non-branching code, then I guess that that's true. What I don't get is how he/she is restricted to linear code. Regular code is turing-complete and therefore much more powerful than regular expressions. Regular expressions are more compact and map better to certain problems, but they are provably less "flexible".

As a side note, I think that Larry Wall suggested calling them "patterns" instead of "regexes" because they are more powerful than regular expressions (though I'm sure the old terminology will still be used). This is fully described here.

Re:Perl 6 is a mistake.

[Anonymous Coward]

So in other words, you never liked Perl all that much in the first place. I honestly don't see what's wrong with variables that include $, %, and @. It's just a way of concisely throwing in some syntactic markers to allow you to have interesting and convenient syntax in other areas. Certainly other languages have similar things; for instance, C has an array dereference operator ("[" and "]"), and nobody complains about it, even though it really is basically the same concept. And then there's the "." operator for selection of members of structs. Again, basically the exact same type of thing, and nobody has a problem with it because they're very familiar with it already.

But I guess what it boils down to is whether it is, in fact, better to have a "nice, clean, pure language". I would argue that it isn't. I don't have a nice, clean pure car. My car's engine is water cooled. That makes it more complicated and less reliable, but it also makes it more efficient. Also, the back brakes are of a different design than the front brakes. Again, it would be purer and cleaner and simpler to make them identical, since that would make it easier to understand them and work on them, but it's more efficient the way it is. And, while I'm at it, my body's metabolism involves the burning of oxygen, when in reality an anaerobic metabolism is much cleaner and simpler (and safer -- do you know how corrosive oxygen is? there's a reason behind health fanatics' taking massive doses of antioxidants). But again, the Kreb's cycle, despite being a very complicated process, is actually waaaay more efficient. So I think sometimes a more complex, less pure, less clean design can be a better design.

Having said all that, Perl is easy and fun to learn if you're into the weird and wonderful ideas behind it. But, like progressive rock music, if you're not into it, it's just irritating and seems virtually impossible to learn. So perl is great on programmer efficiency because it can allow a programmer to get massive amounts of stuff done easily. But on the other hand, it's also quite bad for programmer efficiency because some people just don't get into the ideas behind it and thus find it excruciatingly hard to learn and use.

By the way, one of the really dandy things, IMHO, about Perl 6 is this idea that every damned thing is a closure. Loop bodies are closures, even, if I remember correctly. This is really freaky and wonderful, but maybe just because once you learn about closures, you get addicted to them. Also, by the way, my own personal impression of Perl 6 is that it is actually making the language simpler and cleaner. At least, the everything-we-can-make-a-closure-is-a-closure idea gives me a feeling that some underlying things are being unified in a nice way. I started to wonder, actually, why every language doesn't do it that way, and I haven't come up with an answer yet, other than the idea that maybe it can't be compiled into efficient machine code.

Table of contents?

[jmd!]

Looking at the table of contents, it hardly looks like a valid replacement for Llama or Camel books.

Wouldn't you instead need to see the cover to determine that?

not *intended* to replace the camel book

[josephgrossberg]

"it hardly looks like a valid replacement for Llama or Camel books"

It's not supposed to be. Just as they have conventions for the books' color (e.g. Perl blue), O'Reilly and Associates has conventions for the titles.

* "... Essentials" means an overview of what's new.
* "Learning ..." is a discussion and tutorial on a topic, intended for beginners
* "Programming ..." is the same, but for intermediate and advanced users
* "... Cookbook" is a series of problems and their solutions
* "... in a Nutshell" is like a language reference
* "...: The Definitive Guide" is a combination of all four
* "... Pocket Reference" is a shorter version of the above

Re:not *intended* to replace the camel book

[ClosedSource]

You forgot ".. Annoyances" which is purchased by people who don't use the product described in the book.

Re:Ruby has its own design mistakes

[SewersOfRivendell]

I'd move to Ruby right now, except it doesn't support Unicode

That's not a "design mistake", it's just a major feature that hasn't been added yet. This will be remedied in a future version of Ruby.

A "design mistake" would be something error-prone and impossible to fix, like Python using indentation as part of the syntax.

Re:Cart Before the Horse

[dubStylee]

No, it's more like "show how the cart is being designed so you can help build it and/or begin to use it with the perl6ish pragma in perl5".

Re:Ruby has its own design mistakes

[AceMarkE]

Actually, I believe that as long as all the lines at a given level are indented the same, the actual amount of indenting is irrelevant. Example:

for(1):
for(2): # indented two spaces
for(3): # indented five spaces
for(4): # same as for(2)
for(5): # note different than for(3)

The accepted standard is 4 spaces per indent. And really, most programmers tend to write something similar anyway, Python just forces you to at least make an attempt at making the code readable.

Mark Erikson

Book deals too much with assembly

[wazlaf]

I had a look at it and found that this book deals way too much with Perl 6 assembly (somewhat like the IL code from .NET) rather than concentrate on what's interesting: OOP and new syntax. Seriously, wo is going to use Perl to program bytecode assembly.

Re:Book deals too much with assembly

[chromatic]

OOP hasn't been decided yet. That's the next Apocalypse the design team is considering. Just about everything known about Perl syntax is in chapter 4.

There are also plenty of people who'll program Parrot or IMCC bytecodes. We're the people who are implementing Perl 6, Ruby, Python, Lua, BASIC, BF, Befunge, Scheme, Jako, Cola, Perl 5, and Perl 1 on Parrot.

If you're expecting this to be a new verison of the Camel or the Llama, you'll be disappointed. It's not. It's aimed at early adopters, people who are curious about the state of the project, and people who are interested in developing Perl 6, Parrot, or another language on top of Parrot.

Chapter 3...

[sICE]

is there...

Mixed Company

[chromatic]

Maybe there'd be more women around if you showed them a little respect.

Re:Cart Before the Horse

[rjljr]

But why? Are there really enough interested
people to justify a book about ~planned~ changes
to Perl? Yikes. I really don't understand most programmers.

Why not print the O'caml book: Developing Applications with Objective Caml
(the ICFP contest champ).

Re:Ruby has its own design mistakes

[smallpaul]

That's not a "design mistake", it's just a major feature that hasn't been added yet. This will be remedied in a future version of Ruby.

First, it hardly matters whether it is "just" a design mistake or a missing feature. If he needs the feature and it isn't available, he can't use the language. Second, Unicode tends to have all kinds of implications deep into the implementation of a language. They touch reflection, language syntax, regular expressions, file system, pickling, I/O etc. You can call it "just" a "missing feature" but it is one big feature. I would be surprised if Ruby got proper (i.e. integrated) Unicode support before the pretty major rewrite that will also add native threads.

A "design mistake" would be something error-prone and impossible to fix, like Python using indentation as part of the syntax.

Yeah, many people who have not tried it say that. Turns out that it is less error-prone because it eliminates a whole class of bugs that result from parens that do not follow the indentation.

Finally

[be-fan]

It is nice to see a language designed by linguists rather than mathematicians or engineers. Typical Slashdotters will scoff, but suffice it to say that Shakespeare did not write in Scheme :)

Re:Ruby has its own design mistakes

[yaphadam097]

Yeah, many people who have not tried it say that. Turns out that it is less error-prone because it eliminates a whole class of bugs that result from parens that do not follow the indentation.

The problem with that is that a lot of developers like myself have grown up with Fortran -> C -> C++ -> Perl -> Java, or some similar progression. We don't have a problem matching parenthesis. In fact, any decent text editor or IDE will help us match parens and get the indents looking the way we want them to. Hell, even vi can do that if used correctly!!

It's not like there is nothing else in modern scripting languages that the python folks could have tried to fix. Why go back to the archaic practice of giving whitespace semantic meaning??

You guys are missing the point

[yaphadam097]

From the abstract it is clear that this book is intended to describe the Perl 6 project including the reasons for rewriting the language, the desing philosophy, some of the roadblocks along the way, etc. It sounds like a real interesting read for those who are interested in the process of designing and implementing a full scale computer language, regardless of how you feel about the particular results.

Re:Ruby has its own design mistakes

[73939133]

When I pick up some Python code that's space-indented and edit it in my text editor with 3-space tabs, the Python compiler's going to magically guess that my tab-tab is equivalent to 6 spaces, is it?

If you use tabs consistently for indentation, then it doesn't matter what you set them to, the Python code will remain valid and its meaning won't be affected.

If you mix tabs and spaces, you need to use the same tab setting as the original author anyway or the code will look like garbage.

The flip side of your problem is: what if changing the tab setting makes you misinterpret your code by changing the indentation to be inconsistent with your actual block structure?

The short answer is: you shouldn't change the meaning of hard tabs--it causes lots of other problems. Just use a decent text editor that indents correctly with spaces and standard tabs. Almost all of them do these days.

And, no, this just isn't a problem with Python. Space-based block structure may seem weird, but it works quite well.

2B | !2B == Question

[macmurph]

Everyone knows Perl is just for poetry...

http://www.perlmonks.org/index.pl?node=Perl%20Po et ry

Re:Ruby has its own design mistakes

[metamatic]

for(1): # indented three spaces
for(2): # indented two tabs
for(3): # indented six spaces
for(4): # indented one tab

Quick quiz: Which lines are in which blocks?

Followup: How was I supposed to know that looking at the screen?

Re:Ruby has its own design mistakes

[metamatic]

That's the problem, though. There's no such thing as "standard" tabs.

Re:You must be a joy to be around

[chromatic]

In a year, a woman goes from being virtually unknown to a core member of the Perl 6 design team, president of the Perl Foundation, a speaker at several conferences, and an author.

This news goes public, and the first thing a few people want to talk about is her breasts. When confronted about this, the excuses are "Oh, you're just being too sensitive", "Women like being noticed", and "If she doesn't like it, she shouldn't hang around here."

I'm sorry, but I really don't see any appreciation for Allison's abilities or for her as a person in those comments.

Re:Ruby has its own design mistakes

[bill_mcgonigle]

Actually, I believe that as long as all the lines at a given level are indented the same, the actual amount of indenting is irrelevant.

Unless it's new, that's not true. My first experience with python was copying a script from a webpage, putting it in a file, and getting a runtime error.

Turned out the browser had stuck five spaces in front of each line. I went through and pulled the whole text block to the left so that the leftmost line was in column 0 and it worked properly.

Maybe it has been fixed and there's just alot of animosity from people who tried it too early.

Perl 6 development roadmap to nowhere

[truth_revealed]

Parrot (the Perl 6 VM) is a classic case of Second System Syndrome.

1. Develop VM before knowing what Perl 6 language will look like or what it requirements will be.
2. Claim VM will support all interpreted languages known to man, yet the only language that runs on it is a crippled version of Basic. The other (non Perl) languages will require custom C code defeating the point of having a VM in the first place.
3. Piss away $200K in grant money and have nothing to show for it 3 years later. Gee, why isn't anyone contributing anymore?
4. Threads? We'll worry about it later.
5. Objects? Too tricky for now.
6. Function calling convention - we'll get it right one of these years.

Guys, time to put the horse in front of the cart and get back to the business of writing Perl 6 or Topaz or whatever it is called these days instead of trying to rule the world with Parrot.

Re:Perl 6 development roadmap to nowhere

[truth_revealed]

Forgive Dan. He's been spending time thinking of how to implement them well, rather than just wasting his time coding randomly. Thinking before acting has its merits.

That's quite funny. And Parrot's design is not random?! I guess you haven't been following their development very closely. They've changed calling conventions at least a half dozen times in the past 2 years, just to give you an example of their lack of a true design. Look how far both DotGNU and Mono have come in the same timeframe - they're actually working!

As for Dan and his book, I won't be buying it. He's already made enough money with his $60K Perl Foundation grant to construct the most needlessly (hopelessly?) complicated interpreter design anyone has ever seen. And does anyone know why the Parrot/Perl 6 team is trying to run Ruby, Python, CLR and Java bytecodes anyway? How exactly does that advance the cause of Perl 6?

On a slightly different topic, perhaps you can tell me why on earth isn't Larry prototyping Perl 6 with Perl 5? Afterall, most Ada compilers are written in Ada, and Lisp compilers are usually written in Lisp. Writing a Perl 6 interpreter in Perl 5 would increase community interest in the language as well as debug its concepts and shake out bad features and most importantly, Perl 6 modules and tutorials could be written. Sure this prototype would be slow - but who cares - it would be throw-away code. The final interpreter could be rewritten in C after the language is conceptually stable. Just call me crazy.

I guess I would not be so critical if I did not see promise in Perl 6 - the language. Oh well, perhaps another language will incorporate these concepts.

Re:Perl 6 development roadmap to nowhere

[truth_revealed]

I was referring to the comparitive size of the interpreter projects. The results speak for themselves. DotGNU Portable.NET was done with roughly the same number of developers (mostly by Rhys Weatherley) - and they were not paid to write this code as were the Parrot developers. DotGNU has a CLR VM, runtime libraries, a C# compiler, an assembler and a disassembler.

Re:I'm just wondering...

[gnat]

If you're going to have thoughts like these, could you please keep them to yourself? Some of us appreciate Allison, Elaine, Elizabeth, Kudra, and the other women in Perl for the great things they've done. I would like them to stay around and do more great things rather than be driven away because every time one of them comes to a conference she's nervously looking over their shoulder wondering which guy is the anonymous coward thinking about her boobs. Comments like yours set up a totally creepy environment for women.

And if Allison doesn't post in this thread, it's not because she's thinking "great, men are finally noticing women's bodies and commenting publicly on them". It's because she's off working on open source.

If anyone wants to talk to me about this at OSCON, I'd be happy to explain more forcefully just how much this coward's comment pisses me off.

--Nat

Re:Ruby has its own design mistakes

[makapuf]

you're right. However, tab size is taken as 8 spaces, but your example works (except for(1) in python isn't right, it works the same).

Besides, python supports both indentation block delimitation AND parentheses-like block delimiters.

just use #{ and #} (should be at the end of a line)
or you might use #[ and #]

or even # and #

Re:Ruby has its own design mistakes

[makapuf]

sorry (dumb me), slashcode removed my so-funny

#<cbneal> and #</cbneal>

example.

Matching nested parens with a Perl 5 regex

[Cato]

You can in fact do this with plain old Perl 5 regexes, as follows - to quote from Jeffrey Friedl's excellent Mastering Regular Expressions, 2nd Edition, p. 328-331:

my $LevelN;
$LevelN = qr/ \(( [^()] | (??{ $LevelN }) )* \) /x;

This dynamic regex matches text within an arbitrarily-nested set of nested parentheses, by recursively 'calling' the compiled regex $LevelN from within itself - the left hand condition of the alternation is the exit condition. It works in Perl 5.6 or higher, maybe even earlier - just tested it.

Of course, Perl 6 makes this sort of thing much easier and has a built-in Parse::RecDescent feature within regexes, but the overall complexity of the language is quite scary. I'm looking at OCaml, which is higher level than Perl (though with some features in modules and less syntactic sugar) and almost as fast as C/C++. It's also functional and OO, more details on my OCaml page

Re:Ruby has its own design mistakes

[Plix]

A "design mistake" would be something error-prone and impossible to fix, like Python using indentation as part of the syntax.

That is not a "design mistake." Python was not originally meant to be a production language, it was meant as a teaching tool and as a teaching tool it used the whitespace block delimiters/quantifiers as a way to force programming newbies to learn to write readable code.

Re:I'm just wondering... (haiku)

[bobtheprophet]

Dear sir, you are sad
remove your hands from your pants
and grow the fuck up

Re:Ruby has its own design mistakes

[fizbin]

Second, Unicode tends to have all kinds of implications deep into the implementation of a language. They touch reflection, language syntax, regular expressions, file system, pickling, I/O etc. You can call it "just" a "missing feature" but it is one big feature. I would be surprised if Ruby got proper (i.e. integrated) Unicode support before the pretty major rewrite that will also add native threads.

Actually, this is one place where I think ruby is ahead of your average scripting language currently in the not-yet-supporting-Unicode state. The whole reason that Ruby exists (as in, the original itch the creator was scratching) is that when it was created, existing scripting languages handled Japanese exceedingly poorly. As a consequence, ruby has never been developed in a "all the world is ASCII, and what isn't is latin1" environment. This gives me hope that it will be much easier to add unicode support to ruby than you might think.

Re:Ruby has its own design mistakes

[smallpaul]

Actually, this is one place where I think ruby is ahead of your average scripting language currently in the not-yet-supporting-Unicode state.

What scripting language doesn't support Unicode? BASH? Python, Perl and JavaScript all do.