Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Perl Books Media Programming Book Reviews

Perl 6 Now by Scott Walters 366

Joseph Brenner writes "Every now and then, a beginning programmer asks if there's any point in learning to program in Perl 5, when Perl 6 is going to change everything soon. There are a number of answers to that: one is to point out that Perl 6 is still years away, another is to point out that it is promised that Perl 5 code will run under Perl 6 without modification (a module that begins with the traditional "package" statement is Perl 5 code; if it begins with the new "class," then it's Perl 6)." Read on for the rest of Brenner's review of Scott Walters' Programming in Perl 6 style using Perl 5, a book which answers that question a whole different way.
Perl 6 Now
author Scott Walters
pages 379
publisher Apress
rating 7
reviewer Joseph Brenner
ISBN 1590593952
summary Programming in Perl 6 style using Perl 5


Scott Walters here pursues what might be thought of as the third answer: you can learn Perl 6 now and immediately begin writing programs in a "Perl6ish" sort of way, using appropriate CPAN modules that have been used to implement approximations of Perl 6 behavior: Perl6::Variables, Perl6::Export, Perl6::Contexts, autobox, Perl6::Classes, Switch, and so on.

There are many caveats about using these tricks in production code, however, and Scott Walters doesn't shy away from warning you about them (e.g. p.43 "Source filters are dangerous" where he discusses their increased start-up overhead and potential bugginess -- though he doesn't mention my own peeve which is that they're very confusing when you try and use the Perl debugger).

So possibly the book is not really quite so well suited to an actual beginner-- who probably should not be told about "use Switch 'Perl6'", but the device of spending the early stages of the book directed toward a beginning audience makes it a very useful review for people like myself who have been reading the Apocalypses, but don't remember every detail.

And on the other hand, the book includes some prominent early warnings about common gotchas that beginning programmers seem to be prone to -- e.g. using dynamically defined variables instead of just using hashes.

The standards for writing English in the Perl world are pretty high -- the core members of the Perl community have always cared a lot about clear writing, and it's arguably the world's best documented language (critics will no doubt add that it needs to be). Unfortunately, I can't say that Perl 6 Now quite lives up to this standard. This is a book that was written in a hurry, and it shows: hasty sentences and minor organizational problems abound (e.g. one or two items seem to be discussed in the wrong place; there are an awful lot of explicit forward references, and yet there's at least one place where something was used in an example before being discussed a few dozen pages later). But then in Scott Walters defense, this is certainly a book that needed to be written in a hurry, because its subject matter is such a moving target.

And where the book really shines is in its code examples: short, clear and to the point; the author repeatedly shows how something can be done in Perl 5 code and how it's expected to work in Perl 6. These examples are always clearly labeled "Perl 5" or "Perl 6" in the comments, so that the two can't be confused.

The subjects of some of the examples are pretty cool: e.g. he talks about using PDL ("Perl Data Language") to crunch audio data in MOD format, which I was completely unfamiliar with. A *.mod file essentially contains the "sheet music" for multiple parts (really, MIDI) plus sound samples that specify how notes will sound for each voice. This is discussed in Chapter 7, which is also the free sample chapter. I also liked random walking Arizona's highways as an example of Graph navigation (Chapter 8, p 159), and I appreciate the fact that he downplays inheritance in favor of delegation in his discussion of objects (Chapter 14, p. 262).

All in all, this book is a fun read for the Perl fanatic.

