Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

www.perl.com Debunks Perl Myths

By rusty in News
Sun Mar 05, 2000 at 11:42:37 PM EST
Tags: Software (all tags)

You all know what my favorite language is. But I frequently hear, both on the net and IRL, a bunch of untrue things about perl that a lot of people seem to believe. I remember answering nearly every one of the ten perl myths listed in this www.perl.com article once, in a discussion with a lawyer, an IP broker, and a venture capitalist. None of them were ever programmers. That's how far these myths have spread! Anyone else have good perl (or any other language) myths to share?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o ten perl myths
o www.perl.c om
o Also by rusty

Display: Sort:
www.perl.com Debunks Perl Myths | 41 comments (41 topical, editorial, 0 hidden)
Uh, you refer to perl.com. perl.co... (1.00 / 1) (#4)
by evro on Sun Mar 05, 2000 at 07:11:38 PM EST

evro voted 1 on this story.

Uh, you refer to perl.com. perl.com is not the same site as www.perl.com. You should change this.
"Asking me who to follow -- don't ask me, I don't know!"

Very interesting.... (1.00 / 1) (#5)
by mike on Sun Mar 05, 2000 at 07:18:46 PM EST

mike voted 1 on this story.

Very interesting.
. . . . . . . . . . . . .

I'll give this the thumbs up, even ... (none / 0) (#1)
by Paul Dunne on Sun Mar 05, 2000 at 07:34:22 PM EST

Paul Dunne voted 1 on this story.

I'll give this the thumbs up, even though I still think awk & sed are better ;-)

Re: I'll give this the thumbs up, even ... (none / 0) (#8)
by rusty on Sun Mar 05, 2000 at 11:55:26 PM EST

awk? sed? Good god, man! What are you doing fooling around with High Level Languages like those! Think of all the optimization opportunities you're missing!


Not the real rusty
[ Parent ]

Re: I'll give this the thumbs up, even ... (none / 0) (#24)
by Paul Dunne on Mon Mar 06, 2000 at 07:46:19 AM EST

Well, obviously I don't actually use these so-called "software tools": I do any real work by toggling the front panel switches with my teeth -- doesn't everyone?
[ Parent ]
Re: I'll give this the thumbs up, even ... (none / 0) (#25)
by rusty on Mon Mar 06, 2000 at 07:52:31 AM EST

Front panel switches! What an idea! Man, I'll have to wire up some of those to my transistors... no more plugging and unplugging for me, I tell you...

Not the real rusty
[ Parent ]
Nice. I've just started learning pe... (none / 0) (#3)
by fvw on Sun Mar 05, 2000 at 07:48:11 PM EST

fvw voted 1 on this story.

Nice. I've just started learning perl yesterday, so this might be interesting. Mind you, the first thing this made me think of was the MS linux myths page.

This was already mentioned on Slash... (1.33 / 3) (#6)
by Craig McPherson on Sun Mar 05, 2000 at 08:29:42 PM EST

Craig McPherson voted -1 on this story.

This was already mentioned on Slashdot. Besides, "xyz myths" and "rebuttal to xyz myths" have become way too common in the past few months. It all started with Microsoft's "Linux myths!" then 325 "Rebuttal to Linux Myth"'s, "Netware myths", "Rebuttal to Netware myths", "Sun myths", "Rebuttal to Sun myths," "Win2000 myths," "Java myths," etc. etc. These so-called pieces of literature are bland, uncreative pieces of advertising propoganda for the most part, and vacuous overall. These corporations and individuals need to stop trying to disguise their flamewars as web pages.

Re: This was already mentioned on Slash... (5.00 / 1) (#7)
by rusty on Sun Mar 05, 2000 at 11:53:33 PM EST

Generally, I agree with you. All those "corp-myths" pages are generally marketroid drivel that only tell one side of the story. This is obviously pro-perl, and ORA does have a corporate interest in perl, since they sell the best perl books. But besides all that, it is a very good article.

If you're interested in the other side, www.perl.com also has The Seven Deadly Sins of Perl (c. 1996) and Sins of Perl Revisited (c. 1999). I think it lends a little more credibility when the same site has both sides of the coin.

And about "this was on Slashdot...", the general concensus here seems to be:

  1. If it's a good story, run it.
  2. Many of us don't read /. anymore, so it won't be repetetive.
I don't mind overlap when it so happens that /. actually runs an interesting story. If we start running the same stuff all the time, then I'll worry, because it'll mean K5 has started to Suck (and I don't expect that to happen for at least a year). ;-)

Besides which, out of curiosity I took a look over there, and I couldn't turn up this article. Are you sure you saw it there?

Not the real rusty
[ Parent ]

Re: This was already mentioned on Slash... (5.00 / 1) (#28)
by lachoy on Mon Mar 06, 2000 at 08:24:51 AM EST

It was there, but it of course turned into a
foreach my $language ( qw( python c java scheme ) ) {
  print "Perl sucks, $language rules.\n";

sort of flamefest, like any discussion of perl on /. does.
M-x auto-bs-mode
[ Parent ]
Re: This was already mentioned on Slash... (5.00 / 1) (#29)
by rusty on Mon Mar 06, 2000 at 08:41:14 AM EST

Ugh. yeah, this article worried me a little, cause I didn't want it to be like that. Doesn't seem to be though. We do of course have dissenting opinions, but I had an interesting and coherent, and I think mutually informative, little thread with AH going. Went pretty well, I think. :-)

Not the real rusty
[ Parent ]
I would like everyone on the planet... (3.00 / 1) (#2)
by rongen on Sun Mar 05, 2000 at 09:04:20 PM EST

rongen voted 1 on this story.

I would like everyone on the planet to read the article mentioned above as soon as possible! :) Seriously, it's a good summary of the problems people think exist with Perl and why these issues may not be that big of a deal. I like Perl, I don't feel like I'm wimping out when I implement programs with it (I've actually heard people say "why not use a _real_ language?" ), and I am always amazed at how easy it can be to get things done. Perl is a gift, it makes life easy...
read/write http://www.prosebush.com

A little dose of blasphemy (4.30 / 3) (#9)
by Anonymous Hero on Mon Mar 06, 2000 at 12:22:27 AM EST

From the Perl myths page: "Perl is just for one-liners - can't build `real' programs with it."

Sure, you can write a real program in Perl. You can also build a real bridge with popsicle sticks and rubber cement. But that doesn't mean you should.

Perl is really good at getting glue programs done quickly. It is also really good at making a huge, steaming mess when applied to a large, complex task. I would hazard to guess that most of the people who actually like the language don't maintain Other People's Perl for a living.

Re: A little dose of blasphemy (none / 0) (#10)
by rusty on Mon Mar 06, 2000 at 12:41:37 AM EST

And I shall repeat the counter-mantra "Just because Perl makes it possible to write bad code doesn't mean it requires it" and the zen-like cycle shall be complete.

Now that that's out of the way, I can say what I really think. :-) Yes, perl does make it easy to write bad code. No, perl doesn't enforce bad coding tecniques. The pragma 'use strict' only really requires you to scope your variables properly (and a couple other things, that you should *never* do anyway). I sometimes think there should be a 'use totalitarian' pragma as well, that simply disallows use of many of the sketchier things you can do in perl.

Yes, there's a lot of bad perl out there. Some of it is running this site. :-) But the problem is not with the language. Perl itself is fast, easy to learn (but hard to master, kinda like Go), and amazingly flexible. What's really needed is perl developers who care about writing good code. The biggest problem is that perl is very easy to learn, and therefore a lot of people never learn how it *should* be done.

And I totally agree with you about Other People's Perl. Maintaining my own can be hard sometimes (I'm in that swamp right now, AAMOF). But I still maintain that at heart, perl is one of the good guys. I also think that as more and more people grow up learning OO Perl, better perl will result. A lot of the really steaming piles are from old-time perl 4 guys, who write things like:

while(<>) {s/^.*(\d\/\/):(.*?)\s/$2:$1/;print;}

which, I'm pretty sure, is actually a valid loop. Ugh. Hopefully the tradition of "terseness" will go away pretty soon.

Not the real rusty
[ Parent ]

Re: A little dose of blasphemy (none / 0) (#11)
by Anonymous Hero on Mon Mar 06, 2000 at 01:00:30 AM EST

Yes, perl does make it easy to write bad code.

I would go so far as to say that Perl makes it hard to write good code. This, I think, is the serious problem with the language. If it takes all of my concerted efforts and attention to produce maintainable code in a given language, then that language is a waste of my time.

I agree with you that some Perl programs are worse than others when it comes to readability.. And that it's not valid to criticize a language just because it's possible to write really cryptic code in it. But it is not only possible to write really cryptic Perl code, it is inevitable. Sure, if you really try, your programs will be immeasurably better than the while loop you offer for illustration above. But even the best Perl programs are necessarily difficult to maintain. And for that, I blame the language.

[ Parent ]

Re: A little dose of blasphemy (none / 0) (#12)
by rusty on Mon Mar 06, 2000 at 01:06:18 AM EST

What do you think should be different? I.e. what are the worst offenders in terms of maintainability, and what should be there to make it easier to write good code?

Not the real rusty
[ Parent ]
Re: A little dose of blasphemy (none / 0) (#19)
by Anonymous Hero on Mon Mar 06, 2000 at 02:19:47 AM EST

I'll try to limit this to the worst offenders. :)
  • Data typing: Or rather, the lack thereof. For some, this is just a matter of personal preference. But I believe that if a typing error can be caught during development, then there is absolutely no excuse for it coming up during runtime. To quote someone whose name escapes me at the moment, "Runtime is too late to find out you have no landing gear."

    Is it a string? Is it a number? Is it an instance of FooClass? Who knows? .. until the program bombs out on you when it's in production.

  • Formal function parameters: Or rather, the lack of them. At a glance, there's no way to determine what parameters this function expects:

    sub function() {
    $some_variable = shift;
    # ... lots of other code
    $another_variable = shift;
    # ... more code
    while (@_) {
    # ... yet more code

    Okay, so maybe you try to alleviate this by only gathering paramters at the top of your function and declaring the function as such: "sub function($$@)". Does that really help all that much? So it takes two scalars and a list. What two scalars? What list? Why should I have to read the function in order to figure out what parameters it takes? Furthermore, Perl does no checking of paramters, so even if you manage to pass what you think are the correct amount/type of parameters to a function, you have no way of telling whether they're right.. until your program craps out mysteriously two weeks later.

  • Silly reference semantics: This has been treated extensively elsewhere, so I won't repeat it here. Basically, it boils down to the fact that Perl makes it much more difficult to manipulate data structures than necessary.
Okay, these are my main complaints. I suppose you could dismiss them by arguing that the proper role of a language is not to place restrictions on the programmer (like, say, data typing). If you do argue that, I would have to disagree. Certain well-considered rules and restrictions are what make higher-level languages more robust and maintainable than coding everything in assembly.

[ Parent ]
Re: A little dose of blasphemy (none / 0) (#21)
by rusty on Mon Mar 06, 2000 at 02:44:04 AM EST

Points one and two would be (somehow) fixed in my 'use totalitarian' pragma. I pretty much agree with you there. However, you can check datatypes in your functions, if you think people might be passing in garbage. This should probably be done in any program, anyway (shouldn't it?).

As for three, I quite like perl's reference semantics, and I don't think they impair large data structures in the least. In fact, the examples on the page you linked to are examples of bad perl, or, at least, pretty uninformed perl. If I wanted to, say, build an array of hashes, here's what I would do:

$hash1 = { FOO => 'bar', THIS => 'that' };
$hash2 = { FOO => 'you', THIS => 'them' };
$my_array = [ $hash1, $hash2 ];

Note that I'm not really using arrays or hashes, but array references and hash references. I like references so much I hardly ever use real arrays or hashes anymore.

So, say I want the value of the key 'FOO' in the second hash in the array. It's sitting right there in: $my_array->[1]->{FOO}

That thingy with the arrows above can be used like any other scalar. If I want to use the array like an array, I can call it @{$my_array}. So, for example, I can traverse and print this entire data structure like this:

foreach my $hash ( @{$my_array} ) {
    foreach my $key ( keys %{$hash} ) {
        print "$key equals $hash->{$key}\n";

I think that's pretty nice. And you can nest your '->'s arbitrarily deep.

Not the real rusty
[ Parent ]

Re: A little dose of blasphemy (none / 0) (#22)
by Anonymous Hero on Mon Mar 06, 2000 at 03:17:04 AM EST

In regards to 'use totalitarian': If Perl requires a bunch of sweeping changes that would break every Perl program in existence in order to make the code halfway maintainable, then, well, the language has got problems. :)

Yes, you can create and manipulate data structures as you describe, but then you've got to deal with all kinds of syntactical garbage: @{&my_array}, %{$hash}, $my_array->[1]->{FOO}. I suppose this should really have been a separate "complaint": Perl's syntax just plain sucks. Call me superficial, but the purpose of a language is to act as an interface between a programmer and a machine. And if that interface is unpleasant to use, the programmer's life becomes unpleasant. (If you do not think that this particular syntax of Perl sucks, then I guess it's just a matter of opinion. But for me, rampant punctuation does not a pretty language make.)

[ Parent ]

Re: A little dose of blasphemy (none / 0) (#37)
by ironside on Mon Mar 06, 2000 at 04:55:31 PM EST

I'm new here so hi everyone.

Functions in perl really do suck. If you spend half an hour looking at how python handles function you'll get a glimse of how good they could be and it will always bug you. Does me anyway.

More solid datatyping would be nice but I don't think it is that important.

I code perl as my job (well for some of it) and I spend alot of my time making code maintainable. I have not found this to be the case in any other language. PHP is painfully simplistic but the code is usually readable/nice 'by default'.

Perl is simply a bad choice for large/multiprogrammer projects. The effort that has to be put into making a system maintainable means you lose any of perl's benefits. I 'use strict', not using it means variables end up being impossible to 'place'.

References are cool (and make you feel smart :) but when I look at complex data-structs + oo in perl I really see a system of using references to handle complex stuff. I think a hll should be more than that.

Basically perl is cool until you have to be disciplined with it. Then it becomes an overly complex (syntaxically) pain in the arse.

Just a brain dump...

[ Parent ]
Re: A little dose of blasphemy (none / 0) (#39)
by rusty on Mon Mar 06, 2000 at 06:38:30 PM EST

Yeah. I'm puzzling out an object serialization library that 'lachoy' wrote right now, for use in Scoop, and I know what you're saying.

One plus though, with perl (IMO) is inheritance by encapsulation ('has a' rather than 'is a'). It's really nice to be able to roll a bunch of objects up into one neat little ball, and pass it around to all the methods (well, if you write it right, it goes to all the methods by itself). Ok, it's not "Correct" in the strict CS sense. But it is convenient, and makes the barrier to entry to OO thinking a lot lower.

And when you get a library that's written right, it can be a dream to work with. But maintainability is a problem.

Not the real rusty
[ Parent ]

Re: A little dose of blasphemy [OT] (none / 0) (#41)
by Therac-25 on Tue Mar 07, 2000 at 10:58:12 PM EST

.. until the program bombs out on you when it's in production.

I know that was intended as an off the cuff remark, but I can't help but be anal.

Too many programmers seem to think that the development cycle consists of Plan -> Code -> Production. What about QA? Any problem which is due to something as basic as mistyping a variable (as you note, something that should be a compile-time error) really *should* have been caught in testing. If it wasn't, you're not doing good enough QA.

Testing can't catch everything, but there is something very wrong if it can't catch a compile-time error.

"If there's one thing you can say about mankind / There's nothing kind about man."
[ Parent ]

QA (none / 0) (#42)
by rusty on Wed Mar 08, 2000 at 10:12:22 AM EST

You guys are my QA. :-) And you've been remarkably good at it so far. Of course, I'm not trying to sell anyone this software. If I were, you're right-- someone should be testing it.

Not the real rusty
[ Parent ]
Re: A little dose of blasphemy (none / 0) (#26)
by Imperator on Mon Mar 06, 2000 at 07:56:15 AM EST

while(<>) {s/^.*(\d\/\/):(.*?)\s/$2:$1/;print;}

Actually, if you know Perl, that's very easy to understand. (It appears that for some reason you'd like to replace "http//:foo/ " with "foo/http//", but I assume you were tired when you posted it so I'll give you the benefit of the doubt. :)) The problem is that if you don't know Perl, it looks like line noise.

[ Parent ]

Re: A little dose of blasphemy (none / 0) (#30)
by rusty on Mon Mar 06, 2000 at 08:43:46 AM EST

The example was just something that would be valid, but look like line noise to a newbie. Actually, there has to be a number before the '//', so it wouldn't do what your interpretation would expect. I can read it, but I prefer not to write code like that. :-)

Not the real rusty
[ Parent ]
Re: A little dose of blasphemy (none / 0) (#32)
by rongen on Mon Mar 06, 2000 at 08:50:12 AM EST

I would hazard to guess that most of the people who actually like the language don't maintain Other People's Perl for a living.

Toucheť (sp?).

Actually, I have been confronted with piles of spaghetti code written in Perl (at the time I called it "squirrel"). Yes, that's a freakin' nightmare... But I do like Perl for doing my own thing. For CGI I prefer Java Servlets. For doing my Operating Systems assignments I prefer C. For doing OOP I prefer Java (and I'm learning C++, which seems to have some features which are lacking in Java... plus I have some problems with Java that I am still not finished internally debating).

If you have some skilled programmers who are willing to adhere to a well defined coding style/standard , and who enjoy commenting, there is no reason why Perl couldn't be used for large, long-lived projects... But I agree that this is rarely the case...
read/write http://www.prosebush.com
[ Parent ]

Re: A little dose of blasphemy (none / 0) (#33)
by Emacs on Mon Mar 06, 2000 at 10:04:41 AM EST

I think you get to the heart of the matter when you describe the different languages you use for different tasks. The thing that I find amusing about the language wars is that a language is really a tool for getting a job done. Some tools work better for some jobs and some work better for others. The article kinda touches on that a bit also.

You will probably never hear a bunch of carpenters argue about a hammer being better than a screwdriver... each works great for what it does... yeah you can hammer a nail with a screwdriver, but why?

I love perl for the down and dirty quick tasks and for string manuipulation it's great. But I tend to "think in C" so my perl programs tend to look like C... I use perl alot for quick prototypes and for testing also. You can write a short perl program that will connect to a socket and read/write data in just a few lines. Real nice for debugging etc...

[ Parent ]
Re: A little dose of blasphemy (none / 0) (#34)
by rusty on Mon Mar 06, 2000 at 10:49:13 AM EST

I agree with that. I tend to think in terms of web programming (i.e. I have a mental transaction-based model, which probably makes me useless for anything but web coding), so perl is the natural tool for me to do my job. Whatever else you might say, it's good at handling strings. And 98% of web code is handling strings. Python, I hear, is good at that too. But that whole "whitespace is syntax" thing kinda disturbs me. I should really try writing something in python sometime though. Not mention, Ruby, which sounds very cool. It's basically real Object-Oriented perl, from what I hear... :-)

Not the real rusty
[ Parent ]
Re: A little dose of blasphemy (none / 0) (#38)
by Imperator on Mon Mar 06, 2000 at 06:15:32 PM EST

The whitespace used to bother me, but it's grown on me. I indent anyway, so why not let the indentation replace the curlies? Whether or not you think Perl is readable, it's hard to argue that Python isn't.

[ Parent ]
Good perl references? (4.00 / 1) (#13)
by evro on Mon Mar 06, 2000 at 01:25:25 AM EST

This is sort of off the topic of the perl myths but related to Perl in general.

I tried my hand at perl for databasing and got confused and basically gave up. Then I found PHP and it was like a holy grail. The thing that made PHP so freaking easy was the kick-ass documentation. Like, I wanted to know how to interface with MySQL so I went to http://www.php.net/manual/ref.mysql.php3. Look at that, it's goddamn beautiful.

Now, the only things I used to learn PHP and MySQL were php.net, phpbuilder.com, and the esteemed Webmonkey. That's all. However, I own Programming Perl and Perl Cookbook, and looked for similar references on the web, but I really couldn't find anything. What I was looking for was the Perl equivalent of PHP.net, a list of all of perl's built-in functions (as well as those in all the libraries), how they work, the return types, etc.

Now before anybody flames me for not looking hard enough, or in some really obvious place, I should say that when I learned perl for this database project I was doing, the MySQL on the webserver didn't work, so I created my own bizarre database. When the MySQL finally got up and running I had already decided that PHP and MySQL would be the best route, so I didn't spend any time looking specifically for perl/MySQL references.

I guess the real point / question I have is that there is no central documentation that I have found for Perl. Yeah, there's www.perl.com, but I can't find anything there equivalent to the PHP docs.

Here again I repeat that I am relatively naÔve in the Perl world, I wrote that database and then ditched it when moving to php and never really looked back (except for the occasional email-me form, and my ultra-lame guestbook (my first real experiment with perl)). So keep the flamage to a reasonable level, please.

Oh, I have a request: I want to make it so that when somebody enters text into a textarea and sends it that the line breaks are inserted in the right place. like every 80 chars, but not breaking a word in two. I tried a lot of weird things and the best I could come up with was

$fields{MESSAGE} =~ s/(.{71}[^\s]+)/$1\n/g;

which is not quite what I wanted, because if the last word in the line is superfragilisticexpialidocious, it won't wrap it. This seems like it would be a common problem but I haven't found a solution anywhere and can't seem to figure one out for myself. Any help would be appreciated.

"Asking me who to follow -- don't ask me, I don't know!"
Wordwrapping (none / 0) (#14)
by Anonymous Hero on Mon Mar 06, 2000 at 01:48:15 AM EST

There is a wordwrapping module included with Perl that will do all this sort of stuff for you. I believe it's documented in the Camel book.

[ Parent ]
Re: Wordwrapping (none / 0) (#18)
by rusty on Mon Mar 06, 2000 at 02:18:34 AM EST

Ha! Well, yeah, if you wanna do it the *easy* way! :-)

It's page 512 of P.P. 2nd edition. And probably better than my way.

Not the real rusty
[ Parent ]

Re: Good perl references? (none / 0) (#17)
by rusty on Mon Mar 06, 2000 at 02:15:09 AM EST

First of all, I don't think there really is a good central online source for perl documentation like the (incredibly cool) PHP docs. The camel book does have a whole section that's just an alphabetical list of all of perl's built-in functions -- arguments, usage, etc. The problem really is that a lot of perl stuff is provided by modules, which are not always part of the normal distribution. Generally the way to go is:
  1. Find out what module does what you need to do
  2. Install it
  3. do: $] perldoc modulename
Most perl modules come with very good perldoc-style documentation.

As for your coding question... let's see. Try:

$fields{MESSAGE} =~ s/([^\b]{77})(.*)/$1- $2/g;
$fields{MESSAGE} =~ s/(.{0,80}\b)/$1\n/g;

The first regexp breaks long words (and even adds a hyphen for you! :-), the second searches for the word boudary nearest to 80 chars, and inserts a newline there. The key is the \b entity. It means "word boundary" which is really what you're looking for.

Ok, so maybe sometimes it does look like line noise. :-)

Not the real rusty
[ Parent ]

Re: Good perl references? (none / 0) (#27)
by lachoy on Mon Mar 06, 2000 at 08:20:56 AM EST

Perl has an excellent central source of documentation: your installation of perl. Perldoc is an incredibly handly tool:

Documentation about a function:
perldoc -f function

Learn about references and data structures:
perldoc perlref

Learn about OO perl:
perldoc perlobj
perldoc perltoot
perldoc perlbot

Search the FAQ for an entry by keyword:
perldoc -q keyword

Most (if not all) of the text in these entries is straight from the Camel book, although some of it's been revised in the intervening years.

This isn't to say that other documentation isn't helpful: I frequently use the Perl Cookbook (Tom Christiansen and Nat Torkington) and Object-Oriented Perl (Damian Conway), among others. And sometimes I just need to print out a copy of a modules documentation (try readin the Template toolkit docs all online - ouch!):
man -t -M /usr/lib/perl5/5.00505/man Template
dumps it right out in postscript format to my printer.
M-x auto-bs-mode
[ Parent ]

Re: Good perl references? (4.00 / 1) (#31)
by rusty on Mon Mar 06, 2000 at 08:48:46 AM EST

These docs are indeed excellent, when you already have an idea of what you're doing. The cool thing about the php docs is, if you have no idea, it's all there, laid out and linked, so you can browse and get a feel for the language.

I'm not sure this would even be possible with perl, at this point, though. PHP is a *much* simpler language. Not necessarily less poserful, but there's certainly less syntax.

It would be useful I think for someone to take the php docs as a model and try to get "the perl basics" into the same format. Users can also post comments about the php docs, right there on the page, when something is unclear or inaccurate.

What'dya say, lachoy? Wanna tackle this job? You don't have much else to do, do you? ;-)

Not the real rusty
[ Parent ]

Re: Good perl references? (none / 0) (#35)
by lachoy on Mon Mar 06, 2000 at 12:52:42 PM EST

A lot of this stuff is online, too: Perl documentation pages also a list of tutorials

There are some perl-only pubs online now, most notably Perl Month

I think one of the differences is that Perl is a general-purpose language while PHP is specifically for web applications. This makes it easier to create directed documentation.

That said, a php model might be kind of cool :)
M-x auto-bs-mode
[ Parent ]

Re: Good perl references? (none / 0) (#36)
by rusty on Mon Mar 06, 2000 at 03:50:37 PM EST

Actually, PHP aspires to be as general-purpose as perl. It can be run "standalone" as an interpreted language (with speed comparable to perl, AFAIK), and used for scripting, glue logic, and even small applications. So it's not so farfetched to reverse the playing field and use their good idea for perl. :-)

Not the real rusty
[ Parent ]
Yes, there is more than one way of doing things. (3.50 / 2) (#16)
by Anonymous Hero on Mon Mar 06, 2000 at 01:57:47 AM EST

Python, Scheme, Ruby, TCL, to name a few.

I for one have never seen the attraction that Perl holds for programmers, even die-hard Unix geeks like the kind that tned to cluster around places such as this. Official propaganda to the contrary, Perl syntax is cluttered, and the large number of ways to do things means that no two people can ever agree on how to do things. While this sort of anarchy might serve the lone progammer at his open source project, I don't see how it could easily project into a large, corporate environment. I mean, we need results, and we need them now. Can I count on this if everyone does a different way of "doing things"? Sure creativity might have it's place in some hacker's project that will be dropped in a week, but I can't base a business on it.

if Perl is so good... (5.00 / 1) (#20)
by TomG on Mon Mar 06, 2000 at 02:36:44 AM EST

If PERL is so good, howcome it's written in C? Huh? Huh? ;-)

Not to mention that... (none / 0) (#23)
by Serf on Mon Mar 06, 2000 at 03:29:53 AM EST

... everyone knows C is actually written in Python. :)

[ Parent ]
Speaking of Perl... (5.00 / 1) (#40)
by rusty on Tue Mar 07, 2000 at 06:59:42 AM EST

The next YAPC (yet another perl conference) is coming up, June 21-23th, 19100. (Quick! spot the perl humor in the previous sentence!). It'll be in Pittsburgh again, and best of all, will feature paintball! I am so there. Anyone else who wants to get shot at by the founder of kuro5hin.org, I urge you to attend (especially you, McPherson!). :-)

Not the real rusty
www.perl.com Debunks Perl Myths | 41 comments (41 topical, 0 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!