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:I think I know the problem

[SharpFang]

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

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