Randal Schwartz's Perls of Wisdom 282
| Randal Schwartz's Perls of Wisdom | |
| author | Randal L. Schwartz |
| pages | 350 |
| publisher | Apress |
| rating | 7/10 |
| reviewer | Raymond Lodato (rlodato AT yahoo DOT com) |
| ISBN | 1590593235 |
| summary | A dated compendium of the best of Randal's Perl columns |
Perls of Wisdom is a collection of 65 selected columns from Linux Magazine, Unix Review, and the now-defunct Web Techniques magazines, written between May 1995 and July 2004. In each column, Randal discusses some problem that he had to solve, or that someone else needed help in solving. He carefully discusses the problem, and then shows the Perl code needed to resolve it. Many of the columns are complete applications that can be run (with minor modifications) by the reader. (The listings are also available from the apress.com web site.) Each column has been reproduced as it was written in the original magazine, with "Randal's Note" prepended. Therein lies this book's best feature and greatest flaw. Allow me to explain.
When I first picked up this book, I had only read a couple of Randal's columns (from Web Techniques), and saw that he wrote tutorials of proper Perl usage. He also relies on the wealth of modules submitted to CPAN to leverage a solution. After all, why reinvent the wheel? I expected to see more commentary on the reasons behind choosing one solution over another, or insights into the inner workings of Perl itself. I more or less got what I expected. For example, the first column reproduced in the book (It's All About Context) explains why, when someone used my ($f) = 'fortune'; instead of my $f = 'fortune'; he got in trouble with the law (see the book to understand the legal issue). The first form only retrieves the first line of the output of the fortune program, while the second form retrieves the entire output. Little items such as scalar versus list context can trip many Perl coders.
The first chapter (Advanced Perl Techniques) does give you many tips and insights like the example I just gave. All but two of the twenty columns are little tutorials on the ins and outs of handling the commonplace day-to-day issues that Perl can address with ease. Some delve into more obscure topics, such as the difference between shallow and deep copies of structures, and Perl's Taint mode. Two columns contain complete programs. One extracts the text from the man pages and determines their "fog" index (a measure of readability). The other creates a mirror of files needed by CPAN.pm to install new modules. For each program, Randal gives the entire listing as well as an almost line-by-line description of how it works. Each column is written in a conversational style that is easy to read, yet doesn't talk down to you.
The following chapter is comprised of seven tutorials on the various aspects of searching, sorting, and formatting text. In addition to describing the creation and compilation of regular expressions, Randal also discusses formatting and the nifty "Schwartzian Transform" (Perl's map-sort-map idiom for sorting on almost anything) which was named for him, but not by him. While some of the information is a little long-in-the-tooth (the column on Text-Processing was written shortly after Perl 5 was released), it's all interesting and educational nonetheless.
Chapter 3 starts refocusing the use of Perl to web sites. This chapter discusses HTML and XML processing in six little columns. He shows how to generate a web page index, producing a web page calendar from a file of events, and parsing XML to retrieve the data within. He also includes a lesson on how to use Perl to compare two arrays to create an HTML-formatted difference table.
The next chapter demonstrates that Randal has spent a lot of time working out ways to update and improve his web site. It covers the intricacies of CGI programming in Perl. All but one of the fifteen columns are complete programs (again, available from apress.com) with line-by-line commentary. The programs do implement mostly worthwhile functionality, but each column was pretty much "I had this problem, so I wrote this program. Lines 1-3 do this; lines 4-5 do that, etc." Granted, some of the programs are pretty nifty (check out how he automatically keeps track of the "What's New?" pages), but the reading of one program after another started to become stale.
The final chapter is titled "The Webmaster's Toolkit," consisting of fourteen programs and three tutorials. Randal covers diverse web server background topics such as creating a light-weight load balancer, random links, and forcing users to enter through the "front door." There are also instructive techniques for throttling your web server's usage of the processor (a necessity at the time for Randal, as his web site was co-resident on a server with others), and calculating download times.
In its entirety, Perls of Wisdom contains 65 columns, split roughly half-and-half between tutorials and fully commented programs. More than half of the columns show that Randal uses Perl for web processing more than for general scripting, data reduction and reporting. His tutorial articles are top-notch, but I have a quibble over his program articles, which are somewhat dated. There were a number of prefaced notes to the effect that today he'd do it differently with some new feature or CPAN module. I really wish he had actually updated the column to show the new coding techniques. The original code is interesting in the historical sense, but I wanted to see nuggets of Perl wisdom for me to use in my daily job. The writing style is fine; the bits of insight are useful, but many of the programs are too specific to problems you or I may never see, and were solved in code that's showing its age. I'm glad I got to read the book, but I think it only rates a 7 out of 10.
You can purchase Randal Schwartz's Perls of Wisdom from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
CGI programs (Score:5, Informative)
I picked up from code lying about how to read and write files, get post/get data, and so forth, and slowly built up into quite a good Perl programmer (I suppose. Not amazing, but quite fluent). This wasn't easy though and was slow. Why? I never got taught, all in one place, how to do that. I think this is what this book is trying to do - but with a much wider range than just CGI programs (although it doesn't seem to neglect it, either).
I tried to write my own tutorial for using Perl in webpages to try and help. I'm not going to link to it here though, because it is quite terrible (I was 14 when I wrote it).
After learning Perl, and being able to use it, there is always using the standard librarys. For this, PerlDoc [perldoc.com] has been so helpful to me.
Re:CGI programs (Score:3, Informative)
Link to Randal's Articles (Score:5, Informative)
Re:Link to Randal's Articles (Score:2)
Re:Link to Randal's Articles (Score:5, Interesting)
As an aside, he was probably the best sysadmin I ever worked with. When you wanted something done, he got it done.
Re:Link to Randal's Articles (Score:5, Informative)
But intending harm, no.
"No harm, no foul."
Re:Link to Randal's Articles (Score:3, Interesting)
I'm still suffering from that, in a sense. It did a big dent in my net assets, as well as make it harder for me to work. There are still countries that won't let me enter, although it's not a US restriction on my travel any more. There are also people that cannot (by company policy) hire a felon, so I'm ruled out there too.
But, I've tried to make the most lemonade from the lemons I've been given.
Re:Link to Randal's Articles (Score:2)
Bah, Randal's was an act of misguided intentions rather than the kind of thing you'd read about in the tabloids.
If you're after that kind of thing you'll be glad to hear Java delivers rather nicely, with Patrick Naughton [rotten.com].
Not an acronym! (Score:2, Offtopic)
Re:Not an acronym! (Score:3, Informative)
In the old days people spelled it in all caps, i.e. PERL, which was probably due to the fact that people (including Larry) like to pretend it stands for something. I am not aware of any O'Reilly books that refer to it as PERL, they all list it as Perl.
The most common acronym attributed to it is "Practical Reporting And Extraction Language."
(Yo
Re:Not an acronym! (Score:3, Informative)
(You'll note that actually spells PEARL, a hint of its early name.)
Who needs Tom C., I'll just flame myself.
Actually it spells PRAEL. Duh, I got the wording twisted, it's obviously Practical Extraction and Reporting Language.
Also, I am wrong about the use of PERL on O'Reilly books. I am surprised to see the PERL in a Nutshell [amazon.com] title from O'Reilly.
And as a twist on the theme, the pink camel book [oreilly.com] actually is called
Re:Not an acronym! (Score:5, Informative)
What's the difference between "perl" and "Perl"?
One bit.
Oh, you weren't talking ASCII? :-) Larry now uses "Perl" to
signify the language proper and "perl" the implementation of it, i.e.
the current interpreter. Hence Tom's quip that "Nothing but perl can
parse Perl." You may or may not choose to follow this usage. For
example, parallelism means "awk and perl" and "Python and Perl" look
OK, while "awk and Perl" and "Python and perl" do not. But never write
"PERL", because perl is not an acronym, apocryphal folklore and post-
facto expansions notwithstanding.
Re:Not an acronym! (Score:2)
Reading Perl code? (Score:3, Insightful)
Because of Perl's TIMTOWTDI mantra reading other people's code can be an exercise in frustration, IMHO, because to grok what they have written you may end up delving into some of the more baroque syntax in the language. I've found that many people like writing incredibly terse code which makes its readibility incredibly difficult. While Schwartz may write comprehensible Perl, I expect that the bulk of Perl code in the wild is anything but. This is my biggest peave with the language, and how it can pride itself on this "feature" is beyond me.
Re:Reading Perl code? (Score:5, Insightful)
The TIMTOWTDI ethos is ultimately what makes the language as useful as it is. The more ways there are to do things, the more things you can do with a little creativity. The Perl language is abstracted, as all higher level languages are, but it's forgiving enough to allow you to do things that may not be possible in other languages without a great deal of pain.
The myth that all Perl code is unreadable is preposterous. I've written several very complex pieces of code in Perl that are not any more difficult to comprehend than any piece of C code designed to do the same thing, and often much less so. The phenomenon of obfuscated code is a result of poor programmers (and a pervasive subculture), not of the language.
Re:Reading Perl code? (Score:4, Interesting)
A good programmer will write readable code in any language he's writing in.
The world does not break down into three distinct camps: "Non-programmers", "Good programmers" and "bad programmers". Actually there is a spectrum and all programmers live somewhere along it. A language can encourage readability or discourage it. What does Perl do?
The TIMTOWTDI ethos is ultimately what makes the language as useful as it is. The more ways there are to do things, the more things you can do with a little creativity.
I'm sorry, one does not follow from the other at all. If I added a "+++" operator to C that increments by two then I now have at least three (obvious) ways to increment by two. Does that mean that I can now be more creative in C?
The myth that all Perl code is unreadable is preposterous.
Nobody claimed that in this thread.
I've written several very complex pieces of code in Perl that are not any more difficult to comprehend than any piece of C code designed to do the same thing, and often much less so.
Strange that you use C as your benchmark. How about a language designed in the last twenty years with readability as a goal? Perhaps Java, Python, Ruby, O'Caml, Haskell, etc.
Re:Reading Perl code? (Score:2)
Nobody claimed that in this thread."
I will. I've used C sinxe 1976 and perhaps I'm just used to it. I know three dozen computer langaugaes and prefer assembly.
My opinion is in the gourmet world of C, Perl is nasty fast food; it may solve some short term problem but it's nasty stuff that doesn't do anybody any good long term.
The first time I saw Java course each line made sense to me and I had a more or less instant comprehension of it. Perl just
Re:Reading Perl code? (Score:2)
That's just because you are a C programmer and C syntax ie Java and the like look familiar too you. If you used Perl since '76 (I know that's impossible) you would have similiar problems with C/++/Java. I have learned and use both languages and with experience comes readability.
Re:Reading Perl code? (Score:2)
Even good Perl looks to me like somebody rolled their head on the kayboard.
Re:Reading Perl code? (Score:3, Insightful)
And while yes, Java is easy to understand, it's just another step in the C line that, in the end, doesn't allow for the flexibility of perl, or rather can't be both as flexible and compact as perl.
Re:Reading Perl code? (Score:3, Insightful)
Perl encourages writing code.
It leaves readability as a lesson to be learned by the programmer when he has to fix his own bugs.
If I added a "+++" operator to C that increments by two then I now have at least three (obvious) ways to increment by two. Does that mean that I can now be more creative in C?
That depends, if you don't know the other two "obvious" ways... but you can easily remember the "new" way... then, yes. You are no
Re:Reading Perl code? (Score:4, Insightful)
This speaks to the developer's experience, not the code maintainer's. The code maintainer is stuck maintaining code idioms not of his choosing: and the more idioms there are, the more idioms the maintainer needs to understand to maintain them all.
Working with tools you are comfortable with... will make you more creative. Because you will spend your energy focusing on the problem, not on how to use your tool.
Again, this balances developer comfort ("I get to choose the best fit of ten expressions! Woot! I'm so comfortable!") against maintainer comfort ( "I have to know ten different ways to maintain ten different developers code. Why can't they all just pick one! *grumble*").
Maintaining someone else's code is usualy harder than writing your own, for the comfort factor you cited. A development culture that accepts esoteric ways to write code can be a nightmare, because the coder's defense is always There's More Than One Way To Do It.
If there's One Way To Do It, and that's what the coder did, then I know exactly what it does. If there's One Way To Do It, and the coder didn't quite do that, then I've found a bug, or the coder wrote something subtle, and didn't comment it clearly. In either case, the fact that the code needs fixing stands out clearly.
If There's More Than One Way To Do It, and what the coder did isn't clear, then I have to think hard to decipher what's going on, and whether it is what it appears to be, or whether it's some subtle little Perl trick.
In short, TMTOWTDI helps developers, but at the expense of maintainers, and QA staff charged with proving code correctness.
--
AC
Re:Reading Perl code? (Score:3, Interesting)
You give an extremely naive example. Even Perl doesn't allow you to do that ;-)
But, consider this. Perl allows you to postfix your if() statements, like so:
This is much more naturally readable than:
Similarly, you can use unless to make code easier to read:
Re:Reading Perl code? (Score:2)
Actually when I was first learning perl, once I got over the idea of scalars, I could read through the program I was looking at with no trouble.
Re:Reading Perl code? (Score:4, Interesting)
I agree with everything you say, though some languages make writing read-only code easier than others. APL comes to mind immediately. I did not intend to convey the fact that Perl was unreadable. Rather I feel that Perl gives you more rope to write unreadable code than other languages, like Python.
Of course you can write some incredibly terse code in Python too, especially with recent language additions.
And I would not include C in a list of languages for writing readable code in.
Re:Reading Perl code? (Score:3, Interesting)
Yep. EVERY language can be bent to horrid non-readability.
If you want a language that enforces readability, I would suggest using Perl 6 (the first MAJOR step in the actual implementation of which was just made with the creation of a Haskell-hosted compiler called pugs) and writing a module which enforces your idea of readability. Perl 6 will be the first language to give you enough control that
Re:Reading Perl code? (Score:2)
"Yep. EVERY language can be bent to horrid non-readability."
It is hard to write unreadable Python. It is not hard to write Python that is so "high-level" that you have to spend a lot of time figuring out what it is actually doing. A complex list comprehension can lead to some powerful code that does an amazing amount of stuff in a neat little package. To me this is different than the arbitrary line-noise you get with Perl.
So Perl 6 lets you define your own syntax so that someone reading your code neads
Re:Reading Perl code? (Score:5, Informative)
There you just lost me. The term "line noise" implies a low signal-to-noise ratio, when in fact Perl presents exactly the opposite. The SIGNAL is in fact, so high that many programmers find it difficult to cope with. That's fine, but let's not confuse that with actuall NOISE.
"So Perl 6 lets you define your own syntax so that someone reading your code neads to figure out what your ideas of the Right Language is?"
No. You wholy misunderstood the concept.
In Perl 6, you will have full access to the grammar, so you could enforce your local stylistic conventions. You would obviously not want to make INCOMPATIBLE changes so that your code is still valid Perl, but you could write your own "strict".
Think of it this way. Imagine a C++ header that caused all uses of operator overloading outside of a limited few "neccessary" to be illegal, or that issued a compiler warning on every use of an iterator initialization outside of a for loop. These are just simple (and not very useful) examples, but they serve to illustrate the point: you can instrument the compiler just as fully as you can instrument your code. Don't like the type checking in Perl 6? Make it stricter.
I'm sure that there will be someone who will publish the "python-like bondage" module 15 minutes after Perl 6 is released. If you're into that sort of thing, then your company can take full advantage of it, while still getting all the value of Perl 6 like LISP-style currying and macros, Ruby-style mixins, cross-langauge bindings through Parrot, boxed and unboxed type constraints on standard Perl scalars, full multi-method dispatch, etc., etc.
"Common LISP and Scheme's macro facilities can be used to define your own language constructs"
Yes, but we're not talking about defining language constructs. We're talking about changing the behavior of the compiler in structured, standardized ways that aren't just implementation hacks. Don't get me wrong. Common LISP is on my list of cool languages to learn more about right below Python and Ruby. I'm just saying that these particular Perl 6 features bear a bit more looking at.
"Or hell, TeX lets you redefine the world if you are so twisted, though to me TeX is more unreadable than Perl."
TeX is actually a good example of what I'm talking about. TeX is very readable for a full typesetting system, but most of us could not care less about typesetting. When you need to do specific tasks that INVOLVE typesetting, but you don't really need all of that power and flexibility, you step up a layer of abstraction and turn TeX into LaTeX. LaTeX is valid TeX, so it's not quite the same, but the idea of limiting a powerful system in order to step back a level of abstraction holds.
Perl 6 will provide all of the power that you need from a modern high-level programming langauge, but let you manage that complexity. You might decide, for example, to restrict Perl 6 in your programs to just the facilities that make sense for scientific calculation. You might even introduce a special syntax/grammar for putting differential equations directly into your program without having to quote around them and hand them off to a seperate processing tool (object, module, what-have-you).
None of this is useful for your average 1000-line CGI program, but for the company that produces tens to millions of lines of structured libraries upon which new software is built and re-factored over time, this will all be a godsend.
Much of what Perl 6 brings to the table, Common LISP has done for years, but some of it is either gathered from other, more recent langauges (e.g. Python, Ruby, Scheme, Java, etc.) or is, as far as I can tell, unique. I hope you give it a try and throw away your naive ideas of "line noise" in favor of considering the value to your productivity and the maintainability of your code base.
Re:Reading Perl code? (Score:3, Insightful)
Please, work your way a little bit further down that "list of cool languages to learn more about", before telling people they should use Perl.
Re:Reading Perl code? (Score:3, Insightful)
"And I would not include C in a list of languages for writing readable code in."
I can understand how you can feel that way after looking at some of the C code that's out there. But you have to go out of your way to obfuscate C. There's a reason there's no obfuscated Perl contest: "everybody's a winner!".
It's possible to
Re:Reading Perl code? (Score:3, Interesting)
I'm sure I'm not alone in having spent a lot of time thinking about this over the years. I've recently had to both rewrite someone else's Perl code and write some new stuff of my own. What I noticed immediately is how easy it is to write something complicated in Perl and how easy it is to write code that is so terse that
Re:Reading Perl code? (Score:3, Interesting)
Re:Reading Perl code? (Score:2)
Perl's ability to be terse can be nice in certain situations, but it's certainly not anywhere near the top of perl's list of great strengths.
Re:Reading Perl code? (Score:4, Insightful)
If you think the Perl community describes the Obfuscation contests as an argument for the use of Perl, you are confused about who the community is.
To me, the Perl community is that group of people that does promote readable Perl. Randal Schwartz is a part of that. There is a community out there of very good programmers who love Perl, and plugging into that community has been one of the best moves of my career. The people who actually invented and maintain Perl (Larry Wall, et al) are the real community, and they are very good programmers. The fact that there are a lot of other people out there knocking off quick scripts, running obfuscated contests, and writing ignorant books without reference to the accumulated wisdom of the real Perl community is not in any way a poor reflection on the Perl community and the Perl language.
Yes, the good programmers of the Perl community do occasionally play a round of "Perl golf" or have an obfuscation contest. But noone worth his salt has ever put those forth as if it were a positive reason to use the language.
Good programmers who use Perl use Perl because it is possible to write very good, high quality, modular, readable code in Perl. The people who actually create Perl exemplify and encourage this.
Re:Reading Perl code? (Score:2)
Re:Reading Perl code? (Score:5, Informative)
A list of names is also useful: material by Damian Conway, Larry Wall, Randal Schwartz, Mark Jason Dominus, Simon Cozens (Perl involvement now minimal due to career change), and persons associated with them is going to be top notch. Plug their names into Google and see what they have to say. Catch a presentation or read a book by one of them if you can. Meanwhile, there is truly a lot of junk out there. There's an article out there somewhere about "how to tell a good Perl book from a bad Perl book," which I thought was by Mark Jason Dominus, but I can't seem to find it at the moment.
Finally, 90% of the useful modules you'll see recommended for use from CPAN are written by the intelligent lights in the Perl community. The time-tested modules that are now standard solutions are those that were written with high quality by good programmers.
Re:Reading Perl code? (Score:3, Interesting)
Oh shit now I know I'm old. I see that name and "Perl" dosn't even come to mine. talk.bizarre does.
Re:Reading Perl code? (Score:3, Informative)
> I agree there is a problem in the community with stuff like this.
> Personally, I tend to ignore the community and just use the language the way I feel it's best used.
I started getting into Perl about 5 yrs ago and subscribed to comp.lang.perl.misc
I have never come across a newsgroup inhabited by so many arseholes.
The flaming of newbies was encouraged and posting obfuscated code par for the course. There was an overwhelming sense of how many Perl programmers thought themselves a cut abov
Re:Reading Perl code? (Score:2)
The result is too often gibberish.
Re:Reading Perl code? (Score:2)
I think you've conflated the Perl community with some other group of people. The real Perl community values program clarity, modular and readable code, and high software quality. Yes, there are some games to make the tersest programs possible, but the guys out there like Larry Wall who actually write Perl do not feel that way.
Please see also this post [slashdot.org].
Re:Reading Perl code? (Score:2)
Re:Reading Perl code? (Score:2)
Re:Reading Perl code? (Score:2)
TIMTOWTDI acronym expanded (Score:4, Informative)
Re:Reading Perl code? (Score:2, Interesting)
If you think about the idosyncracies in English (or any natural language), it's really a miracle that we can communicate with each other at all, and Perl's adoption of context and implied default
Re:Reading Perl code? (Score:3, Interesting)
Re:Reading Perl code? (Score:2)
My issue with TIMTOWTDI and the relation to unreadable code is that it requires a greater load on the reader because they have to know (conceivably) all the ways something can be done in order to understand code from different people. TIMTOWTDI is wonderful when you are writing code for yourself, it's a PITA when you are reading someone elses code.
Re:Reading Perl code? (Score:2)
Well, this is really a benefit of code reading in general: learning other ways of doing something. The problem (as I see it) with TIMTOWTDI is that there are too many ways of doing some things, and these compound one another. Sure, if you read enough Perl you'll learn every possible of way of doing something in the language, but at what cost?
Hooray! (Score:2, Funny)
$subject (Score:3, Funny)
Tip #1... (Score:5, Funny)
Re:Tip #1... (Score:2)
"Don't worry about it," was the alleged gist of the response, but Randal insisted. When they said that there was no problem, that's when he ran Crack and presented them with the list of passwords, to prove that they were insecure. That's when they slapped the crim
learning languages (Score:3, Insightful)
Perl doesn't kill readability... (Score:5, Insightful)
Seriously, choose the right tool for the job. When we've got a sys-admin level scripting task, and someone can go in and knock it out in a half hour (or less) with a few lines of Perl, who can say that's bad? I'm currently wading through a bunch of heavily patternized java that pulls checkin logs from a scm system and updates an issue tracking system as part of the build process. It's taken me *days* to begin to "grok" what's going on in the many associated xml config files and bizarre string handling approaches that were used in this undocumented hack. I'll replace it with probably less than 150 lines of Perl, and someone else will happily (and much more easily) maintain it. So there!
At the same time, we've got > 25 developers distributed around the world working on a big commodities trading app -- java works pretty well for that.
Re:Perl doesn't kill readability... (Score:2)
Re:Perl doesn't kill readability... (Score:4, Insightful)
Re:Perl doesn't kill readability... (Score:2)
you mean perl isn't littered with the same problem? hah. one of the touted features of perl is that there's always a zillion ways to do the same thing.
the thing i hate the most about perl is the often implicit behavior of perl. explicit programming is almost always clearer. perl freaks would claim this just demonstrates the power of perl, but it sure doesn't lend to its readibility.
the retarded perl syntax for defining funct
Re:Perl doesn't kill readability... (Score:2)
Yes, but they're not a zillion functions with inconsistent conventions all littering the global namespace all doing the same thing.
I don't expect you to recognize all the tricks in perldoc perlbot, but if you can't understand the pre and post forms of if and the precedence of and and or vs && and || (after a little practice for that one), then you
Re:Perl doesn't kill readability... (Score:4, Insightful)
Re:Perl doesn't kill readability... (Score:2)
I don't use perl for anything that will take more than 1/2 hour, or require more than a page of code.
Except that these short programs slowly start to expand into massive behemoths as I constantly add one more feature. Soon it's unmanageable.
So I've been trying to code my scripts in OCaml to begin with. I've been playing around with "CASH" a bit. Not sure I'm in love with it, but I no longer fear the code getting out from under me.
Re:Perl doesn't kill readability... (Score:3, Insightful)
Similarly, there are Perl people, and there are Python people. One is not better than the other. It just matters on a manner of fitting.
Please stop with the "one is better than the other" stuff. Better for you perhaps.
Re:Perl doesn't kill readability... (Score:5, Interesting)
As they do with C, C++, Java, Snobol, Forth, APL, C#, etc, etc.
Half of the people programming are below-average programmers. Bad programmers can make life HELL in C, and by the same token good programmers can make life quite easy in Perl.
That said, Perl gets a bad rep, not because good code is hard to read, but because a) bad code is more common in any language which is easy to learn and b) Perl has several features which people mistake for non-readability (that is, non- or inexperienced Perl programmers assume that code is hard to read because they don't know Perl and see these things which scare them):
Re:Perl doesn't kill readability... (Score:2, Insightful)
And this is exacerbated when people pull out all sorts of jiu-jitsu to apply regexes to problems that are better and more cleanly handled with a general purpose lexer. But I can see where pulling out a lex-alike doesn't work too well when you're dashing off a script.
Perl is weakly typed, and that frustrates many who are u
Buy this Book (Score:2)
perlmonks (Score:5, Informative)
Randal is a regular contributor there and many of the other leading lights of perl pop up frequently.
Regards,
A monk.
IMPOSTER!!! (Score:3, Informative)
Dear Mr review writer... (Score:4, Informative)
Schwartzian Transforms and raised hackles... (Score:3, Informative)
This is one of the things that's always annoyed me about Perl and its practitioners (well, most programmers, really)...
Given the long history of functional programming (hell, Lisp is closing in on 50 years old), this map/sort/map idiom had to be second nature to any Lisp/Scheme/Haskell/ML/etc. programmer at the time Schwartz wrote about it back in 1996[1]. And the fact that this was such a revelation to the people who read his column that they named the idiom after him just exposes the lack of a diverse programming background for most people. I'm guessing that 50% of the coders out there wouldn't know a map or a fold if it bit them on the ass, and even more wouldn't have a clue as to how to solve something so basic as the missionaries and cannibals problem [stanford.edu] in a declarative/logical manner (without the help of Dr. Google [google.com] that is).
Meh... Bitter rant over, I guess...
[1] I could be wrong, I didn't really do much coding before 1995-ish.
Re:Schwartzian Transforms and raised hackles... (Score:5, Informative)
I had no idea it would take on a life of its own as a standard idiom. And it was not originally "for a column". It was a usenet posting and wasn't presented as anything remarkable.
Just trying to set the record straight.
Re:Schwartzian Transforms and raised hackles... (Score:2, Interesting)
Oh, don't worry, I'm not blaming you or calling you out or anything like that. Hell that column at the least opened a few eyes [pair.com], and that's a good thing. It's just that the ST term is one of the triggers that set off some variant of a bitter "programmers need to learn more paradigms/languages" rant in me...
And the voices in my head won't go away until I vent it somehow...
Thanks Randal (Score:2)
Supporting Perl is truely hell on Earth. (Score:2)
My Sig Says It All (Score:4, Funny)
Learn to program (Score:2, Funny)
Why of course! It worked [k12.ia.us] for Bill Gates, it can work for you too!
From Wikiquote [wikiquote.org].
About 'my ($f) = `fortune`;' (Score:4, Informative)
Its not the language... (Score:2, Insightful)
TMTOWTDI and the Perl syntax have hardly anything to do with badly written code in Perl or any other language. Sure understanding an expressive language like Perl takes a bit more than learning a language like Java. But that does not mean that Java or [insert any language here] prevents you from writing ugly code. I am primarily working as a Java developer on mostly large projects and the amount of badly written code I have to deal with is simply frustra
I like Perl (Score:4, Insightful)
Rewrote the script using 2 hashes in about 15 minutes. Completed in less than a minute with all the info I was looking for.
So, um, I think an evaluation of most programming languages is more dependant on the programmers than the language itself. Sure some languages lack the proper data types or features, but any modern/complete language is capable of being readable and resource efficient if the programmer knows what they are doing. IMO, of course. I'm not a developer.
Re:It's always amused me... (Score:2)
> that such a f'ugly language should be named with an homonym of such a beautiful thing as a pearl.
Huh? I just finished converting my codebase from Brainfuck to Perl [cydathria.com], because I found Perl to be a little bit more readable.
And that guy muttering to himself in the corner isn't crazy. He's just our Ook [dangermouse.net] porting lead.
Re:Perl and work (Score:2)
Problems with readablility of Perl code is a sort of a chicken and egg situation. People develop "prototypes" in Perl, and there is almost an expectation of "throw away code". To contrast this with Java, there are people that write a class with a main method with everything in th
Re:Perl and work (Score:5, Insightful)
It is not how long it takes you to understand a perl script of X length that is relevant.
What SHOULD be the important data is: Whether it would take you MORE time to understand a C or Java program that does the same thing.
I have seen cases where people complain that it takes them a week to understand a Perl Script of 500 lines. So they write a new program in C, that does the same thing in 5,000 lines. Which then takes me 8 days to understand.
One of Perl's image problems is that because it does so much with so little, people underestimate what the tiny program does and therefore get frustrated when it takes them more time to understand than a C program of the same size, even though the C program does 1/10 what the Perl one does.
Re:Perl and work (Score:4, Insightful)
you can do incredibly complex things in a few characters in perl, which can be far more difficult to grok than the same thing described in 20 lines of C code.
it's both a blessing and a curse. a blessing because you can beat out very complex things quickly, and a curse because it is a major pita to maintain.
perl also stubbornly avoids some useful language constructs in the name of "language purity". eg case statements. yes i know about Case.pm, but its not stock perl. and yes i know perl6 will have it. only took them ~20 years to get there
Re:Perl and work (Score:2, Insightful)
From the Camel:
Unlike some other programming languages, Perl has no offical switch or case statement. That's because Perl doesn't need one, having many ways to the same thing. A bare block is particularly convenient for doing case structures. Here's one
Re:Perl and work (Score:2)
also, perl6 will have official switch statements, so apparently they decided that this "doesn't need one" claim was false. only it took them 20 years to come to that conclusion.
Re:Perl and work (Score:2)
What does the following Perl command do, how does it do it, and how many lines of C would it take you to produce the same output (not necessarially the same way!)
Re:Perl and work (Score:2)
For example I could say "My name is Andrew."
OR I could say: My name is an anagram of "Wander" with the last two letters swithed and then take the first letter and move it to the back.
Or I could say: The first letter of my name has the same first letter as the fruit traditionally used to represent the fruit of Knowledge in the bible. The second letter....
It's easy! (Score:2, Insightful)
So, let's rewrite this program without implicit $_ variable, without && comparision and with a temporary variable.
for my $number (2..100)
{
my $unary_string = (1 x $number);
if ( $unary_string !~ m/^(11+)\1+$/ )
{
print $number;
}
}
Which is quite readable now.
For all numbers between 2 and 100. Take
Re:It's easy! (Score:2)
I'm only gunna correct that tiny little bit
Re:Perl and work (Score:3, Insightful)
Re:Perl and work (Score:3, Funny)
Easily. A young white male who had taken too much caffeine smoked a joint at 4 am to calm down at on a project that was way overdue and underfunded had to add several things to his code to make it work by trying them at random; eventually it worked but he can't explain why.
How'd you get access to the MX missile codebase just out of curiosity?
Re:Perl and work (Score:2)
Re:Perl and work (Score:3, Interesting)
Perl syntax is very flexible. You can write Perl that looks something like C, or Perl that looks something like Basic, or Perl that looks something like Java, etc.
You might get two Perl programmers who both write small, efficient programs to do the same thing using similar architectural and design approaches. Both programs could look radically different, depending on the author's slant on Perl.
That is what mak
Re:Perl and work (Score:2, Insightful)
Re:Perl and work (Score:2)
Recently I went the other way with rewritting a C windows program in perl. A section of the code was parsing a string sent from an rfid reader with temperature measurement. The prior author spent 2 pages of code tokenizing and using a if/elseif/else and cases structures which I replaced with a single well written regexp. The regexp is compaction of meaning and is much easier to understand.
Secondly the prior application used a "ping" to test if the interface was up. Again the original C programm
Reality: no one like inheriting code of any kind (Score:2)
Re:Quote++ (Score:2)
CC.
Re:Quote (Score:3, Informative)
Re:First Use Python Post (Score:2)
Re:Next title in this series (Score:2)
I expect to see next:
"Portrait Painting With Dog Vomit"
I guess one mans flamebait is anothers +5 insightful...
English module (Score:2)
Have you tried the built-in English module? Just add this line to your script:
use English;
Then you get verbose aliases for the magic variables. So $. becomes $INPUT_LINE_NUMBER, $" becomes $LIST_SEPARATOR, etc.
A complete list of the aliases can be found here [perl.com].
Re:Perl Is Awesome (Score:3, Funny)
Write all of Unix from scratch on a PDP 11/20.
I'll wait.