Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Secret History of Perl

Hemos posted more than 14 years ago | from the larry-speaketh dept.

Perl 279

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.

cancel ×

279 comments

Sorry! There are no comments related to the filter you selected.

Re:Larry Wall is a treasure (0)

Anonymous Coward | more than 14 years ago | (#1402564)

Please - look both ways before you cross the street, and every other precaution we can think of. We can't afford to lose you...

Its not that cloistered over there in perltown - Larry is neither the chief maintainer for perl5 or the chief developer of perl6. Thankfully, those people have an excellent role model...

This argument is tired and untrue (0)

Anonymous Coward | more than 14 years ago | (#1402568)

I will admit that if you know Perl well, then yes, you can write powerful programs quickly

Then learn it and shutup.

A crappy programmer is crappy in any language. Even Java will slap you down if you don't know some of the intracacies of how the language works. There's no free ride in programming...you're going to have to earn your million.

However, if you have ever tried to maintain a perl program

Yawn...maintaining crappy code in any language is a hassle. Once again, its hard to read any language you don't know how to use. Even Java won't solve this problem for you.

Perl's design is not just a rebellion against established thinking, it is a rebellion against good software design and it shows

Most perl coders aren't trying to write large applications with the language. Obviously it isn't well suited for writing 100k LOC programs - neither is Python (both are too slow at this size), so programming in the large is irrelevant. Its about getting things done. Until you really need to get something done in a short amount of time, you'll probably have no use for, or ever understand the motivation for perl.

Perl Shell - the next revolution (0)

Anonymous Coward | more than 14 years ago | (#1402569)

One piece of software I have become interested in is the Perl Shell (psh).

With it, you can do normal shell-like operations, but load in perl packages, and do perlish stuff right there on the command line.

I'm excited by this and I really hope it one day kills off sh,csh, etc, all of which are showing their age and are really, really painful to program in.

The notion of simply combining the most powerful scripting language with interactive shell operations is just to powerful to ignore.

Re:Crazy guy, crazy language (0)

Anonymous Coward | more than 14 years ago | (#1402572)

Python is a mental constrictor.

Read the printer friendly version of the article. (0)

Anonymous Coward | more than 14 years ago | (#1402574)

Link: 10&article=uncultured">http://www.linux-mag.com/cg i-bin/printer.pl?issue=1999-10&article=u ncultured [linux-mag.com]

The printer friendly version has the whole article on one page, rather than balkanizing the thing into five sections. (Why do websites do that? Chance to show more ads to readers?)

Re:This argument is tired and untrue (0)

Anonymous Coward | more than 14 years ago | (#1402575)

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.

This should be considered a strength, not a weakness. Flexibility costs you a little brain ppower at the beginning, but pays off in the end.

It's certainly possible to write large scale software projects in Perl

Hmmm, although I am a perl-head, its unlikely that a dynamically typed and linked language will give you the performance you need for programs this size. I am not limiting my criticism to perl or python in this regard. Of course, if you rewrite parts in C, then your perl or python code was simply a prototype - an approach i support and encourage. Its easier to get the concepts right in perl and then reimplemenet in C if need be.

Its all about using the right tool for the job.

Re:Perl - a new mainstay in the world of unix (0)

Anonymous Coward | more than 14 years ago | (#1402576)

You will know. When your code you try to read six months from now

Right - because if you aren't using perl, you'll still be developing the project. I imagine the code will be even more fresh in your mind if you're using a totally handicapped-approved language like Java, which is even more verbose.

I'm not picking on Python - its a great language, and most perl folks would do well to learn it and use it where applicable.

Re:Crazy guy, crazy language (0)

Anonymous Coward | more than 14 years ago | (#1402577)

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.
Thankfully, not all programmers are burdened with your learning disabilities.

Talk about a cliff-hanger ending.... (0)

Anonymous Coward | more than 14 years ago | (#1402578)

How can this be off-topic in a story posted by someone calling themselves "Tim Toady" ?

Re:Python Bigotry (0)

Anonymous Coward | more than 14 years ago | (#1402579)

Ian, please keep your frothing python bigotry to yourself. It has no place here.
Mark that one up as Insightful.

Tom's right. I'm really sick and tired of the python people shitting all over perl. Maybe they were shit on by script kiddies as children. I don't know. But their zealotry has convinced me never to even try to learn python. They should take they flames elsewhere. Everytime perl comes up, they spray us with flamewars. Screw it. That guy is being offtopic, flamebaiting, and trollish. It's not related to the main article. It's just religious fervour. Screw him.

Re:Crazy guy, crazy language (0)

Anonymous Coward | more than 14 years ago | (#1402580)

Perhaps, but the problem is that even well written Perl code requires a good knowledge of the syntax

WHAT LANGUAGE DOESN'T???

Programming is hard work. Language syntax is the least of it. If you can't handle some minor issues of learning the syntax of a language, you should have very low expectations for your performance as a programmer.

I know this is starting to sound like a flame, but your general argument that its all so confusing is simply starting to sound like the type of bitching I hear from people who haven't read Programming Perl or made a real effort to learn Perl in some meaningful way.

Dumb debate (0)

Anonymous Coward | more than 14 years ago | (#1402581)

Listening to all this talk about what tools make dumb programmers less dumb is ridiculous.

Take a language like Java - most people think it helps bad programmers become mediocore programmers, but since bad programmers never bother learning about heap vs. stack, object churn, object reuse, and serialization, they'll never be much use to anyone as Java programmers in any case.

No one anywhere needs crappy coders. Dicussing their plight is a waste of time.

Re:Legos kiddies and professional architects (0)

Anonymous Coward | more than 14 years ago | (#1402582)

You obviously have a vested interest in stating otherwise. The more people you can convince that Perl is easy to learn and work with, the more books you sell.
This is slanderous bullshit. I have never seen Tom lie, or even twist the truth, in order to get people to spend money. In fact, if you get to know him, you'll see how anticommercial and graciously and honestly helpful he is. He's given away more of his time and energy and life for free than he can ever hope to gain back. Conspiracy theories like this are the worst thing I can imagine to hit somebody with who helps so many of us. What a cheap shot.

Argue with his ideas, but insult him ad hominem for reasons of greed and you become slimier than anything you could thrown on someone else.

We listen to what Tom says about Perl because of his experience. Should we just get idiots in here who've never written any Perl? Does writing a book mean you're suddenly not an expert? Should we stop listening to Rich Stevens and Dennis Ritchie and Larry Wall for the same reason?

What a horrible thought!

That these people have written books makes them more credible, not less so. Shame on you!

Re:There *is* such a thing as too much flexibility (0)

Anonymous Coward | more than 14 years ago | (#1402583)

I don't think there are many people, even among skilled Perl coders, who could claim to know all of the neat tricks available.
You obviously don't subscribe to P5P. Tom has no monopoly on cleverness and tricks. I'll bet there are hundreds of people there who know every single Perl `trick', your funny word for feature.

On that question, what about knowing every little semantics of the two dozen C libraries used to write Enlightenment? That's far harder than learning what angle brackets do it Perl.

Re:Legos kiddies and professional architects (0)

Anonymous Coward | more than 14 years ago | (#1402584)

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?

*laugh* moderate this guy up!

Come on Tom, you can make better arguments then that ;)

Re:Perl and Y2K (0)

Anonymous Coward | more than 14 years ago | (#1402585)

Please don't blame your lack of understanding of the localtime function call on Perl. I'm looking at the camel book, and it clearly says that the return values come straight out of struct tm. Also, two sentences later, it says "the year has had 1,900 subtracted from it". As a programmer, you do have some responsibility to understand exactly what values are being returned from a function call. If you can't figure that out, you have no right using the function in the first place.

Also, if some of your dates are showing as 19100, then I'm assuming you are doing the following:

printf("The year is 19%d\n", localtime() -> year);

Now how the hell is Perl, or any language for that matter, supposed to make your code Y2K compliant when you have hardcoded a 19 in there? Hardcoding a 19 should have been your first clue that your code wasn't Y2K compliant. Yes, your code, not perl. Also, I suggest you read the Perl Y2K statement again, as it clearly says that it is possible to make your perl programs non-Y2K compliant if you really want to, which is just what you did.

Re:Legos kiddies and professional architects (0)

Anonymous Coward | more than 14 years ago | (#1402587)

I have never seen Tom lie, or even twist the truth

LOL, this sounds like HAL -
"Tom has never made a mistake, or distorted information"

And now for something even easier to read (0)

Anonymous Coward | more than 14 years ago | (#1402590)

Python equivalent to your first version is

for thing in array_of_things:
print thing

The equivalent of your second version is

from string import join print join(array_of_things, '\n')

While yours is the cleanest perl I have seen in a long time, it should be obvious that python eins on readability.

Re:There *is* such a thing as too much flexibility (0)

Anonymous Coward | more than 14 years ago | (#1402591)

Ok Tom, you want to play the "please back up your statements with mathematically sound arguments" game.

No one wants you to take it from Reimann Sums, just justify what you mean about "too much flexibility". Its pretty simple - what flexibility is bad?

I don't think there are many people, even among skilled Perl coders, who could claim to know all of the neat tricks available.

The same can be said for any language. C++ is full of bugbears that most programmers aren't aware of, nor need to be aware of. You're propping up all your own programming inadequacies on the notion that perl's syntax is somehow too difficult to comprehend. What you've really demonstrated is that you are unwilling or unable to grasp the tools that millions of other programmers (who have "done their homework") have few problems wielding usefully.

There is no language that gives you something for nothing.

Early versions of Perl (from 1988) (0)

Forrest J. Cavalier (16105) | more than 14 years ago | (#1402606)

Here are the RocketAware.com links to early versions of PERL (like versions 1 and 2) in the comp.sources.unix archives.

Perl - a new mainstay in the world of unix (1)

Anonymous Coward | more than 14 years ago | (#1402608)

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.

Re:Interesting statement[s] (1)

Anonymous Coward | more than 14 years ago | (#1402610)

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

Re:Perl is *NOT* Hard for Beginners (1)

Anonymous Coward | more than 14 years ago | (#1402611)

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

Scalar/Reference problem also exists in many langs (1)

Anonymous Coward | more than 14 years ago | (#1402612)

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.

Re:Crazy guy, crazy language (1)

Sanity (1431) | more than 14 years ago | (#1402617)

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.

--

Re:Crazy guy, crazy language (1)

Sanity (1431) | more than 14 years ago | (#1402618)

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.

--

There *is* such a thing as too much flexibility (1)

Sanity (1431) | more than 14 years ago | (#1402619)

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.

--

Re:Crazy guy, crazy language (1)

Sanity (1431) | more than 14 years ago | (#1402620)

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.

--

Re:Legos kiddies and professional architects (1)

Sanity (1431) | more than 14 years ago | (#1402621)

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.

--

Re:Crazy guy, crazy language (1)

Sanity (1431) | more than 14 years ago | (#1402622)

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!

--

Re:Legos kiddies and professional architects (1)

Sanity (1431) | more than 14 years ago | (#1402623)

It seems a little naieve to say that your favourite programming language is "organic and natural" and others aren't. It is like and English speaker saying "English is much more natural than German". It is relative to what you are familiar with. The point is that regardless of your point-of-view, Perl's philosophy is one of having maximum flexibility, minimum design constraints. As I have explained elsewhere in this thread, too-much flexibility and redundancy(sp?) make languages too difficult to comprehend for all but experts. Programming is a skill, I agree. But once you have got good at programming in one language, it should be possible to apply those skills to comprehending code written in other languages. Perl's flexibility prevents this, and I think that is a bad thing!

--

Re:There *is* such a thing as too much flexibility (1)

Sanity (1431) | more than 14 years ago | (#1402625)

Firstly, Re: Tom's contribution to the Perl literature, I am well aware of that, and his resulting fan-club. He certainly is prolific, both on paper, and on screen.
You claim that you can learn as much or as little as you want of Perl, and then happily code using that. My point is, and has been throughout this thread, that Perl is difficult to comprehend for those trying to maintain the code, not those trying to write it. Because Perl offers so much flexibility is it very difficult to understand code based on a knowledge of a subset of the Perl langauge, and because the syntax is so flexible, almost everybody is only aware of a subset of the language! In my view, syntax should be as simple as possible, leaving the complexity to the libraries which can be indexed and consulted with ease. It is much more difficult to index a syntax than a library.

--

Re:Crazy guy, crazy language (1)

Sanity (1431) | more than 14 years ago | (#1402628)

The difference between Unix and Perl is that with unix, it is clear when you see the "fgrep" command, that in order to learn more about it, you must type "man fgrep". What page of "Programming Perl" will explain how to interpret:
$@ && ($@ =~ s/\(eval \d+\) $$ (\d+)/0;
The problem is that it is much more difficult to find out what a particular syntax means unless you already have a vague idea (ie. ooh, that is a regular expression, go to the regexp chapter) but even then it can be difficult. You don't need to have any idea what "fgrep" does, or "System.out.println" if Java is your language, in order to look it up.

--

Re:Crazy guy, crazy language (1)

JerkBoB (7130) | more than 14 years ago | (#1402643)

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

Re: finding bugs in Perl... If you're not using -w and strict, you really should be. Even for quickie one-off scripts, take the time to program the script properly, using locally-scoped variables. It builds character, or something... I started off programming in C, but do systems administration now and use Perl all the time. Most of what I program still looks mostly like C (which earns me ridicule from the Perl-hacking webmonkeys here), but it works and is easily read and maintained by people other than myself. As far as weak typing in Perl goes, I think it's just a matter of shifting one's thinking. It's usually pretty obvious what the 'thingies' (scalars) are being used for if the programmer has taken the time to document and write unobfuscated code.

Which leads to the comment about software design... Again and again I see people complaining about how awful Perl is to read and maintain. When I see that, I have to think that either they're digging their heels in and don't want to learn something new (I was there), or else they've only really seen nightmare scripts written by people with less than a clue about good software design. As many other people have pointed out, it's possible to program badly in any language. Some make it harder than others (java, smalltalk for examples), but there are always tradeoffs to be made.

In short, don't write off (npi) Perl without at least trying it out first. If you do systems administration or large amounts of text monkeying, you will not be sorry you tried it.

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

Re:Crazy guy, crazy language (1)

JerkBoB (7130) | more than 14 years ago | (#1402644)

d'oh... wasn't done editing. sometimes i wish there was a "Are you sure you're ready to submit?" option for those times when i hit submit instead of preview. *sigh* Oh, well.

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

Re:Crazy guy, crazy language (1)

JerkBoB (7130) | more than 14 years ago | (#1402645)

If all you had to do was string manipulation (like outputting HTML), then you're golden with perl. But would you choose to use Perl as a language for developing business logic?

Or to write a database? (insert your own examples here)

I don't think most people will argue with your contention that Perl isn't the best language for everything (I certainly won't). However, for people like me who do systems administration or for companies like mine which use Perl for allowing web pages to talk to databases, it's great. As our company grows and we add more logic to the system, we'll probably think about moving that logic from Perl to something compiled, but for now most of what we do is presentation, and this is where Perl shines.

Of course I wouldn't want to write a database (or compiler, or productivity app) in Perl. I also wouldn't want to write it in Java, or SmallTalk, or (insert lots of other languages here)... Perl is a good thing to have in a well-rounded toolbox, though. Sorta like an adjustable crescent wrench/hammer/screwdriver all rolled into one. Sure, that socket driver might work better for a certain situation, so it might save time to use it instead, but a lot of times the multi-tool will work just as well or better (faster since you've already got it).

Carrying the metaphor to an extreme, one could make the case that a good programmer should have a large toolbox of specialized tools. However, lugging around all of those tools is not practical, and it's much easier to have a multi-tool that fits in one's pocket, and the specialized tools are only pulled off of the shelf when the multi-tool doesn't work well enough. The key is recognizing when one is beginning to waste time by futzing with the multi-tool when the specialized tool would work better.

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

Re:Crazy guy, crazy language (1)

chromatic (9471) | more than 14 years ago | (#1402650)


...my point is that to anyone trying to learn Perl, all perl code is obfuscated to an extent.

To anyone trying to learn Latin, all Latin is obfuscated to an extent. "Paginarium Fulvinarium" anyone? (Watch me misspell it and prove my point.) I'm not aware of any programming languages which don't have some commonly used idioms that might confuse neophytes.

...give a non-Perl programmer a copy of "Programming Perl" and see how long it takes them to figure it out...

Why would you hire a non-Perl programmer to maintain existing Perl code? Are you suggesting that one measure of the 'suckiness' of a language is the ease with which someone ignorant of the language can perform code maintenance?

--

Re:Early versions of Perl (from 1988) (1)

Forrest J. Cavalier (16105) | more than 14 years ago | (#1402658)

Whoa. Like the HREF got replaced with a link to slashdot.... Hello Rob, get somebody on that!....Maybe this will work, sort of.

Here are the RocketAware.co m [rocketaware.com] links to early versions of PERL (like versions 1 and 2) in the comp.sources.unix archives.

http://www.rocketaware.com/comp.sources.unix/spec/ softdev/lang/perl/

Re:Larry Wall is a treasure (1)

mezzo (20109) | more than 14 years ago | (#1402661)

Agreed. I love reading his writings, they always make me laugh and think. In fact, I think it was cos I read one of his speeches which got me to learning perl. Sorta, what kinda language can a man with this kind of mind produce?

Perl is Hard for Beginners (1)

SEWilco (27983) | more than 14 years ago | (#1402668)

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. I had to resort to translating a few simple awk and sed scripts to see what the equivalents were.

Re:Perl and proof of the Open source model (1)

NullGrey (46215) | more than 14 years ago | (#1402675)

Perl is one that I usually bring up, along with Apache, SendMail, and BIND.

Re:Legos kiddies and professional architects (1)

cainem (48703) | more than 14 years ago | (#1402676)

Easy on the bold, tiger ;-)

What exactly is a "Visual Basic Weenie", anyway? Is anyone who knows VB automatically a "weenie", or is there some qualifying characteristic?




Editorial botches (1)

TimToady (52230) | more than 14 years ago | (#1402677)

Note that the figures are botched at the beginning. The first figure is supposed to be about combining Linguistics, Computer Science, Common Sense, and Art.

Re:Crazy guy, crazy language (1)

speek (53416) | more than 14 years ago | (#1402683)

Your example brings to mind an image of two ugly demons at the bottom of a pit competing to see which is less ugly.

Try comparing Perl to a syntactically friendly and well-designed language, and

use an example other than one dealing with string manipulation, where Perl is great, no one denies.

If all you had to do was string manipulation (like outputting HTML), then you're golden with perl. But would you choose to use Perl as a language for developing business logic?

Or to write a database?
(insert your own examples here)

Re:Crazy guy, crazy language (1)

speek (53416) | more than 14 years ago | (#1402684)

I agree entirely. I wish I could mesh languages together so that I could use the best of them all at different points in my programmin tasks.

However, a lot of Perl advocates seem to want to do a lot more with Perl than is good for it. Why did Perl get OO stuff added on, for example? Is that really the direction Perl should be going?

Re:Legos kiddies and professional architects (1)

mochaone (59034) | more than 14 years ago | (#1402688)

Saying that Perl sucks is acceptable in the context of the previous poster's comment. He prefaced his statement accordingly so it didn't just come out of nowhere.

You seem to imply that "competent, professional programmers" can write Perl programs and leave them in good state for future maintainers. I assume you mean programmers who are true CS people and not some accountant who took a course in programming at night school. I don't see where a formal CS education can prepare anyone for the syntactical mess that Perl is. Intelligent people, regardless of background, have been successful programmers. I believe there are some languages that are more suitable for learning and quite frankly, Perl isn't one of them.

You obviously have a vested interest in stating otherwise. The more people you can convince that Perl is easy to learn and work with, the more books you sell. Perl can't be everything to everyone, but please stop denigrating people for either complaining about Perl or for being "an unskilled laborer". You sound elitist and actually contradict yourself when you do that.

Re:Legos kiddies and professional architects (1)

mochaone (59034) | more than 14 years ago | (#1402689)

Take a deep breath and count from 1 to 10. Feel better?

The fact that you interpreted my comments as slanderous says more about you than me. Tom Christiansen is a Perl evangelist. Tom Christiansen is an author of Perl books. Tom Christiansen stands to benefit from the proliferation of Perl.

It's also amusing that you ask me not to "attack" Tom when that seems to be his favorite MO. Maybe you need to give Tom a pep talk about that.

Re: Crazy guy, crazy language (1)

meek13 (68425) | more than 14 years ago | (#1402691)

I will admit that if you know Perl well, then yes, you can write powerful programs quickly ithin particular domains (notibly cgi scripting), some might even enjoy this.

isn't this a rather important feature? certainly it's possible to write utterly incomprehensable code in perl. that's possible in any language. the beauty of perl is the fact that buried in all that potental confusion is a truly powerful and intuitive solution to just about whatever problem one faces. not many languages can claim to be as diverse as perl, and the languages that do encompass the same broad spectrum don't (in my experience) do it nearly as cleanly. *shrug* perl's not for everyone, but it's invaluable to those who don't like learning new syntax every time they face a new problem.

mike

Re:Perl is *KINDA* Hard for Beginners (1)

meek13 (68425) | more than 14 years ago | (#1402692)

can't say i completely disagree with the sentiment in the original post. perl's not the most intuitive language, and it certainly can be difficult to grasp some of it's more esoteric features. one of the amazing things about the language, however, is that one doesn't *have* to grasp it's totality to do astounding things in short periods of time. perl's just damn good at what it does, and once you've figured out the basics, you can do just about anything, do it well, and do it quickly.

That's the wonderful Perl Cookbook does. And it does so splendly. I've only ever bought one Perl book -- this one -- but I've bought it three times. :-)

the first perl book i picked up was the camel book, and it's served me well.. got my second copy last week actually. the first one didn't hold up to my repeated perusings, and apparently decided to run away. i can't imagine a better investment though. there's more information packed into those few hundred pages then i'd have thought possible.

mike

Re:Crazy guy, crazy language (1)

jbaratz (68830) | more than 14 years ago | (#1402693)

Any language can be written incomprehensibly (C even has the obfuscated C contest to prove it), PERL just makes it easier. However, having worked in a company that made extensive use of PERL, I can say that maintence of that code was just as difficult (no more, no less) than maintenence of other code.

Software maintence all comes down to design standards and code review. In a good system there are agreed upon coding standards that all developers are familiar with, and code gets a peer revier before going into production. This review stage tends to lead to confusing bits of code getting commented heavily. As always, YMMV

Re:Perl and Y2K (1)

jidar (83795) | more than 14 years ago | (#1402696)

It was the result of a cut-paste and some hasty editing. Blah.. sorry.

Re:Perl and Y2K (1)

jidar (83795) | more than 14 years ago | (#1402697)

Why though? Why return the year minus 1900 if the intent is NOT to get a 2 digit year? And if the intent is to get a 2 digit year then clearly the code has a Y2K issue as it no longer does so. If the intent is NOT to get a 2 digit year, what is the intent? The function returns 'the year minus 1900' then we have to 'add 1900' to get the correct year.. how does this make sense?
Given all of that information, I think it would be a reasonable mistake, and as such not treated so.. hrm.. arrogantly?

Re:Perl and Y2K (1)

Tim Behrendsen (89573) | more than 14 years ago | (#1402698)

Well, I can appreciate your point, but take some responsibility here. If you had written:

printf("The year is 19%d\n", localtime() -> year);

How would you have expected that to work? Would the phrase "Perl is Y2K compliant" magically make that 19 turn to a 20?

Or did you do it a different way? Give me an example of how you wrote your script, and how you expected it to work in 2000.


---

What limitations with GPL? (1)

bigdogs (90229) | more than 14 years ago | (#1402700)

Larry Wall mentions in the article that just having the GPL prevented people from using Perl, and that's why he added the Artistic License.

What are the limitations with the GPL that he was concerned with?

Re:Crazy guy, crazy language (1)

sydj (90817) | more than 14 years ago | (#1402701)

And to be honest, who would design human language the way it is? Unneccesary redundancies and contradictions do not a nice language make. It's only because of the amazing capacity of the infant brain to learn language that we pick it up so easily.

That's the point isn't though? Despite it's "design", human language is expressive and powerful. It's evolved that way. And so it is, and will be, with Perl. Like LW said :

"A camel is a horse designed by a committee. Or at least it looks like one. But appearances can be deceiving, and a camel is well adapted to its ecological niche. So is Perl. Despite the fact that it is designed by a committee."

Plus, from the Camel book,
"Camel's weren't designed to smell good. Neither was Perl."

Re:Larry Wall is a treasure (1)

sydj (90817) | more than 14 years ago | (#1402702)

Also, thank LW for patch, surely his second best contribution to the programming world.

Re:Interesting statement[s] (1)

Darth Yoshi (91228) | more than 14 years ago | (#1402703)

Metaphores are like scabs. If you pick at them, they bleed. :-)

Re:Perl and Y2K (1)

sh4de (93527) | more than 14 years ago | (#1402704)

I started programming in Perl mere six months ago. I don't know, maybe I was just lucky to be guided at the most important resource of Perl right in the beginning: the online documentation packaged in the Perl distribution.

I remember reading about Perl's y2k compliance in the docs. From there, it was a no-brainer:

[blade@leela ~]$ perldoc -q 2000
=head1 Found in /usr/lib/perl5/pod/perlfaq4.pod
[clip]
The year returned by these functions [gmtime and localtime] 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.

I have the habit to get indignant when my intelligence is insulted, also. It helps to learn just the right amount of humility to consult the documentation first to avoid the need to blush later. YMMV.

Re:Crazy guy, crazy language (1)

bornholtz (94540) | more than 14 years ago | (#1402706)

In fact, I doubt if all but the most experienced Perl coders could write anything non-trivial without looking at a manual.

I guess I don't understand why it is so wrong to read the manual. Whenever a newbie asks a question is seems that the first response is always along the lines of "rtfm". If you follow comp.lang.perl.misc at all you will quickly learn that reading the manual is a "Good Thing". Linux has a similar culture around it. That's why all those HOWTO's are included with every distro.

I use Perl a lot and I'm not thumbing through the manual all the time. However, when I switch to C, C++, or Java I do look stuff up because I'm used to the Perl way of doing things.

My point is that when you only use a language occasionally (and especially when you only use it when you "have no other choice"), it might be difficult to remember all of the intricate details of the syntax. I'm just guessing that it is the intricate details because the if() blocks and the for() loops can be made to look exactly like C (but they don't have to). Also, most of the operators I use are exactly like every other language I use.

Perl is unquestionably a powerful language. There is a lot of obfuscated syntax (but all of that syntax is well documented). Even when you are writing "non-trivial" applications, Perl doesn't force you use all of the syntax of the language.

Re:Python Bigotry (1)

keyeto (113479) | more than 14 years ago | (#1402710)

Tom, please keep your own foaming at the mouth to yourself. It is a constant nuisance, and has no place anywhere.

Re:Crazy guy, crazy language (1)

wumpie (115336) | more than 14 years ago | (#1402711)

I agree.

Perl is not THE solution for everything, but for a lot of things. It is really great for system management and web stuff. Its also good for small programs doing just one special thing (see "rapid prototyping"). Because these are the things i do (i do not write huge ...-applications), Perl is my language.

Of course, its not easy to learn, but OReilly books help alot :-). I wish i will get only a quarter as skillfull as Larry or Tom.

See ya !

wumpie

Re:This argument is tired and untrue (1)

BinxBolling (121740) | more than 14 years ago | (#1402713)

A crappy programmer is crappy in any language.

Now this is a tired and untrue argument. While the best language in the world won't probably won't prevent a crappy programmer from producing crappy code, a poor language will most certainly make it much harder for a good programmer to produce good code.

If the quality of the language was irrelevant and only the programmer's skill mattered, all software would still be written in assembly language. It isn't. The conclusion is obvious.

Re:Possible /. interview? (1)

jbarnett (127033) | more than 14 years ago | (#1402715)

Thrid that. I vote (if I get a vote) to get Mr. Larry Wall over on slashdot for an interview.


Re:Crazy guy, crazy language (1)

evilphish (128599) | more than 14 years ago | (#1402716)

I disagree, yes perl can be hard to follow
sometimes, but the same is true of any language.
I for one find perl easy to use and code
in. its easy for me to look at other peoples code
and see why they set up sub routine A. instead of
sub B. but show me a chunk of C or java and I get
confused. Saying a language sucks because you
have a problem with it is pointless.
Use whatever works for you.

Gentleman, you can't fight in here, this is the war room..

Crazy guy, crazy language (2)

Sanity (1431) | more than 14 years ago | (#1402720)

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.

--

Re:Crazy guy, crazy language (2)

Jon Peterson (1443) | more than 14 years ago | (#1402721)

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

Re:Crazy guy, crazy language (2)

Jon Peterson (1443) | more than 14 years ago | (#1402722)

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.

Re:This argument is tired and untrue (2)

slim (1652) | more than 14 years ago | (#1402724)

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.

--

Re:Perl and Y2K (2)

slim (1652) | more than 14 years ago | (#1402725)

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

Re:Crazy guy, crazy language (2)

happybob (3990) | more than 14 years ago | (#1402728)

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

Re:Crazy guy, crazy language (2)

HiredMan (5546) | more than 14 years ago | (#1402729)

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

Re:Crazy guy, crazy language (2)

JerkBoB (7130) | more than 14 years ago | (#1402735)

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

That is obfuscated? (2)

tilly (7530) | more than 14 years ago | (#1402737)

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

Re:Perl and Y2K (2)

seebs (15766) | more than 14 years ago | (#1402741)

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.

Re:There *is* such a thing as too much flexibility (2)

Roundeye (16278) | more than 14 years ago | (#1402746)

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?

Re:Crazy guy, crazy language (2)

Roundeye (16278) | more than 14 years ago | (#1402748)

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.

Re:Interesting statement[s] (2)

evilpenguin (18720) | more than 14 years ago | (#1402752)

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.

Re:Crazy guy, crazy language (2)

cje (33931) | more than 14 years ago | (#1402762)

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.

Python Bigotry (2)

Tom Christiansen (54829) | more than 14 years ago | (#1402775)

Ian, please keep your frothing python bigotry to yourself. It has no place here.

Re:This argument is tired and untrue (2)

Tom Christiansen (54829) | more than 14 years ago | (#1402776)

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.

Re:Crazy guy, crazy language (2)

Tom Christiansen (54829) | more than 14 years ago | (#1402778)

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.

Re:Possible /. interview? (2)

meek13 (68425) | more than 14 years ago | (#1402780)

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

Re:Legos kiddies and professional architects (2)

jsm2 (89962) | more than 14 years ago | (#1402783)

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

Re:Perl - a new mainstay in the world of unix (2)

latifpaws (94523) | more than 14 years ago | (#1402784)

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.

Perl and proof of the Open source model (2)

seron (108111) | more than 14 years ago | (#1402785)

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.

Perl Rawks (3)

Anonymous Coward | more than 14 years ago | (#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!

Re:Legos kiddies and professional architects (3)

Anonymous Coward | more than 14 years ago | (#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.)

Larry Wall is a treasure (3)

jht (5006) | more than 14 years ago | (#1402788)

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

I just LOVE this quote: (3)

jabber (13196) | more than 14 years ago | (#1402789)

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!

Re:Crazy guy, crazy language (3)

evilpenguin (18720) | more than 14 years ago | (#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.

Interesting statement[s] (3)

Pike (52876) | more than 14 years ago | (#1402791)

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

Re:Crazy guy, crazy language (3)

Tom Christiansen (54829) | more than 14 years ago | (#1402794)

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.

Re:Legos kiddies and professional architects (3)

Tom Christiansen (54829) | more than 14 years ago | (#1402795)

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.

Perl and Y2K (3)

jidar (83795) | more than 14 years ago | (#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

Re:Crazy guy, crazy language (4)

Roundeye (16278) | more than 14 years ago | (#1402798)

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.

Re:Legos kiddies and professional architects (4)

speek (53416) | more than 14 years ago | (#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?

Anyone can write bad code in any language (4)

Ted V (67691) | more than 14 years ago | (#1402801)

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

Possible /. interview? (5)

NullGrey (46215) | more than 14 years ago | (#1402802)

Hey, Hemos & Taco, can we get Mr. Wall for a /. interview? He would be most entertaining.

Legos kiddies and professional architects (5)

Tom Christiansen (54829) | more than 14 years ago | (#1402803)

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.

Re:Perl and Y2K (5)

Tom Christiansen (54829) | more than 14 years ago | (#1402804)

"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?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?