Forgot your password?
typodupeerror
Perl Programming

The Secret History of Perl 279

Posted by Hemos
from the larry-speaketh dept.
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.
This discussion has been archived. No new comments can be posted.

The Secret History of Perl

Comments Filter:
  • by Anonymous Coward
    I am absolutely thrilled at the high level of integration perl is getting in free and non-free unices.

    Its incredibly useful to know that like sed/awk/grep, perl is and will be available on nearly any useful OS you can install.

    You can gripe about the syntax, bitch about "readability", but the fact is, once you learn it you'll be hard pressed to use much else. Perl is here to stay.

  • by Anonymous Coward
    While you're right in a way (this isn't the best story for Python advocacy), it's understandable (disclaimer: when I'm more alert, I guess I'd say I'm a Python advocate). The motivations are a lot like Linux advocacy done right: You know there are people using NT because it's the only thing they've heard of or because it's popular, not for technical reasons. You know some of these people would be better off running some UNIX. Not all, but some. Meanwhile you're sitting there with your Linux and you want to share. You point out the flaws in NT. Some switch over. Everyone's happy.

    Some with P*. Perl is older and more popular. Hence it has more users. It's userbase is a cross between Java's and Javascript's, the former generally know what they're doing, and the latter, um, don't. Put VB people in there too. You know some of these people would be happier with Python than Perl, but they use Perl all the same. I doubt even the most rabid advocates of either language would claim that either syntax is perfect for every mindset. Perl's syntax is very, very different and matches a specific type of programmer. In the same way, Windows is a good match for some people. But I seriously doubt they're good matches for everyone using them. There are some "programmers" using Perl who would be well-severed by a bit of enforced indentation.

    Now I'm not pretending that all or even most advocates act this way. But in the ideal form...
  • by Anonymous Coward
    "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 exists. Get it from Active State [activestate.com].
  • by Anonymous Coward
    The only problem I've had with Perl is that when I started learning it there was no starting point. "Ten Most Used Perl Phrases" is needed as a starting point, but I couldn't find it.
    That's the wonderful Perl Cookbook [slashdot.org] does. And it does so splendly. I've only ever bought one Perl book -- this one -- but I've bought it three times. :-)
  • C and C++ let you do the same obfuscation with pointers. The solution is simple - choose an intelligent naming scheme, like

    $S_foo = "Plumber";

    $FR_foo = \

    Where "S" is for scalar, and "FR" is for function reference.

    Even if you don't like this in particular, you get the drift.

    And before you respond with - "what about type globs???" - simple - don't use them.

  • After some 255 comments posted, it's pretty clear that nearly everyone is commenting on the comments instead of commenting on the articles. That's really quite a shame, because the article is rather a good bit better than the comments are.
    On the contrary, many of the comments were very educational and entertaining. In particular the Lord of the Rings inspired prose and the Emo Phillips hacked-quote have been spirited away into my humor folder. (And everyone has a humor folder.)

    The bitch, of course, is the time it takes to read through all the comments to find the diamonds in the rough. Fortunately this article has been the veritable South Africa for such uncut diamonds; one doesn't have to look far for quality writing.

    Kudos to you.

  • i mean really! isn't the entire point of different languages about choice to begin with? just like the idea of different OS's? is there a best or worst? bragging about who's script is better than who's or if one language is more capable or less resistant to failure due to built in fault tolerance that someone else might not like isn't the point. the point is to have options. arguing only pisses people off and they stop working on projects like this (or may never start them).

    let's keep things to a low roar (as my father would say)...

    / k.d / earth trickle / Monkeys vs. Robots Films [xoom.com] /

  • So what is your point - "Some people like Perl"? No sh1t Sherlock! My point is that they, or those that follow them, would be better off if they coded in something like Python. I haven't relied on anecdotal evidence to make my argument, saying "uh, yeah, Perl is cool because loads of my friends like it" is hardly an argument of worth. I was hoping that you were trying to say more than that, but clearly not!

    --

  • Python is probably the language most like Perl, and Larry invented Perl. How is that off-topic?

    --

  • Of course obfuscated programs can be written in any language, but my point is that to anyone trying to learn Perl, all perl code is obfuscated to an extent. Take the difference between the following three Perl statements:
    $S = "Plumber";
    $S = \
    $S = Plumber;
    Now a good Perl programmer could tell you the difference, but give a non-Perl programmer a copy of "Programming Perl" and see how long it takes them to figure it out - quite a while I would expect. In contrast, Python has no such complications - the syntax is much cleaner (even if you only use the primitive metric of the number of %, $, @, and & characters in the average piece of code).
    To say that all languages are like this is simply not true. I program in C, Java, C++, Python, ML, Prolog, and when I have no choice, Perl. Perl is the only one of these languages where I absolutely could not write a piece of code without a syntax-reference manual to-hand. In fact, I doubt if all but the most experienced Perl coders could write anything non-trivial without looking at a manual.

    --

  • Maybe, but it's possible to write shitty code in any language
    Perhaps, but the problem is that even well written Perl code requires a good knowledge of the syntax (which is not easy to remember) and a language-reference close to-hand, to be understood. I think the issue is that Perl affords too much flexibility. Many people wonder how this can be a bad thing, and it isn't if all you do is write code, but if you ever have to read code, flexibility and reduncancy(sp?) quickly become the enemy - and the big difference between Perl and other languages is the level of flexibility and redundancy afforded.

    --

  • Ok Tom, you want to play the "please back up your statements with mathematically sound arguments" game. We aren't talking about maths, we are talking about people, and what makes a language difficult to comprehend. Perl is full of very useful features which, if you are aware of them, make some tasks very quick and very easy. As an example, what about using angle brackets to glob files in the condition of a while statement.
    Now when most people see angle-brackets in a conditional statement, they expect them to be greater than, or less than, this will (and does) lead to confusion, particularly in complex statements. You asked for an example, I have given you one. The problem with a language full of neat little short-cuts like Perl is, is that while you only need know some of the shortcuts to write Perl code, you must know all of them to understand it. I don't think there are many people, even among skilled Perl coders, who could claim to know all of the neat tricks available.

    --

  • What about from the perspective of a company trying to decide on a language. You have just said that only skilled Perl coders can maintain your Perl code - hardly a ringing endorsement of Perl, or your coding ability. Further, not everyone wants code that can only be maintained by an expert, and there are languages out there that don't need an expert to maintain them (Python, Java, C to a lesser extent). If you like coding in Perl, and those who have to maintain your code are sufficiently skilled then fine, but not every company has these resources.

    --

  • Actually while I don't think Tom was expressing his views for financial gain, I do agree that attack is definitely his M.O. I recall one incident where he set up a monthly spam to some guy because he didn't like is email formatting, and then killfiled replies to that guys address. Not to mention the time half way though a debate (in which I was being more than civil) he accused me of being a troll and kilfiled me! There should be a guideline against insulting people and then in the same breath informing them that future emails from them will be ignored.

    --

  • The mechanism you describe is very self-serving from the perspective of a Perl programmer - "Perl is good because it locks companies in to hiring experienced Perl developers" - you say "locks", I say "traps"! If the same development work was done in Python, then almost any experienced programmer, with three hours with Guido's Python tutorial, could probably maintain the code excellently. I don't want to keep my job because my employer is "locked" into a language I happen to be familiar with, I want to keep it because I am a good programmer!

    --

  • Larry Wall is a good writer, he is funny, and he holds your attention well. Unfortunately humour doesn't help with language design. This will probably be marked down as flame-bait, but this is my honest opinion - even if it might be unpopular, censor me if you must. Perl sucks. I will admit that if you know Perl well, then yes, you can write powerful programs quickly within particular domains (notibly cgi scripting), some might even enjoy this. However, if you have ever tried to maintain a perl program, particularly someone else's, then believe me, the fun drains right out of the experience. Perl code is a mess of obscure control characters which can change the meaning of the code significantly. More to the point, Perl will generally try to "guess" what you want to do even if you don't quite express it correctly (Tom Christiansen's words, not mine). This may initially sound like a good idea, but it makes finding bugs a nightmare. Perl's design is not just a rebellion against established thinking, it is a rebellion against good software design and it shows. If you are thinking about learning Perl, do you (and anyone who has to maintain your code) a favour, and learn Python instead.

    --

  • No, that's not flame bait, although I guess it's one end of the spectrum. I've seen a whole load of Perl that just plain hurts (NOCOL springs to mind).

    But that's not really a good reason to decide what languages to learn.

    If you are interested in human languages you should enjoy Perl. Perl has in my mind the distinction of being possibly the only language that is at once genuinely different and innovative and at the same time widely used and practical.

    For me, learning Python would be like learning Esperanto. I don't like my languages clean, I like them clever and I like them useful.

    You boss might have fits at the notion of a programming language with the capacity for slang, but once you're there, you're hooked.

    Hmmmm. Perl - the thieves cant of the Internet :-)
  • It all depends what you are reading.

    Sure, Perl's syntax for dereferencing sucks:

    @array{$listofarrays->[$element]}

    But them Perl's syntax for interpolation rocks:

    print "We had $start pounds, and bought $number apples for $price per apple.";

    And as for Perl programmers needing a manual, yes, that is true, because Perl is a big language with a large number of builtins. So what - Unix is a big OS and most sysadmins will frequenty need to do a quick 'man' to check out flags and arguments and such. Same with Perl. It's not big deal.

  • 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.
    --
  • From a bio on the O'Reilly Website:
    • 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 [perl.com] with "ordinary programmers." [LOL]. More humor at perl.org is a three-year-old rant [perl.com] 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.

    • [Who really uses Java for] their day-to-day automation tasks? Have Java overtaken Perl, or even C, for web-affilated tasks? ... [Java is] still a load on any browser running today...
    Your point isn't exactly "wrong" but it is making some common mismatches.

    First of all, what's a "day-to-day automation task?" If it's munging a logfile and posting the results to a web page, you're a sysadmin and you do use Perl (you'd be silly not to). If it's supply chain management, you are an "enterprise user" and you are increasingly likely to use Java (you've never used Perl).

    Second of all, people who jump into discussions about Java by talking about how crappy applets are, are missing the fact that Java is becoming the language of choice for server-side, distributed program. Of course, this pisses off a lot of Perl programmers who feel it's "their turf."

    What we see here (repeatedly) are sysadmin's saying "I use Perl for everything." Well, duh.

    Then we have people who clearly haven't done anything with Java since it first came out nor do they work in the realms where Java is being used widely. "I coded a site to sell frozen doo-doo balls over the web and we used Perl!" Big deal. Just be glad you didn't have to use ASP.

    Finally, are the repeated claims that Perl is easier for "non-programmers" to learn than Java. Uh, who cares what "non-programmers" do? That's their business -- meanwhile, I've got work to do and I need progammers to do it. What Tom claimed in his essay was that only "ivory-tower" elite programmers could program in Java and that's just plain wrong. Wrong wrong wrong. WRONG. Wrong. Wrong wrong wrong (wrong) wrong. So there.

  • You're objection is coming from one of Perl's strengths. Perl has a very low barrier to entry. People with functionally zero programming tallent can write programs in Perl and have them work. Even worse, people with no large scale design skills can make large programs do what they want.

    This is why lots of Perl code is so horrible. But, look at what this means to C. C doesn't have this same problem, because the language is so feature poor that you can't write a large program without some design skills.

    People with the design and programming skills can write maintainable software, large and small. With Perl they can do it with a whole lot less effort, because it frees them from the mundane, build-your-own-low-level-data-structure game. And that's why Perl is a nice language.

    scottwimer
  • Howdy,

    I think Perl is the "right tool for the right job" - you just have to be sure you're doing the right job with it.
    Perl is a godsend for CGIs and fills a role no other language does. It's:

    • Interpreted - for short simple programs this is perfect
    • Cross platform - one of the few that really is
    • GREAT text/data tools - one line whitespace removal/rot 13?
    • and that's not mentioning auto memory allocation, arrays, hashes etc.

    I came to CGIs knowing C and tried hard to like it for that couldn't - the C programs were twice the length of the Perl examples and then I had to deal with new compiler environment, knowing the size of arrays at compile time and other memory issuses. All of these went away with the conversion to Perl.

    Perl is exactly what the web needed but was created before it even really knew it needed it. It's like Java but good and useful. ;)

    =tkk

  • 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."

    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 .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.

    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.
  • 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.

  • 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.
  • Perhaps, but the problem is that even well written Perl code requires a good knowledge of the syntax (which is not easy to remember) and a language-reference close to-hand, to be understood.

    Is this not true of most (if not all) languages? One would assume that if one is trying to maintain already-written code that one has some knowledge of the syntax and language constructs. Frankly, I think well-written Perl is easier to read (more natural) than a lot of other languages. Compare the two following code fragments:

    C

    for (int i; i < MAXLENGTH; i++) {
    printf("array[%d]: %s\n", i, array[i]);
    }

    Perl
    foreach $thing (@array_of_things) {
    print "$thing\n";
    }

    Alternatively (and a bit more obfuscated, yet easy to read by an experienced Perl programmer:

    print join "\n", @array_of_things, "\n";

    There, was that so bad? I can see how it might be confusing that those two snippets do the same thing, but that's flexibility, and there's power in flexibility. Either fragment is much easier to natural language flow than the C fragment.

    --
    A host is a host from coast to coast...

  • 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
  • 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
  • just one little stupid correction: Sapir and Whorf were two people, not one.
  • 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, 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.

    -Brent
  • Good programmers write in X.

    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 ... 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.

    "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.
  • 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.
  • The reason you haven't relied on anecdotal evidence for your arguments is that you haven't relied on evidence for your arguments. You actually haven't relied much on reason either, so the term "argument" is debatable. Your best tactic so far has been to try to appear to misconstrue the words of others so that you can argue against what you choose for them to have said.

    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.

  • Then use them where they are necessary. Do you see anywhere that I said that one should use Perl where it is not warranted. By all means, the people one hires should be as capable and flexible as possible. One think that you seem to assume is that Perl programmers are only Perl programmers. Why, I'm not certain. I also program in C, C++, Java, lisp (and scheme), ml, various flavors of assembly, awk, a number of scripting languages, even VB and VC++, and more. Most of the good Perl programmers I know are generally good programmers and can say the same. They also cost more than a 1-language programmer. I personally have not learned Python because I know Perl, they fill some of the same niches, and my time is valuable. One day I may learn Python beyond the trivial knowledge I currently have of it and hopefully I will find it as easy to learn as Perl.

  • As you have said, you function for quite a while (5 or 6 years i think you said) without knowing the full syntax of the language...therefore YOU CANNOT READ OTHER PEOPLES PERL CODE until such 5 or 6 years learning and memorzing every possible dorky way (many of them sparsely documented, two lines in "Programming Perl" on page 238 perhaps and nowhere else) of doing something is complete.

    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.

  • And Spanish uses those weird little upside down punctuation marks, and what's with those brackety quote things? And Russian, what's with that oddball alphabet? When I look at an R I expect it to face the other way!

    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?

  • My claim is that since I have had a lot of experience on a lot of projects for a lot of people doing a lot of Perl programming -- having seen an uncountable number of Perl programmers from newbies to gurus -- that your claim is unsubstantiated. Perl is actually empirically one of the easier languages to learn, and one of the easiest languages in which to learn how to write powerful programs. I've seen kids, PHBs, Wall Street traders, carpenters, arrogant C programmers, etc., learn Perl without complaint.

  • First, a company with non-trivial in-house software development needs should be prepared to get competent coders and competent designers, which may be found to varying degrees within the same employee(s). I'm not implying that a company must hire a QA team, certified software engineers, and programmers with Ph.D's [ well, you wouldn't find many of those anyway, but that's another discussion entirely ], but before hiring programming resources the company should have a clear idea of their needs and directions before spending their money.

    Perl is an easy language to use. Any given 5-person+ company probably has Perl-capable employees (the comment about Perl books being on Wall Street desks has a lot of truth to it because even non-technical people find Perl incredibly useful). To increase efficiency in the company, find places where math and paperwork is being needlessly done by hand, apply some Perl, and a limited amount of efficiency increase will probably arise. Hiring a programmer to do Perl will probably result in more efficiency increases. Having little idea of what a company needs and hiring a cadre of Perl programmers (or any language) is probably a recipe for disaster.

    Given a company that knows where it wants to go technically, which has or hires people which actually design the software to fulfill those needs and has experienced programmers which write the software in Perl (the language under discussion, but this holds true for most languages):

    • the code written will be optimized for the criteria important for the company
    • the code written will take advantage of advanced features of the language to provide flexibility, and to provide the optimizations desired (modularity, sophisticated regular expressions, XS access to shared objects, persistence, network transparency)
    • the code written may implement non-trivial algorithmic approaches to solve optimization problems
    • the code may contain sophisticated data structures

    There are reasons a company chooses Perl as an implementation language in a large project (such as the hypothetical one being described), and they hire experienced programmers to execute it [hopefully]. The guy arguing that he gets confused about the use of greater-than-signs in while loops should never be allowed to touch the code for this project, because he can only screw it up. This is assuming that (as it should be) the code is as well-documented and cleanly written as possible.

    Yes, the company is now "locked in" to hiring good Perl programmers to maintain this code. If it is feared that there is a problem with obtaining these people (over and above the problems we all have obtaining good people in this market anyway) then they should use a different language which has more available programmers. The fact that the company is "locked in" to having to get good programmers is nothing unique to Perl -- it is a hallmark of a good system which, if it was truly needed, is generating some substantial benefit for its owners.

    If the company did not need this quality product then they shouldn't pay for it. I happen to get paid for being one of the people that designs and helps write such products, and a number of these have been in Perl (and because of this more of them probably will be in the future). The companies pay good money for my work (as well as all the other people I work with) because they want sophisticated code that solves difficult problems. I am not trying to toot my own horn -- there are hundreds of thousands of people doing the same thing I am for the same reasons.

    The bottom line is that companies need to evaluate their needs well before throwing money at technical problems. This is independent of a good language like Perl.

  • Hardly. Read the comment. Insert Python where you see Perl if you can't figure it out. For any large project you are "locked in" to some degree to certain technologies for various components. you have to make a commitment to languages somewhere -- and hopefully the choices are educated. For a large project you will likely get locked in to a very small number of languages. If Perl is one of them then you will need good Perl programmers.

    I'm sorry that you don't understand this.

  • Dude. What is your f*ckin' aneurism?

    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".

  • languages for morons (VB comes to mind)

    If by "languages for morons" you mean "Written so that even morons can do something useful", I disagree. Granted, I can take anyone with half a brain cell and teach them to make a cute little "Hello, World!" program within 30 minutes. Given another 30 minutes, I can have them designing fairly complex dialog boxes.

    But have you ever tried to produce something truly useful out of VB? It is useless for everything except Windows programming, and it is useless in Windows unless you know how to use all the @*&$ing objects that come with it. The language itself is simple enough, I'll admit, which is about as relevant as saying the English alphabet is simple.
    Written for morons? Not likely. Designed by morons? Apparently.
  • 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.
  • Oh, and I meant that i would NOT use Java to write a filter. Sometimes I think faster than I type. Not often, but sometimes...
  • If you are thinking about learning Perl, do you (and anyone who has to maintain your code) a favour, and learn Python instead.

    Why is it that any thread on slashdot about Perl have people saying "use Python instead"? Or should I say, how come that Larry gets such an interview, and Guido doesn't? If Python is so much better, then why don't I see as many Python items on slashdot as I see Perl items?

    Mind, I'm not saying Perl is better than Python. They are different. For some people, Perl works better than Python. For others, Pythons works better. I would never recommend Perl as a first language; I might recommend Python. But there are lots of people who no longer need a language with training wheels, although some never can part from the comfort of having them.

    -- Abigail

  • Sure, Perl's syntax for dereferencing sucks:
    @array{$listofarrays->[$element]}

    Maybe it does, but your words would have more effect if you actually used valid syntax. Your syntax is so hopelessly wrong, I can't even guess what you want to do.

    A normal deference would be:
    $arrayref -> [1]; # Or
    ${$arrayref} [1];
    Is that so much harder, than say, C?

    -- Abigail

  • but if you ever have to read code, flexibility and reduncancy(sp?) quickly become the enemy

    This is true to a certain extend. That's why childrens books use a small set of words, and are often repeatative. But great novels tend to use a much larger set of words, and people don't mind different constructs of sentences.

    -- Abigail

  • Because Perl offers so much flexibility is it very difficult to understand code based on a knowledge of a subset of the Perl langauge

    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

  • 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).

    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

  • The Java programmer writes a standard

    Now, if we only had a standard Java environment....

    -- Abigail

  • This is *NOT* a perl problem, nor a design flaw, nor anything of the sort.

    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.
  • Perl sucks.

    Well, that's your opinion, and you're certainly entitled to it. Personally, I love it. I do a lot of text processing (with log files and the like) and Perl's regular expression capabilities makes it damn simple to extract the little bits and pieces that I need and arrange them into a usable form. Compared to what I used to do (bastardized conglomerations of Bourne shell, sed, and awk) Perl is a godsend.

    However, if you have ever tried to maintain a perl program, particularly someone else's, then believe me, the fun drains right out of the experience.

    Maybe, but it's possible to write shitty code in any language. One of the big promises of COBOL is that it was supposed to be "self-documenting"; a person should be able to take somebody's code, sit down with it, and read it from beginning to end like a Zane Grey novel. Well, anybody who has had the dubious honor to sit down with 100,000 lines or so of a payroll system written by some antisocial mainframe guy with a basement office knows that even a "self-documenting" language can be used to write some pretty nightmarish code.

    It's possible to write bad COBOL code. It's possible to write obfuscated C code. And yes, it's very possible to write hard-to-understand Perl code. But that doesn't mean that it's the fault of the language. A good developer can write well-commented, easy-to-follow code in any language .. and that includes Perl.
  • I think you are acting intentionally dense and I find it irritating.
    I'll consider the dense part, but not the intentionally part.
    The problem is precisely that Perl's deliberate obfuscation of the distinction between numbers and strings makes it harder to do polymorphic overloading
    I haven't seen evidence of that.
    because strings and numbers /aren't/ the same thing and the coercions that Perl automatically invokes are not always the ones you want to use.
    That's what you say. In my worldview, you're wrong. If I have a string of bytes with values in the 48-59 range (that is, digits). I can elect to perform operations on them that don't make sense for values outside that range. So what? There are many other sets of ranges with their own operations that make sense uniquely within those ranges.

    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.

    For example, suppose you need to serialize values to send it to some other application, and that this serialization format is not plain text, and has different conventions for strings and numbers.
    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.

  • curious... I understand why it is a great example of a successful free software project, but why is it a successful demonstration of open source? It seems that larry wall and people (of his choice) have done all of the development. The only thing I can think of is that it has been ported to so many platforms.
    That's like saying that all the development work for Linux was done by Linus Torvalds and people of his choice. "Choice" isn't the operative term. About the only person Larry ordains is the release manager, but even that is completely a volunteer thing. If you check the change logs, you'll see that there are hundreds of different names in there. Larry didn't "choose" to have those people help out by contributing code. They chose themselves, just as with any other open source project. Most of the people who do most of the work are the ones you've never heard of. You can't lavish enough praise on Gurusamy Sarathy, Matthias Neeracher, Nick Ing-Simmons, Tim Bunce, Ilya Zakharevich, Graham Barr, Andy Dougherty, Dan Sugalski, Jarkko Hietaniemi, Malcolm Beattie, Chip Salzenberg, Paul Marquess, and Andreas König (just to name a few of the names that pop into my head; please forgive me for omissions; see the change logs) to really thank them for their herculean efforts. It's the volunteers that have made Perl what it is today. They gave freely of themselves. They didn't get "chosen".

    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.

  • Wrong. `themself' isn't a word. Sorry, Tom, but as a writer, you should know better.
    Curiously enough, that didn't seem to stop your from understanding me, now did it? :-)

    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 [crossmyt.com] and this collection [crossmyt.com] 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? :-(

  • What's up with compiling perl is that there is a perlcc tool in the current release, one which is much improved in 5.005_63 over previous releases. The initial work was done by Malcolm Beattie, quite some time ago, with substantial recent work done by Vishal Bhatia and Tom Hughes, and perhaps Nick Ing-Simmons if memory serves. This includes modes for simple C output, more optimized C output (who says `optimal' is an absolute superlative? :-), and `Perl byte code' output.

    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:

    Apache-ASP Apache-Album Apache-Archive Apache-AuthCookie Apache-AuthLDAP Apache-AuthPerLDAP Apache-AuthenCache Apache-AuthenN2 Apache-AuthenNIS Apache-AuthenNISPlus Apache-AuthenPasswd Apache-AuthenPasswdSrv Apache-AuthenRadius Apache-AuthenSmb Apache-AuthenURL Apache-AuthzNIS Apache-AuthzPasswd Apache-AutoIndex Apache-CIPP Apache-Cookie Apache-DB Apache-DBILogConfig Apache-DBILogger Apache-DBILogin Apache-EmbperlChain Apache-Filter Apache-Gateway Apache-GzipChain Apache-HeavyCGI Apache-Htgroup Apache-Htpasswd Apache-Htpassword Apache-Icon Apache-Language Apache-Layer Apache-LogFile Apache-MimeXML Apache-Mmap Apache-Module Apache-OWA Apache-OutputChain Apache-PHLogin Apache-ParseLog Apache-Peek Apache-Perl-contrib Apache-PrettyText Apache-Proxy Apache-ProxyPass Apache-RandomLocation Apache-RedirectDBI Apache-RefererBlock Apache-ReverseProxy Apache-RewritingProxy Apache-Roaming Apache-SSI Apache-Sandwich Apache-Scoreboard Apache-Session Apache-SetWWWTheme Apache-Stage Apache-SubProcess Apache-Sybase-CTlib Apache-TempFile Apache-Throttle Apache-TimedRedirect Apache-Traffic Apache-TransLDAP Apache-UploadSvr Apache-Usertrack Apache-VMonitor Apache-correct_headers Apache-ePerl ApacheDBI ApacheMysql B-LexInfo HTML-EP HTML-Embperl HTML-Mason Taco eperl libapreq mod_perl
    There's also a great book from O'Reilly called Writing Apache Modules in Perl and C [modperl.com]. 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 [usenix.org] for things in this realm.

  • I should have really hoped that the copious examples would have sufficed. Did you read them all? The Churchyard site has oodles of them. Did you go to google and try looking up "singular they"? There are plenty of links there.

    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. :-)

  • Tom's suggestion that you hire only experienced C++ programmers to write perl is unrealistic)
    I can't imagine which Tom you might be referring to, because it certainly wasn't this one.
  • The main problem boils down to this: the Perl program print x; compiles and runs without an error message. The equivalent program in Python, Java, C, or C++ produces a compiler error. I have a hunch that a lot of programmers have torn out a lot of their hair while debugging Perl programs because of this.
    It does?
    % perl -we 'print x'
    Unquoted string "x" may clash with future reserved word at -e line 1.
    Name "main::x" used only once: possible typo at -e line 1.
    Filehandle main::x never opened at -e line 1.
    I should hardly call that "without error", albeit you might rightly point out that those are merely warnings. Very well. Let's add some more pain, and then do a compile-only check.
    % cat noncomp

    use 5.005_63;
    use warnings FATAL => 'all';
    print x;

    % perl -c noncomp
    Unquoted string "x" may clash with future reserved word at noncomp line 3.

    [Exit 255]

    As you see, it wouldn't even compile. Anything else you'd like? Perl lets you choose your own level of pain. It's perfectly reasonable that a programming project should have a coding standard with a high pain level, just as it is perfectly reasonable that a quick four-liner not be required to suffer the same.
  • Eek. Looks like you need the "we wish we had a <PRE> tag" program, in ten lines or better:
    #!/usr/bin/perl -p
    #
    # code2html - convert code to html for posting to slashdot
    #
    # tchrist@perl.com
    # Sunday, December 19th, 1999

    BEGIN { print "<TT>\n" }# AND THE SPIRIT OF awk...

    # first kill all the tabs
    1 while s/\t+/ " " x (length($&) * 8 - length($`) % 8) /e;

    # then the four standard naughty bits
    s/&/&amp;/g;# must remember to do this one first!
    s/</&lt;/g;# this is the most important one
    s/>/&gt;/g;# don't close too early
    s/"/&quot;/g;# only in embedded tags, i guess

    # make lines break where they should
    s/^\s*$/<P>/ || s/$/<BR>/;

    # make sure spaces aren't squishticated so we
    # can do indentation and properly align comments
    s/( {2,})/'&nbsp;' x length($1)/ge;

    END { print "</TT>\n" }# ...SHALL BE WITH US ALWAYS

    That makes your code look like this:
    #!/usr/bin/perl

    use Mozilla::LDAP::Conn;

    die "No connection\n" unless ($conn = Mozilla::LDAP::Conn->new('my_server));

    @attrs = ('cn', 'mail, 'telephonenumber');

    $entry = $conn->search('my_searchbase', 'sub', "cn=$ARGV[0]", \@attrs);

    die "No match\n" unless ($entry);

    $entry->printLDIF();

    while ($conn->nextEntry()) {
    print "\n-----------\n";
    $entry->printLDIF;
    }

    $conn->close();

    Which I think you'll find much more pleasant to regard.
  • just one little stupid correction: Sapir and Whorf were two people, not one.
    I was alluding to the Sapir-Whorf Hypothesis, but dropped the "hypothesis" portion.
  • 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.
    Feel free. I just showed you the code. :-)

    Then you wouldn't need to use idioms that look completely baffling to the novice.
    That one I reject. You don't design a language so it compromises the long-term users with the fleetingly ephemeral novices. The amount of time you spend not knowing something pales before the time you spend knowing it.

    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.

    (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,
    It's already easy to do so. This wouldn't improve how easily a perl programmer could read your code.
    and easy to define your own version.
    One again, go for it. :-)
    You also keep the diamond operator in reserve so you could use it for something else.
    Oh, now you've just gone and shot yourself. Either it's perfectly acceptable to use new operators that weren't in ancient Semitic, or else it isn't.

    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:

    leftterms and list operators (leftward)
    left->
    nonassoc++ --
    right**
    right! ~ \ and unary + and -
    left=~ !~
    left* / % x
    left+ - .
    left<< >>
    nonassocnamed unary operators
    nonassoc< > <= >= lt gt le ge
    nonassoc== != <=> eq ne cmp
    left&
    left| ^
    left&&
    left||
    nonassoc.....
    right?:
    right= += -= *= etc.
    left, =>
    nonassoclist operators (rightward)
    rightnot
    leftand
    leftor xor
    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:

    \Quote the next metacharacter
    ^Match the beginning of the line
    .Match any character (except newline)
    $Match the end of the line (or before newline at the end)
    |Alternation
    ()Grouping
    []Character class

    *Match 0 or more times
    +Match 1 or more times
    ?Match 1 or 0 times
    {n}Match exactly n times
    {n,}Match at least n times
    {n,m}Match at least n but not more than m times

    *?Match 0 or more times
    +?Match 1 or more times
    ??Match 0 or 1 time
    {n}?Match exactly n times
    {n,}?Match at least n times
    {n,m}? Match at least n but not more than m times

    \ttab
    \nnewline
    \rreturn
    \fform feed
    \aalarm (bell)
    \eescape (think troff)
    \033octal char
    \x1Bhex char
    \x{263a}wide hex char
    \c[control char
    \llowercase next char (think vi)
    \uuppercase next char (think vi)
    \Llowercase till \E (think vi)
    \Uuppercase till \E (think vi)
    \Eend case modification (think vi)
    \Qquote (disable) pattern metacharacters till \E

    \wMatch a "word" character (alphanumeric plus "_")
    \WMatch a non-word character
    \sMatch a whitespace character
    \SMatch a non-whitespace character
    \dMatch a digit character
    \DMatch a non-digit character
    \pP Match P, named property.Use \p{Prop} for longer names.
    \PP Match non-P
    \XMatch eXtended Unicode "combining character sequence",
    equivalent to (?:\PM\pM*)
    \CMatch a single C char (octet) even under utf8.

    \bMatch a word boundary
    \BMatch a non-(word boundary)
    \AMatch only at beginning of string
    \ZMatch only at end of string, or before newline at the end
    \zMatch only at end of string
    \GMatch only where previous m//g left off (works only with /g)

    I think only the extensions are a bit tricky:

    (?#text)
    A comment.

    (?:pattern)
    (?imsx-imsx:pattern)
    This is for clustering, not capturing.

    (?=pattern)
    A zero-width positive lookahead assertion.

    (?!pattern)
    A zero-width negative lookahead assertion.

    (?<=pattern)
    A zero-width positive lookbehind assertion.

    (?<!pattern)
    A zero-width negative lookbehind assertion.

    (?{ code })
    Experimental "evaluate any Perl code" zero-width assertion.

    (?p{ code })
    Very experimental "postponed" regular subexpression.

    (?>pattern)
    An "independent" subexpression.

    (?(condition)yes-pattern|no-pattern)
    (?(condition)yes-pattern)
    Conditional expression.

    (?imsx-imsx)
    One or more embedded pattern-match modifiers.

    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.
  • Tell that to the C++ people, who decided that input and output should be done via the >> and << operators.

    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.
  • I keep meaning to learn Python.
    You should. Learning is good. There are many nice things about 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.
    You can approach this from more than one angle. On one hand, that's the same thing that the tcl people always say, which--at least in old days before John put so much work into new tcl--pretty much required that you always wrote parts of your program in C. That's not necessarily everyone's panacea. It also means you lock yourself into keeping the main language a bit slower.

    On the other hand, it always provides an escape into turbo power. And a far, far nicer escape, I hold, than writing something like:

    #ifdef MCRT0
    atexit(_mcleanup);
    monstartup((u_long)&eprol, (u_long)&etext);
    #endif MCRT0

    asm ("__callmain:");
    exit(main(kfp->kargc, argv, environ));
    }

    #ifdef DYNAMIC
    asm("___syscall:");
    asm(".word 0");
    asm("movl 4(ap), r0");
    asm("subl3 $1,(ap)+,(ap)");
    asm("chmk r0");
    asm("jcs 1f");
    asm("ret");
    asm(" 1:movl $-1, r0");
    asm("ret");

    #endif /* DYNAMIC */

    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.
  • Gee, your python code didn't compile. Gotta love a language where whitespace bugs out the compiler so badly. :-(

    The equivalent to your python code in Perl is as simple as the following:

    for (@array_of_things) {
    print;
    }

    # look -- indentation is irrelevant!
    for (@array_of_things)
    {
    print;
    }

    # so is that trailing semicolon
    for (@array_of_things) { print }

    # :-) suppose i, good be can postfix
    print for @array_of_things;

    # this one is a tad different
    print "@array_of_things\n";

    # this one could be best, depending on formatting
    print @array_of_things;

    # and then there's this one
    print join("\n", @array_of_things, '');

    # Or this:
    {
    local($\, $,) = ("\n", "\n");
    print for @array_of_things;
    }

    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 [perl.com] 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.

  • You have just said that only skilled Perl coders can maintain your Perl code - hardly a ringing endorsement of Perl, or your coding ability.
    It is unthinkable to expect someone not skilled in language X to maintain code written in language X -- for all values of X. The hiring manager who made that fatal decision should themself be sacked.
  • To make the mechanism fully general and programmer-extensible requires type-safety. Perl doesn't have that, and I count it a flaw.
    Hard to say what you mean by type safety. Compile-type range checking? I was never particularly found of Pascal's declarations of a 12-element array of integers being fundamentally differently typed than a 13-element array of the same. Nor did I much care for its allowing you to create a type that guarantees, for example, that an integer (such as a year) be greater than 0 and less than 2000 (oops :-).

    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.

    mike
    • Anything that says "X sucks" stands a good change of being downscored, and probably deserves it, too. Please endeavour to express whatever sentiments lie behind that outburst using substantiating reasoning rather than emotive expletives.

    The poster says, quite clearly, what he dislikes about perl;

      • Perl code is a mess of obscure control characters which can change the meaning of the code significantly. More to the point, Perl will generally try to "guess" what you want to do even if you don't quite express it correctly (Tom Christiansen's words, not mine). This may initially sound like a good idea, but it makes finding bugs a nightmare.

    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.

    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 .pl.

    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

  • once you learn it you'll be hard pressed to use much else.

    I learned it, I like it. But I totally agree with Yoda (quoting funkster@midwinter.com):

    EXTERIOR: DAGOBAH -- DAY

    With Yoda strapped to his back, Luke climbs up one of the many thick vines that grow in the swamp until he reaches the Dagobah statistics lab. Panting heavily, he continues his exercises -- grepping, installing new packages, logging in as root, and writing replacements for two-year-old shell scripts in Python.
    YODA:
    Code! Yes. A programmer's strength flows from code maintainability. But beware of Perl. Terse syntax... more than one way to do it... default variables. The dark side of code maintainability are they. Easily they flow, quick to join you when code you write. If once you start down the dark path, forever will it dominate your destiny, consume you it will.
    LUKE:
    Is Perl better than Python?
    YODA:
    No... no... no. Quicker, easier, more seductive.
    LUKE:
    But how will I know why Python is better than Perl?
    YODA:
    You will know. When your code you try to read six months from now.
  • 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.
  • by Anonymous Coward on Wednesday January 05, 2000 @08:29AM (#1402786)
    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!
  • by Anonymous Coward on Wednesday January 05, 2000 @08:00AM (#1402787)

    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.)

  • by jht (5006) on Wednesday January 05, 2000 @06:17AM (#1402788) Homepage Journal
    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
  • by jabber (13196) on Wednesday January 05, 2000 @07:05AM (#1402789) Homepage
    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!
  • by evilpenguin (18720) on Wednesday January 05, 2000 @07:12AM (#1402790)
    I don't think Larry Wall would hold perl up as a paradigm for language design. What he would do is to hold it up as a very useful language for doing what you need done right now as opposed to what you done right now.

    It's much eaiser to do C-like things in a bug free manner in perl. Add to this that perl is a "scripting" tool, as opposed to a compiler (yes, the language is "compiled," but not in the same sense as with a true compiler) so you don't have (well, mostly don't have) the make complexities; editing code is also building code, so rapid toolmaking is facilitated.

    Sure bad perl is hard to debug, but nowhere nearly as hard as debugging bad C.

    There are "purer" languages that are very well designed. Java is certainly easier to write bug free programs in than any other language I personally use, but it isn't all that well suited to the kinds of applications I use perl for: what I lovingly call "suck and puke" applications.

    I know that people use perl for end-user applications, but with the exception perhaps of CGI, I wouldn't ever do that.

    I also would use Java to write a filter.

    I get kind of tired of the search for the "one true language" or the "one true tool," or even "the one true design method."

    A rich palette of tools, designs, and methodologies of managable complexity gives you the greatest ability to confront any situation.
  • by Pike (52876) on Wednesday January 05, 2000 @06:25AM (#1402791) Homepage Journal

    "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.

  • by Tom Christiansen (54829) <tchrist@perl.com> on Wednesday January 05, 2000 @01:17PM (#1402792) Homepage
    The most ugly thing in my mind being the
    while(<>)
    type of construct. It is synonymous with all that is bad about perl syntax. Saving a few characters does not in anyway make it a more powerful language. It just caters to people who are too lazy to write readable code. THIS is the problem with perl.
    Excusing your abuse of the word "synonymous", I really must disagree with your use of the word "few". Those "few" characters you just saved are in fact all of this:
    if (@ARGV == 0) {
    unshift(@ARGV, '-');
    }
    while (defined($ARGV = shift(@ARGV))) {
    if (!open(ARGV, $ARGV)) {
    warn "Can't open $ARGV: $!\n";
    next;
    }
    while (defined($_ = <ARGV>)) {
    # ...
    }
    }
    You see, while (<>) {} is a standard way of writing a rather complicated but extremely frequent pattern found in virtually all filter programs. Let's call it the `filter pattern', shall we? Now, do you really want to make people write that whole thing out every single time they care to employ the filter pattern? What will that save? Is it somehow clearer to write in low-level than in high-level code? Not necessarily. It depends upon the level of abstraction at which you focus. Is it perhaps less error-prone? By no means! It's more prone to error, not less so. That's because because replacing one line of code with a dozen (or what have you) increases the risk of error that many times as well. It also distracts the reader and the writer from the problem at hand. And it causes synchronization issues if you care to update that bit of code in one place. Wouldn't you like to have it updated in all places instead, all at once, so you don't have to remember to change it in all places? I know I would. And yes, this has actually occurred for that bit of code. Thank goodness we had a pat idiot for a standard pattern.

    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:

    #!/usr/bin/perl -p
    #
    # code2html - convert code to html for posting to slashdot
    #
    # tchrist@perl.com
    # Sunday, December 19th, 1999

    BEGIN { print "<TT>\n" }# AND THE SPIRIT OF awk...

    # first kill all the tabs
    1 while s/\t+/ " " x (length($&) * 8 - length($`) % 8) /e;

    # then the four standard naughty bits
    s/&/&amp;/g;# must remember to do this one first!
    s/</&lt;/g;# this is the most important one
    s/>/&gt;/g;# don't close too early
    s/"/&quot;/g;# only in embedded tags, i guess

    # make lines break where they should
    s/^\s*$/<P>/ || s/$/<BR>/;

    # make sure spaces aren't squishticated so we
    # can do indentation and properly align comments
    s/( {2,})/'&nbsp;' x length($1)/ge;

    END { print "</TT>\n" }# ...SHALL BE WITH US ALWAYS

    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.
  • by Tom Christiansen (54829) <tchrist@perl.com> on Wednesday January 05, 2000 @07:57PM (#1402793) Homepage
    After some 255 comments posted, it's pretty clear that nearly everyone is commenting on the comments instead of commenting on the articles.

    That's really quite a shame, because the article is rather a good bit better than the comments are.

  • by Tom Christiansen (54829) <tchrist@perl.com> on Wednesday January 05, 2000 @07:11AM (#1402794) Homepage
    Perl affords too much flexibility.
    Kindly explain your premise. Please document which flexibility is wrong, and why. Expound upon precisely which areas you would prefer inflexibility in. Demonstrate why your desired lack of expressivity would help you.

    Perl has a finite syntax, one that's infinitely easier (no, that's not hyperbole; it's true) than any natural language. The excuse that there are thinks you will not have time to learn in a ten-minute perusal of the language is no excuse whatsoever.

    You'll have to work much harder than you have to justify your position.

  • 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?
    I think to this one I shall respond in code:
    @lengs = qw(C C++ Java Pascal Perl Basic FORTRAN COBOL);

    for $coder (@lengs) {
    for $proggie (@lengs) {
    next if $coder eq $proggie;
    print "Don't hire $coder hackers to maintain $proggie code!\n";
    }
    }

    print "\n";

    for (@lengs) {
    print "Hire $_ hackers to maintain $_ code.\n";
    }

    There. Now the blame is more equally distributed, and the advice hopefully more clear.
  • by jidar (83795) on Wednesday January 05, 2000 @07:23AM (#1402796)
    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
  • by tilly (7530) on Wednesday January 05, 2000 @09:14AM (#1402797)
    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.
  • by Roundeye (16278) on Wednesday January 05, 2000 @07:18AM (#1402798) Homepage
    People seem to think that they have an inalienable right to sit down in front of a program written in a language with which they are vaguely familiar and begin hacking someone else's code - and bitch when the language is not trivial enough to do that. While I am all in favor of languages with simple syntax (C, Python), or languages for morons (VB comes to mind), when I choose to code a project in Perl I don't expect some Perl newbie to maintain my code later -- because I know Perl well and I use the advanced features of the language for their power. If you don't want to take the time to learn Perl then go program in any of the zillion other languages available; but don't claim to be "just another perl hacker" or expect to be able to maintain good Perl code.
  • by speek (53416) on Wednesday January 05, 2000 @08:32AM (#1402799)
    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?
  • Very well, Jordan. I'll answer those particular points. I trust you will be content with my doing this rather than laboriously addressing your own points, since they seemed to be mostly about my not having answered each and every issue that the original poster had raised.

    I really do wish, however, that someone else would please write some lengthy and detailed perl apologia sometimes. Truly I do.

    Perl code is a mess of obscure control characters which can change the meaning of the code significantly. More to the point, Perl will generally try to "guess" what you want to do even if you don't quite express it correctly (Tom Christiansen's words, not mine). This may initially sound like a good idea, but it makes finding bugs a nightmare.
    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.

    while (i++ < j);
    b[i] = a[i];
    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:

    @files = `ls`;
    $files = `ls`;
    The first, being in "list context" by merit of being on the RHS of an array assignment, actually ends up being
    @files = split(/(?<=\n)/, `ls`);
    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.

  • by Ted V (67691) on Wednesday January 05, 2000 @07:34AM (#1402801) Homepage
    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
  • by NullGrey (46215) on Wednesday January 05, 2000 @07:02AM (#1402802)
    Hey, Hemos & Taco, can we get Mr. Wall for a /. interview? He would be most entertaining.

  • Perl sucks. I will admit that if you know Perl well, then yes, you can write powerful programs quickly within particular domains (notibly cgi scripting), some might even enjoy this. However, if you have ever tried to maintain a perl program, particularly someone else's, then believe me, the fun drains right out of the experience. Perl code is a mess of obscure control characters which can change the meaning of the code significantly.
    Anything that says "X sucks" stands a good change of being downscored, and probably deserves it, too. 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. 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:

    STOP HIRING VISUAL BASIC WEENIES TO MAINTAIN PERL CODE!.

    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.

  • by Tom Christiansen (54829) <tchrist@perl.com> on Wednesday January 05, 2000 @08:16AM (#1402804) Homepage
    "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."
    You aren't going to want to hear this, but listen carefully: you did not RTFM.

    It's clearly documented. Always has been. You were just guessing how localtime(3) behaved instead of looking it up and reading the precise behaviour. A library API is a contract. If you sign up to using that library without reading the fine print, then you cannot complain when that fine print bites you in the ass. Stop guessing, and read!

    You are incorrect in your assumption that this is somehow peculiar to Perl. Whether it's peculiar in general is another question entirely. :-) I wrote about this in a letter to Dan Gillmor [mercurycenter.com]. Essentially, you need to understand a struct tm [openbsd.org]. Apparently the situation is even worse in Java Script, where it appears that different implementations behave differently.

    If you're on the cutting edge of Perl technology, please pay special attention to the new -DPERL_Y2KWARN configuration option. It produces an effect like this:

    % perl -we 'printf "Year is 19%d\n", (localtime)[5]'
    Possible Y2K bug: %d format string following '19' at -e line 1.
    Year is 19100
    Interesting, eh? Another option is to use the D'oh::Year module [perl.com] by Michael Schwern. The author wrote about it here in Dej a News [deja.com]. Anyway, here's the README.Y2K file from the 5.005__63 release of Perl:
    The following information about Perl and the year 2000 is a modified version of the information that can be found in the Frequently Asked Question (FAQ) documents.

    Does Perl have a year 2000 problem? Is Perl Y2K compliant?

    Short answer: No, Perl does not have a year 2000 problem. Yes, Perl is Y2K compliant (whatever that means). The programmers you've hired to use it, however, probably are not. If you want perl to complain when your programmers create programs with certain types of possible year 2000 problems, a build option allows you to turn on warnings.

    Long answer: The question belies a true understanding of the issue. Perl is just as Y2K compliant as your pencil --no more, and no less. Can you use your pencil to write a non-Y2K-compliant memo? Of course you can. Is that the pencil's fault? Of course it isn't.

    The date and time functions supplied with perl (gmtime and localtime) supply adequate information to determine the year well beyond 2000 (2038 is when trouble strikes for 32-bit machines). The year returned by these functions when used in an array context is the year minus 1900. For years between 1910 and 1999 this happens to be a 2-digit decimal number. To avoid the year 2000 problem simply do not treat the year as a 2-digit number. It isn't. When gmtime() and localtime() are used in scalar context they return a timestamp string that contains a fully- expanded year. For example, $timestamp = gmtime(1005613200) sets $timestamp to "Tue Nov 13 01:00:00 2001". There's no year 2000 problem here.

    That doesn't mean that Perl can't be used to create non- Y2K compliant programs. It can. But so can your pencil. It's the fault of the user, not the language. At the risk of inflaming the NRA: ``Perl doesn't break Y2K, people do.'' See http://language.perl.com/news/y2k.html [perl.com] for a longer exposition.

    If you want perl to warn you when it sees a program which catenates a number with the string "19" -- a common indication of a year 2000 problem -- build perl using the Configure option "-Accflags=-DPERL_Y2KWARN". (See the file INSTALL for more information about building perl.)

    We've known about this in C for about twenty years or so. So, let's not pretend you haven't been notified, ok?

news: gotcha

Working...