Slashdot Mirror
Perl 6 Essentials
Make no mistake, Perl 6 isn't here yet, but it's coming. The book starts with a good explanation of "the plan"; chapters 1-3 deal with the history, goals, and design considerations of the project. It's a good conceptual overview of the process about how it has been run so far, and how it seems to be continuing. Chapter 3 is of special interest, as it showcases some of the in-depth thought that has been poured into the project. Though we all aren't language theorists, it helps allay some of the fears that change brings while being completely fascinating reading.
This first part of the book isn't very useful without a fairly solid Perl 5 background. It wastes no time in chapter 4 discussing syntactical differences in the v5 to v6 transition. Programmers should be pleased with the practicality of the approach to the new language, as it refers to the new structures and features, and how they solve simple workarounds that Perl veterans are used to in Perl 5. Currying, multimethods, class definitions and structures, new operator syntax, and the dynamics of the new regular expression engine (now called rules) are all touched on, and their values made obvious to the reader.
The last three chapters are for those interested in Parrot development and those who wish to port languages to Parrot. (There are active projects to port Python, Ruby, and even .NET to Parrot.) The section has a slight perl slant to it, but is really about the interpreter and compiling / running Parrot code. It is a fairly complete reference to the different parts of PASM (Parrot Assembly Language), and its role in porting languages to use Parrot. A comfort with assembly language basics is assumed in these sections, as the syntax and concepts of registers and machine code are made easier with general assembler familiarity. This part was somewhat dry for me, as it reads more like a reference than anything else, but it covers the topic fully without droning or leaving anything out. Examples are abundant and range from the simple, to the integrated, and are enough to get people started programming and writing tests with Parrot bytecode.
It should be noted that this book is valid and accurate now, but any development project can make changes quickly. There are places where the authors have admitted that a feature isn't in stone, and is possible to change. According to chromatic, an editor for O'Reilly, the plan is to update the book once a year until Perl 6 is released. Until then, a great place to keep up to date for the casual observer is at the p6p digest. This book goes down a lot easier than the Apocalypses, RFCs, and Exegeses, and I'd heavily suggest it to anyone who is serious about being ready for 6 or joining in on development . I preordered it from Amazon when I saw it was coming out, and am quite happy with my investment.
Table of Contents- Project Overview
- The Birth of Perl 6
- In the Beginning . . .
- The Continuing Mission
- Project Development
- Language Development
- Parrot Development
- Design Philosophy
- Linguistic and Cognitive Considerations
- Architectural Considerations
- Syntax
- Variables
- Operators
- Control Structures
- Subroutines
- Classes and Objects
- Grammars and Rules
- Parrot Internals
- Core Design Principles
- Parrot's Architecture
- The Interpreter
- I/O, Events, Signals, and Threads
- Objects
- Advanced Features
- Conclusion
- Parrot Assembly Language
- Getting Started
- Basics
- Working with PMCs
- Flow Control
- Stacks and Register Frames
- Lexicals and Globals
- Subroutines
- Writing Tests
- PASM Quick Reference
- The Intermediate Code Compiler
- Getting Started
- Basics
- Flow Control
- Subroutines
- IMCC Command-Line Options
- IMCC Quick Reference
You can purchase Perl 6 Essentials from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This one is a great addition to the book shelf, you all know how to do certain things in Perl 6 but this book clarifies nicely why you are actually doing it. Also, it introduces nice new perl concepts which hardcore perl 5 scripters might not have come across before.
There is no god
Amazon has for $2.50 less than bn (almost 15% less!)
So that's what... like 100 pages of the string "Smoke crack" repeating?
print "Smoke crack" x 1000000 .. hey, that was pretty easy.
It's $4.50 cheaper at bookpool.
They're also doing a free shipping deal.
-Dave
Bookpool.com rocks:l +6&Go.x=0&Go.y=0&Go=Go
http://www.bookpool.com/.x/t2y2rmrlx8/ss/1?qs=per
$15.50USD
There is no real way for you to figure out how many websites use Perl but you could figure out how many are hosted on Apache. Then you can assume that if they are running Apache then their server probably has Perl installed. ...so you can get a count of sites that might possibly be using perl! Oh, and I use perl in my sites so there you go, add one to your count of sites that use perl.
>limited in what you can do. This is because Perl isn't OO (so you
>can't create Node classes, for example, usefull in a linked list) and
>because it lacks pointers. Some of you may notice that PHP lacks
>pointers, but look deeper! Behind the scenes, hidden from the user
uh.. some might even notice that Perl does NOT 'lack ponters' -
what do you think all those \$a, \@b, \%c are ????
sigh...
Agreed. This is especially important in the free software world, where every advantage we can get we need. With all these languages abounding, there is a divide in our community.
You sir, are a f'in nutcase, that or I hope this was meant to be parody.
Perl is vastly superior to PHP for these core reasons:
*Perl is more standardized, due to it's greater history.
*Perl is installed on a larger variety of systems and comes in some version on almost all unix systems
*Perl has better DB support, DBI & it's associated DBD modules, it doesn't rely on DB-specific commands, it uses a standardized Database Interface module thus making porting between DB servers exceptionally easy.
*Perl has structures, objects, plenty of OO support, it's not wonderful but I can accomplish anything I need. Nested Hash Tables are a true god send. Complex data structures are easy in Perl, not so in other languages.
*Perl has better string manipulation
*PHP used Perl as part of it's basis
*PHP embeds itself into HTML which violates the OSI model for programming, by not abstraction the presentation layer.
And so on...
I'm too tired.. someone else finish this punk off.
I don't absolutely hate it, but I think that it is pretty bad. I wrote pretty readable perl when I was active (I like to think), but you could do some really horrible stuff.
I particularly don't like the automagic variables springing up all over the place and don't get me started on "bless" and the class system.. gha... I've even had it commented to me that I could use $_ where in fact I had opted to be explicit, which really irked me. "You want me to make the code less readable?"
And all that bullshit justification about "less to type" you'll hear.. I've never been bound by the speed of my fingers seen over the duration of a project. Sheesh.
(and no, I don't care what issues has been solved in Perl 6 -- I hope I'll never have to use it again)
Belief is the currency of delusion.
Those of you unfamiliar with Perl history may find it interesting that the "Parrot" started out as an elaborate April Fool's day joke two years ago. Here is the book that was announced. Strangely enough, people found the idea useful and are now actively developing it!
Slashdot's first reaction to VMware
It may come as a surprise that within the pages of 'Perl 6 Essentials'lies what could be two books
Not really, but what does NOT come as a surprise to me is that we have yet another glowing book review with a bn.com affiliate link. I've seen far too many glowing reviews on this site, about books that I know to suck donkey balls, to trust the reviews here anymore, especially knowing that readers are more likely to follow affiliate links when the review is positive than when it is not (And this from the same site where people so often rip stock analysts for writing glowing reviews of companies that garner their firms big i-banking fees). I wouldn't trust a movie review if I knew the reviewer was getting paid every time people went to saw the movie, and this is almost the same thing. Maybe Slashdot should put up a disclaimer...
If I see a book whose title sounds remotely interesting reviewed here, the first thing I do is go directly to amazon, and check out their user reviews. At least there you'll potentially see a bunch of negative reviews, instead of a chapter summary and a "this belongs on every Perl/PHP/Mysql/Linux geek's bookshelf".
You know, some programmers write things other than web pages.
Perl 6 Essentials is a sneak-preview of Perl 6, the widely-anticipated rewrite of the Perl programming language. Still in development, the Perl 6 project is a community-based effort to keep Perl vibrant well into the 21st century. This book covers the development not only of Perl 6 syntax but also Parrot, the language-independent interpreter developed as part of the Perl 6 design strategy. Although Perl remains a vibrant language with a fiercely loyal following, it has undergone many changes to keep up with new technologies and applications that were not anticipated when Perl was first introduced in 1987. Through its community-based development model, Perl has kept up with changing times and remained fresh when other languages might have stagnated. Internally, however, there have remained kinks and stumbling blocks that developers have needed to sidestep, long-abandoned features that have been maintained only for backwards compatibility, misdirected phrasings that have hindered more intuitive syntax structures, and a cacophony of modules that sometimes work well together, but occasionally don't. Perl continues to have a strong following devoted to its development, but in the meantime, a group of core Perl developers have begun working on Perl 6, a complete rewrite of the Perl language. While Perl's creative philosophy and common-sense syntax are sure to remain in Perl 6, everything else in the language is being re-examined and recreated. Perl 6 Essentials provides an overview of the current state of Perl 6 for those who await its release. Written by members of the Perl 6 core development team, the book offers an explanation of the various stages of the project, with reference material for programmers who are interested in what changes are planned or who may want to contribute to the project. The book will satisfy their curiosity and show how changes in the language will make it more powerful and easier to use. Perl 6 Essentials is the first book that offers a peek into the next major version of the Perl language. This book is essential reading for anyone interested in the future of Perl.
Bethanie: Whore...
Fan Whore
okay, first off: Perl owns you.
now that that's out of the way, I like Perl because it gets the fuck out of my way. once you've got a grip on the syntax (which, despite the whines of those whose brains have been dulled by Python syntax, is uncomplicated and consistent), programming in Perl becomes like writing pseudocode. easy. it reminds me of programming in BASIC back in the day -- carefree.
not like Java, where you're plowing through Java In A Nutshell to find the right class method to do what you need every other line. not like C, where you're walking a tightrope between null pointers and memory leaks the whole frickin time. in Perl you write what you want the program to do, and it does it.
in other words, it's a high level language, as opposed to being one or two steps above asm.
"$_" is a perl pronoun. Anyone that actually KNOWS any perl, doesn't find the use of implicit pronouns at all confusing, or unreadable, the same way that anyone who knows the english language doesn't find pronouns at all confusing.
If, in response to your message, I say "You obviously never knew perl very well to begin with", it is very easy to use the context of this post to know that "You" refers to the author of the post that I'm replying too.
In the same way, in a statement such as
foreach ( @array ) { print }
It is extremely obvious, to anyone who actually knows perl, what "print" is refering to.
Saying "you can do some really horrible stuff" in Perl in fact tells me that you probably don't know much about programming, at all. You can "do horrible stuff" in *any* programming language. Over the years I've seen more than my fair share of horrible C, C++, Java, Ruby, Python, Smalltalk, PHP, and yes, even Perl.
I currently am working on a Perl project that is up over 250,000 lines of code, and has been in development for two years. The code is all maintainable, and easy to understand, even for new people starting on the team with no prior knowledge of the code.
Maybe you just suck.
So, how many editions should we expect?
Opinions my own, statements of fact may contain errors
Of course, if you just go read the Apocalypses and Exegeses on perl.com and the FAQ on parrotcode.org, you get all of this for free.
When I started using Perl 5 I figured it to be about 10 years ahead of its time. Being about 5 years since then I think I was pretty close to right.
Development of it is taking a long time but it has been worth it.
Some peoples minds don't seem to fit Perl 5 quite right and complain about it. Should have a lot more options of languages and style in P6.
Its a blazingly fast byte code interpreter. Having this Open Source is a very powerful thing and something many projects will find useful.
Excellent points, thanks. I'll just add a few notes:
- Don't forget that Perl is bright blue, while PHP is dark green. If you have an aversion to bright blue, you should definitely code in PHP.
- Three out of four gnomes script their underwear-cart code in PHP; Perl gets sticky on hot days.
- Perl behaves badly under zero-gravity conditions; PHP will actually make your computer lighter. The benefits of this should be obvious to everyone.
Really, there's no competition. PHP is the obvious choice - and its emissions are less fattening, too.
-- http://frobnosticate.com
For the love of god, don't use PERL. We are thirty years out of the seventies....
exactly. thirty years and we still can't fucking get past C. isn't it time we start using languages designed for humans and not machines?
If you've been keeping track of the Parrot project's progress for the past 2+ years you'd see that they're going nowhere fast. No language implemented other than a toy Basic language, no thread support, no object support, no exception support, no stable standard calling convention, no code module support (like Java .jar files), a proliferation of stupid one-off opcodes that should be method calls - and worse of all - no working Perl support. As for Ponie/Perl5 on Parrot - I'll believe it when I see it - this Parrot project blows more hot air than a thousands hair dryers. Tell you what - give me the $200,000 that they've been given and I will write the Perl6 interpreter for them. A lot of better open source projects have been written with little or no funding at all. There's no excuse for the pace of this project - it's directionless and leaderless.
> what do you think all those \$a, \@b, \%c are ????
:-O so that means they "mean something".
Random selections of characters aren't they ? Oh shit, we're talking Perl arent we
(FYI, I posted this on the thread for this book's announcement.)
..." is a discussion and tutorial on a topic, intended for beginners ..." is the same, but for intermediate and advanced users
Understanding O'Reilly titles can help you decide which blue book(s) to purchase. Just as they have conventions for the books' color (e.g. Perl blue, Java purple, security yellow), O'Reilly and Associates has conventions for the titles.
* "... Essentials" means an overview of what's new.
* "Learning
* "Programming
* "... Cookbook" is a series of problems and their solutions
* "... in a Nutshell" is like a language reference
* "... Pocket Reference" is a shorter version of the above
Joe
http://www.joegrossberg.com
This book isn't about Perl 6 at all, and there's nothing about it that's "essential." Part of the book is about the *plan* for Perl 6, but that's just plain silly. Who wants to read about the plan for some that's in the middle of development? Odds are that much of this part of the book will be completely invalidated long before Perl 6 is actually released.
The rest of the book--most of the book, actually--is about the Parrot virtual machine. Now, really, does this matter to Perl programmers at all? Is there a book about the innards of the interpreter used for Perl 5? Or a book about Python bytecode? It only matters if you're going to write a compiler that targets Parrot. And, again, note that Parrot is also a work in progress and will likely change dramatically before Perl 6 is actually released.
In short:
1. This is a book about vaporware.
2. Most of the book is not about Perl 6.3.
3. Why did O'Reilly even bother with this?
I was writing in a combination of Java and Perl on a Linux system. PHP is a wonderful scripting language to work with. While Java forced me to write clean code, the clean Java code sucked up memory and was slower than molasses on my Apache 1.3.26 server running Resin. I had to dumb down my Java code to speed it up. When I did that, the cleanness of Java went away.
What I miss about Perl is being able to write obfuscated spagetti code so unreadable that I had no idea how the code functioned 3 months later.
I also miss all of the broken and largely alpha and pre-beta modules on CPAN.
Will it be released at the same time as HURD?
No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
...interesting if true.
No, only the really clever stuff does...
"Faith: Belief without evidence in what is told by one who speaks without knowledge, of things without parallel." - A.B.
I think the plan is important in the sense that the it gives members of the community an idea of what's going to happen who haven't been following it that close.
As far as delving into the guts, yes there is a book about the innards of perl5 Extending and Embedding Perl. A good read actually. I myself am looking forward to a refactored implementation. perl5 isn't too pretty inside the bowels.
-William Shatner can be neither created nor destroyed.
Yeah! 'cuz if we don't write all our software in the same language, the OSS movement is doomed!
WTF are you talking about? Divide the community... it's about the software, not the language. Who gives a damn if the code is written in Perl, Python, Ruby, or, heck, shell script, as long as it does something useful?
My website (hosted by windows 2k/IIS) uses perl.
:-)
That's really sick.
That's like using IE on *nix/Wine.
While I tend to prefer Perl as well, many of your reasons for prefering it are not entirely informed...
"* Perl is more standardized, due to it's greater history."
Not really sure of the point you're trying to make here. Niether project really has a standards body behind it. Perhaps you mean Perl is more accepted.
"* Perl has better DB support..."
Granted, although PHP provides a DB abstraction layer in Pear now, which all good PHP coders should be using...
"* Perl has structures..."
Some would say this is a bit ad-hominem, with the "not so in other (which?) languages part, but others would say the OO part is Perl's weakness. Either way, both languages (Perl in 5, PHP in 5) are working to improve their OO models.
"* Perl has better string manipulation"
True. Probably why PHP apes it in some respects.
"* PHP used Perl as part of it's basis"
This isn't really a good reason, since the obvious rejoinder is "ah, so PHP is an improvement on Perl then?". At any rate, its a bit silly to pick on another language for appropriating the good parts of other languages when you like Perl. Pot, this is Kettle, over, you are BLACK!
"PHP embeds..."
You mean, kind of like Mason with Perl? Really "violations of the OSI model" aside, this tends to be WHY PHP is so popular, because its very easy to use to do the odd simple thing because of this. Yes, you run into the problems with it when you start to do a larger project (which is why there are all those PHP template systems, I suppose.) but why deride something that works very well for the 80% of cases that are out there. It's also entirely possible to use PHP as a non-HTML-embedded language, of course.
That being said, I'd choose Perl in a heartbeat over PHP for a large project, particular one not Web related, for a number of reasons.
* Far better support for modules, and a much larger library of solutions already available.
* Some speed related issues out of the box.
* The afore mentioned string manipulation issues.
* Better ability to do things like signal handlers, and other "Unixy" things.
* What IMHO, I consider better language/character set support.
What is the background of the programmers who wrote the Perl code you're criticizing? Sysadmins with 5 minutes to get something done or professional programmers who negotiated time for proper design to be included in the development time?
And what are the goals of the Perl coders who wrote that garbage? To combat reverse-engineering and theft of code by unskilled script kiddies, some use obfuscators for deployed code while keeping easier-to-maintain versions private. Almost but not quite like keeping C/C++ source private while distributing binaries.
In general, I can point to C, C++, and even Visual BASIC code and make strong statements about them being obscure unmaintainable garbage. Lets face it, most programmers (even the ones with computer science degrees from respected universities) truly suck and have no business coding for a living.
When I saw Perl code, it made me stay away for years because it wasn't "obvious" compared to other high level languages. Out of curiosity, I read the first few chapters of Programming Perl and came to realize that I've been missing out--the same Perl code that initially looked like garbage actually made sense and looked very elegant because it didn't force the programmer to jump through hoops to "get stuff done".
If you've read & understood that book and still see unmaintainable Perl code at your company, maybe it is time to push for some coding standards.
Given Perl's extensibility, you can even have exception handling similar to Java's throw/catch/finally.
Again, nothing stops Perl programmers from using coding standards that enforce naming conventions, use of the same exception handling library, etc. The fact that they don't choose to doesn't reflect on the language but on the coders and the circumstances (having only 15 minutes to write a quick utility to fix a problem) which led them to write unmaintainable code.
Write a glowing review, and post a link and watch the balance in your affiliate account grow! What's wrong with making some spare change on the side? Except, the original review is tainted - it can't be objective because the author has something to gain.
Did you know that many retail stores make more income off the interest on their credit cards than they do off of what people buy directly out of the store? There are whole industries built on deception - and what they appear to do and what they actually do are two different things. Follow the money and you'll see what they actually do.
Have you tried 'use strict'?
What's wrong with bless? It's just a way of telling Perl what class an object belongs to. Any OO framework needs something equivalent. C++ does it at compile time, but I think the Perl approach is cleaner because a distinct keyword (bless) performs a distinct operation (marking the class of the object.)
If you are looking to convert perl source into java source, then you are probably totally out of luck though.
Well, this seems to be the main reason behind all those "Perl is unreadable" complaints:
People who don't know Perl have more trouble reading Perl code than people who don't know, say, Python, have trouble reading Python code...
Yeah... I came to the same conclusion... I would have though someone would have tackled the problem before now though...
Admittedly, my response is coming from the perspective of someone who is very happy with Perl, despite it's shortcomings. I've been programming in Perl for almost 4 years, and have only dabbled in PHP (though my brother has used both extensively and prefers Perl greatly). However, some points of your argument are flawed, so I hope to clarify a few things. I'll just address each point:
/home/` or something, which is stupid to do because system calls are extremely slow and can usually be handled with perl commands that aren't platform specific), you shouldn't have to change anything else.
* Ease of use. I knew Perl before I tried PHP, so I can't really say which is easier. Both were very easy because I knew C and C++ before either one.
* The OO of PHP is excellent. If this is true, then PHP must've vastly improved since I used it. When I did, it had very weak OO support. Despite the odd syntax of OO in Perl, it is a very excellent OO language. I wish it did have a few more features, but they are to come in Perl 6.
* Outstanding database support. This is just patently wrong. Perl has vastly better DB support through DBI. PHP has modules specific to different DBs, but DBI is an excellent abstraction layer that has an implementation in every DB I've ever heard of (Postgresql, mysql, msql, oracle, etc).
* Speed. PHP is faster than CGI perl in a web environment, but in my experience perl is faster in server scripting. Mod-perl is equally fast to PHP in a web environment, so the whole point is moot.
* Portability. You must not know how to program if you can't port your perl code across operating systems. The only thing you might have to change is the location of the perl interpreter (the #!/usr/bin/perl line). Unless you're using system calls (like `ls
* Graphics. There are many graphics modules available on CPAN for perl. I honestly don't know how the implementations compare, but they both have them.
* Data Structures. Perl supports complex data structures also. I'm not familiar with all of those structures you mention, but I'm fairly sure (if memory serves me on all of the definitions) that Perl does linked lists, hash tables, and queues at the minimum. Also, Perl has pointers, though I believe they refer to them as "references" (not to be confused with references in C++). The syntax is a bit different, like if you create a hash (aka associate array) %hash and then pass \%hash into a function, on the other side you'd have $hash (a reference to %hash, references are written as scalars). Then if you want the "stuff" key, you can do $hash->{stuff} or $$hash{stuff} (antiquated syntax) to retrieve it. Same goes for arrays. It also has a fairly robust OO implementation, once you get past the obvious hack syntax utilized for it (since it was added after the language was written, Perl 6 will correct this).
It seems obvious to me that you didn't spend much time trying Perl before you gave up and moved on. Maybe that's an unfair assessment, but most of the limitations you perceive in Perl just aren't there.
Neither are you mate, no, not pretty at all, at all.
In the same way, in a statement such as// foreach ( @array ) { print }// It is extremely obvious,
The only thing that's obvious to me is that the code example you gave is a poor way to write "print @array;" The urge to be clever is way too prevalent in Perl.
I do not have a signature
Turn my world upside down, hurt my brain, then expect me to shell out .... Oh. Only 18 bucks? Ok then. Never mind.
The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.
Just rewrite the code, you lazy ass. ;)
You wouldn't want non-OO Perl being directly converted into Java equivalence anyway-- the whole point of OO design is to abstract things and make it easier to maintain and modify the source code after it has been created (software engineering practices). A sloppy program-ported version of your Perl code into JSP or whatever would probably be a NIGHTMARE to support.
not "poor", just different. TMTOWTDI.
No, that is print "@array"
I'll thank you for not pondering about the :P
attractiveness of my internals.
-William Shatner can be neither created nor destroyed.
Probably noone. Though, Perl is very common.
:)
The distinction is that it isn't called PERL, it is Perl. There once (a short while) was a Perl ripoff called PERL that was a bit similar, but without all the features that makes a maintainable and secure application possible. If anyone is curious, you could have a look at Acme::Inline::PERL at CPAN, which brings the power of PERL to Perl. Yes, the ACME:: namespace is for sillyness and joke modules.
I buy my books on Book Pool and they always has it for less than Amazon. http://www.bookpool.com/.x/r45rkojm50/ss/1?qs=Perl +6+Essentials+&Go.x=13&Go.y=4&Go=Go
PHP is such a kludge that it makes Perl seem like a good design.
There are things I like about Perl, and on rare occasion I still like kicking out Perl scripts for text processing and the like. Heck, even Microsoft used Perl extensively for all of it's Build and Unit Testing for their shared source implementation of .NET.
However, for a software application (and this includes web applications) I've contended that scripts suck. This definitely includes Perl. I don't care what Yahoo or Google is doing with Python or PHP, and I don't want to get into those particular case studies as it will open up a can of worms and it deviates from my argument. When you say that you spend a lot of time messing with Java class libraries trying to lookup which API to use for a certain function, I have to ask, "what IDE doesn't practically type that for you?". Okay, so you're using emacs. Well, than go back to Perl, and try to remember which of the 1,000's of Perl modules you need to load, or worse, just reinvent the wheel.
The benefit of Java, C#, etc. is that you are almost as high a level as a scripting language, but you have most all the power and structure to allow you to write scaleable software applications. Compilation is trivial and can be JIT'd like Perl, and strong typing is actually a good thing that speeds up development, contrary to popular belief.
I mean really, have you _SEEN_ slashcode? Perl and other scripting languages have their place, but not for applications.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
in other words, it's a high level language, as opposed to being one or two steps above asm.
But as a functional language, Perl lacks structure, but makes up for it's very free form nature. Just today I was converting a query from Perl to C. Perl's version of the query was approx 150 lines. C was close to 1000.
I'm learning Python now, so I can get a high level language with a bit more structure(i.e. datatypes are much more explicit). I'm aware that Perl has objects too, but it seems to me it was never an integral part of the language.
Tell you what - give me the $200,000 that they've been given and I will write the Perl6 interpreter for them.
How will you write the interpreter for a language that is still being designed? This may be part of why Parrot is going nowhere...there is nowhere well-defined to go!
What's with all the anti-Perl flamebait? It's fine to prefer PHP or Python or whatever, but at least give Perl the credit that it's due. It's fast, really truly cross platform, widely distributed, open source, munges text like nothing else, was the first decent backend to websites, and has a bunch of useful design patterns built into the language.
And regular expressions, too! Like Perl, you may hate the syntax but but you've got to love the power. Ah yes, it's like one of those fire-breathing car-crushing truckosauruses... ugly but mighty. I heart Perl.
(Before you hit reply, yes, I am aware of the bad aspects of Perl. But most of them are optional, and I can live with the ones that aren't.)
Vino, gyno, and techno -Bruce Sterling
But it's here, now. Arguably one of the most cross-platform, complex Open Source application. Just have a little faith with Perl 6. You might not like it, but many will, just like mozilla.
Excellent responce
HenryJamesFeltus.com
Sometimes one of the ways to do it really is better.
I do not have a signature
Is it not true that most Free Software projects
start small and then pickup exponentially? Debian
had less than 70 develpers for several years,
today there might be 1000 developers. Or, how
about testing the the 2.6 kernel? Most people
do not test the kernel until the release date
gets closer, at which point traffic and bugfixes
also increase exponenttially.
That's Fotango, who deserve a huge thanks from everyone who cares about Perl 6.
Chris
M-x auto-bs-mode
Except that those do different things unless you flog the field seperator to "" first.
OK then: print for @array; #the idea here is that we're printing something, not that we're doing something with each element of an array, so let's get the print at the front if we can.
To my way of thinking, changing default values of those kinds of global values (like $,) is a bad idea and should be confined to very specific blocks as needed by using local. That way people can use built-in functions in other pieces of the code without worrying what you've done to the defaults somewhere else.
I do not have a signature
a Perl5 book, buy something else.
So what if Perl6 is not ready. If I was interested
in the Unified Theory, I would buy an appropiate book for
the topic; or do I first have to wait until physists
finaly decide whether the theory is valid or
invalid?
These are references, not pointer.
Following the Perl 6 development process is a lot like that. You gain some appreciation of how all those indispensible but ultimately hidden services were actually put into place. Then maybe you will be able to use them with a bit more insight and respect.
-- Our systemic servants do not good masters make.
complain that the language is "strange". If
I know Chinese, I would insist that the language
is just natural.
Perl takes years to learn. That is why it is
so powerfull. Can you imagine how usufull
French would be if you could learn French withing
days? Simple languages are practically useless.
(Please correct me if wrong). As for Perl6,
it is impossible to judge ahead of time, unless
of course, you are too eager to spread FUD, much like Caldera,
and you keep your reasons a secret.
I have taken the trouble to study the Perl6
features, and I even know Parrot Assembly, not
to mention that many Perl6 features have
been available as Perl5 for years! I am still
waiting to hear why the project is ill conceived,
which unlike Topaz, it enjoys the support of
most p5p (perl porters), they are the very
same people who wrote perl5. If anything, the
past history is a one of atchivement and success,
not (as you claim) one of failure.
there was an attempt to rewrite the kernel
in C++. Although that attempt was a failure, did Linux
turned out to be a failure?
We will judge when it arrives. I am just suspisious
of people who arrive to speak ill about other
people's projects before completion, especially,
when these people have a prior record
of achivement.
You're full of it it! \$a isn't a pointer, it's a reference... Oh wait, nevermind. :-)
most of your comment show your lack of knowledge for both PHP and Perl, and You should not post if you don't know anything about what you speak. Sorry for trolling, but there is a lot of errors in your post. Please learn more about web programming before posting such messages. I'm shoked to read such messages on Slashdot.
Perl takes years to learn. That is why it is so powerfull. Can you imagine how usufull French would be if you could learn French withing days? Simple languages are practically useless.
I was trying to say just that. I was criticising people who don't know Perl yet depreciate it because it looks "stranger" to them than e.g. Python looks to people who don't know Python.
> Perl is old news.
:-D. Yeah. Well with Parrot, you'll be able to write your super-high-level code that doesn't need to worry about such things in Ruby, but then write your lower-level code in a language which gives you more control, and compile it all down to Parrot byte code. I expect that Perl 6 will allow a bit more optimisation that Ruby does.
>
> Ruby.
Personally I love Ruby. It's great fun to program in. There's one thing I don't like about it, though: anytime you want to do ANYTHING, you have to do a method call. That means you have to take some object, and look through one or more hash tables of method names => methods. You can't evel 'call' a piece of code without looking up its 'call' method. I'm sure that hurts efficiency quite a bit. What would be nice would be to use Parrot-style vtables for common operations like get-subelement, get-attribute, call, etc. (however I think Parrot's gone a little overboard with the huge Vtables... Maybe there should be a 'mini' version of the Vtables or something...) So instead of saying
object.call('param1','param2',etc)
you could say (assuming 'CALL' is some kind of keyword)
CALL(object,'param1','param2')
or maybe even
object.CALL('param1','param2')
'CALL' would be recognised by the compiler as a lower-level method call. No method names to deal with, so it's much faster
Sorry. That was incoherent (ant? whatever) and vaguely off-topic. Mmeh.
Duct tape, XML, democracy: Not doing the job? Use more.
If Perl is old then Ruby's just a baby.
Ruby says "bwarghhhhh!"
Karma: Bad due to google bombing - Robert Watkins woz 'ere.
but not in this case.
No. This is exactly one of those cases. The benchmark clearly favors using print LIST over a for loop.
Rate foreach print list
foreach 107043/s -- -82%
print list 592417/s 453% --
It's 5x faster AND more readable to use print LIST. If you want to persist in the delusional use of overly clever constructs without a good reason, be my guest, but you are just making your life more difficult along with the lives of anyone who has to use or maintain your code. BTW, none of this should be construed as blanket condemnation of $_ or any other clever Perl construct. In many cases the implied or context sensitive constructs in Perl are a major win in terms of writability and readability. Had the ACs example contained a map or done something more interesting with each element of the array than just print it out, he/she would just as likely have been right on the money.
I do not have a signature
...but then, if you were worried about speed, you wouldn't be using perl.
come on. get a hold of yourself.
But what do I know. I'm just looking for anonymous gay sex.
It's not the raw speed that's at issue here, it's the relative speed. And I don't know that I believe that Perl is all that much slower than any other language once a script is loaded into the interpreter and set in motion. It's that startup time that makes us think it's so slow, mostly.
I do not have a signature