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.

Re:PERL is dying!

[MisterFancypants]

PERL is dying, just like BSD

..and Stephen King. That guy has died more than 500 times by now if my count of Slashdot posts is correct. I wonder if all the mainstream media places are keeping it under wraps because they don't want us to know he's an unstoppable super monster.

Re:PERL is dying!

[Anonymous Coward]

Whoa, may I introduce you two?
Troll-AC - meet Troll-Moderator

Funny.. really you ought to be hit by something big.. that would be funny.. tsk.. *walks away mumbling*

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.

[Anonymous Coward]

Your writing style reminds me on stileproject

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.

Perl.....

[Smartcowboy]

...was used by Taliban in their anti-aircraft missile defense system. (click here!)

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?

Ruby has its own design mistakes

[metamatic]

I'd move to Ruby right now, except it doesn't support Unicode. I really don't see any point in learning another language with no native Unicode support; I may as well stick with Perl 5.

And like you, I'm not touching Python because of the stupid indentation block structuring. I mean, that's such a blatantly stupid idea... 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? And I'm not going to get irritated and confused by the fact that two indentations that look identical on the screen are seen differently by the compiler? Yeah, right, I believe that...

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

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.

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??

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.

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: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.

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.

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: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.

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.

Cart Before the Horse

[wdr1]

'nuff said.

work on the language, then write the book.

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: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).

Don't mod parent up! It's a troll. See here:

[Anonymous Coward]

http://www.rubygarden.org/article.php?sid=256

Re:I'm just wondering...

[dubStylee]

You are disgusting little idiots. Your stupid remarks about celebreties are just plain ugly. When you bring this to the realm of people in our own community you move to the level of maggots.

Go ahead and mod me down for flaming, I'll gladly take the hit.

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:Mixed Company

[be-fan]

If you knew me in person, you'd know I treat women with a great deal of respect. It just goes to show you how utterly stupid taking someone's jokes so damn seriously can be!

Re:Mixed Company

[dubStylee]

Perhaps some day you'll be a minority in a group of people whom your job requires you to associate with and who make a regular practice of making fun of that minority and then come to know the difference between a joke and a verbal assault.

In person, the intent and impact of a joke is tempered by other cues such that the butt of the joke can tell whether it is told "in good fun" or with intent to harass. In a forum like this one, no amount of smilies conveys those cues. The constant gay-bashing and mysogyny on slashdot are truly ugly and offensive.

Is it an accident that there are more women doctors and scientists than there are women programmers even though all three fields require technical skills? Do you feel no sense of responsibility to provide a welcoming atmosphere to encourage more women to join our field? Whether or not you consider the "jokes" funny, surely you can understand that they do not provide a welcoming atmosphere.

Imagine for a minute that you are my fifteen year old daughter surfing the net while trying to figure out what field to enter. Do you think these jokes, whatever their intent, will encourage her to become a programmer?

Re:Mixed Company

[be-fan]

Perhaps some day you'll be a minority in a group of people whom your job requires you to associate with and who make a regular practice of making fun of that minority and then come to know the difference between a joke and a verbal assault.
>>>>>>>>>
Dude, I'm a Muslim Indian. Don't give me any crap about being a minority. Every time an article on Slashdot comes out about programmers, you get some anti-Indian people crawling out of the woodworks. However, its quite easy to distinguish between those who are joking, and those who sound like they mean it.

In a forum like this one, no amount of smilies conveys those cues.
>>>>
A smily takes place of physically smiling while saying something. Between that, and the cues inherent to sarcastic language (from my original post --- "it's not like", and the exclamation mark) only people who can't read well should have a problem discerning a joke from a statement.

Is it an accident that there are more women doctors and scientists than there are women programmers even though all three fields require technical skills? Do you feel no sense of responsibility to provide a welcoming atmosphere to encourage more women to join our field?
>>>>>>>
In school I used to help run projects that tried to get young kids interested in robotics. One of the goals, in particular, was to get little girls interested in technology. Again, don't give me shit about "welcoming atmosphere." We're among adults here, and adults should be mature enough to tell the difference between a joke and a personal attack. Besides, in my experience, the problems with getting girls interested in technology runs a lot deeper than some jokes, or a welcoming atmosphere. There are systematic biases in our society that penetrate to the very value systems of traditional families. It's these biases that are keeping girls out of technology. It's the fact that every commercial involving Stoffers or WalMart involves a "mom taking care of her family." It's the fact that to this day, there are men who believe that women can't do their job just as well. The only things jokes do is take the edge off an otherwise harsh and bitter reality.

