Slashdot Mirror
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?"
"The camel has a single hump; The dromedary two; Or else the other way around. I'm never sure. Are you? -- Ogden Nash"
so why not give this piece of 1980s computing history a try?
Because I can't actually do anything with it?
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.
'cuz remember.. 8 spaces != 1 tab != 4 spaces
:set shiftspace=8 or tabstop=4
great for when yuo do
-
ping -f 255.255.255.255 # if only
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:
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.
Bash script for FP whores
I submitted this story almost 20 years ago!
Do you even lift?
These aren't the 'roids you're looking for.
All the power of QBasic, the readability of assembly, and the flexibility of DOS batch scripting...
(Apol. to all the offended nostalgics :)
Q.
Insert Signature Here
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?
Now fixed.
Bash script for FP whores
I submitted this story almost 20 years ago!
/. 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!
Normally, you would think that with that much lead time, the
I used to bulls-eye womp-rats in my pants
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
It has to be, it's 20 years old.
:)
Oh, how about this:
I know slashdot is behind the news, but this is ridiculous.
I thought perl was released december 18th...
Did I miss something?
As someone who uses perl quite a bit, using this 1.0 gave me a line I've seen before only in my nightmares:
Aaaaaggghh! Must ... have ... warnings ...
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.
Now wash your hands.
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.
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
"...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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
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.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
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...
-- Alastair
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
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!
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
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.
(Score: -1, Stupid)
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?
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
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!
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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.
-- Alastair
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:
However, then you say: Perl is crap!. Needless to say this usage corresponds to the second definition:You appear to be confused, I suggest you read the Carp documentation, its very informative, and you'll learn a lot about Perl.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
my password really is 'stinkypants'
Then why don't you use an EDITOR that eliminates repetitive tasks?
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
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.
.cpan.org ... I hate Perl.
No way I'm going to bother with anything at
It is crap!
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
That's very torpor of you.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
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.
Run make depend now? [y]
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.
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.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
COBOL has similar maintainability benefits to Python.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
> 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..