(Note: the title Perl 6 Now bears a strong resemblance to an emacs package I've been working on called perlnow.el, but there is no relation.)


You can purchase Programming in Perl 6 style using Perl 5 from bn.com; it's also available in eBook format (password protected PDF, using your email as password) for $15. Source code and and a sample chapter are available online: Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Perl 6 Now by Scott Walters

Comments Filter:
  • PHP5! (Score:5, Funny)

    by Douglas Simmons ( 628988 ) on Wednesday August 17, 2005 @02:09PM (#13341625) Homepage
    I hate to be Jonny Raincloud, but pretty soon PHP will be able to do whatever perl does, if it's not there already. And anything that it can't do that perl can will be obsolete. So no, don't waste your time learning perl 6. Do the right thing and brush up on your PHP5. I got my site to print in any font I want the time AND date, powered by php, baby!
    • Does PHP have the equivalent of CPAN?
    • Re:PHP5! (Score:2, Interesting)

      by utopianfiat ( 774016 )
      s/(1|2|3|4|5|6|7|8|9|0|one|two|three|four|five|si x |seven|eight|nine|ten|eleven|twelve|thirteen|fourt een|fifteen|sixteen|seventeen|eighteen|nineteen|tw enty|thirty|forty|fifty|sixty|seventy|eighty|ninet y|hundred|thousand|million|billion|trillion)/<b>\1 </b>/g

      Look, I'm violating patents! [slashdot.org]
    • I am not sure this troll even knows what perl is. I suspect he thinks its just for web pages in cgi and the like, which is as far from the truth as it gets.
      • Perl users are happy when it gets used for EVERYTHING and anything, its like, shit, I have spent all this time learning, now I want every technology to be doable in Perl! 3d, yes, internet sites, yes, databases, yes, write one in perl. operating systems, yes, write one in perl!

        PERL is very scripty and cgi'y. I used PERL (sorry perl) while doing some basic CGI about 6/7 years ago.

        Never used it since. Have used PHP since... don't use either. All Jsp, Java SE, JSF and Python now.

    • You're joking, it's not PHP that Perl has to compete with, it's Python! PHP will always be slower than mod_perl 2 on Apache2 (bbc.co.uk runs on this and it is a monster), but Perl's primary use is not for server scripting (mod_perl) but as a power tool. Whenever you need to do something with your system beyond the power of shell scripting, use Perl;
  • there are an awful lot of explicit forward references,

    Are these always bad? I've been having the same trouble with PMD Applied [pmdapplied.com]; when I'm in an earlier chapter babbling about the XPath rules it seems really convenient to say "and if you want to learn how it _really_ works, check chapter 9 for a nuts and bolts description of DocumentNavigator and AxisIterators and all that". But I hesitate to add notes like that because folks don't seem to like them. Seems handy at times, though...

    • Backward references are always better than forward references. That's why in my FORTRAN days I often argued that we could replace GOTO statements very easily if we simply added a COMEFROM statement to the language instead:

      10 MOL = 42
      DO 20 I = ID+1, X
      X = H * 0.5
      SUM = SUM + F(X)
      20 CONTINUE
      IF (
    • there are an awful lot of explicit forward references,

      Are these always bad? I've been having the same trouble

      Well no, of course they're not always bad, and they're certainly not always avoidable... no subject is easy to completely linearize the order of presentation, and even mapping one to a hierarchy can be pretty tricky. A lot of them can be pretty irritating/confusing though, and in general you try and minimize them where you can in technical writing.

      Have you heard Larry Wall's story about

  • by Sweetshark ( 696449 ) on Wednesday August 17, 2005 @02:11PM (#13341643)
    The standards for writing English in the Perl world are pretty high -- the core members of the Perl community have always cared a lot about clear writing
    Yeah, right. Why should one obfuscate English, Perl offers much more possibilities to do so.
    • I wouldn't call that obfuscation. I'd call it a language that puts too much emphasis on clever and complicated idioms. It's designed by people with a good understanding of language, but are more concerned with having fun than with expressing themselves clearly.

      And that's what's wrong with the standard Perl books too. They don't resort to the nasty clunkspeak that's standard for bad technical writing. But neither do they write well. There are too many humorous asides, the material is not well-organized, an

  • CPAN (Score:5, Insightful)

    by kevin_conaway ( 585204 ) on Wednesday August 17, 2005 @02:17PM (#13341705) Homepage
    I believe that CPAN is one of the major (if not the only) things keeping Perl alive and well.

    It is a great language, and has been used successfully by many huge companies (Amazon for one), but I think if those companies had to redo it again today, I don't think they would choose Perl again. I think that purely as a language, it has been surpassed.

    Having a large, mature 3rd party library is what is hampering the adoption of some of the up and coming languages.
    • Re:CPAN (Score:5, Insightful)

      by radtea ( 464814 ) on Wednesday August 17, 2005 @03:04PM (#13342160)
      I believe that CPAN is one of the major (if not the only) things keeping Perl alive and well.

      My own experience suggests this is absolutely true. I learned a bit of Perl in 2000, then had a look at Python, and realized that 90% of what I wanted to do, no matter what I wanted to do, was already implemented in Perl modules. Python, in contrast, had a a much, much smaller collection of stuff available. Despite certain nice features in Python, the abundance of pre-existing native functionality in Perl won the day for me.

      One could argue that Perl functionality can always be called by other languages, but I have extensive experience in mixed-language programming (C/FORTRAN, C++/Java and Perl/C++) and don't really want to deal with the debugging nightmare that it often entails. So given that I could do everything I wanted to in Perl and still live by Booch's Rule 122 ("Never write code unless you absolutely positively must"), Perl was the clear choice.

      The only likely replacement for Perl is Perl, as Perl6 will be able to draw on the huge community of Perl developers who have a vested interest in keeping the language alive and flourishing, and it is very likely that debugging from Perl6 into Perl5 will be relatively seamless.
    • Amazon chose Perl pretty recently, so I'd say you're wrong about that. I don't see the other major companies that use Perl extensively like Ticket Master, CitySearch, Overture, and Yahoo complaining about it either.
      • Amazon chose Perl pretty recently

        I'm pretty sure it's been a while now - I had a conversation with a recruiter from Amazon about perl around 6 years ago (and it was their main language then).
    • by Cyno ( 85911 )
      I have yet to see a language that surpasses it, except Perl 6. Java, Python, Ruby, C, C++, etc. All have their own problems and none of them can use my Perl 5 objects.

      Perl 6, on the other hand, might be able to use my Perl 5 objects, along with some Java, C, python, brainfuck, etc. libraries. If it gets to that point the bar for all other languages will have been raised, including .NET. But how long will it take to get to that point?...
      • Java, Python, Ruby, C, C++, etc. All have their own problems and none of them can use my Perl 5 objects.

        But is that a problem with those other languages, or with Perl?

  • by Seumas ( 6865 ) * on Wednesday August 17, 2005 @02:25PM (#13341767)
    I was going to bring this up in the thread about beginning programming the other day, but I came too late to the party. Hopefully someone can offer me some advice.

    First, I'm not really a programmer. Not professionally, at least. I've been writing Perl for about four or five years, though. I'm not well-versed in OO and I'd like to be. I've just found it such a stumbling block in Perl and that's probably because I'm doing in Perl in the first place. It's the first language I picked up since I played around with BASIC and Pascal as a little kid.

    I run a large auction site. Maybe 40,000 members. I wrote the entire engine (auction, forums - everything) in Perl. But it's getting complex and difficult to maintain as it is. And the performance is not holding up. I could move to mod_perl, but rather than re-writing everything (and possibly doing so in OO), I thought I'd just write it in another language.

    I don't want PHP. So that leaves me mostly with Python and Ruby. I've done a lot of reading, but am not sure which would be more appropriate. I think Python might stick me back in the old "easy to do things wrong and blow your foot off" world of Perl. Ruby on the other hand would probably help me gain a better understanding and real-world use of OO.

    Performance is an issue. So are available packages. My backend is postgresql and I need whatever language I use to have an extremely capable and flexible and mature postgresql DBI.

    At the moment, I have to say I'm leaning toward Ruby. But it does seem that Python might have more mature packages available to it and be a bit more widely used. I'm just skittish because everything I've heard has given me the impression that it's very Perl-ish and if I'm going to be in that world, I might as well just stick with Perl in the first place.

    Thoughts?
    • I think you would be better off rewriting it in OO Perl based on mod_perl2. You don't have to learn a whole new language(and the attendant kludges that one makes when writing an app in a language they are learning) and it will fast and stable. Plus, you can just transplant any neat little regexs and functions instead of reimplementing them. YMMV.
      • I second this. Going from straight Perl to mod_perl is a great step to make for the speed and functionality of your site. I think you might be surprised by just how much speed is possible with mod_perl.

        There are two ways to port an existing application to mod_perl; the fast way and the proper way. The fast way is essentially to take your entire existing application and make it one giant function within mod_perl. Try a quick basic port and see how much better your site performs once you do. I think you'll be
    • by Marc2k ( 221814 ) on Wednesday August 17, 2005 @02:43PM (#13341950) Homepage Journal
      No. Here's your main problem:
      First, I'm not really a programmer.
      I wrote the entire engine.
      But it's getting complex and difficult to maintain as it is.
      And the performance is not holding up.

      So you're admittedly not a very experienced programmer, and you're expecting to have the web logic engine that you built, presumably from scratch, be scalable and modular, without ever refactoring it? In programming, we call the kind of query you just gave a 'silver bullet' problem, and unfortunately, there is none in this case. No one language, or framework, for that matter, is going to fix problems inherent in poor design. That's not to necessarily denigrate your programming skills, but don't expect that rewriting an app that was developed from scratch and is exhibiting growing pains to see great speed and modularity gains by porting it to another language. I've got a good hunch that if you started all over again, still using Perl, and chose your toolset wisely, your app would be more stable, scalable, functional, and modular.
      I've worked with a lot of web languages/frameworks, and yes, Ruby would similarly solve the problem, but please don't ever say "real-world use of OO" with regard to Ruby. Rails is what, a year old? Basecamp and 43 Things are the largest sites actually running Rails (the latter being as esoteric as you can get, and pretty low-traffic, at that), and you're not going to see a major player using Ruby at this poing. If I take your meaning of "real-world" correctly, CORBA is more like what you're talking about, though I don't think you necessarily want to mess with that sort of thing right now.
    • I have similar experiences as you do, with programming languages, except I don't manage a large auction site.

      One of the things I've been learning lately, is that with Perl, there are ways to optimize it. I'm not second guessing your proficiency with perl, but if I was in your shoes, I have an idea what I would do.

      Have you ever thought of open-sourcing your engine? If some of the gurus come by and optimize your code, you would benefit immidiately and learn quite a bit in the process.

      Again, I don't know how
    • Performance is an issue. So are available packages. My backend is postgresql and I need whatever language I use to have an extremely capable and flexible and mature postgresql DBI.

      From the standpoint of integrating a website/database, the database will always be your substantial performance bottleneck, unless your code is utter garbage. PHP, Python, or Ruby are all adequate for this task.

      The biggest thing you can do for performance is design a Normalized database, and to make sure there is proper indexing
    • The points above about sticking with what you know make sense, but you admit that your site is getting hard to maintain. A framework like Ruby-on-Rails will likely alleviate a lot of the scalability and maintenance issues. If you've managed to hack together a functioning site with 40,000 members in perl, you won't have too much of a problem learning Ruby or Python. They both generally have One Well Known Way To Do It,

    • I don't know anything about Ruby, but I do program in Python a lot. Perl was my first experience with a scripting language. Coming from C, I was initially amazed at how nice it was to have strings be first-class data types and to no longer have to explicitly manage memory. The syntax was a little confusing, and I never really got proficient at it. I tried reading some OO-based perl and got totally lost.

      Some years later, I happened to try out Python for a project and fell in love. I find the syntax ea

    • I haven't worked with it, but Zope (zope.org) is written in Python. You might be able to transition to it by putting whatever content management type stuff you have in there while figuring out how to do whatever it doesn't do in python yourself. There are a number of commerce modules for it, don't know how easy it would be to modify them rather than just doing it yourself. I'm sure there will be a bunch of code you do yourself, but no sense reinventing the wheel for basic website stuff.
  • by defile ( 1059 ) on Wednesday August 17, 2005 @02:26PM (#13341777) Homepage Journal

    Everyone attacks Perl code for being unreadable but I don't think I've ever come across real world Perl code that I couldn't manage to deal with (eventually). I've seen some bad code and written some bad code and Perl doesn't have exclusivity in either of those areas. ;)

    Does someone have a good example of unreadable, real world Perl code? And I don't mean obfuscated Perl contest entries.

    When it comes down to it, other people's code is just freakin' unreadable no matter what they write it in. In fact, my own code looks unreadable and unmanagable if I haven't seen it in awhile. Just the nature of the industry.

    Maybe Perl is just a high profile target since the internet is full of small (and useful) pieces of Perl code?

  • by jjn1056 ( 85209 ) <`jjn1056' `at' `yahoo.com'> on Wednesday August 17, 2005 @02:36PM (#13341888) Homepage Journal
    check out "http://pugscode.org/"

    for a working perl6 compiler. Yeah, it is not yet feature complete, but progress is very rapid.

    Perl6 is really amazing. It removes most of the worst parts of perl5 and make things even easier on the programmer. If you do an research at all you can find that.

    Some people are even starting to port important CPAN modules to perl6 and discovering how much a pleasure it is to use.

    see http://www.perl.com/pub/a/2005/07/28/test_builder_ p6.html [perl.com]

    as an example of that.

    btw, check out the example code. for all of you who think perl5 looks like static on a tv screen, you will be pleasantly surprised I think.

    peace
  • The review concludes by saying the book is "a fun read for the Perl fanatic." So post that review on Perl.com and tell us here on Slashdot why any non-fanatical programmer would want to use a half-baked imitation of an unwritten language.

    I love and use Perl. But the grammar is already rich and varied. Throwing incorrect Perl6 code into the mix is going to make Perl5 code even harder to read. I sure hope not too much of this stuff makes it onto CPAN (although I know some of it already has).

  • by Cytlid ( 95255 ) *
    Umm... to all the naysayers... wonder why netcraft says slashdot.org uses mod_perl? (sarcasm, no need for -5, Obvious).

    I for one, welcome our perl-loving overlords. (and the book, too!)

    • by doom ( 14564 )
      Umm... to all the naysayers... wonder why netcraft says slashdot.org uses mod_perl? (sarcasm, no need for -5, Obvious).
      I think a better question is what's up with technocrat.net [technocrat.net]. Bruce Perens brought it back to life, only now it's running on slash. The old one was a Zope site, as I recall... It couldn't be that moldy old Slash is better than a nifty Python project, could it?
  • by duffbeer703 ( 177751 ) on Wednesday August 17, 2005 @02:40PM (#13341919)
    Ruby on Rails blows away Perl. I used to code in Perl, but I was working on re-implementing Windows XP as a Firefox extension, and I just wasn't getting the productivity that I wanted out of Perl.

    So I switched to Ruby on Rails this morning, and I'm so productive, that its sick. Within 5 hours, I have a Firefox extension running on my AIX workstation that can run most Win32 software... Photoshop, Outlook and Half Life 2 work ok, although I only get 40fps with HL2. (I'm working on that)

    After dinner I'm going to reproduce every module in the CPAN library, which I estimate will take approximately 2.25 hours. I can't wait!
  • by guacamole ( 24270 ) on Wednesday August 17, 2005 @03:04PM (#13342159)
    So, what happens if I use perl6 to run a script that has neither "package" nor "class" statements in it. How is it going to decide which language is that?
  • by Lost+Found ( 844289 ) on Wednesday August 17, 2005 @03:06PM (#13342172)
    I've been asking myself a lot lately why so many people seem to hate Perl. After spending the last few years going from comfortably familiar to extremely familiar with the syntax and features, I think I have the answer.

    When you really get down into the guts of perl, you get to do all kinds of crazy nifty things with XS, AUTOLOAD, regular expressions, etc. Perl's syntax is such that once you're intimately familiar with it, you can be either very expressive or very concise.

    A lot of code ends up going the concise route because when you know what you're doing, it's easier to write (less keystrokes). Then perl newbies / passer-byers take a look at it, don't understand it, and freak out and say that perl is crap.

    Then perhaps they're threatened because there's a huge community of smart perl programmers that manage to upstage them constantly.

    To zoom out on the issue a bit, I'm really sick and tired of this current movement in computer science where so many think that programming should be made into some kind of simple task that anyone can do. Hence you end up with languages like Java that hold your hand really really tight and refuse to let go. Is Grandma writing software really a good thing? Or should we save it for the people who at least have a passing familiarity with computers & networks; hell, someone who might even know a little bit about the basic mechanisms in a typical UNIX kernel?

    (I refuse to drive a car built out of legos... I don't care that the technology enabled your three year old to do it... it's a high speed highway, damnit, and my life is on the line!)

    Make no mistake - there's still an undergound of brilliant developers that understand their systems inside out and produce amazing, high performance code. Many of them are in the open source community. And we refuse to let go of our power tools. You may use whatever language you like, but expect a well-deserved ass kicking if you get in our face and try to tell us you know better.
    • A lot of code ends up going the concise route because when you know what you're doing, it's easier to write (less keystrokes). Then perl newbies / passer-byers take a look at it, don't understand it, and freak out and say that perl is crap.

      Fewer keystrokes should not be a design goal of a language. Do you remember the first time you wrote a C program, and you named your first variable 'a', your second 'b', until you got up to say, 'l' or so, and then you realized that you saved a lot of keystrokes but it wa
      • Fewer keystrokes should not be a design goal of a language.

        Your objection is silly and I think it's because you focused on variable names at the expense of what Perl really tries to optimize, Huffman-wisee. The driving question of Perl (and especially Perl 6) design here is "Why should common operations require a lot of syntax?" In English, why should words such as "he", "she", "I", "you", and "it" be short instead of long? Why is say a better keyword to print a string with a newline attached than pr

    • Flame On! (Score:3, Funny)

      by Qbertino ( 265505 )
      First of all some TLC for you Perl Fanboys (and girls) out there: Everybody loves Perl. Perl is cool, fast, delivers fast results in the area it rules and is the grand daddy of OSS languages. Nearly all books on Perl are fun to read and at least a great laugh.
      In fact it's quite amazing how long this quirky relic of ancient Unix paradigms managed to survive. It's 2005 and Perl _still_ is taken for granted as a PL. That's a terrific feat!
      The only PL in the same demografic group that is still in use is SQL. An
      • Re:Flame On! (Score:4, Interesting)

        by Chandon Seldon ( 43083 ) on Thursday August 18, 2005 @12:38AM (#13345481) Homepage

        I prefer programming in Perl to Python. This is primarily because Perl has better variable scoping, which combines nicely with "use strict" and "use warnings FATAL => 'all'".

        In Python, there are two scopes for variables: Global and Function. In perl, any { block } gets it's own scope for "my" variables. This means that temporary variables disappear when you're done with them rather than sticking around clogging up memory and name spaces. Because perl has variable declaration statements (my, our), it can check at compile time to make sure you have no typos in variable names. In python, any time you do an assignment you might be declaring a new variable - and you'll never know until you get incorrect output.

        Also, Python has no do...while(). This gives you the amazing choice of duplicating program logic (awesome when you change only one instance later) or putting in a "while 1:" - rather than knowing where the loop condition is, the maintnence programmer gets to randomly guess *and* this opens the way for "sometimes the loop never ends" bugs. Not good times.

        I'm looking forward to Perl 6 where it will be possible to have semi-static typing. That will mean even less code that compiles but doesn't work. I really wouldn't want to be using a language without similar features for any sort of non-trivial software project.

    • by Sweetshark ( 696449 ) on Wednesday August 17, 2005 @04:00PM (#13342666)
      Then perl newbies / passer-byers take a look at it, don't understand it, and freak out and say that perl is crap.
      And in a way they are right: Perl is crap for RAD by now compared to other languages.
      Then perhaps they're threatened because there's a huge community of smart perl programmers that manage to upstage them constantly.
      Yeah, the zealots and their praises are probably one the main reason for the hate against perl. Its just not that good as the zealots claim. Thus people are disappointed.
      To zoom out on the issue a bit, I'm really sick and tired of this current movement in computer science where so many think that programming should be made into some kind of simple task that anyone can do.
      That sounds so elitist it hurts. But yes, programming should be as easy as possible, but not easier.
      Hence you end up with languages like Java that hold your hand really really tight and refuse to let go. Is Grandma writing software really a good thing?
      Grandma uses VisualBasic or PHP, but not Java. Oh, and its a lot better when Grandma writes software in Java than in PHP or Perl.
      Or should we save it for the people who at least have a passing familiarity with computers & networks; hell, someone who might even know a little bit about the basic mechanisms in a typical UNIX kernel?
      No. Your Perlcode might even run on a Non-UNIX System - this is one of the reasons to use Perl, Python, Ruby or Java.
      ... it's a high speed highway, damnit, and my life is on the line!
      So you prefer to use a very powerful old car without any safety measures, because "you can handle it". Yeah, right.
      Make no mistake - there's still an undergound of brilliant developers that understand their systems inside out and produce amazing, high performance code. Many of them are in the open source community. And we refuse to let go of our power tools. You may use whatever language you like, but expect a well-deserved ass kicking if you get in our face and try to tell us you know better.
      Uhhh, Im scared. You really remind me of this guy: http://www.pbm.com/~lindahl/real.programmers.html [pbm.com]

      Those who live by the sword get shot by those who don't. [bash.org]
    • I'm with you there. I think perl is great as a scripting language. I strongly prefer strongly typed languages for system development, although I wish one of them handled regular expressions with the elegance of perl.

      All of my complaints with Perl are really complaints with scripting, and 'use strict' and packages really take care of most of that.

    • I hated Perl because it sat in the festering wasteland between shell scripting and full-blown compiled languages. Why would you want the complexity of C++ with the functionality of Bash? I learned the basic syntax about seven or eight years ago and decided there was no place for Perl in my toolbox. Not for lack of room; it just wasn't worth knowing.

      Of course it turned out that I was competely wrong. I was sitting down to dinner with a friend, and he was going on and on about all the different ways the vari

    • Extreme conciseness has a dark side: it makes the code much more difficult to understand.

      Back to the original question: I hate Perl because: if I don't use it for a little while (couple of months), I can't program in it without cracking a book. I program in a LOT of other languages, ocassionally, and I don't have this problem with any of them.
    • Why do I hate perl?

      Because when I said (1,2, (3, 4)) I really actually truly wanted a nested list, but Perl happily flattens it without warning. (Note: I know about references -- minefields suck even if you know where the mines are).

      Because I am tired of sloppy, legacy syntax like auto-quoting of barewords in some contexts, and the stupid hacks it takes to work around them (like prefacing constants with +).

      Because I want objects and inheritance, not blessed hash references and @ISA.

      Because I want to be abl
  • Obligatory (Score:3, Funny)

    by value_added ( 719364 ) on Wednesday August 17, 2005 @03:49PM (#13342554)
    I still find this funny [axis-of-aevil.net].

    And still use Perl.
  • Stop waiting around for Perl6 and start using Ruby.
  • People who still care about programming languages are wasting their breath.

    Look at the difference between a bad, a good programmer and an excellent programmer. We're talking 1 to 2 to 10 factors in productivity and quality here, easily.

    Programming languages? Unless it's a language (or programming paradigm) the programmer doesn't know (in which case it doesn't matter much whether it is Java, C, C++, Perl, Python or ruby) at all, the difference for the same programmer from one to another may exist (depending

Measure with a micrometer. Mark with chalk. Cut with an axe.

Working...