Perl 1.0?

James A. A. Joyce writes "The title says it all. There's a tiny blurb over at dev.perl.org. Download Perl 1.0 here, for all of those nostalgics in the Slashdot audience! It's only 263KB, so why not give this piece of 1980s computing history a try?"

Comments

Quote in the bottom of my slashdot main page

[Smartcowboy]

"The camel has a single hump; The dromedary two; Or else the other way around. I'm never sure. Are you? -- Ogden Nash"

Re:Quote in the bottom of my slashdot main page

[larry bagina]

the only thing spookier than the coincidental quote at the bottom of the page is the coincidental ad at the top of the page. And the predictable content between them.

Re:Quote in the bottom of my slashdot main page

[Anonymous Coward]

a dromedary has one, a bactrian has two, both dromedary and bactrian are camels. Anybody dares to mod this +1 informative?

Re:Quote in the bottom of my slashdot main page

[Anonymous Coward]

You do realize that there are several possible banner ads on this page, don't you?

Re: Aside from historical value, what's the point?

[gooru]

so why not give this piece of 1980s computing history a try?

Because I can't actually do anything with it?

There's one good thing about it.

[Anonymous Coward]

At least it doesn't consider whitespace syntaxtically significant!

Re:There's one good thing about it.

[sporty]

'cuz remember.. 8 spaces != 1 tab != 4 spaces

great for when yuo do :set shiftspace=8 or tabstop=4

Re:There's one good thing about it.

[Anonymous Coward]