Imagine for a minute that you are my fifteen year old daughter surfing the net while trying to figure out what field to enter. Do you think these jokes, whatever their intent, will encourage her to become a programmer?
>>>>>>>>>
At fifteen, your daughter should be mature enough to realize the difference between humor and personal attacks. If she can't, then she should read more and get a full understanding of how language conveys intention. I have a brother who is 13 years old. He finds all the Flash videos on the internet about muslims hilarious. However, the one time somebody made an intentionally hurtful comment to him, he was very offended. If you can't distinguish between what somebody says, and what he means, you can't expect others to refrain from saying certain things just because you might misinterpret it.

Re:Mixed Company

[dubStylee]

Dude, I'm a Muslim Indian.

Ok, then obviously it was wrong of me to assume that you don't know the joking from the underside. Your points about other institutional reasons for lack of women in programming are well taken. I hope my daughter develops the same thick skin as your younger brother. I still disagree with you about the nature of joking on slashdot, but thanks for discussing the situation.

Re:Mixed Company

[Anonymous Coward]

Hmmm. Smilies convey meaning? not always.. could also convey the impression you are reading the comments of some sick pervert.. I myself am in a minority.. I'm deaf... I enjoy deaf jokes, and love telling them... Jokes.. and comments are two different things.. a Joke has a punchline.. like.. WOW, you see those knockers? Sure would like to have 'em on my door!..Might be in bad taste, and even that would need clarification whether it was intended as a joke.. maybe add (J.K.) to the end of it?
HOWEVER...! if I were a prospective employer checking up on you or your background (and don't think they WON'T).. do you really think I would be impressed with a comment like that posted in a public forum, when considering you for employment in an office setting of mixed gender?? I think not!
Joke it may be.. Sick Comment, it may be.. either way.. I don't really think it belongs in a public forum....not only for the sense of decency of others, but for your own good as well...

Eh?

[Daleks]

The first Perl 6 book was out in 2000.

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 :)

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.

2B | !2B == Question

[macmurph]

Everyone knows Perl is just for poetry...

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

Perl vs. PHP

[theolein]

It seems that PHP is moving in the same general direction in that it is now usable as a commandline tool and is adding many unneeded features, but at least the syntax is cleaner.

If you look here...

[Anonymous Coward]

"http://conferences.oreillynet.com/os2003/perl/"

Leon could be an attractive woman if he would do his hair differently.

I don't mean that as a knock at Leon, but he has a nice jawline.

On the other hand, Dan or Perrin will never be mistaken for a woman. And I mean that in the nicest possible way.

P.S. Randal... nice haircut... for 1977.

Shocker

[Anonymous Coward]

"I hope my daughter develops the same thick skin as your younger brother"

Am I the only one who's shocked you've managed to meet a girl, have sex with her and bred?

Hopefully, your wife is more interesting.

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.

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

[Anonymous Coward]

Evidently you need to read "Perl 6 Essentials" and perhaps to download Parrot and actually look at what state it's in. _Then_ come on here and blither randomly.

(1) If you were following Dan's blog, p6i, p6l or read the book in question, you'd know that its requirements are known. It's mostly just the syntax getting to those requirements that isn't.

(2) Actually, it's just the compilers that need the C compiling. The bytecode translators will generally run happily as bytecode.

(3) For vapourware, it's remarkably usable.

(4) Actaully, it's being worried about. Always has been.

(5) 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.

(6) Yes.

You show a splendid grasp of concepts saying "Perl 6 or Topaz or whatever it is called". One day, read "Perl 6 Essentials" - it's nice and cheap on Safari. Maybe you'll have a clue then.

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

[Anonymous Coward]

Ah yes, DotGNU and Mono. Aren't they both implementations of existing specifications?

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:Perl 6 development roadmap to nowhere

[Anonymous Coward]

So you're comparing apples and oranges. Great.

Re:Perl 6 development roadmap to nowhere

[Anonymous Coward]

More like apples and vapor.

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

I've very sorry...

[Anonymous Coward]

that you can't appreciate a woman's mind and her breasts.

And no, I'm not trolling.

Oh Nat, you're so manly

[Anonymous Coward]

"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."

How noble of you to defend a woman this way!

I consider you the most anti-female poster of the group. As I pointed out before women can be smart and sexy.

Of course, you apparently are neither of those things, so its probably you don't understand.

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:Matching nested parens with a Perl 5 regex

[Anonymous Coward]

As with perl5, one can expect that in perl6 although you get loads of convenience features you aren't required to use them.

Chapter 4 of "Perl 6 Essentials" is a real eye-opener. It has the language explained _clearly_. No distracting run downs of the RFCs or what has been changed since 5. No forced example program. And a clear explanation. Of course, it only covers objects and classes simply, due to the lack of the appropriate apocalypse, but you get an idea.

It's just not as complex as many people make it out to be - that includes the core design team =)

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

[bobtheprophet]

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