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

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?

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

[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

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.

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

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

wtf?

[larry bagina]

I submitted this story almost 20 years ago!

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.

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

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

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.

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.

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.