If you've actually *USED* Python, you'll find that it's a benefit, not a problem. Enforced readability through the language is good. You should stick to a coding style anyway when you're working on a large project with several people (something you may not have done if you've no significant commercial programming under your belt).

Having Python choose that style for you is a terrific readability benefit compared to something like Perl. It makes decyphering other people's Python code very very easy. It may not be exactly what you like - but I think it's a big win in the long run.

What will you complain about next? Having to use squiggly brackets in C? Having to press enter on the command line?

Re:There's one good thing about it.

[SharpFang]

You should stick to a coding style anyway
true.
Enforced readability through the language is good.
false.

I often find myself writing some C or Perl piece that if I follow general rules of indentation and generally obey the standard, I'll made that thing unreadable. Like, I have a 3-line-long boolean statement in if() (not even very complex but using lonv variable names) or add some "inline" error exception code like "...or die()" that's unrelated to the logical structure and shouldn't be indented.

Sticking to a code style is generally a good advice. But it shouldn't be LAW because indentation is meant to help understand the program by exposing important stuff, and hiding the less important and author of the language simply can't predict beforehand what we write will or will not be important and it's up to the programmer to follow the rules when they are wise and to BREAK THEM when they contradict the logic of the program being written and stand in way of better, more readable code.

Re:There's one good thing about it.

[kruntiform]

Oh dear, it looks like you didn't close one of your HTML blocks properly ;) In Python, you can join lines with a backslash:

if 1900 < year < 2100 and 1 <= month <= 12 \
and 1 <= day <= 31 and 0 <= hour < 24 \
and 0 <= minute < 60 and 0 <= second < 60: # Looks like a valid date
return 1

and you can split any kind of bracketed expression over multiple lines:

month_names = ['Januari', 'Februari', 'Maart', # These are the
'April', 'Mei', 'Juni', # Dutch names
'Juli', 'Augustus', 'September', # for the months
'Oktober', 'November', 'December'] # of the year

I don't know that you mean by inline error exception, but you can start comments at the fist column so that they stand out:

# *** inline error exception ***
"something ..."

(Some of the formatting in the above examples is messed up a bit by some slashdot bogusness. Actually, there's an argument against Python's whitespace blocks for you -- things like slashdot can mess them up.)

Re:There's one good thing about it.

[trouser]

Yeah, cause if you were forced to indent your code it might become slightly more readable which would marginally diminish the obfuscation inherent to all Perl code.

I suspect the initial popularity of Perl was due largely to it having been much better than the alternatives available in the late 1980s. And it's still better than the alternatives that were available in the late 1980s. The continued popularity is driven by an established userbase of guru Perl coders who aren't willing to budge and new users who pick it up because it's so popular it must be good.

I would rather use Java than Perl. And I'd rather be eaten by a crocodile than use Java.

Re:There's one good thing about it.

[unshaven23]

Perl's not that bad a language, once you've added the pragma use strict;. I love using perl for most quick and easy to automate tasks. If I had to run back to C every time I needed to look for "Foo" in a database or "Bar" in a logfile to replace it with its lowercase equivalent I wouldn't get any work done.

I'm all for strictly typed languages, with tons and tons of possibilities that perl doesn't have, but those languages don't save me time on small things. Perl is ideal for "quick shell scripts and CGI", but if you asked me to write something larger I'd grab back to C or C++ (depending on the nature of what you're asking).

Most people that use perl (nowadays) will tend to agree with me on this. If it has to be done quick and dirty, use perl and make good friends with CPAN. If you have the time and the project is bound to grow, use a different language.

Re:There's one good thing about it.

[metamatic]

So when I pull up a piece of Python code that's indented with three spaces, and edit it in vi which is configured to indent with tabs and display tabs as three spaces, the Python interpreter is going to somehow divine which lines line up? I don't think so.

No matter how much Python advocates try to convince me that it'll all somehow be better, I already spend too much time having to clean up irregularly-formatted Java and Objective-C code, and that's just for my own benefit when I have time spare. I don't want to deal with a language where I have to reformat other people's code just so I can work with it.

Re:There's one good thing about it.

[Anonymous Coward]

If you can't do it in Korn Shell, it doesn't need to be done.

Re:There's one good thing about it.

[Anonymous Coward]

Perhaps you have not yet mastered the Zen? If one tries to code Perl like "C", you get "C" that is written in Perl. Such is not the way of the Zen.
Instead, code the Perl, and let the magic do the work for you.

Perl is very expressive. It does what you say, and very little that you say has zero effect, compared with Java, where -- perhaps -- half of the code only exists because it must exist. Computo ergo Sum.

As for the sigils, perhaps you are treating programs as English. This is a mistake. A few characters of Perl are like Egyptian Hieroglyphs, tremendously powerful and instantly obvious to the trained eye. So little can be said with so few words, wasting no verbage or nounage. If you try to read it as English instead of understanding the meaning as Perl, you will be lost. @_ is not line noise. It's symbolic -- and for those that think graphically (outside of language), it can be processed very quickly -- as often in software some things have no good English analogue.

Do not pronounce $_ as "dollar_underbar", *know* the meaning of $_. Do not look at %dict as "percent dict", but know what the sigils do for you. They are there to lead the way, all you have to do is understand them instead of read them.

Also grasp the Zen of functional programming and the futility of over-complexity. Complexity serves to make things harder, so one must forego complexity. OOP? Added complexity for small programs. Structure? Add only what is required.

And I suppose you are also wondering about regex syntax. Regexes have clean syntax? This is to say that Elephants are too big and should come in a variety of colors.

Anyhow, learn the idioms, understand the Perl, don't speak it, and you will have a great written language -- if I can't be spoken or translated easily into other languages, perhaps that is the meaning of it's true greatness.

The written language of Egypt and the Mathematics of Babylon are not analogous to what English/Arabic -- but this doesn't mean they are not worthy of our study. What you see as line noise or drawings painted on walls may carry an elegance that simple utilitarian code-as-English will never succeed at grasping.

Larry's interest in language has benefitted Perl immensely. Try to look on Perl with that light.

Re:There's one good thing about it.

[Da VinMan]

Well, the obvious answer is to just use an editor where this isn't a concern. It really isn't too much to ask to standardize the tools on a project so things like this don't become an issue. Besides, with vi, I believe you could just embed vi directives that configure vi on the fly to your current tabbing standards, etc. True?

Anyway, I used to think that the division between programmers produced by Python's indentation requirement was a problem. After all, it makes us argue about a stupid sounding issue. However, I don't think it's a problem anymore. It's an acid test. To me, the central question is: Will you conform your working style enough to allow tools to augment your work and to allow the rest of your team to work with you? If your answer is no, then Python is not for you. If you answer is yes, then Python is for you. I prefer not to work with people who answer 'No' to that question. In general, they like to make a PITA out of themselves on several levels, and I have no desire to put up with that pain.

Of course, you could counter all this by saying something to the effect of "BS! It's really a question of whether you let your tools get in the way." or something like that. But then, that just affirms what I've been saying. Allowing our tools to change our working style a bit is a tradeoff, and it's one that many programmers are not willing to make. Hooray for them I say... let someone else work with them.

The technical point you raise above is a good one (i.e. the fact that Python code can be broke by inconsistent editor settings), but was never a problem for me on the Python project I worked on. Maybe we were just lucky, but all the problems people like to cite about the indentation rule just never came up for us. Even if it had been issue, I don't see how it could be much worse than a missing curly brace in Java. It's not a big deal to fix.

Re:There's one good thing about it.

[AJWM]

If I had to run back to C every time I needed to look for "Foo" in a database

Um, what have you got against whatever flavor of interactive SQL your DB supports?

or "Bar" in a logfile to replace it with its lowercase equivalent

Um, vi? or awk? or sed? or even ed?

Maybe the reason Perl programmers like it so much is that they're too lazy to learn any other tool. Just as if the only tool you have is a hammer, every problem looks like a nail, then if you're a Perl hacker, every problem looks like it needs a Perl solution...

Re:There's one good thing about it.

[Anonymous Coward]

For me, Perl scripts become unmaintainable at size about 100 kB. I do most of my everyday tasks in Perl. It is more powerful than any of shell scripts, sed or AWK. For scripts longer than 100 kB I'd recommend Ruby or Python. But if you want speed, none of them.

Re:There's one good thing about it.

[sisukapalli1]

Most people that use perl (nowadays) will tend to agree with me on this. If it has to be done quick and dirty, use perl and make good friends with CPAN. If you have the time and the project is bound to grow, use a different language.


I mostly disagree. A lot of advances in the abstraction of data (text templates, DBI abstraction, xml parsers, etc.) and modules from CPAN make a very compelling case for using Perl as a very good language for large projects too. Just that someone can write crappy code, doesn't make the language bad.

A good example: a lot of people that I know that write servlets use things like

out.println("<a href=\"" + pageLink + "\">Welcome</a>");

or something in perl, like
print OUT "<a href=\"$pageLink\">Welcome</a>";
or better,
print OUT qq{<a href="$pageLink">Welcome</a>};

when some templating mechanisms are better used, such as velocity
<a href="$pageLink">Welcome</a>
or Text::Template
<a href="$pageLink">Welcome</a>
(hehe... same way in both perl and java)

Comparing how novices write in Perl with how seasoned developers write in java is comparing apples to oranges.

S

Re:There's one good thing about it.

[Anonymous Coward]

What about the people who pick up your Python code 10 years down the road? Will they be using the exact same editor with the exact same settings? If so, it'll be a significant hindrance to them because it will be so outdated (see Ada-83 editors, FORTRAN editors, etc).

Re:There's one good thing about it.

[Da VinMan]

I have a hard time believing that people will have a hard time grokking today's Python code 10 or even 20 years from now. Really, isn't it much more evil to have to look up/remember the meanings of Perl operators over time? Good grief! If Python's worst sin is making people deal properly with whitespace in their programs, then future Python legacy programmers will have easy lives indeed!

Re:There's one good thing about it.

[bheerssen]

Blanket statements... Aaarghhh.

Don't base your choice of language on any arbitrary criteria such as file size. A language should be chosen based on the specific requirements of the application under development.

If your application needs to be able to parse many different kinds of documents, or you need to parse documents for many different types of data, the perl would probably be a nice fit. If you just want to enter and display data in a database, perhaps some other language might work better.

I have a script (perl 5.6 compatible) that is pushing 2000 lines, plus custom modules (3) that add up to an additional 1000 lines, plus CPAN modules that add up to lord knows how many lines. It gets accessed by as many as 50 clients simultaneously. It runs fine. By the time I finish porting it to mod_perl, it should handle many, many more simultaneous requests than that.

I chose perl for this project because no other language that I know of can match the text mangling features in perl. Perl can be (and often is) used successfully in an enterprise environment - in fact, you are looking at one. Slashdot runs perl.

Re:There's one good thing about it.

[metamatic]

Well, the obvious answer is to just use an editor where this isn't a concern.

Oh, so now I need a special text editor to use Python. Are there any editors which automatically adjust their tab width to match the apparent value used in the file being edited? Or are you talking about some hypothetical editor?

It really isn't too much to ask to standardize the tools on a project so things like this don't become an issue.

On the contrary, I think the chances of my persuading the open source developers whose code I use to conform to one standard, let alone my standard, are slim to none.

As to why tab damage is worse than a missing curly brace in Java: the difference between a curly brace and the absence of a curly brace is always visible.

Re:There's one good thing about it.

[elflord]

No matter how much Python advocates try to convince me that it'll all somehow be better, I already spend too much time having to clean up irregularly-formatted Java and Objective-C code,

Spoken like someone who's never actually tried it. Look, until you've tried it, you don't know what you're talking about, and you're just blowing smoke (like most people on slashdot). So shut up already.

Re:There's one good thing about it.

[Istealmymusic]

Oh, so now I need a special text editor to use Python.

No, all you need is to learn how to repeatedly press the spacebar instead of the tab.

Re:There's one good thing about it.

[Istealmymusic]

Um, vi? or awk? or sed? or even ed?

Maybe the reason Perl programmers like it so much is that they're too lazy to learn any other tool. Just as if the only tool you have is a hammer, every problem looks like a nail, then if you're a Perl hacker, every problem looks like it needs a Perl solution...

Perl is more like a swiss army knife than a hammer.

Re:There's one good thing about it.

[AJWM]

Perl is more like a swiss army knife than a hammer.

Fair enough. But while I use my swiss army knife a lot, I'd still rather use the right tool for the job if it's available.

Re:There's one good thing about it.

[weierstrass]

I like to use a programming language designed to ELIMINATE repetitive tasks.

Re:There's one good thing about it.

[Istealmymusic]

Then why don't you use an EDITOR that eliminates repetitive tasks?

Re:There's one good thing about it.

[metamatic]

Sorry, but you need to convince me that tab damage isn't going to be a problem with Python, even though it is with every other programming language I've ever used (over a dozen).

Maybe there *is* something remarkable about Python that makes it not subject to the formatting problems encountered in every other programming language, but convincing me of such a remarkable claim will require more than telling me to shut up.

Re:There's one good thing about it.

[shadowpuppy]

Asking people switch editors is probably taken with more disdain than asking them to switch programming languages. By now I know how to use vi/vim better than most people know how to use emacs. Switching would be a real pain in the ass. However, I can switch the editor to use spaces instead.

Personally I find the use of spaces for indentation to be an abomination. Because what invariably happens is somewhere someone uses 3 spaces instead of 4 or something like that. Then one editor will mix spaces and tabs. I used to have macros that would fix indentation for perl. I'm not sure what I would do for Python.

Re:There's one good thing about it.

[elflord]

Sorry, but you need to convince me that tab damage isn't going to be a problem with Python, even though it is with every other programming language I've ever used (over a dozen).

Saying that indentation is going to bring python projects to a halt is like trying to argue that unpaired parens will stop a perl project (or LISP!). In practice, it just doesn't work like that. Why ? Is it because it's easy to remember to close all parens ? Or is it perhaps because the interpreter catches these errors very quickly ?

The same happens with python. Indentation errors are caught very quickly. At worst, it's a minor nuisance while you fix the settings on your editor.

This, I suspect, is the reason why Python programmers do not in practice run into substantial syntax problems as a result of tabbing. It is a complete non-issue for people who program in python, it's only an issue for people who don't program in python and want something to bitch about.

Re:There's one good thing about it.

[Anonymous Coward]

No matter how much Python advocates try to convince me that it'll all somehow be better, I already spend too much time having to clean up irregularly-formatted Java and Objective-C code, and that's just for my own benefit when I have time spare. I don't want to deal with a language where I have to reformat other people's code just so I can work with it.

You don't, of course. You have to fix the formatting of irregularly-formatted Java and ObjC code because people have formatted it wrong. Improperly indented Python code doesn't work (in most cases, doesn't compile). You'll never have to reformat someone else's code to work with it, because it already has consistent formatting. You just continue to work in that formatting.

Both emacs and vim auto-adjust for files with a modeline (a single comment specifying tab width, spaces vs. tabs, etc.) If someone has slipped up and left out the modeline, you react like so (vim):

:set et ts=4 # for code indented four spaces
:set noet ts=8 # for code indented with tabs

Slap in a modeline and the problem is permanently fixed. Basic familiarity with your editor and the ability to type, in the worst case, fourteen characters are all that's required.

Re:There's one good thing about it.

[Anonymous Coward]

You wouldn't worry. The indentation is /already/ consistent as written, or the code wouldn't run. Either use a modeline in the file or do a quick

:set et ts=4 sw=4
:%retab

and you're ready to edit to your heart's content. If you still insist on indenting with tabs, you can use

:set noet ts=8 sw=8
:%retab

One editor mixing spaces and tabs isn't a problem; the person will have to fix their editor to be consistent or their code won't work.

Re:There's one good thing about it.

[Da VinMan]

Switching would be a real pain in the ass. However, I can switch the editor to use spaces instead.

Well, there you go! You found a way to work with the team. That's the whole point as far as I'm concerned.

Because what invariably happens is somewhere someone uses 3 spaces instead of 4 or something like that.

That would be my fear too. If you and I were on a project together and some greenhorn did that, suffice it to say that they would feel the sting from the reprimand for a while.

As far as what you would do with code like that, the answer is to throw it back to the dork who messed it up. If the indentation is all off, then it won't even compile. Therefore, it's not even usable. So, why worry about salvaging it? It's not even worthy of that yet.

See? The whole indentation thing is just a bunch of fear. It's not a real problem. I'm guessing from your post that you have not used Python yet, or that would be obvious to you too. Give it a try, you just might like it.

Or don't. But please refrain from expressing a bunch of FUD on something you haven't tried yet.

Re:There's one good thing about it.

[Fujisawa Sensei]

COBOL has similar maintainability benefits to Python.

Re:There's one good thing about it.

[Anonymous Coward]

Maybe because he prefers programming language that eliminates repetitive tasks, not an editor. Please see original post.

Re:There's one good thing about it.

[HumanTorch]

> What will you complain about next? Having to use squiggly brackets in C?
how could you complain about squiggly brackets in C and languages with significant whitespace at the same time?

seriously, a lot of people (including me) think languages that use braces are more readable than those that use significant whitespace such as VB. Perhaps we are just used to it, or perhaps the squiggly is the visual key to unlock our latent modularity..

eh

[Anonymous Coward]

so why not give this piece of 1980s computing history a try?

Or yould do as the C programmers do and still be left in the 70's.

Re:eh

[GnuVince]

If I had points, I'd mod you "Insightful". It's true, C has not evolved much (except for libs) since the 70's. Time to move to the 21st century please.

Re:eh

[Anonymous Coward]

Time to move to the 21st century please

Welcome to .Net's C#, hm, what's that familiar smell? Maybe if I sipped a bit more on my cup 'o joe...

Re:eh

[adelton]

Why move anywhere? It's perfect.

Re:eh

[tomstdenis]

It hasn't radically changed but it has changed none the less.

We don't use K&R style function parameters. I'm rather certain various keywords are new [and deprecated like "auto"]. The language is actually a standard now, not just a "works on my compiler".

I can't really see a valid argument for most newer languages. For example, often people argue "with Java you don't need to recompile to run it elsewhere". But that isn't actually a feature of the Java language. It's a feature of the Java runtime environment.

Nothing is stopping people from writing a C compiler that targets a VM that is then subsequently ported to other boxes.

Similarly for Javascript [which is very much like C not Java ... wierd, should be called C-script] C could be used there.

And similarly for CGI applications, etc, etc.

The only other language I can understand for daily use is Perl which is way better at text manipulation. C++ doesn't actually allow the author todo anything that can't be performed with clever use of structures [and not that complicated todo anyways]. Ruby and PHP are Perl knock-offs, Java is just stupid, slow and a bitch to work with, etc, etc, etc.

There is probably a reason why the vast majority of software people use is written in C. I just can't put my finger on it...

Tom

Re:eh

[Anonymous Coward]

You make some excellent points, tom. So, what do you think of the new perl built-ins, can_manham() and bottle_mangoo()? I'd imagine they'll help you out a great deal!

Re:eh

[tomstdenis]

I don't get it. Can you rephrase your post in a form that doesn't read like a down syndrome retard bashed his keyboard with his forehead?

Thanks,
Tom

Re:eh

[Anonymous Coward]

Are you describing his post, or yours?

Re:eh

[tomstdenis]

Yes.

Re:eh

[Anonymous Coward]

I thought so. There's a treatment for your condition. It's called laying off CANNING THE MANHAM AND BOTTLING THE MANGOO!

Re:eh

[tomstdenis]

Can you please continue posting these? These sorts of replies are validating my existance. I need them to reassure I'm still alive.

I need you! Give me your soul!

Re:eh

[Anonymous Coward]

Oh, okay, I'll do my best. See, it's about Perl, right? and perl has functions. And now it's got functions called first,

can_manham()

and another one called

bottle_mangoo()

See, as you, tomstdenis, both can manham and bottle mangoo, I figured you might use these functions often to help you can manham and bottle mangoo. Does that help at all?

Re:eh

[Anonymous Coward]

I don't swing that way.

Re:eh

[tomstdenis]

TROGDOR!

memories

[Anonymous Coward]

Anyone else remember perl's early foibles and its similarity to awk?

Re:memories

[Anonymous Coward]

You mean besides its similarity to awk?

Some things to point out.

[James A. A. Joyce]

Before I continue, I'd just like to point out that on the offchance that something goes wrong with regard to dev.perl.org, I uploaded a copy before the article was posted in case of Slashdotting or if you just want to use a mirror.

With that out of the way, there's a few limitations of the language which I found quite interesting:

• There's no switch statement
• There are no hash table variables (i.e. those beginning with a '%')
• No support for recursive subroutines
• And yes, Larry does say that Perl "actually stands for Pathologically Eclectic Rubbish Lister, but don't tell anyone I said that." Oh. Oops.

Oh, and when you download the package and untar it all into a directory, it won't work out of the box. Here's some instructions on how to make it work on Red Hat Linux system. First, untar it all into one big folder. Then, run ./Configure and just press Enter. When 'make depend' has run, you need to edit the Makefile. Open the Makefile up in your text editor and get rid of all the lines containing either '<built-in>' or '<command line>'. Then you should be able to just do 'make' and you now have a copy of Perl 1.0 as ./perl in the current directory.

Re:Some things to point out.

[Anonymous Coward]

There's no switch statement in perl5 either, dumass.

Re:Some things to point out.

[Anonymous Coward]

yes there is. It was added in perl 3, IIRC.

Re:Some things to point out.

[QuMa]

There still isn't a switch statement you know... Well, not in perl 5 anyway. There'll be one in perl 6.

(oh, 5.8 has "use Switch;", but that's cheating)

Re:Some things to point out.

[reynaert]

No, Perl5 has no switch. There are several ways to emulate one (some less ugly than others) but there is no true switch statement. From the perlsyn manpage:

There is no official "switch" statement in Perl, because there are already several ways to write the equivalent.

I believe I read Perl6 will have one.

Re:Some things to point out.

[SharpFang]

> Forbidden
> You don't have permission to access /drewt/tgz/perl-1.0_15.tar.gz on this server.

Could you fix please?

Re:Some things to point out.

[Magic Thread]

As others have noted, 5.8 doesn't have a switch statement either. "Perl actually stands for Pathologically Eclectic Rubbish Lister, but don't tell anyone I said that" also appears in the perl manpage in 5.8, under the Bugs section. I wonder why they still haven't fixed it!

Re:Some things to point out.

[chromatic]

There are certainly hashes in Perl 1. See hash.[ch], for example.

Did you file a bug report for your Makefile issue? Richard Clamp is maintaining this version.

Re:Some things to point out.

[unshaven23]

bah, switch is for people who are scared of using if... Incidentally, perl does have a nice alternative. Prepare a hash with all the possible values used as keys, and then use references to functions to do what you want to do.

For instance:

#!/usr/bin/perl

use strict;

sub reply_y { print "You code too much perl!\n"; }
sub reply_n { print "You don't use enough perl!\n"; }

my %switch = ( 'y' => \&reply_y, 'n' => \&reply_n };

print "Would you use a hash as a switch statement? (y/n) ";
my $answer = <STDIN>
if (!$switch{lc $answer)) {
print "You've reached the default\n";
} else {
&$switch(lc $answer));
}

I however don't recommend things like this to fellow programmers that have to maintain this sort of code in the near/far future. Things like this tend to become unreadable. I can't say I miss switch that much in perl. Switch always seemed a bit syntacticly unpure in some way, but that's just my twisted mind.

Re:Some things to point out.

[cant_get_a_good_nick]

Things like this tend to become unreadable.
And thats different from 99% of perl code out there how?

Re:Some things to point out.

[Istealmymusic]

Nothing wrong with dispatch tables. Very maintable in my opinion.

Re:Some things to point out.

[fizbin]

See, now I'd inline the whole table if you're only using it once:


print "Would you use a hash as a switch statement? (y/n) ";
my $answer = <STDIN>;
if ($answer !~ /^[yn]$/i) {
print "You've reached the default\n";
} else {
chomp $answer;
{
'y' => sub {print "You code too much perl!\n";},
'n' => sub {print "You don't use enough perl!\n";}
}->{lc $answer}->();
}

Re:Some things to point out.

[Phroggy]

As long as you're simplifying the example, if it's just printing strings, why use subs?

print "Would you use a hash as a switch statement? (y/n) ";
my $answer = ;
if ($answer !~ /^[yn]$/i) {
print "You've reached the default\n";
} else {
chomp $answer;
print {
'y' => "You code too much perl!\n",
'n' => "You don't use enough perl!\n"
}->{lc $answer};
}

You've lost one of the benefits of using a hash, by the way: your check for $answer against 'y' or 'n' isn't tied to the possible values of the hash, meaning the two could get out of sync if you have many possible values and change them from time to time. Checking if(exists $switch{lc $answer}) is a cool thing to be able to do.

wtf?

[larry bagina]

I submitted this story almost 20 years ago!

The Language To End All Languages

[quinkin]

Ah, Perl 1.0.

All the power of QBasic, the readability of assembly, and the flexibility of DOS batch scripting...

(Apol. to all the offended nostalgics :)

Q.

Re:The Language To End All Languages

[Magic Thread]

You forgot "the speed of Java."

Re:The Language To End All Languages

[Anonymous Coward]

And "the regularity of /dev/random"

Sorry about that.

[James A. A. Joyce]

Now fixed.

I think I know the problem

[recursiv]

I submitted this story almost 20 years ago!

Normally, you would think that with that much lead time, the /. crew would have been able to get their act together and post the story. But I think I figured out what went wrong. Slashdot didn't exist yet!

Re:I think I know the problem

[SharpFang]

err, slashdot is written in Perl :) So..... was it written in some pre-1.0 version? ;)

Dupe Post

[Anonymous Coward]

It has to be, it's 20 years old.

Oh, how about this:

I know slashdot is behind the news, but this is ridiculous. :)

