Slashdot Mirror
The Secret History of Perl
TimToady writes "Many otherwise intelligent people seem to think that Perl just sort of happened by accident. But Linux Magazine has just now put their October issue online, and it includes an article entitled Uncultured Perl: Perl's Creator Shares his Thoughts on a Subversive Lifecycle. It's basically the secret history of how Perl infested the world, intentionally subverting everything in its path including
the NSA, Unix, and the GPL. " Reading Larry Wall stuff has to rank as one of my favorite reading experiences.
--
Tom, you've hung around Slashdot long enough to know that's /always/ what happens. Maybe it stings more when it's about Perl...
--
I don't think the guy deserves to get slapped down for this.
It's true that two people can write two well-designed Perl scripts which achieve the job elegantly and correctly, and yet each use a feature of the language which the other has not encountered. Perl prides itself on the fact that you don't need to learn the whole of Perl in order to get stuff done -- and yet as a result, learning the whole of Perl becomes more difficult than learning the whole of other languages.
It's certainly possible to write large scale software projects in Perl (define some standards at the very beginning. Tell your coders what features of Perl they may not use.)
I keep meaning to learn Python. I like its philosophy. For the record, one the strengths Guido claims for Python is that it works excellently in 100k LOC programs: you prototype in Python, then profile, then replace the slow parts (which will be 5% of the code) with C. Python is friendly to that kind of approach.
--
That's a common mistake, and it was discussed a *lot* in Perl circles in the run up to Y2K, but it is most certainly not a bug in Perl. The polite way to say "you just suck" is "you didn't read the documentation, you just guessed how locatime worked" -- which is no way to use an API.
Localtime() is inherited from C. Man localtime says "tm_year - The number of years since 1900". Arbitary, yes, programmer-unfriendly, yes, but a bug, no, and its behaviour is well documented.
Far worse, is the javascript year function I hear about (I've nver used Javascript personally) - where the function returns the last two digits of the year if the year is 2000, then from 2000 onwards, returns the whole four digits. I dread to think what fevered mind thought that one up.
--
- Tom Christiansen is an author and lecturer...
And a damned fine one, I'll freely admit.Tom Christiansen is not someone who has planned, staffed, lead or coded a large, commercial software project at any time since the "e-commerce explosion" began in 1995 or so. Tom Christiansen is a zealot so blinded by his Perlcentrism, that he predicted that Java would be too complicated to catch on with "ordinary programmers." [LOL]. More humor at perl.org is a three-year-old rant about how some Perl vaporware is going to squash Java completely.
I find it endlessly hilarious and completely ironic that Tom repeatedly accuses people of not understanding the basic realities of the programming world. Utterly hilarious.
Actually, his basic assumption is very valid. Unmaintainable code is bad code.
I won't argue the goodness/badness of perl. But I will argue that for real software (code that is used more than once), if it isn't maintainable, it's crap.
You utterly missed my point. I agree, unmaintainability is bad. But maintainability is ONLY ONE OF MANY aspects of good software. As you so delicitly put it "if it isn't maintainable, it's crap." But it's also crap if it doesn't work, it's crap if it runs too slow, it's crap if it's not done yet, etc. etc.
Saying maintainability is the only thing that matters is very nearsighted. I'll bet Win98 has some pretty maintainable code in it, but that does not make it a good OS.
You argument (if you care to call it that) is reasonable. The problem lies in your basic assumption, which I will paraphrase: "Code maintainability is the ultimate good, unmaintainable code is synonymous with bad code."
.au files, play them in order with pauses in between, etc. etc. I thought of nothing but perl, and it worked like a charm. Do I ever need those scripts again? No. Do I care if I cant read them? No.
In some environments, this is true. If you are writing the code to control balistic missiles, maintianability will be very important (second, I hope, to correctness). However, in some cases, maintainability falls third or fourth on the list of prioirites. Sometimes its not a priority. I'll give an example from my personal life. I'm learning morse code, and I was going to go on a 5 hr flight. Since I only have 1hr battery, and I wanted to save that for working, I made a minidisc full of code and printed the answers on a piece of paper. How would you generate 100's of random characters, store them in seperate files, encode them to
You make argue that that is not a production environment, mere scripting. This is true, but I would argue that the line between scripting and programming is a fine one. Regardless, there are even cases of production environments where maintainability comes low on the list. cgi/database applications in which getting the damn thing working is more important than being able to maintain it. Just try to implement slash in C. Sure you can do it. Sure you can do it well, and maintainable. I'll see you in 3 months, and you won't have showered in weeks.
And, even if you accept the tenet that unmaintainable is bad, Perl is just as capable of clean code as any other language. In that way, perl can be of the dark side, it makes it easy and tempting to write unmaintainable code. But, on the other hand, writing clean code in perl is just as hard as writing code in any other language. So, assuming you want to write clean code, perl is just as good. Just cause it can make messy code does not mean you are obliged to do so.
In short, TMTOWTDI. This can never be bad. This is why open source is good. It all comes back to freedom. You can choose between GNOME and KDE, Linux and *BSD, Perl and Python. There is always another way, another value set. Perl is just looser about its value set.
--Nick
I think the idea is that instead of defining a new operator in the language, you should be able to write a subroutine to encapsulate reading lines from files given on the command line.
Then you wouldn't need to use idioms that look completely baffling to the novice. (Although to be fair the diamond operator is one of the first things you learn.) And it's easy for users to see what's going on by looking at the source, and easy to define your own version. You also keep the diamond operator in reserve so you could use it for something else.
-- Ed Avis ed@membled.com
IMHO having builtin operators makes sense for things like addition, subtraction and so on. In Perl, things like hash lookups would also be a useful thing to put into an operator.
But - again IMHO - reading lines from a file isn't really suitable for its own operator. Having
$filehandle = open('filename') or die;
$line = readline($filehandle);
is probably more understandable than
open(FILEHANDLE, 'filename') or die;
$line = ;
OTOH, doing the same with the + operator would make code less readable.
-- Ed Avis ed@membled.com
D'oh! Flipping Slashdot text posting system. That last line of code should have FILEHANDLE inside angle brackets. Maybe I should use Tom's script to quote things before posting.
-- Ed Avis ed@membled.com
My point still stands. Most programmers would have little trouble learning what 2 of the 3 do. The last one is a concept that most people don't need whose equivalent in other languages winds up with substantially worse syntax. In fact Python actually does not support an equivalent. Its scoping rules are simply not sufficient to the task of defining true closures.
And you criticize Perl for providing that concept under a syntax you don't like? A concept that most programmers don't require, and which is worse or non-existent in many other languages? Besides which, in Perl what it gives is perfectly predictable if you understand references. (Which are easier than pointers - however unlike C you can actually get useful stuff done without using them.) You \ something to get a reference, and then you can use the reference as if it were that thing. What could be easier?
Yes, there is a lot of syntax to Perl. By and large though it follows a very predictable grammar. Sure, most experienced Perl programmers may not know you can do something like
@foo{'bar1', 'bar2'};
but anyone with who is familiar with the language will have little trouble guessing what that should do. (Return a list based on multiple hash lookups in a hash.)
Complaining that you can write obfuscated code in Perl is like complaining that it is hard to correctly parse the correct English sentence, "Buffalo buffalo buffalo buffalo buffalo" and punctuate it appropriately. (Trivia, the word "Buffalo", repeated an arbitrary number of times, can always be parsed as a grammatically correct English sentence. This relies on the fact that it can mean either the animal or "to bewilder and confuse".)
Yes, you can obfuscate any language. You can also write clearly. And you can do either in Perl. Well I can at least...
Sincerely,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
At issue is the difference between a string, a reference to a function, and calling a function.
Now I grant that "Programming Perl" is not the easist way to learn the distinction between the three. Most Perl programmers don't need to use references (unlike, say, C and pointers), so the middle one is likely to leave a lot of them scratching heads, and is buried pretty well in Chapter 4.
However how many C programmers would have trouble with pointers to functions? And how long would it take the average non-C programmer to figure out what a piece of code that produced one was doing given a standard reference? More than that, how big is the gap between learning how pointers work in C and figuring out what the heck something like
(this->*(facts_supported[i].factfunc))();
means?
Regards,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
just one little stupid correction: Sapir and Whorf were two people, not one.
Of course, the Linux Kernel isn't developed by volunteers, for the most part. It's more like building a cathedral that isn't blocked off by big "construction zone" signs. Then people with the ability are free to step on in and see whats going on, and perhaps point out problems or help in various ways.
-BrentGood programmers write in X.
... Do you really think "programmers" never have to do text processing? You will never find a C library that does text processing as well as Perl.
What is X? Depends on what needs to be accomplished. C is not the best tool for every task. Neither is Perl. Neither is FORTRAN or Lisp or Java or
"Honest people, if you want something better than perl, build your own camel. Or get in perlguts and start hacking it yourself. That's what open source is about, right? "
Right on, man. I should probably add the following caveat to my above statements: You aren't a good Perl programmer unless you are familiar with the perlguts.
Not Perl's Fault. C does the same thing. POSIX *requires* the same thing.
And it's been in the docs forever.
What on earth did you think the year *was*? I mean, when you have a "year" in a system you're told is Y2K compliant, and it's under a hundred, doesn't this inspire you to check how you use it?
This is *NOT* a perl problem, nor a design flaw, nor anything of the sort. It's a reasonably plausible design decision that was made about 20 years ago, and everyone has been told about it.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Can anyone show me a code fragment which outputs a '19100' date, and which would have worked correctly with a true 2-digit time format? A function which outputs '100' instead of a two-digit year might be based on a reasonable, if incorrect, assumption. I can even imagine a wrong-headed attempt to handle post-1999 dates producing the year '20100'. However, hard-coding a '19' is asking for trouble no matter what date format you think you're getting.
Weblogging Considered Harmful:
The fact of the matter is that I am in no better position to say that Perl is easier to learn than Python than you are in a better position to say that Python is easier to learn than Perl.
My evidence, however, is anecdotal in only the trivial sense that all evidence presented in this forum is anecdotal since it is accounted by someone else. My experience with Perl and its use far exceeds your 31337 K1dz implications. Not only do I make very good money as a developer, have years of experience with professional Perl development, but I have also taught Perl for a living, and have wide experience with the experiences of others who have learned and used Perl.
And I still stand beside the claim that Perl is easy to learn and powerful to use. Presumably so is Python. Wonderful. At least you being a rabid Python user ensures that I won't ever have to deal with your sorry ass on a project.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
If you'll check what I wrote you'll find I didn't say I was still learning Perl syntax after 5 or 6 years (damn, man, I'm not so stubborn not to have given up on the language by then if that were true!). The syntax takes very little time at all. Familiarity with the functions and library suite don't really take all that long. Probably after a year I'd never seen any new functions, and very few new things on CPAN of use to me (well that might be stretching it a bit, since CPAN does keep improving to this day).
The things that one learns after 5 or 6 years with Perl are very advanced techniques -- an occasional idiom, advanced data structure manipulations, more and more perlguts (2 years ago I was embedding perl interpreters in C and C++ programs, and linking in libraries (including SUID PVM libraries) -- ever see a C++ module which instantiates a Perl interpreter which embeds more C modules? fun stuff), distributed objects (think Perl CORBA), etc.
I can't remember having that much trouble with Perl syntax, to tell the truth. Maybe it's harder for some than others. I have seen garbage code by junior programmers in all languages. And gurus are gurus. The nice ones use comments that say things like "deep wizardry. do not touch." and mean it. When you spend enough time to see why then you really appreciate their handiwork.
I don't really spend much time looking up syntax for Java applications. Java's syntax *is* simple. But the language is contorted. Additionally, Perl actually is portable where Java has purported to be (this is the subject of too many holy wars for me to want to rehash). I stopped using Java, not because the language is bad, but because the current implementations are horrible, and Sun's behavior over the past 2 years has been unforgiveable.
YMMV of course.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
If you don't know the language, either learn it, or don't expect to know it. Perl has a different syntax than [ pick your favorite non-Perl language ] that's why it's Perl and not some other language. If you read the first couple of chapters of "Learning Perl" (much less any of the excellent and more advanced O'Reilly books on the subject, on the front of which you might have even seen Tom's name were you not too busy trying to figure out why those idiots left the "a" out of "Pearl") you'll get a perfectly good introduction to the operators, syntax, types, and some of the basic idioms of perl programming.
Perl is non-trivial, easy to learn, and powerful. Since TMTOWTDI you can learn a subset of the language and be perfectly effective forever, but you can also continue learning more about the language and become a better programmer. I have been programming in Perl for 5-6 years now and am still learning new things (and my programs become more robust and more portable). There's no magic "Perl pill" to swallow, there's no book that will teach you Perl in 21 days or 24 hours, but you can be programming usefully in Perl in 24 hours without much of a problem.
It seems to me that you are an outsider/newbie to Perl who was dismayed at the differences between Perl and your current favorite languages. I don't know much about python (and yes I've actually written some programs in it), and have never really gotten keen on it and could probably post a comment like yours about Python in a similar forum, but I know that there are a lot of python users who write good programs (Zope being one of my favorites), so there's no point in me ignorantly knocking an apparently good product.
So why are you?
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
I'm not going to spell out the list of all the people in the past I have seen learn and use Perl, their backgrounds, whether they maintained code written by what types of programmers, which books they might have read, whether they used Cyrillic as their alphabet of choice, etc., to make you understand what I have been trying to say in this now-tired-ass-thread:
- I have seen a wide range of perl users, programmers, and students, and my opinion (having at one point learned Perl myself, and having dealt with Perl in a number of different capacities) is that Perl is easy to learn, is very powerful, and very flexible.
- there is a big difference between hacking up some scripts and seriously using/maintaining/designing-in Perl (I even spent about 20 minutes somewhere in this thread pointing that out)
- Perl is not a panacea. Perl has its place and its uses. There is no panacea.
- It takes work to learn. There is no welfare state in technical education: you either put in the hours and learn (this is true for everything -- the fact that some languages are easier to cut-and-paste programs than others does not imply that the cut-and-paster is a programmer by any stretch of the imagination). It is my opinion that most of the Perl naysayers in this thread have been just such cut-and-paste "programmers".
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
That was the version Larry was talking about. He started that ball rolling. He was talknig about how they decided to have someone make a commercial version.
Can you point out a language where you can maintain code based on knowledge of only a subset of the language? Letting people maintain code who only know a subset of the language is a sure way of disaster - in any language.
because the syntax is so flexible, almost everybody is only aware of a subset of the language
And you back up your claim with... ?
-- Abigail
Natural languages aren't context free, and people have surprisingly few problems with that. Why shouldn't a computer language use context?
When you want to change the type of a value you do it explicitly.
And doing it explicitly and not implicitly is good because of...?
In a language with well-defined types, it's trivial to overload operators so they do the right thing polymorphically
True, but look what you are saying later:
Syntax is helpful when it distinguishes different semantic domains;
So, first you bash Perl from not treating strings and scalars are different semantic domains, but yet is applaud the fact that it's possible to overload operators to do semantically different things based on the types of their operands. That doesn't make any sense. Could you please make up your mind which of the two you like?
Argument list flattening. Again, there are ways around this, but they require fairly sophisticated understanding of the language.
That's like saying that using pointers requires a fairly sophisticated understanding of C.
In fact, much of Perl's syntax is just pointless complexity.
That's not a fact, that's an opinion.
Why are references to aggregates prefixed with a '$'?
Because references are scalars and not aggregates. I don't find that hard to understand.
How come packages and classes are defined with the same syntax?
Because a class is a package. Remember: Syntax is helpful when it distinguishes different semantic domains. In Perl, there are no semantic differences between packages and classes.
-- Abigail
It is a Perl problem in the sense that it effects Perl too - it is however not only a Perl problem. Perhaps it isn't a design flaw, but it certainly isn't the smartest decision made by the people making the C standard. Returning years since 1900 doesn't help the programmer at all - now he needs to do work regardless whether he needs 2 digit years or 4 digit years. Years since 1 BC (the year before 1 AD, or the year 0 for the astronomers under us) would have avoided a lot of problems.
While not reading the manual isn't an excuse, you can't get away with stupid decisions just because you've documented it. I think it was a very unfortunate decision. It is of course way to late to turn it back. When designing Perl, Larry could have choosen that localtime would return 4 digit years. He preferred to follow the C standard, which has merrit as well. Had Perl be designed 10 years later, he might have made another decision.
-- Abigail
Yes, "Learning Perl" was the best starting point for me. The Cookbook appeared later...but is better once one already has an introduction.
Think about the Unix sort(1) program. Notice how it does not attempt to infer the type of its input stream. That's because it's a generic program. If you want to interpret your data as numeric data, than you are free to use sort -n. It's like that with Perl. *You* are in charge.
Ah, and just whose fault is this? I say that the fault lies with that other program for expecting so much rigamarole. Didn't we learn that ioctl(2) was bad, and simple text-based interfaces to controlling devices were infinitely better than binary crud?If you expect to treat your data like a string of digits, feel free. If you don't know what you want to treat it as, then I suggest you make that decision yourself. If you can't figure out how to do regex tests, there are manpages to help you.
I'm not being intentionally dense. I honestly cannot see your problem! In my world, you see, that `problem' simply does not occur.
I feel like you keep complaining about problems that occur in a two-dimensional world to someone who lives in a three-dimensional world rather askew from your own 2D plane, intersecting in only a few places.
I don't run crying to the makers of Unix to have them `fix' their filesystem so that a file has a "I'm full of numbers" property in its inode just so that the sort program can know whether to assume a -n flag or not.
So, too, with Perl. It makes these things easier by not distinguishing them. You've simply defined easier to be "hard". Perhaps you shouldn't be doing that.
Sure, there are places Larry keeps a tight control over--just try wedging a few more lines of C code in the inner interpreter loop, for example. But by and large, the Bazaar around the edges is a richly diverse free-for-all where all kinds of people do all kinds of things.
In any event, it most certainly is, which means this is another annoying case of paradiorthosis. :-(
See the entry for "themself" in the 3rd Edition of Fowler. Make sure you also read both Steven Pinker and this collection by Henry Churchyard, which is replete with endless examples of singular they and its declensions from the 1300s to the present day.
And as for the "themself" versus "themselves" thing, we use "yourself" when the antecedent is singular. For example: "You're going by yourself, aren't you, Johnny?" Notice there's no "yourselves" there. English has always done this, so "themself" over "themselves" works just as well now as it did back in 1570 when Caxton wrote, "Each of them should make themself ready."
Now, wouldn't it be nice to get back to talking about Larry's article instead of make false corrections? :-(
But this isn't want you want to look at for the CGI performance issue. You'll get an order of magnitude (10-40x) by using Apache's mod_perl to pre-load the pre-compiled programs directly into your httpd daemons. The amount of support for Apache in Perl is phenomenal. In the Apache directory alone on CPAN, we have all these:
There's also a great book from O'Reilly called Writing Apache Modules in Perl and C . It's got an Eagle on the cover.Of course, eventually even this breaks down. I don't think you want to handle 100,000 hits per second this way. For that kind of situation, you need to look into much more sophisticated systems of redundant daemons, sometimes with highly clever dispatch mechanisms way down low, such as with TCP splicing. See the latest Usenix `USITS' symposium proceedings for things in this realm.
If you can bring yourself to say "yourself", and I certainly can, yet still use a plural verb with "you", then it requires no stretch of the imagination to do the same thing with "they" and all its forms. Mind you: "themself" was in use long before we discontinued the opposition of "thyself" versus "yourselves" and started "yourself" versus "yourselves".
You shouldn't say, "We already have a meaning for `they'." You lead one to believe that the plural sense is the only meaning. It isn't. Not only isn't it the only meaning now, it never has been. "They" has always taken the role of a pronoun for an unknown antecedent. In modern speech, we see other interesting things happening with it, where even when the gender is known, but the exact identity is not, "they" is sometimes employed.
You can't just "invent" a new word for so important a job as a personal pronoun--not if you expect it to take hold. This is far too important a job. You can always invent new words for new things (although it's best if there's some parental etymon to lend meaning), and you can often invent new words for old things. But we already have an old word for an old thing: one that everyone intuitively uses and recognizes, irrespective of whether they happen to notice the practice or just go on blindly communicating using the language of their ancestors and their peers. (As in fact, I just did in the previous sentence. Did you have a fatal heart attack? No? Good. If you did, well, that's a real shame, but I'll just assume you aren't reading this. :-)
You'll never overcome the inertia of a word in adequate production in a critical role. I'd like to see you change around "we" just because it suits your fancy, too.
It doesn't matter if you argue from an artificial, presciptivist point of view, because the evidence of continual and widespread use since well before Modern English even existed up though our current day illustrates that this is a meaning that has always existed. You can't just invent grammars and impose them on language. The real people know how it works, and don't need to try to fathom Latin rules applied to a non-Latin tongue in order to understand this.
BTW, you forgot to hit "post anonymously" this time. :-)
And Perl *was* designed for an easy learning curve, you know. The people is was written by and for find it extremely simple. My grandmother probably wouldn't, but that's no one's fault.
Even though the readline operator was the oddest thing to me when I first looked at Perl, that was all of five minutes back on December 18th 1997. That's something like one and quarter million times that initial five unsettled minutes. Shall we reverse it and make me pay 1,264,032 times for something just to make some neophytes first five minutes somehow easier? I think not.
It's already easy to do so. This wouldn't improve how easily a perl programmer could read your code. One again, go for it.Perl has plenty of other operators in it that the Assyrians and the Sumerians never heard of. Big deal. That's irrelevant. If you want to use English, go for it. If you don't want to use what Perl offers, especially its regular expressions, for fear of a new operator, then perhaps you would be happier with something else.
I've never understood why people have trouble with things like this. It's all so easy. Just look it up, and now you know it.
Here are Perl's operators. Notice how finite they are:
Most of those are already familiar. The few that aren't, you can always look up, and then they will be. Perl doesn't go adding new operators willy-nilly. We got the spaceship in 91 or before, and the arrow in 93. Not much really happens since then. And we got the angle operator in 87. You'd think people would've gotten used to it by now.Of course, the regexes have their own language. Here they are:
I think only the extensions are a bit tricky: Maybe it's just be, but I think the only nasty ones are the parenned bits, and again, you can look them up.I'm big on the "look it up thing". From the my earliest days, we always had dictionaries and encyclopedias around the house. My mom, a teacher, was always having us look things up. And of course, every time you go to the reference book, you come away with more than you bargained for.
Perhaps I have an encyclopedic memory that others don't have. Or maybe I use this stuff more. I still look up some of the funny parenned bits Ilya has added. I don't mind that -- too much. :-)
Well, thanks. I'm glad we could be of service. Some of the better postings weren't even highly scored.
Remember how much Perl was originally used in a filter-type environment. It's nice to have a succinct was to get a common idiom encapsulated in simple syntax. You know, like backticks, which seem the same kind of issue.
In any event, it's about twelve years too late to argue about. :-)
Ian, please keep your frothing python bigotry to yourself. It has no place here.
On the other hand, it always provides an escape into turbo power. And a far, far nicer escape, I hold, than writing something like:
If you're going to use Python, just realize that it's not going to be all that fast. The program (a mere ten-liner) I use to format for slashdot code blocks like the one above runs 10x faster than the less-functional Python equivalent offered up by one of its anonymous zealots. Of course, it's easy to see that this sort of problem is precisely the kind of thing that Perl is very, very good at. The best artisans and architects use a variety of tools for a variety of tasks. The most reasonable of the language advocates understand that there is no single truth. I've seen tcl and python and java people (by which I mean strong advocates and frequent users) all use perl for areas in which it excels, such as the one I just used it for above.The equivalent to your python code in Perl is as simple as the following:
But thanks for the compliment on clean code. I realize it wasn't mine you were complimenting, but Perl thanks you.I believe that it's easy to write beautiful code in Perl if you want to. I'm very sad that people don't want to. Here's one old example where I've made a stab at using indentation to make nice code. I could probably put a bit more work in it. I've many more recent examples as well, if you care. I believe seeing good examples of well-formatted code is critical for a beginner. We tried to do that in the Perl Cookbook, but there's always room for more.
And yes, I'm aware of programming-by-contract, with language-support of pre- and post-conditions. This is, however, a run-time issue, unless you've solved the halting problem. :-) Meanwhile, I just use asserts.
Perhaps you mean static type analysis. Perl has some of that, or, rather, can. For example, it will automatic inline certain kind of functions that it deems safe, much like a good C compiler, and unlike languages like Python. Another example is that there are situations where you can make perl raise a compile type explosion if you access a mistyped data attribute name in an object field, a type of functionality present in C++ but absent in Python. However, this is the exception not the rule, for Perl is really not much into static analysis.
But if you content yourself with dynamic typing, Perl's actually quite good with this. All objects are strictly typed. You can't coerce them as you can in C++. If you call a method from class Y on an object of class X, and class X is not derived from class Y, then you'll raise a run-time explosion.
What you and so many others constantly harp on is that Perl allows a "string" and a "number" to be used interchangeably as need arises. And I tell you truthfully: I do not understand you! I'm quite serious. Then again, this might be evidence that Sapir-Whorf was right after all. :-)
Strangely, those who complain of this flexibility never seem to decry with equally strident voices the ability to interchange floats and ints, or single-character items with multi-character strings; and seldom do they complain of a variable's use as a boolean.
What they're missing is how convenient it is for input and output that strings and number go back and forth. I don't relish having to call something like readinteger or readchar or readstring, nor having to call something like writeinteger or writechar or writestring. I was burnt too often as a young child by coredumps and consternation from scanf(3), sprintf(3), and their brethren ever to go back to that misery. (Maybe someday I'll tell you about the atrocity of rpmfind(1) some day.)
Please, let me just write$n = <FH> (or, if you prefer, $n = readline(*FH) ), and be done with the matter. I've got better things to worry about.
seconded. larry wall's one of the most interesting people on the planet. he's got an uncanny ability to wrap his mind around *everything*, and spit it all back out in a clear, consise, and humorous manner. he'd be ubercool for a /. interview.
mikeThe poster says, quite clearly, what he dislikes about perl;
While it's not a Doctoral Thesis, it does seem to me that the above qualifies, at least by Slashdot standards, as "substantiated reasoning".
Tom elides this substance and attacks an isolated statement - "Perl sucks" - to enter into a barrage of emotional attacks. Tom incidentally offends those who have a problem maintaining Perl code, suggesting the fault may lie with them, and goes on to suggest that those who know Visual Basic are "Weenies".
As far as I can see, Tom's post was pretty substance free. It's easy to assert that perl is without flaw when it comes to the often heard complaints about maintenance, it's more difficult to make substantive points showing where the common pitfalls of perl that might bite a would be maintainer are not really much of a problem.
I'm sure Tom wouldn't make the claim that maintenance of programs is just as easy in all computer programming languages and thus any such complaints are the fault of the maintainer or the author.
I happen to believe that Perl does lack attributes of a programming language that lends itself to high maintainability. I think this is probably a design tradeoff. Perl is not Ada, it's not Visual Basic and thankfully, it's not Cobol.
-Jordan Henderson
I work for Department of the Navy and we also use Perl for mission critical applications.
I recently deployed a 70 channel temperature acquisition system written in Perl running on Linux in conjuction with Apache. This system was deployed at 500 ft of depth for over 3 months and was not physically accessible during this time. A BSOD would have cost 30k to access. Perl was a joy to work with and the project was developed in the space of 2 weeks.
They're doing the best that they can, given the circumstances, and should be encouraged, not squelched.
.pl.
Encouraged to learn a different language, that is, before they develop the bad habits of a lifetime.
By the way, it kind of looks silly when you get all sanctimonious about people who rip on Perl, and then give us an ALL CAPS yell about "Visual Basic Weenies!" (at the same time, demonstrating a mean touch with the HTML bold tag). What is this, a schoolyard bullying chain -- the C jocks beat on the Perl geeks who beat on the VB handicapped kids?
Visual Basic is another language which is dead easy for non-programmers to write horrendous code in -- why the hell should these hypothetical people who care enough to write a program, but not enough to learn how need to hack Perl before they get respect from you? Like it or not (and I don't), Microsoft ASP is showing up in a lot of places where you'd expect
People will always use the tools they can use to get the job done. And, hopefully, there will be gifted people like Larry Wall who care enough about them to help. But you needn't convince yourself that you're ever going to see Donald Knuth handing out one of his famous cheques for a really snappily written Perl script. If you care about that sort of thing.
jsm
I learned it, I like it. But I totally agree with Yoda (quoting funkster@midwinter.com):
EXTERIOR: DAGOBAH -- DAY
YODA: LUKE: YODA: LUKE: YODA:I think that we should really point to perl when people start talking about free software not catching on. This is a program that has been around and is still going strong.
----- When it is dark enough, men see stars.
I work for a major American automotive manufacturer, and we use Perl every day to write mission-critical applications. As in "if this doesn't work, we don't make cars"
This isn't CGI-scripting, this is applications development, stuff my peers do in C, C++, Smalltalk, or Java.
We work an order of magnitude or two faster than these other groups, just because Perl is so easy to pick up and work in - and because professionally written Perl is so easy to maintain.
Not to mention that every single deployed Perl application has it's source code _right there_. It is impossible to lose Perl source.
I would not be suprised to see Perl completely replace Java in the next few years, especially if Sun keeps acting the way they are.
Go Perl!
Please endeavour to express whatever sentiments lie behind that outburst using substantiating reasoning rather than emotive expletives. [...]Perl is not a rebellion against `good design'. In many senses, it is an expression of the same, where good design means something organic and adaptive, something tuned more to the wait people think than to the way computers operate.
Ok: I think Perl is a badly designed language that makes programming in it harder than it should be. Here's why.
First, the type system, or more precisely, the lack of one. Values are not type-safe, in the sense that they can change meaning based on the context they show up in (eg, strings and numbers).
Please note that I'm not talking about dynamic versus strong typing: I'm talking about the types of values. Common Lisp and Smalltalk are both dynamically typed, but a value in either language always has a well-defined type. When you want to change the type of a value you do it explicitly.
An example of how this problem complicated the design of Perl is the need for two sets of operators to distinguish whether you are treating a scalar as a string or a number. In a language with well-defined types, it's trivial to overload operators so they do the right thing polymorphically -- look at Cecil's generic function mechanism for an example of how this works.
Dynamic scoping. I'm aware of the existence of 'my', but having two different scoping mechanisms (one of which just shouldn't be used but is nonetheless the default) is an undeniable crock.
Argument list flattening. Again, there are ways around this, but they require fairly sophisticated understanding of the language. To add insult to injury, there's no simple way of naming the parameters of a function. Even Scheme has this -- and it's the sort of language that gives you sand and a fire if you want a wineglass!
The syntax. One of the persistent-but-wrong claims about Perl is that having lots of syntax is an indication of how the Perl culture values having more than one way to do things. In fact, much of Perl's syntax is just pointless complexity. Syntax is helpful when it distinguishes different semantic domains; it is a bad thing when dissimilar ideas are conflated or when there are similar ideas with wildly different spellings. (For example, see how Haskell and ML use syntax to distinguish type specifications from function definitions.)
For example, why is 'eval' used to denote exception handling? Why are references to aggregates prefixed with a '$'? How come packages and classes are defined with the same syntax? There are answers to all of these, but those answers are historical rather than meaningful. Cars used to have reins in the early 20th century, but no one would argue that they belong on a car for the 21st.
In order to properly support having an sophisticated syntax, the right thing to do is to have a facility for syntactic extension like Lisp macros. These can be extended to infix languages, btw -- see Dylan for an example of how.
One last bit: don't denigrate the accidental programmers who've had Perl thrust upon them, or who have turned to it from a starting point of zero knowledge. They're doing the best that they can, given the circumstances, and should be encouraged, not squelched.
I agree with this 100%, and am quoting it just so it will be repeated. The fact that Perl encouraged people to start automating grunt work means that it is a great benefit to humanity, no matter how imperfect it is from a CS standpoint. (The same could be said of Basic, for that matter.)
In the whole community, there are a large number of talented programmers, and a smaller number of truly elite hackers who can do most anything.
And then there is a tiny group of people, who could probably be counted with your fingers and toes, who just have that certain "it" that lets them understand their work, the needs it fills, and the larger context into which it all fits.
Larry Wall is close to the top of that list. Unlike most, he understands that what he produces means something in relation to the rest of the world and the community. Perl is the kind of tool that could only come from a mind like Larry's - and there aren't enough of those minds to go around.
Thanks for Perl, Larry - my sysadmins thank you too. Please - look both ways before you cross the street, and every other precaution we can think of. We can't afford to lose you...
- -Josh Turiel
-- Josh Turiel
"2. Do not eat iPod Shuffle."
It's almost like we're doing Windows users a favor by charging them money for something they could get for free, because they get confused otherwise. --LW
It's free-based Wall.
I nominate the above quote as the new open-source motto. Ha!
-- What you do today will cost you a day of your life.
"In particular, we really needed to have a commercially packaged version of Perl for the Windows folks, because many of them were (and still are) clueless about open source. It's almost like we're doing Windows users a favor by charging them money for something they could get for free, because they get confused otherwise."
This is a common misperception among Windows users; that you get what you pay for. Having to shell out some cash makes us think we're actually getting a better deal somehow. Go take a $40 tie from the Daytons place and put it in a Target for buy it. Not a bulletproof metaphor, I know, but illustrative nonetheless.$4.59: somehow people will be far less likely to
Speaking of bulletproof metaphors, I like Larry's comments about the Cathedral and the Bazaar. The Linux kernel is far more like a Cathedral built in full public view by a small crowd of highly skilled volunteers than a bazaar full of dirty tents and shouting people. Perhaps the users in the Linux community at large act as though they are in a bazaar, but the metaphor just doesn't fit, and LW points this out well.
Of course, there's an even briefer version of that pattern: the -n or -p command-line option, as seen in filter programs such as this one:
Life is too short, and too prone to error, to write all that out in longhand each and every time I care to employ that pattern.That's really quite a shame, because the article is rather a good bit better than the comments are.
Let me just say, ack! I read the Y2K info on perl and was assured that Perl was compliant. When the rollover happened several of my scripts started printing the year as 100 or 19100. I blame myself for not having looked into the problem deeper, I just read the popular opinion information on the net about how Perl is Y2K compliant. Well it turns out it is compliant, but only if you use it 'right'. Here is an example. If you use the localtime class it will return a year in what appears to be a 2 digit format. I say 'appears' to be because it turns out that localtime isn't returning a 2 digit format at all, its actually returning a number which is the number of years elapsed since 1900, which just happens to look like the familiar 2 digit format we all know and love right up until the Y2K rollover happens. Here is what I mean, a month ago the year portion of localtime returned '99', now it returns '100'. According to many perl sites, however, this is Y2K compliant. They would have me believe that everyone has been using it wrong and that if people would have wrote their code correctly in the first place this wouldn't happen.
The solution?
printf("The year is %d\n", 1900 + localtime() -> year);
Thats fine by me, I don't have a problem doing that. I just get pissed off at how arrogantly all the literature on this subject treats the topic. "There is no Y2K problem in perl, you just suck"
Okay.. riigghht. That wasn't a coder problem.
"We are just using an entirely new way to represent the date that isn't more human readable, or more machine friendly, that just happens to look exactly like the standard 2 digit year format until the year 2000 occurs, at which point it still works exactly as planned."
Can you spell denial?
I dont mind putting in workarounds, *shrug* big deal. I just get a bit indignant when my intelligence is insulted this way.
http://language.perl.com/news/y2k.html
Sigs are awesome huh?
Let me see.
The localtime() documentation has been part of Perl for years. You will find it repeated in books, Perl's Y2K statement, etc. If you read the documentation rather than use the "try and guess" approach you would have known what that function returned.
As the saying goes, Assume means "Make an Ass of U and Me."
And so, after not reading Perl's documentation, not reading Y2K statements, not testing your own code (despite hearing "Y2K" being chanted for months), you do not think that the existing problem was your fault?
Furthermore if you read the documentation, those Y2K statements, etc, you will find out that the decision was made not in the design of Perl, but in the design of C. Perl chose to imitate what C did a good 10 years ago, and C chose the format for that struct over 20 years ago. Personally I think that a 4 digit year would have made more sense than year-1900. But year-1900 makes a lot more sense than a 2 digit year! (Do you like coding in windowing logic to guess the century? Me neither!)
Oh, and a pointed question. Those scripts that began returning 19100? How many of them would have returned 1900 if the year was returned as a 2 digit year like you asked? Oh really? And you have cause to complain???
Sincerely,
Ben Tilly
PS Your proposed "solution" is not even correct Perl code. I leave conclusions as to your competence to the reader.
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Hire x programmer to do x programming, and hire
y programmer to do y programming. That's your mantra? But it doesn't really make sense. Hire a good programmer is really what you want, don't you think? A good x programmer, will learn and create better y code than a bad y programmer.
The question really becomes, what languages are good programmers most likely to _want_ to program in?
First, make it work, then make it right, then make it fast, then, make it bloated!
I really do wish, however, that someone else would please write some lengthy and detailed perl apologia sometimes. Truly I do.
The first point is with respect to small changes in punctuation (not "control characters") making a large difference in semantics. This is, of course, completely true, and I saw no reason to dispute it. However, it is likewise also true in nearly every language that comes to mind, whether programming or natural.Consider the tremendous difference in choosing single or double quotes in a C string. Notice how quote choice makes a big difference in shell programming as well, and even more importantly, how this is not the same difference as C manifested! Notice how in C the presence or absence of an asterisk or an ampersand completely changes what happens, just as in Perl the presence of absence of a dollar sign or backslash (to choose corresponding construct) can have tremendous impact. Notice, too, how in C a spurious semicolon can completely change your world.
And of course, positioning of that ++ matters a lot, too.I could cite plenty of examples in English, too, such as:
- I dedicate this book to my parents, Mother Theresa and God.
- I dedicate this book to my parents, Mother Theresa, and God.
The place where Perl is particularly heavy on symbolic notation is in regular expressions. Modulo Icon, I don't know of any language or system currently in use that affords so much power. Regular expressions (ok, I know they're not truly regular by the proper language-theory definition) are an extremely compact but user-friendly interface to various sorts of FAs. Yes, of course interchanging, omitting, or deleting one single character completely changes the meaning, because each symbol carries a large amount of semantic content. This is equally true of any other language that uses regular expressions, whether it be from libc or in any other programming language. Consider how differently a circumflex can be interpreted in a call to regcomp(3) depending on whether it is the first thing in the string or not, as well as whether it's the first thing after the opening square bracket of a character class. It's subtle. You do have to be careful. Such is the nature of the beast. Then again, I haven't seen a Calculus book that eschewed symbolic notation, either, and I'm not certainly I'd care to.Let's consider the "do what I mean" effect. If you'd like another quote of mine on this matter which is also somewhat mixed in its connotation, then consider: " `Do what I mean' is really just `do what Larry means', and if you and Larry don't mean the same thing, then you may be in trouble." :-)
I guess the bottom line here is Perl's context-dependent behaviours. I have mixed feelings about this whole issue, and could probably work up a fairly substantial jeremiad in either direction. I'm talking about the fact that things like these two:
The first, being in "list context" by merit of being on the RHS of an array assignment, actually ends up being It seems pretty obvious that it's more fun to write it without that ugly split. A reasonable alternate approach would be the creation of two separately named functions to do this job. But that's not what happened.Of course, it's not as though C were free of issues of context dependence. Consider how the comma operator acts in "list context", such as when you construct an actual or formal parameter list to a function or when you create an aggregate data initialization, compared with the normal, "scalar context" comma operator. Or consider how sometimes c[] and *c are equivalent (parameter declarations), and how sometimes they are not (extern declarations). And for a real fun time, just try to explain to a neophyte why argv[0][0] is doing run-time pointer arithmetic (assuming the conventional declaration), but that data[i][j] would not be given a declaration like char data[MAX_X][MAX_Y] to create a proper two-dimensional array.
C has plenty of other "do what I mean" issues. For example:
- Letting multiplication bind more tightly than addition -- a secret, implicit rule
- Permitting but not requiring a trailing comma on aggregate data declarations
- Allowing int to be omitted in declarations involving extern, static, auto, unsigned, and volatile.
- Defaulting functions to have a return type of int.
- Assuming that for(;;) should mean while(1).
- Sign extension on some architectures.
- Freely coercing integral types
I imagine there are more of those, too, that I could come up with if I had. In fact, I'm quite sure that I could list a bunch of "do what I mean" issues for Python if necessary. Certainly the significance of whitespace and indentation is one glaring case. Another is the default nature of many libraries to raise an exception upon error, rather than returning an error status, even when that exception is, as K&P put it in Java's case, far from exceptional.So I didn't address these issues because I felt that they were largely true, but not particularly relevant. All symbolic encoding systems are subject to semantic shifts due to small changes in symbols. And many of them attempt to "do what you mean". Does Perl share these properties? Of course it does.
Finally, Jordan, you've stated that you feel that Perl lacks attributes of a programming language that lends itself to high maintainability. I don't know whether this is fair or not, because I do not know what your metric is. If you're looking for me to play the devil's advocate, I could point out things like
- minimal static analysis
- extremely late binding
- libertine autoextension of memory
- free, dynamic conversion between intrinsic types
- default mode is for fast-and-loose programming, not careful architecture with elaborate pre-declarations
However, our advocate's adversary would be quick to illustrate how easily these can be construed to be not bugs but features given the appropriate target environment. In this respect, you've probably hit the nail on the head when you mentioned trade-offs.But you haven't enumerated your criteria, so it's hard to judge what you're thinking.
Anyone can write bad code in any language. It takes good programmers to write good code. But it also takes a good language, and perl is one such language.
The problem with many languages such as LISP is that it's so _difficult_ to write good code! Perl is such a gem because it tries very hard to make your life easy. Of course, some people still do things the wrong way. It's not an issue of the language. It's a problem with the programmer.
Although I do admit that Python is an equally good language.
-Ted
Hey, Hemos & Taco, can we get Mr. Wall for a /. interview? He would be most entertaining.
+-- (Score:-1, Moderator on Power Trip)
Perl is not a rebellion against `good design'. In many senses, it is an expression of the same, where good design means something organic and adaptive, something tuned more to the wait people think than to the way computers operate. It is a kind of design which has proven itself time and again over the last several thousand -- if not in fact, billion -- years.
As for the common refrain, "I can't maintain other people's code!", this is just another bit of popular Perl FUD. Eschew such nonsense. The underlying inability may reflect on you. It may reflect on them. But it does not reflect on Perl.
What you hate is when the code to be maintained was written by an unskilled laborer, someone who doesn't understand the tenets of software design. It would be hell maintaining that code no matter what language it was written in. Another scenario for hating life is when the original coder was competent, but the person doing the maintenance is completely clueless. Here my plea:
You don't hire them for maintenance of C++ libraries, so stop hiring script kiddies (I mean nonprogrammers who can only cut and paste others' scripts) to maintain Perl. This is your fault for hiring the wrong people for the job.
I've had the pleasurable experience of maintaining a great deal of Perl code that was designed and implemented by competent, professional programmers. You cannot compare the work of the Legos kiddie with that of the professional architect. It's insulting to all three parties.
One last bit: don't denigrate the accidental programmers who've had Perl thrust upon them, or who have turned to it from a starting point of zero knowledge. They're doing the best that they can, given the circumstances, and should be encouraged, not squelched. Most programming is performed folks not trained in formal software engineering. You should compliment them for how much they were able to accomplish, not diss them for not knowing the precepts and subtleties of good design. Perl succeeds because it is available not just for professionals, but for casual programmers as well.