Slashdot Mirror
Randal Schwartz's Perls of Wisdom
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.
Randal Schwartz totally change everything about perl. I mean, the things people can do now. My mind = BLOWN by his contributions.
I first learn Perl with the aim of creating dynamics webpages. I learnt from the tutorial Picking Up Perl - this is great and taught my most I needed to know with regard to the language - but it didn't teach me how to use it for websites.
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 has been so helpful to me.
- Jax
Since there wasn't a link to Randal's collection of articles I'm providing one here. There's some excellent stuff in there.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
At best, it's a retro-nym.
It's not offtopic, dumbass. It's orthogonal.
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.
Another punny title!!
I really $feeling $author. His contributions to $language were $adverb $adjective. I really hope he $does_doesnt[int rand(1)] write more books. The are $adverb2 $adjective2.
If one can write a book about good Perl style,
I expect to see next:
"Portrait Painting With Dog Vomit"
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.
Perhaps I missed it. But where is the explanation of 'best feature' and 'greatest flaw'?
eskwayrd = m^2c^4
Don't Hack Into Your Employer's Systems
Before you design for reuse, make sure to design it for use.
People kill readability (with Perl).
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.
who's moderating the meta-moderators?
> 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, 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 porting lead.
For those trying to follow along but not able to immediately expand the acronym, TIMTOWTDI is There Is More Than One Way To Do It.
500GB of disk, 5TB of transfer, $5.95/mo
I used to do small scripts in perl and I originated a fairly complex system in Perl which was written as if it was C++ (no direct access of object values, only methods, etc).
However having said that, I also later inherited a system written in Perl. Thousands of lines, lots of complex data structures. This experience permanently soured me on Perl. While it is possible to write good code in Perl, this doesn't always happen. Especially with the sense that perl is a scripting language that you use to develop hacks or short scripts. The temptation to do a shortcut is too great.
This leads me to another annoyance: Magic. Perl is too magical. To be truly effective in Perl you must know most or all of the magic. If you are unfamiliar with an idiom you have to resort to the manual/books. This means there is not a simple guiding principle (ie: abstraction) you can take and apply to problem solve any situation. The movement to exceptional magical cases is backwards thinking.
None of this matters if you're sitting at home writing one-off cgi-scripts (which is how perl became most famous), but once you move into the area of "professional" development, or at least large scale coordination, you quickly see the value in simple readable code.
In the end, most people who get paid to write code are rewriting and enhancing existing code. If it takes a week to understand a 500 line perl script, the code has probably delivered negative value to your team and company!
Repton.
They say that only an experienced wizard can do the tengu shuffle.
While I tend to prefer the camel series, it's not unusual to crack open a perl book and try to find a chapter that actually tells you how to do something - and then find that it's nigh unreadable.
So, given that it's based on fairly readable columns, this would still be a useful book.
Now if I can just figure out why the warnings spit out when I refer to a hash table result as the input to a hash table, saying it's an uninitialized value when, in fact, that value has been initialized, then I might be able to run things thru Perl with the -w flag more often.
-- Tigger warning: This post may contain tiggers! --
Being a big fan of Randal Schwartz's Perl column, I bought this book when it first came out. I find his writing clear and concise, and easy to understand even for beginners. The best part of this particular book is chapter 3 which I used to learn how Perl was used on the web, and it helped me to create many of the scripts that I use for my own website.
Want to learn about anything sexual? Check out the sex wiki:
If you have to read 6 books and 200 columns to learn a language, then the language is a fucking mess, and should be abandoned to the scrapheap of history.
Took me a lot more than that to learn English as a small child (Go Dogs Go!) or French, German, and Latin later on.
Are you saying we should be speaking grunts and clicks instead? Or should we just use binary and nod our heads and shake them?
It's a poor programmer who blames his lack of skill with using tools on the tools themselves.
-- Tigger warning: This post may contain tiggers! --
not everyone - never seen the attraction of php
For anyone getting into perl I can not recomend The Perl Monks Monastery enough. Lurk for a while, use super search to find the answers to almost any perl question you may have and if all else fails post to Seakers Of Perl Wisdom and enlightenment shall surely follow.
Randal is a regular contributor there and many of the other leading lights of perl pop up frequently.
Regards,
A monk.
Maybe you live in interesting times
Randal Schwartz's Perls of Wisdom will never take the place in my heart that is forever occupied by Steve Litt's PERLS of Wisdom!
When I was a tad, we didn't have all these fancy newfangled languages. We were so poor, we were glad to have two bits to rub together. We had to make everything from bits. Why, I remember one time, I wanted a dog, so I made one from bits. He was a little buggy, but he was the best damn dog a boy from the bit-mill ever had. I wore my fingers to bloody nubs flicking toggle switches on that front panel. But I learned the value of hard work and perseverence. Not like you youngsters these days with your nancy keeyboards and you poofter mice.
In this world nothing is certain but death, taxes and flawed car analogies.
Sorry...
As I've heard on IRC, "chmod 333 *.pl: you don't loose any of the readability after you've written the file.
CC.
TaijiQuan (Huang, 5 loosenings)
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)
In the example above, the single quotes should be backquotes instead.
my $f = 'fortune'; will just assign the string "fortune" to $f. This is what the article has, and it's wrong.
my $f=`fortune`; will run a program called "fortune", and assign it's output to $f.
my ($f)=`fortune`; will assign the first line of the output of the fortune program to $f.
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.
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 in a declarative/logical manner (without the help of Dr. Google that is).
Meh... Bitter rant over, I guess...
[1] I could be wrong, I didn't really do much coding before 1995-ish.
-30-
... holy wars, again.
Kill for your favorite editor
Take back the holy land of (insert fav language)
Burn at stake (eq "flame") advocates of (insert OS)
[this sig has been trunca
I remember debugging a Perl script that I was supporting. To paraphrase Truman Capote, I spent one day removing a backslash and the entire next day putting it back in. I never did fix the problem.
No, it's a poor programmer who doesn't choose to use simpler, cleaner tools that do the exact same thing instead, and costs his/her employer money by not doing so. So who's the poor programmer here again?
Or do you not write code for a living? My money is on "no".
You don't learn Perl - it gets absorbed through the blood-brain barrier. Leads to nasty flashbacks, too...
That is all.
Why of course! It worked for Bill Gates, it can work for you too!
From Wikiquote.This is supposed to convince me that learning Perl is a good idea?!!!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Why do posts which make an iota of sense get modded down?
Why is the trivial response to the insightful grandparent marked insightful?
It's shit like this that makes you want to stop reading Slashdot.
False quote. Wheee.
It really is. You can make it as readable or unreadable as you want. We use a ton of Perl scripts in our internal software; they handle customer service, repair issues, sales, provisioning, everything the company does actually. I like Perl because it's really easy to generate dynamic HTML with it. I avoid using $_ and other magic variables because, while they are useful when writing the program, they are a kick in the head when reading the program a month or two later. I have yet to come across a task that couldn't be implemented fairly easily in Perl. Plus, Perl has been around long enough that a ton of great packages are available for it; if I need to do a SOAP connection -- Perl supports it. Database interface? Perl handles it great. Time to talk to the serial port? Perl can do it! Honestly, to me the toughest part is figuring out what the user REALLY needs to get done with a particular piece of software; putting a Perl script together for it is the easy part. I have used other languages but for web-based software I'd recommend Perl (in our case using mod_perl on a Debian Linux server with a PostgreSQL back end) over just about anything. Your mileage may vary but I have to say that a lot of this hating on Perl is unfounded! Hate the player not the game folks!
Regular Meta Moderators are not more likely to get mod points.
Read more about the issue here.
That's because English is a fucking mess, and should be abandoned to the scrapheap of history. I'm surprised you say that's the case with Latin though. Sure learning all the vocab takes time, but that's equivalent to learning the library in a language rather than the language. Understanding how to fit subjects and objects and verbs together, how to work out what ending to put on things, what's grammatical and what isn't took you more than 6 books? I'm surprised.
I am trolling
This is the only book I recommend along with Programming Perl. There really is a lot of great stuff in there, and the book is short enough that you will actually read it. The Schwartzian Transform has appeared in my code many times and it wouldn't had I not read this book.
...there would never have been anything but open source as everyone would be capable of writing any kind of code they wished any time they wanted. Of course, it wouldn't have been much worthwhile given it would largely have dealt with referring to libraries of nonsense code which embodied inane ideas like MustWatchSurvivor() and McDonaldsEveryNight(). Screwed if it was, screwed that it isn't.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
After i read Learning Perl and doing test scripts, i felt like i was a real programmer in my gut (instead of just trying to "get it").
Thanks for the best book on learning programming, Randal!
your articles over the years have really improved my perl coding, and there are many code samples you provided that made it practically verbatim into production code where i work.
Come on, you'd be in the same boat if you were inheriting someone's lisp or java or whatever. Ineriting code sucks! Everyone knows this. This is why good coders demand "new code" positions when they interview.
"I think Perl appeals to hackers who like to write. I think Perl flexes some of the same mental muscles that writing and speaking flex and therefore appeals to people who tend to think in language-centric ways. It also probably explains why the primary strength of this idiosyncratic, language-like programming tool is processing text and text-like patterns. It just appeals to people who are linguistically minded and was developed with language interpretation in mind."
And yet we still can't get coders to comment their code, and write documentation.
---
Ptags
Or do you not write code for a living? My money is on "no".
You'd be wrong.
As to Python being "better" than Perl - it depends on what you want. Is English cleaner than other languages? No, yet everyone speaks English if they want to get things done, pretty much.
-- Tigger warning: This post may contain tiggers! --
its the developer that writes unmaintainable code.
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 frustrating. And most of it is written by "Senior" developers and design pattern aficionados!!!
The language is designed to be difficult to read. It allows you to do things far too many different ways, it is crammed full of "shortcuts" like @_ to make code as unreadable as possible, and it doesn't even support function arguments, making every frigging function require argument handling at the top. This is perl's fault, and although you can write code without @_isms, the fact that they are part of the language encourages them to be used. There is simply no reason for shortcuts and automagical variables with no letters in them.
The important thing is not wether it would take you more time to understand a C or java version, its would it take you more time to understand a python or ruby or pike version. And in all cases the answer is no. There is no excuse for perl to suck as bad as it does, there are 3 perfectly good alternatives, that are all much easier to both write, and read. Perl needs to be put euthanized.
Funny, I just read 2 Python Books (one was Dive into Python), and am convinced that I have to read at least another (the library reference) Maybe because I want to do some serious stuff with the language and reduce the number of wheel reinventions :-D.
Perl Programmer for hire
Just because you avoid using @_ and $_ and $#@)$(_ and all the other "helpful" automagical variables with no names doesn't mean they aren't there. If a language adds something, people will use it. There is no reason for this crap to exist, and that is most certain perl's fault.
And I am sorry, but there was never any excuse to design a language where functions don't take arguments. This the stupidiest, most rediculous thing I have ever seen. function (arg1, arg2) is a whole lot nicer than having to validate the contents of an automagically argument array and then assign the contents of the array to arg1 and arg2.
<rant>
It isn't the language: it's the programmers using the language that make Perl programs unreadable.
That being said: there are a lot of mediocre programmers in the world who think that it is neat to use every feature of the language they are using. This leads to unreadable Perl / C / insert your favorite language programs.
However, Perl does provide much much more than a yard of rope with which a company can hang itself by employing programmers without having the necessary controls in place (e.g. design / code reviews, etc.) to ensure that maintainable code is being produced.
</rant>
Mostly I agree, but the good thing about perl is that if you just want to fix a bunch of files, say, it's as simple as this:
perl -p -i -e "s/\r//g" *.txt
or whatever.
Was I the only one that heard
"You'd do it for Randall Scwartz"
Townspeople with angelic chorus: "Raaandall Schwaartz".
When I read that headline?
after thirty years - the reference is meaningless, but the joke is still funny.
(note to nitpickers yes I know the original is Randall Scott)
Real SUV's don't have cupholders
It's 5:42 A.M., do you know where your stack pointer is?
(Score:$number, $adjective)
It's not difficult to read at all; however, you wrote it in backward perl syntax with implicit variables. It's easy. It prints a concatenated list of prime numbers between 2 and 100 with no delimiter.
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 that number convert it into UNARY format. Now, if it doesn't match recursively the first set of ones (at least 2) with the trailling set of ones having the same number of ones (at least once).
So basically the matching algorithm is like this:
2 11 insufficient
3 111 insufficient
4 11 11 matched 4
5 11 1 11 mismatch
6 111 111 matched 6
7 111 1 111 mismatch
8 1111 1111 matched 8
9 111 111 111 matched 9
10 11111 11111 matched 10
11 11111 1 11111 mismatch
It seems to test for prime numbers...
If it's not a non-prime number since no match is found it prints the number without any delimiter on stdout.
Conclusion:
If I was to write this script with this "algorithm", I would write it like this:
#!/usr/bin/perl -w
# Print prime numbers between 2 and 100 by converting it into unary format and by testing for matching multiple pairs of double ones or more.
for (2..100)
{
my $unary_string = (1 x $_);
print if ( $unary_string !~ m/^(11+)\1+$/ );
}
BTW, writing a program in C to test for prime number would be quite more complicated!
Especially if you use this algorithm without a regexp library!
Enjoy!
Fred.
- Long life to Perl!
Randall Schwartz came to a PDXLUG meeting and got kicked out by the owner of the coffee shop because he refused to pay a service charge for using his credit card to purchase a coffee.
Personally I have nothing against Perl, it's just that I spend about half my time writing server apps in C and the other half writing web apps to interface with them. It makes me more productive to be able to switch languages instantly.
This is supposed to convince me that learning Perl is a good idea?!!!
:-)
Well, one of the primary motivations for Perl was to replace shell scripts. It really shines at that. If you don't believe me, trying maintaining a 2,000 line shell script, and compare it to the equivalent perl script. I'll bet you'll take perl, because it's usually (a) simpler, and (b) more powerful.
The backquotes were taken straight from shell scripting, in order to make it easier to port shell script to Perl. Perl kept the meaning the same, because changing it would have confused the target audience (shell programmers).
The regular expression syntax is backwards compatible with sed for the same reasons, though Larry extended the regular expressions to have very useful things, such as matching on whitespace versus non-white spaces.
Perl turned out to be astoundingly popular, and useful for many more things than shell scripting, though it's still good at that.
Much of the ugly syntax was inherited. There are many ugly things about Perl syntax. But on the other hand, Perl works, works well, and generally gets the job done with little coding effort. If one puts in enough coding effort into making the code simple and expressive, then Perl is maintainable as well.
If you don't, well, Perl will teach you more quickly than any other language why writing simple, expressive code is a good idea. Just try to maintain it six months later...
--
AC
Believe it or not, there are "subroutines" in Perl for things that take more than one page of code!
-- someone who has ~150k lines of production perl (+ smaller amounts of Java and VB) bringing in ~$1m/year (additional hint: "perl modules")
"light-weight load balancer"
This phrase seems wrong to me in so many ways. How can a load balancer have weight? It either does, or doesn't...with varying levels of efficiency. Is the load itself light weight? If so, why bother load balancing at all?
I wrote a Perl script yesterday with a bad algorithm using 2 lists. Ran all night and was still running when I got into the office this morning, and it didn't spit out any relevant data.
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.
> That's because English is a fucking mess, and should be abandoned to the scrapheap of history. I'm surprised you say that's the case with Latin though.
Because even the Romans hated Latin. They ended up writing all their plays in Greek.
I avoid using $_ and other magic variables because, while they are useful when writing the program, they are a kick in the head when reading the program a month or two later.
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.
Vino, gyno, and techno -Bruce Sterling
Sometimes I even wish C would use different operators for signed, unsigned and floating-point multiplication (among others). In reality I have to use many typecasts to tell the language what I really mean, which is unclear and error-prone.
In the case of perl, this is exactly the wrong way to do it!
Media that can be recorded and distributed can be recorded and distributed.
-kfg
I don't like to mod someone down without saying why.
Lot's of responses on Slashdot are predictable. Mention BSD and you'll get 20 posts about how it's dying, etc. Mention Perl and you will get quite a few posts complaining about how Perl is unreadable or not suited for 'real' programming.
Then you will get a bunch of people saying Perl code can be good or bad depending on the programmer who wrote the code.
It's kind of silly really, and I usually just ignore it. I would have ignored your vulger post as well, but someone modded it as 'funny' I disagree with your statement being funny.
So you can say I am not modding your post, but I am modding the person who thought such a vulgar comment, of which literally dozens of similar ones exists, deserved to be modded as funny.
Maybe the first time it was a little funny, but at this point I don't think it's funny unless it's at least a bit clever. This post is just an AC saying what's been said over and over already.
BTW, I don't object to this simply because it's vulgar. I enjoy watching "South Park", which is often extremely vulgar, but it is also fresh and clever. That is why it's so funny to me.
So unless you got a new angle on 'Perl Code is Trash', I really don't think it should be modded up as informative, funny or anything.
Anyway, you should prove your point with a telling example of Perl obscurity. It's not like such a thing would be hard to find
Peace, or Not?
The principles of writing clean software apply whether the program is 1 page or 100. There is *nothing* preventing the creation of large, maintainable programs in perl except the ignorance and/or laziness of the programmer.
You can write unstructured, ill-formatted, ill-documented slop in any language. A lot of people just think 'perl: quick and dirty solutions. Don't bother to use good craftmanship.' Guess what they end up with?
I've been a professional perl programmer for years, and I have no trouble understanding and maintaining my old code. Thousands and thousands of lines of code.
Forget Perl, I can't even understand your presumably English language posting.
Forget to close a tag did we?
(insert cheap shot about "typical Perl programmers lack of ability to write anything coherantly.")
Need Mercedes parts ?
"Why of course! It worked for Bill Gates, it can work for you too!
"The best way to prepare [to be a programmer] is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and fished out listings of their operating system.""
This explains nearly everything. Code reuse is a good thing but...
Dear Bill;
That code was in the garbage can for a reason. The good stuff was in nice binders neatly placed on peoples shelves.
Need Mercedes parts ?
"When I was a tad, we didn't have all these fancy newfangled languages. We were so poor, we were glad to have two bits to rub together. We had to make everything from bits. Why, I remember one time, I wanted a dog, so I made one from bits. He was a little buggy, but he was the best damn dog a boy from the bit-mill ever had. I wore my fingers to bloody nubs flicking toggle switches on that front panel. But I learned the value of hard work and perseverence. Not like you youngsters these days with your nancy keeyboards and you poofter mice."
You had bits? Why when we were kids we could only dream of bits. We had scraps of paper and fountain pens. But we were happy.
Need Mercedes parts ?
your code is not any easier to maintain than C code.
if anything your example shows how perl is broken and needs to use bubblegum and bailing wire to provide basic functionality of other languages.
but go ahead and ignore the fact that perl6 adds a switch statement because they realised that they (and you) were completely and utterly wrong. larry wall knows more about perl than you do, and he added the switch statement to perl6 syntax. pwned.
There are three serious problems with Perl
1. Magic. Filehandles are magic, for example, and consequently possess magical properties that don't map cleanly onto understanding what's 'inside' a variable. In other languages a variable is either (a) a simple scalar or (b) an object reference, but in perl there are 'magic' things like filehandles that just don't map cleanly.
2. Syntax. e.g the way an inbuilt 'function' like match or split (or are they statements? - they have implicit side effects, too) needs that weird tilde 'operator' to assign its output somewhere other than the default $_. That's disgusting
3. Compilation. Because almost any weird combination of metacharacters is probably legal perl, the compiler will often choke a LONG... way away from the originating error e.g missing piece of punctuation. This causes considerable head scratching.
Also
I think the metacharacter idea to determine variable type is flawed. It makes perl very hard to read because the human brain just doesn't handle this stuff, and soon the whole thing just blurs into line noise. The idea in modern languages is that if you don't know what variable 'aVar' is, you use the IDE features to automatically jump to the declaration, or auto-complete to immediately see what you're dealing with. So the need for $f and @a assumes your IDE is a text editor. Sorry, but the world has moved on!.
Isn't perl a bit heavyweight for that kind of stuff, as opposed to a bit of shell and sed?
Yeah, perl modules are a way to deal with it, but there's only so much you can put into a module. As for subroutines, you still need to be able to see and understand the program as a whole. It would take a very disciplined programmer to make a program modular enough that you could maintain it by simply looking at the subroutines in isolation.
I am trolling
... or is that the most ass-hat way to discover primes ever?
A C program (and a sane Perl script) would be more complicated in that it would require more lines of code, but it would require effort to produce an algorithm which is less efficient and less obfuscated than this one.
This has nothing to do with Perl as a language, and everything to do with irritation at people who code using pointlessly clever algorithms like that one.
"Programming perl" = perldoc perlrun?
Shop as usual. And avoid panic buying.