Re:Dupe Post

[AKnightCowboy]

I know slashdot is behind the news, but this is ridiculous. :)

"Bah, I saw this on fark.com three weeks ago."

The title must not say it all

[Anonymous Coward]

I've always wondered about this construction: "The title says it all." The person then goes on to discuss something about it, as in "[t]here's a tiny blurb over..." Does the title say it all or not?

Also on my annoyance list: "Needless to say." If it's needless to say, then why say it?

Re:The title must not say it all

[Istealmymusic]

Also on my annoyance list: "Needless to say." If it's needless to say, then why say it?

The clause "needless to say" is used to avoid patronizing the more advanced readers, while still providing seemingly-obvious information to the neophytes. Needless to say, what is obvious to one is not necessarly obvious to another; therefore what needs to be said to a neophyte does not need to be said to a guru.

birthday?

[perlchild]

I thought perl was released december 18th...
Did I miss something?

Re:birthday?

[Anonymous Coward]

Larry Wall's birthday, you big silly.

Ack!!!

[stevens]

As someone who uses perl quite a bit, using this 1.0 gave me a line I've seen before only in my nightmares:

$ ./perl -w -e 'print "Just Another Perl Hacker,";'
Unrecognized switch: -w
$

Aaaaaggghh! Must ... have ... warnings ...

What the hell?

[Anonymous Coward]

Have you seen what the submitter's username (James A. A. Joyce) is a link to? Trollse.cx, a parody of goatse.cx featuring a picture of Eric S. Raymond on its front page.

Re:What the hell?

[Anonymous Coward]

Yep :) JAAJ is a "troll on trolls", being to the troll community what a troll is to slashdot community :) I like that!

He's an incorreigible karma whore too, but we must him forgive that :)

Why not try it out indeed?

[torpor]

I'll tell you why not: because its PERL!

I can't imagine it was good at 1.0, considering how crap it is at its current whatever-it-is release ...

Re:Why not try it out indeed?

[Istealmymusic]

Never knew "crap" was an adjective. Maybe you mean Carp? (Its not an adjective either.)

Re:Why not try it out indeed?

[torpor]

No, I mean crap, as in the stuff that comes out of everyones ass.

I'll use it however I want. I think Perl is crap!

Re:Why not try it out indeed?

[Istealmymusic]

Maybe you should read the Carp POD documentation.

Secondly you contradict yourself. First you say: I mean crap, as in the stuff that comes out of everyones ass.. This cleary coincides with the first definition of crap:

1 a usually vulgar : EXCREMENT b usually vulgar : the act of or product of defecating

However, then you say: Perl is crap!. Needless to say this usage corresponds to the second definition:

2 sometimes vulgar : NONSENSE, RUBBISH; also : STUFF 4b

You appear to be confused, I suggest you read the Carp documentation, its very informative, and you'll learn a lot about Perl.

Re:Why not try it out indeed?

[torpor]

I think you must be American. In British English, you can say that you think something is "CRAP" and it means that you think that thing is actually shit.

No way I'm going to bother with anything at .cpan.org ... I hate Perl.

It is crap!

Re:Why not try it out indeed?

[Istealmymusic]

That's very torpor of you.

Perl 1.0

[metamatic]

"...so why not give this piece of 1980s computing history a try?"

Because I remember it?

I didn't consider Perl usable until Perl 5, because that's when it *finally* got lexically scoped local variables... Pretty horrifying that it took four major revisions to get that far.

I'll tell you why not

[Anonymous Coward]

because it's crap that's why. Python and Ruby are the pimp daddys. Perl is their bitch.

I'm crushed.

[chrome]

...
Run make depend now? [y] ./makedepend
echo arg.c array.c cmd.c dump.c form.c hash.c search.c stab.c str.c util.c version.c | tr ' ' '\012' >.clist
Finding dependencies for arg.o.
Finding dependencies for array.o.
Finding dependencies for cmd.o.
Finding dependencies for dump.o.
Finding dependencies for form.o.
Finding dependencies for hash.o.
Finding dependencies for search.o.
Finding dependencies for stab.o.
Finding dependencies for str.o.
Finding dependencies for util.o.
Finding dependencies for version.o.
echo Makefile.SH makedepend.SH | tr ' ' '\012' >.shlist
Updating Makefile...
Now you must run a make.
chrome@zaphod $ make
make: *** No rule to make target `', needed by `arg.o'. Stop.